The time taken to write code has dramatically sped up. But now the issues are shifting towards other parts of the SDLC. How do we actually make sure that we're turning that into [[20220509010256-engineers-business-value]], and making sure we're producing maintainable code.
In general this is where I'm most skeptical about AI as a whole. We don't have much information on people leveraging AI in large codebases over time. It's really good for greenfield and generating things from scratch, but Im still less convinced (and practiced) on how it deals with maintaining a codebase.
[[20260601032608-vibe-coding-dangers]] and [[20260625012124-ai-code-review]] provides a summary on how to evaluate how much you you can leverage vibecoding for a particular use case, but there's still a broader shift at play. A shift away from writing code, and a shift towards managing codebases, knowledge, and [[20260318091849-ai-context-tokens]].
[[20260625104409-comprehension-debt]] talks about ensuring that you need to understand the code that's being written too. You can't just let AI create everything and then trust it, as you'll accrue an invisible debt that becomes impossible to pay down.
[[20260625121144-loop-engineering-ai]] and [[20260604045417-ai-software-development-loops]] talk about the human involvement required in more complex AI loops. Ensuring that there's a human responsible for certain parts.
https://vercel.com/blog/agent-responsibly shares a similar sentiment about the responsibilities a human has when vibe coding. It advocates for improving the orchestration and infrastructure around AI, improving things like deployment strategies, automated rollback, [[20221117105511-canary-release]], etc.
The gap between "this PR looks correct" and "this PR is safe to ship" has always existed. Agents widen that gap by producing code that looks more flawless than ever, while remaining entirely blind to production realities.
As such, it's equally (or even more important) to read the instruction-related code and information for your AI agent than the code itself. Using tools like [[20260413103002-ai-compound-engineering]] relies on the compounding step producing accurate information. It's not just noise, you have to read it. [[20260612022142-ai-plan-first]]
Even Statsig shares a similar sentiment (https://amplitude.com/blog/amplitude-and-statsig-partnership):
While teams can generate more code than ever before, the software development lifecycle remains bottlenecked in many other places. The challenge is how to evaluate code before it’s released, how to track what’s working after release, how to know what to roll back and when, and how to turn those signals into what to build next. AI builders can’t do that today, so they are generating code faster than they can understand its impact or measure its efficacy. That’s the problem Amplitude and Statsig are solving together.
https://martinfowler.com/articles/exploring-gen-ai/13-role-of-developer-skills.html points out some long term qualms I've also found. Things like writing verbose yet meaningless tests, patching issues instead of doing [[rootcauseanalysis]], etc.
As of 2026, I found that a lot of my time is shifting towards review and orchestration, and that side hasn't caught up. It's a little less exciting than generating something new and shiny, but it's more important. It's the maturity part of software development.
There's a struggle where DORA metrics incentivise shipping faster, but have no metrics around understanding code. There's no metric for the health of the code, but there are a lot of metrics for getting things to production. How does an engineer balance increasing DORA metrics, writing code faster with AI, reviewing all of the AI created code, getting AI to review the code, understanding the AI created code as a human as we're responsible for it, etc. There's a lot of juxtaposing goals that don't really fit together. It even relates to [[20220509010256-engineers-business-value]] - are we prioritising quantity over quality?
[[20220627113555-software-development-lifecycle]]