A founder’s-eye view of when AI actually speeds up engineering, when it doesn’t, and what that changes about who you hire.

If you’re investing in developers to deliver features with AI support , consider this: teams heavily using AI have seen pull request review times increase by nearly 91%, according to Faros AI, based on data from more than 10,000 developers across 1,255 teams. While coding itself has become quicker, the actual work – the working software that meets your requirements – has not improved.

In my experience leading an engineering-focused company, I’ve observed this shift firsthand. Two years ago, a feature might take a developer a full day, involving hours in the editor, line-by-line debugging, and repetitive setup code. Now, the same task might involve a developer spending an hour specifying the requirements, running three AI agents against those instructions, and then dedicating the rest of the day reviewing and interpreting the results. This isn’t less work; it’s different work, and for those hiring or managing engineers, it alters what you should be compensating.

This isn’t about overhyping AI or claiming it solves all problems. It’s about addressing the common question I get from fellow founders: when does AI genuinely accelerate my team, and when am I deceiving myself?

What Actually Changed

Over the past twenty years, turning a business idea into functional code was the most costly part of software development. Now it’s much cheaper. Modern AI models can produce a first draft of code in minutes. What once required a full day of typing now only takes about an hour of setup plus a quick initial draft.

Sean Grove from OpenAI has pointed out that coding itself accounts for only 10 to 20 percent of an engineer’s value. The remaining 80 to 90 percent, he argues, involves structured communication: precisely defining what needs to be built and describing it clearly enough for correct implementation. Even if you don’t agree with his exact figures, the trend is clear. Much of what you’ve paid developers to do was never just about writing syntax.

In reality, engineers now spend more time writing clear specifications and reviewing AI-generated code against them than writing every line manually. Some teams go further, making the specification the ultimate source of truth, with generated code considered not directly editable. Most teams fall somewhere in between. Regardless, the key point is that the real effort and cost now lie in expressing intent and verifying outcomes.

When AI Actually Speeds You Up, and When It Doesn’t

This is the key question for your budget and timelines, and the honest answer depends heavily on what you’re building and who you’re building it with.

For simple, new projects, the evidence is positive and clear. In a controlled study where developers built a basic HTTP server from scratch, those using an AI assistant finished noticeably faster. Another field experiment with nearly five thousand developers showed that the number of merged pull requests increased by about 26%. If you’re creating something new – like a landing page, a basic internal tool, or an initial feature – AI assistance is very likely to accelerate delivery.

However, in large, existing systems maintained by experienced engineers, the situation is different. A study by METR tracked experienced open-source developers working on large, mature codebases with millions of lines of code, and found they were 19% slower with AI help, even though they believed they were about 20% faster. The difference between perceived speed and actual speed is something a founder should consider before trusting status updates. METR later revised this study after discovering a sampling error, so treat it as an important signal rather than a definitive conclusion.

Both results reveal a trust issue worth understanding before relying on AI-generated work for customer-facing projects. Currently, AI co-authors a significant portion of production code industry-wide, yet 76% of developers report frequent hallucinations and low confidence in AI-written code, according to Qodo’s 2025 State of AI Code Quality report. The gap between delegation and trust can hide hidden costs. Time saved during coding often results in costly, tedious audits later.

A practical rule I follow when someone claims a project shipped thanks to AI quickly: determine whether it was a small, self-contained new task or a change to a large, existing system your business relies on. For small projects, trust the speed claim. For larger ones, question what was verified and by whom before accepting the claim.

What to Look for When You’re Hiring or Evaluating Engineers

If typing speed and syntax memorization mattered less than you think, then screening for them matters less too. A handful of skills have become disproportionately valuable, and none of them shows up on a typical resume filter.

• Architectural thinking: can this person decide how a system should be structured, not just implement a piece of it?
• Requirements precision: can they take a vague idea like “we want it to work like X” and turn it into something specific and testable?
• Verification and judgment: can they tell you honestly whether an output is actually correct, not just whether it passed an automated test?
• Context engineering: do they know how to hand an AI system the right background and constraints so it produces something usable on the first or second pass, instead of something that technically matches the words of the request?
• Orchestration: can they run and coordinate several AI workstreams on different parts of a project at once, without losing track of what each one actually did?

None of this means the older skills are worthless. A developer still needs enough fluency in code to catch a wrong answer, because you can’t evaluate what you can’t read. It means raw speed at producing code is no longer the differentiator it used to be, and a hiring process still built around it is measuring the wrong thing.

Who Owns the Mistake

Here’s what remains constant, no matter how advanced tooling becomes: the person approving the change is responsible for the outcome. You can’t hold an AI system accountable when things go wrong in production, nor can you renegotiate client relationships with it. A human must be able to explain and justify what gets shipped.

This directly impacts your budget. If your team produces significantly more code, review and verification are no longer optional overhead – you can’t cut costs there – they are now the main bottleneck. A plan that relies on AI drafting initial versions but ignores the need for thorough review isn’t faster; it’s a plan with an unbudgeted, hidden step, often revealing itself at the worst moment – during production, in front of a customer.

I was wrong about this two years ago. I believed that once a team mastered writing good specifications, verification would become mainly unnecessary. That was only partly true. Even Guy Podjarny, a leading advocate of specification-first development, has shifted from using “spec” to “context”. Natural language is inherently too ambiguous for complete reliance without meticulous checking, and future models won’t fix this because it’s a language property, not a flaw of the tool itself.

What This Means for Your Hiring Plan

This shift has both unsettling and reassuring aspects, and both are accurate. The unsettling part: the number of entry-level engineering roles at highly AI-driven companies is decreasing, while demand and compensation for architecture and AI expertise soar. If your hiring plans rely on a large pool of junior developers for routine tasks, it’s worth reconsidering. The reassuring part: similar patterns have occurred before and defied expectations. For example, compilers were expected to enable analysts to code independently, and CASE tools aimed to eliminate developers. Yet, none of these forecasts fully materialized. Instead, they reduced the need for hand-coded assembly or redefined roles into platform engineering. The key takeaway: don’t interpret this shift as a reason to cut engineering investment. Instead, invest more in strategic, architectural skills and recognize verification as a core, planned expense.

Five Things I’d Do Differently This Quarter

• Stop hiring engineers based solely on their knowledge of syntax and logical thinking. Instead, prioritise architectural thinking and the ability to articulate requirements precisely. Ask candidates to explain how they will verify AI-generated output, not just how they will produce it.
• Factor verification time into every estimate involving AI-generated code as a planned expense, rather than treating it as a potential cost-saving area.
• Do not frame industry shifts in terms of “AI replacing developers” or “AI saving us time and money.” Historically, every such innovation has raised the bar for engineering skills rather than eliminating the need for engineers altogether. Plan your hiring and expectations accordingly.

The developers you hire today are specialists in architecture, security, and articulating and verifying logic. They must be able to precisely define what needs to be built and – based on evidence – determine whether the result meets those specifications. These hiring criteria differ from those of three years ago, as do the associated cost factors.