Technical, cognitive, and intent debt
51–60 of 103 posts
Re: Technical, cognitive, and intent debt
#52This is my current visualization of the problem: https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU... I think the "cognitive bottlenecks" in software engineering live between artifacts, where code is simply one of them. outcome → requirements → spec → acceptance criteria → executable proof → review I'm making experimental tooling that automates the boring parts around those transitions, while keeping human…
Re: Technical, cognitive, and intent debt
#53This is my current visualization of the problem: https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU... I think the "cognitive bottlenecks" in software engineering live between artifacts, where code is simply one of them. outcome → requirements → spec → acceptance criteria → executable proof → review I'm making experimental tooling that automates the boring parts around those transitions, while keeping human…
cool dataviz but it's editable! trying to pan and zoom and scoll on my phone led to moving elements around on the canvas
Here's image you can open on the phone https://pbs.twimg.com/media/HGjHvSsWIAAkhHL?format=jpg&name=...
I also did a post explaining reasoning behind this diagram: https://x.com/br11k_dev/status/2047105958451507268
But I'll make a proper post on HN once I have all ingredients ready!
- Minimal CLI tooling
- Jupyter Lab you can go through step by step, on example greenfield project (URL shortener app)
- Blog post on what I've been doing for last 2 months
Re: Technical, cognitive, and intent debt
#54Re: Technical, cognitive, and intent debt
#55Unfortunately large parts of the paper that he linked to from the Wharton school is entirely AI generated, and yet to be peer reviewed. I realize that most researchers use AI to assist with writing, but when the topic of your paper is "cognitive surrender", I struggle to take any content in there seriously.
Re: Technical, cognitive, and intent debt
#56This is my current visualization of the problem: https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU... I think the "cognitive bottlenecks" in software engineering live between artifacts, where code is simply one of them. outcome → requirements → spec → acceptance criteria → executable proof → review I'm making experimental tooling that automates the boring parts around those transitions, while keeping human…
I like the "between artifacts" framing. One layer I'd add is proxies/metrics. In a lot of analytics-heavy systems, the real loss isn't spec -> code, it's question -> proxy. Once the proxy gets baked into acceptance criteria, dashboards, or evals, people optimize that and gradually forget it was only a proxy.
I'm kidding. But yes, I explicitly didn't model it yet. The bigger vision is there's a reason for Spec to exist, right?
And that would be Outcome.
> "We observed that users share 100+ characters long links too often and they are frustrated when it doesn't work / crop / browser address bar limitations"
So the outcome is: "Users no longer have to worry about long URLs". And then you have idea, a spec: "what if we let them create and use short URLs for sharing?" -> URL shortener app.
And yes, this ERD is easily expandable. I'd rather not add more fields but keep the "core" schema short and nice.
Things like outcome, observations, analytics, they can be simply extra tables linking to Spec, ACs, etc. Jira tickets, Datadog dashboards, Tableau analytics, whatever makes sense to teams. And it doesn't require you to setup a postgres instance. MVP would run on sqlite3.
I also seen a lot of effort trying to link different systems together specifically for simpler context access for agents. "RAG enterprise intelligent search" it is.
What's concerning to me is that even Sourcegraph haven't thought about what I'm thinking since 2015: linking specs to code directly, via SCIP. I should be able to press a button "find specs", in addition to "find references" and "find implementations". And I strongly believe they are sitting on a gold mine right now.
From my experience, it all comes down to code, and so code was the first-class artifact for a long time. Up until I realized that code is only a lossy representation of the spec artifacts. And if nobody ever records spec as an artifact...
What I'm saying is that the pain is real, I've been here for a long enough time. And I should be able to at least use something like this even if the industry doesn't want to.
Re: Technical, cognitive, and intent debt
#57Where's the other half of the article? What an abrupt ending...
Re: Technical, cognitive, and intent debt
#58Unfortunately large parts of the paper that he linked to from the Wharton school is entirely AI generated, and yet to be peer reviewed. I realize that most researchers use AI to assist with writing, but when the topic of your paper is "cognitive surrender", I struggle to take any content in there seriously.
Good thing I didn't read it but used an LLM to summarize it for me!
Re: Technical, cognitive, and intent debt
#59LLMs don't lack the virtue of laziness: it has it if you want it to, by just having a base prompt that matches intent. I've had good success convincing claude backed agents to aim for minimal code changes, make deduplication passes, and basically every other reasonable "instinct" of a very senior dev. It's not knowledge that the models haven't integrated, but one that many don't have on their forefront with default s…
You should go get attention at conferences. You could write a book called Practical LLM Coding
Re: Technical, cognitive, and intent debt
#60Earlier quoted context omitted.
You should go get attention at conferences. You could write a book called Practical LLM Coding
Do you think O'Reilly would still put an animal on the cover?