I came across a post on X recently that has been stuck in my head.
An engineer who had just joined a large company described what software development looked like on their team now. According to the post, Claude Code was being used for almost everything: specs, code, tests, PRDs, tickets, bug resolutions, reports, and the rest of the work surrounding them. The strange part wasn't that the team was using AI heavily. What bothered me was the claim that nobody was actually reading much of what was being produced. Engineers were apparently being pushed to ship as much as possible, while still being expected to remain accountable for the result.
Original post: https://x.com/v0xium/status/2101526107128529120?s=20 The author described people working 12–13 hour days while essentially sitting in front of an AI agent and pressing enter. You can disagree with parts of that story, and I don't know whether it represents every large engineering organization. But the reaction to the post was interesting. A lot of people seemed to recognize something familiar in it: AI has made producing software dramatically faster, but the human side of software development hasn't necessarily sped up at the same rate.
That made me wonder: what happens when we make writing software faster than we make understanding software?
For a long time, writing code was the obvious bottleneck. A developer could spend half a day implementing a feature, writing tests, fixing syntax errors, looking up documentation, and getting everything into a shape that could be reviewed. AI has removed a huge amount of that friction. Today, an agent can take a reasonably described task and produce an implementation across multiple files in a fraction of the time. But the code is only one part of the job.
Someone still has to understand whether the implementation matches the actual requirement. Someone has to notice when a seemingly reasonable decision conflicts with the rest of the system. Someone has to think about the edge case that wasn't mentioned in the prompt. Someone has to investigate what happens six weeks later when a user does something nobody expected.
That work has always existed. AI just makes it possible to produce the part before it at a much faster rate.
And that creates a strange new bottleneck.
Maybe the limiting factor in AI-assisted software development isn't how quickly we can produce code. Maybe it's how quickly humans can build enough context to trust it.
This is also where the idea of accountability starts getting uncomfortable. If an engineer is given enough time to understand, review, test, and challenge an AI-generated change, then saying “you own the code” makes sense. But what happens when the organizational expectation is simply to keep shipping? If the machine can generate hundreds of lines while a human barely has time to look at the diff, accountability starts becoming more complicated.
The irony is that AI can actually make this problem harder to see. A generated feature can look finished. The tests can be green. The pull request can be neatly formatted. The ticket can move to “done.”
But software has always had another layer underneath the visible output: the reasoning.
Why was this architecture chosen? What assumptions does this implementation depend on? What happens when the database is slow? What happens when the API returns something unexpected? Why does this code exist in the first place?
Those are the things you usually discover when something breaks.
And that is why I don't think the biggest risk of AI coding is simply “AI writes bad code.” We've always had bad code. Humans wrote plenty of it.
The more interesting risk is that AI can make the process of producing code feel so productive that we start treating output as evidence of engineering.
It isn't.
If an AI agent can produce code ten times faster, should the expectation really be that engineers now ship ten times more?
Maybe the better use of that extra speed is to give engineers more room to investigate, review, test, redesign, and think about the things that used to get squeezed out by deadlines.
I'm not against AI coding. Quite the opposite. I think we're going to use more of it, not less. But I don't think the goal should be to remove the human from the development loop. The goal should be to remove the parts of development that waste human attention while preserving the parts where human judgment actually matters.
Because if we end up with AI generating the code, AI generating the tests, AI reviewing the code, and humans simply approving whatever reaches the final screen, then the interesting question isn't whether AI replaced the programmer.
It is whether we accidentally replaced engineering with throughput.
For me, that is the distinction that matters. AI should take more of the implementation burden, but engineers should still have the time and control to understand what is being built and decide what actually ships. That's also the idea behind what we're building at LatentForce: AI should handle more of the work without taking the engineering out of the process. I shared this thought from the LatentForce account here:
https://x.com/LatentForceHQ/status/2102071006869459169 The future of AI-assisted development shouldn't be about humans pressing enter faster.
It should be about humans having more leverage to build better software.