Posted by dhorthy 4 hours ago
> # We tried this > In July 2025 we went full lights-off
Isn't it pretty well-accepted at this point that the models underwent a step-change in usefulness around fall 2025 / spring 2026? I know that I was able to start handing agents whole features after that, but not before.
I feel like any perspective/experience on "what agents can/can't do" from before that period is... maybe less than relevant to the modern era. TFA calls it out a few sections later with "But surely the models have gotten better since then", but then just writes off any improvement. That does not match my experience.
They still are far from perfect but they're massively helpful.
For instance I think their post "long-context isn't the answer" on their website post straight-up isn't accurate, and gives me the impression they are just extrapolating previous performance to new models. In my experience, Opus 4.6 and newer have worked very reliably for long context to me (i don't perceive any intelligence drop at 700-900K tokens). Yeah it's extremely cost-inefficient, but it works.
>I was pretty excited for a world where we could just ask for things and let the models cook and not read the code and get beautiful production software
I feel so disconnected reading those things. Reading and writing code is what brings me joy. I'd never feel "bummed" or "stuck" with it.
Yes, in an ideal world, PRs read well, are a joy to review, reflect what you discussed etc etc. We have to be real; there is only so much we can do to that end.
I'm not sure how the best teams do PR review, from my perspective it sucks. I'm talking specifically about the UX. I've always hated Github's PR page, so I typically reviewed by pulling down the branch and opening the diff with $EDITOR.
These days I think there's really no excuse for the awful UX. Linear (a company that isn't even in the domain of code review) put out a basic PR review feature[0] that is already better than what GH offers. It's simple: point a small model at the PR, group file changes together based on theme, add some commentary and sort by importance (schema changes > openapi spec).
Immediately, so much mental load has been reduced without the reviewer or the requester doing anything. This feature is pretty damn basic, and I think there are obvious next steps like generating visualisations which a dedicated product could find the time to implement.
Keen to hear others thoughts on why this is the wrong approach, or if there are tools in wide use that solve for this, or why this isnt the right problem to focus on.
Isn't that what commits are? Or ... should be?
I think all these platforms chasing code review are doomed. My LLM doesn't need any of this tooling.
We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code).
The future of software production is more like Replit – not GitHub.
QA?
Software systems are like gardens (or owning a pet) - they need to be tended to, and somebody needs to know how they work. Software is not an artifact that you "make" and don't come back to until years later when it needs replacing, like a paved street.
Software development is not a "task" like designing a logo, it's a continuous operational undertaking.
This is also known as being a terrible engineer. If a company enforces human review and someone deliberately tries to circumvent this with an LLM, I'd fire that person in an instant
The reason for human code review is:
1. So *you* understand what's going on, not the LLM, and people can ask you questions about it
2. Because LLMs are not that good at code review
It seems weird to brag about literally not doing your job. It sounds like you could be replaced with a python script, what value do you bring?
I can't help but notice that this person is speaking as a programmer, not the person in charge of employing programmers. Is that what the business values code review for? In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid. And LLMs are already better than human reviewers at the "Find Bugs" part. Design and alignment with PMs and sales can happen before and after software delivery. At least that's how my employer sees it (and I suspect most other businesses).
It's a rough time to be a programmer who cares about the code, who understands software is a creative process, who understands that designing the software is intertwined with the code, who cares about systems. The hyper-focus on delivery was already a lot to deal with before LLMs.
Also, it's not just some subjective value put in human review. If a change causes a major outage and it turns out it's because 5 reviewers were all shirking the company-mandated responsibility of review, and it could trivially have been caught, I would 100% expect those people to get fired. It's not a process issue if people are intentionally circumventing the process.
I tried experimenting with what is ultimately a treesitter based approach - https://github.com/0x007BA7/codebook
And really liked it. Definitely nowhere near production ready but I think theres room for a player to come in and do something similar.
When $EDITOR = VSCode there's a shortcut on the GitHub PR page: if you type a . it opens in github.dev in a VSCode instance.
[1] - this course: https://www.coursera.org/learn/machine-learning/home/welcome
If you think you can just assign Github tickets to AI agents and go drink daiquiris on the beach I think you'll find that you end up with more and more towers of abstraction and indirection. There are 'points of view' that emerge during coding I think. And at some point you as a human have to be like "wait... what if we use Redis here". "Wait.. the API is already returning the data we need". "Wait... let's not add customers to the report who have not been active in the past year". Stuff like that
I know it’s a bit cliche at this point, but this harkens to “programming as theory building”[0] which I agree is easy to lose out on when embracing agentic coding today.
- claude code plan mode - mattpocock/skills - obra/superpowers - research/plan/implement
etc etc
Rather than “lights off,” utilizing information theory, decision-making theory and creativity theory makes me better at asking for the right things.
Memory is not transcribed to weights like when humans sleep. Memory is notes handed to someone on groundhog’s day who can’t remember yesterday. We hope they believe us. Don’t be too surprised when a highly entropic system introduces entropy to a project over time.
but yes if you're working in very small slices then I think it's very feasible to skip program design and just review the code as you go, and resteer live. I do this all the time for tasks that are too big for a oneshot but on the smaller side overall.
I feel like the explanation does nothing to actually elucidate why models can't do it. Is it an inherent weakness of LLMs? Training processes? The typical "this is crap" that we constantly hear? It goes on to write about RL and how there's no penalty for bad design. But that sort of side-steps the question and makes you ask: "why not do RL and make a penalty for bad design?" Of course the models aren't good at it ... they're not good at anything until you've tuned them and put them in a harness that rewards good edits and throws away (improves) bad edits. That doesn't explain why "models can't do software maintainability." The real question is why harnesses can't do software maintainability, and how to build a system that can do it. (I suppose that's the purpose of the ad at the bottom of the page.)
Design skills take about 10 years to develop, in my experience, and a lot of smart engineers go through a phase where they make gawdawful messes in the name of “magically easy” designs around the 5 year mark.
Design requires wisdom born of experience, isn’t measurable, and requires forming a mental model of how the system hangs together as a whole. It’s just not stuff LLMs are good at.
My current evolving take on "how would you build such a thing" is you need to tee up a roadmap of 20 features and feed them to a model one at a time, so it can't design up front for what's coming.
That way if it builds the first 10 features and the codebase goes to slop, it get's penalized when it can't build features 11-20, or when those features take wayyy more tokens/time/cycles than a model that maintains a clean codebase can do.
This is how most real software is built by most teams - incrementally, getting feedback from users along the way, and steering goals in response.
I don't know if it's a question of how many features to feed to the model, either. Of course, overwhelm the context with too many features and it will get confused. But that's where the memory management idea that G. Huntley talks about is helpful. You're trying to steer the model within its memory limits towards a certain goal.
The problem is getting it to produce "good" code. Formalizing what that means is the task of the programmer. How do you steer a model towards always, or more often, producing good code so that you don't have to do rework? That's the same problem as with a junior engineer, but the way you do it is different. Right now we're trying to do it with mountains of prompts — which sort of works but has diminishing returns — and with onerous code reviews. We've seen this get better over time, but I think some more mechanical methods will help as we figure out how best to steer the models.
a lot of the model's constraints come down to how they are RLed. Discussions online would be a lot better if everyone understood how the labs train the models in a high level (or did a lil data labeling)
It works quite well, as it puts your entire focus on writing (hopefully) unambiguous specifications vs. having to discuss unwanted changes with an LLM during code-review. One flaw is that this only works great if you know exactly what you want, which is not always the case.
Code is just detailed specifications on how things should operate.
It turns out that there are now a few more people that want to get their hands on building software, that don't necessarily understand code, but do have a fundamental idea of system design / requirements.
As you said code has always been a much more explicit representation of those specs, yet arguably introduces lots of noise, necessary to make the program compilable.
Us devs already had the obligation of writing technical documentation for non-technical people, just not at an explicit depth. From an efficiency PoV making that documentation more explicit is much cheaper than manually writing the compilable code. Hurts to say but AI got pretty good with the latter.
Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.
yes exactly - this is what I'm advocating for - that you can't skip the system design, and that actually good system design goes down to the typedefs and object graph at the code level, not just mermaid charts and db schemas and service contracts.
I will highlight what a few others have said along the lines of "a sufficiently detailed spec IS code" - that is, to make the spec guaranteed to produce the code you want, the spec will look a lot like code (and will be roughly the same effort to review as the code itself anyway, saving you no time)
what I'm proposing is "how can you maximized the odds that the code WILL be good or close enough to good that its easy to get there, with the LEAST amount of human effort/attention" - how can you move fast without skipping what matters
https://haskellforall.com/2026/03/a-sufficiently-detailed-sp...
The corollary of agents being bad at maintainability but good at coding is that you can vibecode all the parts where maintainability doesn't matter.
So if you build a (domain-specific) modular architecture for your software first you can then just let your software factories loose on building the modules.
“Oh just this one time”
Then an agent sees the pattern and assumes it’s a best practice. Then your beautiful architecture is ruined.
“Just this once” indeed.
the idea that if you have a solid core and decoupled modules, you can have "zones" in your codebase where you allow the model to run wild and do a little slop, because you know the blast radius is contained