Software Engineering as a term was popularized around 1968, during a NATO software engineering conference. One of the main themes during the conference was "The Software Crisis." Industry leaders discussed frustrations with massive complex systems that were routinely over budget, late, and unreliable. Fast forward to the current day, and the crisis was never fully or cleanly resolved. It instead transformed into a chronic condition, managed by companies through breaking work into smaller chunks and focusing on what matters most using Agile methodologies. While machines were improving exponentially, human cognitive load and communication remained some of the biggest process bottlenecks. That is, until AI agents started effectively contributing to codebases during 2025.
AI is arguably the most profound disruption the software industry has ever faced. In a few months we went from almost completely relying on engineers to write code, to companies like Google claiming that 75% of new code is now AI generated. At Procurify last month, more than 80% of new code was at least co-authored if not fully generated by AI. We've also seen a 3x increase in throughput. With all this new potential we've unlocked, have we finally solved the software crisis?
The aha moment, and its limits
Most of us have had an "Aha" moment over the last year. We opened an AI agent in planning mode and gave it a goal. We then watched it think for a moment, and it proceeded to decompose the work into a clean, ordered list of tasks. We used to need to bring a team together and whiteboard to get output similar to this. You approve the agent's plan and it proceeds to execute, changing files, running tasks, and marking tasks as done. For a few minutes, you realize you aren't managing this project; you are just watching it execute in front of you. It's easy, and it's fast. You feel like you've acquired new superpowers, and you decide to test them out in a real-life scenario, one that has an impact beyond your own screen.
A small agentic workflow works beautifully. Treat a larger project the same way and the approach won't scale. Agentic work concentrates naturally in one place: a terminal. On a small screen that's fine, but on a sizable project it starves everyone else of context. The PM has no milestone to track, the designer has nothing to review until the work is nearly done, and code review piles up at the end instead of happening along the way. This is the trap waiting for any team that scales agents up: execution gets faster, but the coordination around it doesn't. Larger projects still need documentation and progress that every stakeholder can see. At Procurify, we now transform agentic plans into Jira stories and tasks before execution starts. The plan is visible to everyone, and the agent works inside our process instead of around it.
The multiplier trap
As agents get more capable, optimism creeps into planning. A team estimates six weeks, and someone asks whether that number accounts for agentic development. After all, AI is a force multiplier. As I mentioned, we've seen throughput at Procurify jump 3x, so surely six weeks is really less. Should we just bake that multiplier into every estimate?
Yes, but no. AI is genuinely changing how fast we ship, but you can't take a throughput number and staple it onto a project plan. Planning has been historically difficult and inaccurate because projects don't bottleneck on raw coding speed. They bottleneck on UX, design, reviews, and cross-team dependencies, none of which a code-writing agent makes disappear. That 3x is also likely skewed. A lot of it comes from tearing through small tasks and toil faster, not from compressing large, coordinated projects. Apply the multiplier to a real project and the estimate will fail, badly.
To stay disciplined, keep planning from historical project data. As we get more efficient and better at using AI, those gains show up in the data on their own, and that's when they belong in an estimate. If a migration that used to take four weeks now takes two because AI helped, you can confidently plan the next migration for two. What you can't do is assume the next one takes two because AI exists. Let the results earn the number.
Rethinking the disposable MVP
There's a flip side worth calling out. We used to sink real effort into MVPs. Yes, minimal, but never throwaway. The goal was that if an MVP proved worthy, we could build on it rather than start over, so we front-loaded design, architecture, and pattern decisions to keep that door open. AI changes that equation. When a product person can push an MVP through agentic coding with minimal engineering support, the cost of a test drops far enough that throwaway becomes the point. We can float more ideas as disposable MVPs and defer the design, architecture, and pattern conversations until one actually shows signs of life. We can spend our expensive, careful thinking only on the ideas that have earned it.
So, did we solve it?
Not quite. AI didn't cure the software crisis; it moved it again. The bottleneck is no longer how fast we can write code. It's everything around the code: keeping stakeholders aligned, planning honestly, and deciding what deserves our attention. Agents are extraordinary contributors, but they're still just contributors. The teams that get the most out of them are the ones that treat speed as a gift while holding the line on discipline, visibility, and judgment. The crisis of 1968 was about machines that couldn't keep up with our ambitions. Today the machines can keep up, and maybe outpace us. The remaining challenge is making sure our processes, and our thinking, are worthy of the speed.