In short: AI hasn’t eliminated the software engineer’s job, it’s inverted it. Writing code used to be the job; now AI makes writing fast and the real work is design judgment, code review, and understanding what’s actually shipping. Skip that thinking at the point of generation and it doesn’t disappear, it resurfaces later, under worse conditions. At Fundbox, our answer is to reinvest the time AI saves into deeper design review and broader ownership, not just faster shipping.
A few months ago we were partway through a high-stakes go-live for an important partner integration. It went well in the end, but there were some painful stretches from hitting edge cases that only surface under real conditions. That part isn’t especially unusual. What made this one notable was that diagnosing it took longer and proved more challenging than it should have. When we finally sat down to trace the issue, what slowed us down wasn’t the problem itself. Instead it was the fact that we were working with code we hadn’t fully grokked as a team, because we had leveraged AI agents to write it.
That experience drove home for me how much the daily experience of being an engineer has changed. Think about what a good day looked like two years ago: headphones on, deep in a single module, writing code for most of the day. Design and review were the bookends, but the writing was the job. Today it is almost exactly inverted. The writing is the fast part now, because AI does so much of it, and the day fills up with everything else: what to build, why the system should be designed this way, whether the diff in front of you is actually right.
It would be easy to look at that shift and conclude the thinking got easier, but I don’t think it did. The critical thinking it takes to ship correct, maintainable software didn’t disappear when AI took over the typing. It moved. And if you skip it at the point of generation, it doesn’t vanish. It comes due later, bigger, and usually at a worse moment. That is more or less what happened to us. The thinking that should have gone in up front got deferred, and we ended up doing it later, under more pressure than we needed.
Making software is not a spectator sport
This isn’t just a Fundbox story; it turns out to be an industry condition. A design engineer at Notion gave a talk this summer that resonated for me about how understanding is the new bottleneck.fallback mark The point is that once agents start landing fifty-thousand-line pull requests, the old way of staying on top of a codebase, reading it line by line, stops scaling. Delegate without comprehension often enough and you rack up what he calls cognitive debt: you slowly become a spectator to your own software.
One concern is the creative side: without understanding, you can’t have the next good idea. This is true of course, but I worry about the unglamorous side: you can’t debug at 2 a.m. what you never understood in the first place.
Is AI-generated code actually making developers faster?
Everyone is counting the code that gets produced but not the code that gets thrown away
Predictably, the industry is mostly celebrating the volume. Microsoft says AI now writes as much as 20% to 30% of its code. Google puts its number north of 25%, with some internal repos already past half. Meta is betting that within a year, AI does roughly half of its development.fallback mark Those are the figures that make the headlines.
The figures that don’t make the headlines sit on the other side of the ledger. In a controlled trial, the research nonprofit METR had experienced developers predict AI would make them 24% faster; afterward they felt about 20% faster, but were measured 19% slower.fallback mark The code shows the same strain. GitClear, sifting hundreds of millions of changes, found duplicated code climbing, refactoring falling off, and the share of code rewritten within two weeks of a commit roughly doubling; Google’s own DORA research ties heavier AI use to less stable releases.fallback mark And in a Fastly survey of nearly 800 developers, close to a third said fixing AI’s output ate up most of the time it supposedly saved.fallback mark That gap, between what we measure and what we actually pay for, is the whole story.
Our view at Fundbox: Reinvest the time and effort saved
How do you navigate this landscape? The natural impulse—the “tokenmaxxing” route—is to view this as a temporary deficiency in intelligence that the next frontier model will resolve. The prescription is always more: more autonomy, more agentic layers, more infrastructure to manage the infrastructure. There is merit to this, of course. Models are evolving at a breakneck pace, and we prioritize staying at the edge of that curve at Fundbox. But even the most sophisticated systems don’t absolve you of the responsibility to comprehend your own output; they merely shift the locus of that understanding.
Push that reasoning to its logical conclusion and the boundary becomes clear. If a system reaches a point where human comprehension is truly optional, the role of the engineer ceases to exist. The profession doesn’t become easier; it evaporates. We are not at that horizon yet, nor do I expect to see it anytime soon.
What we currently possess is a massive productivity dividend. Producing the same volume of work now requires significantly less cognitive load per line of code. This dividend offers a fork in the road: you can either pocket the savings or reinvest them.
Pocketing it looks like coasting and letting the agent generate the code while you step back from the surrounding architecture.
Reinvesting it means holding the level of effort constant but redirecting it toward higher-leverage activities. It means more rigorous design critiques. It means reading pull requests with genuine intent. It means utilizing these tools for maintenance and quality, not just raw production. Most importantly, it means using that saved time to expand the scope of what you own. It is the same standard of excellence, applied to a larger map.
"You can choose to pay the cognitive tax now, by design, or pay it later, with interest, during a post-mortem."
That was the takeaway from our integration. We reached the finish line, but we paid a premium because we had to claw back the understanding we should have established at the start. The intellectual work is a fixed cost; we now aim to pay it upfront, on our own terms.
The title of engineer remains secure because as long as software requires understanding, it requires people. But the day-to-day reality of the work has already shifted beneath us. The challenge is that this pivot isn’t equally easy for everyone. Some have defined their careers by the very skills currently being commoditized, while others are entering a field without the foundational experience to know where their focus should land. These two archetypes are facing very different futures, and that is where I want to turn next.