There's another reckoning already happening inside companies.
Senior leaders are experimenting with AI in their spare time, building surprisingly capable applications in an evening or over a weekend, and returning to work with the wrong lesson. They describe what they want, iterate with the model, connect a few services, and produce something that looks remarkably close to a working product. From there, it’s easy to conclude that software development has fundamentally become that simple and that internal engineering teams should now be able to deliver production systems at the same speed.
Timelines shrink, staffing plans disappear, and individual engineers are increasingly expected to handle product management, user experience, design, architecture, development, testing, deployment, and support. In some cases, all of that responsibility is placed on one person.
After all, a leader built an app over the weekend. Why should a team need three months?
Because the two things aren’t even remotely equivalent.
A prototype proves possibility
A prototype is designed to answer a narrow question: can the idea work, can the core interaction be demonstrated, and can the concept be made tangible enough to gather useful feedback? AI has made this process faster, cheaper, and more accessible. People who previously needed engineering support to explore an idea can now build something themselves, while engineers can test alternatives without committing to weeks of implementation.
That’s genuine progress, but a prototype succeeds when it demonstrates possibility. A production system succeeds when it continues working after it encounters reality.
A weekend application rarely needs to support thousands or millions of users. It may not need authentication, authorisation, auditing, accessibility, observability, data retention, backups, rate limiting, internationalisation, incident response, or disaster recovery. It doesn’t have years of accumulated business rules, nor does it need to integrate with legacy systems owned by several other teams. It probably doesn’t have contractual service levels, regulatory obligations, established support processes, or customers depending on it to run payroll, receive medical supplies, manage financial transactions, or operate their businesses.
Most importantly, the cost of failure is usually close to zero. When a prototype breaks, its creator refreshes the page, adjusts the prompt, edits the code, or starts again. When a production system breaks, customers lose trust, employees are pulled into incident response, contractual commitments may be missed, and the company may lose money.
You can build anything quickly when there are no guardrails and failure has no consequences.
The difficult work starts after the demo
AI is extremely effective at helping someone get from nothing to something. It can generate an interface, define an initial data model, create API endpoints, assemble common components, and produce enough functionality to make an idea feel real. That first portion of the work can happen at remarkable speed.
The danger is assuming the remaining work is equally easy.
Production engineering is full of details that don’t appear in a demo. Teams still need to decide what happens when two users edit the same record, an external dependency becomes unavailable, a model returns malformed or unsafe output, or a migration fails halfway through. They need to enforce permissions across tenants, manage customer data deletion, recover from partial failures, diagnose degraded performance, prepare for unexpected scale, and ensure that someone can operate and maintain the system after the original developer leaves.
These aren’t excuses invented by engineers who are afraid of AI. They’re normal production concerns. Ignoring them doesn’t make them disappear. It merely delays when the organisation pays for them, usually at a much higher cost. And the bill always comes due.
Coding faster doesn’t eliminate product development
AI can make good engineers substantially more productive. It can accelerate research, reduce repetitive work, suggest tests, identify defects, generate scaffolding, explain unfamiliar code, and help engineers explore several implementation paths before choosing one. Engineering leaders should expect teams to adopt these tools thoughtfully and should challenge them when they refuse to engage with capabilities that could materially improve delivery.
But faster coding doesn’t eliminate the rest of product development. It doesn’t reduce the need to understand the customer, resolve ambiguous requirements, make trade-offs, validate the user experience, or align multiple teams. Nor does it remove the work required to ensure that a system is secure, maintainable, operationally sound, and appropriate for the organisation’s architecture. Writing code faster accelerates one part of the delivery process, but it doesn’t make the other parts disappear.
The idea that an engineer can now “do it all” confuses tool-assisted capability with infinite capacity. An engineer may be able to generate a passable interface without a designer, but that doesn’t mean the interface is good. They may be able to write product requirements, but that doesn’t mean the right customer problem has been identified. They may be able to generate hundreds of tests, but that doesn’t mean those tests validate the assumptions that matter.
AI can help one person perform more types of work, but it doesn’t guarantee that one person can perform every discipline well, simultaneously, under an aggressive deadline.
Unrealistic plans create predictable failures
When leadership overestimates the extent to which AI has changed, the consequences aren’t theoretical. Timelines are created without engineering input, assuming implementation is trivial. Teams are understaffed because every engineer is expected to produce several times more output. Design and testing are compressed because they’re treated as optional activities around the “real work” of generating code. Technical concerns are dismissed as resistance because the prototype appeared to work, while the risks are transferred to the people responsible for delivery even though they didn’t create the plan.
The organisation then acts surprised when quality falls, deadlines slip, employees burn out, or the system fails in practice.
In the worst environments, this becomes openly toxic. Engineers raise legitimate concerns about feasibility and are accused of being negative. Estimates become commitments before the people doing the work have been consulted, and teams are threatened with replacement if they can’t meet dates that were fabricated without any meaningful understanding of the system.
That isn’t an AI strategy; it’s management failure with an AI justification.
Healthy engineering organisations don’t remove the people closest to the work from decisions about how it’ll be delivered. Leadership has every right to set priorities, define outcomes, demand urgency, and challenge teams to find a faster path. Engineers shouldn’t be allowed to hide behind complexity, inflate estimates, or resist change simply because a new approach is uncomfortable.
But urgency isn’t the same as fantasy. Challenging a team to move faster is leadership. Inventing a deadline and threatening the team when reality doesn’t conform to it isn’t.
Engineering judgement matters more, not less
One of the more damaging ideas emerging from the current AI enthusiasm is that experience matters less because models can provide knowledge. In practice, AI makes judgement more important.
A model can generate several possible solutions, but someone still has to recognise which one fits the context. It can produce code quickly, but someone still has to determine whether that code is secure, scalable, testable, and maintainable. It can confidently recommend an approach that’s subtly (or overtly) wrong, and someone still has to detect that error before it reaches production.
The faster code can be generated, the faster bad decisions can be embedded into a system.
Experienced engineers aren’t valuable because they type faster. They’re valuable because they understand consequences. They recognise patterns, identify hidden dependencies, ask uncomfortable questions, and know where apparently simple changes tend to fail. A mature organisation needs to use AI to amplify that judgement, not to declare it obsolete.
The answer isn’t to slow down
None of this is an argument for preserving old processes simply because they’re familiar. Some engineering organisations are too slow. Some teams have accumulated ceremonies, approval layers, architectural rules, and testing practices that add little value. Some engineers use quality as a vague justification for avoiding accountability. AI should force organisations to examine how work gets done and remove steps that no longer justify their cost.
The answer isn’t to pretend nothing has changed; it's to identify precisely what has changed.
Perhaps a prototype that once took three weeks now takes two days. Perhaps a developer can complete a well-defined implementation in half the time. Perhaps test creation, documentation, migration scripts, and operational tooling can be accelerated. A smaller team may even be able to own a broader surface area because AI reduces the burden of moving between unfamiliar technologies.
Those are reasonable hypotheses, but they should be measured. Compare cycle time before and after adoption. Track defects, rework, incident rates, customer outcomes, and maintenance costs. Find the parts of the delivery process where AI creates durable improvement rather than a compelling demonstration, and then change planning assumptions based on empirical evidence.
Don’t take one leader’s weekend project and extrapolate it into an operating model for an entire engineering organisation.
What responsible AI leadership looks like
Leaders who genuinely want AI to improve delivery should ask where it’s already creating measurable leverage, which tasks have become substantially cheaper, which constraints still dominate delivery time, and what new risks it's introducing. They should identify where teams can experiment safely, distinguish customer protections from outdated process, and consider how roles should evolve without pretending that every discipline has disappeared.
They should also involve the people doing the work. Ask engineers to demonstrate how they’re using AI, where it saves time, and where it creates rework. Ask product and design teams how faster prototyping changes discovery. Ask security and operations teams which risks require new controls. Set ambitious goals, then allow the team to shape a credible plan.
Good leadership creates constructive tension between urgency and reality; it doesn’t remove reality from the conversation.
The real competitive advantage
The companies that benefit most from AI won’t be the ones that conclude software engineering has become trivial. They’ll be the ones that learn where AI genuinely compresses work and where complexity remains stubbornly human. They’ll distinguish prototype speed from production readiness, expect more from their engineers, and continue to respect engineering judgement.
They’ll use AI to improve talent rather than justify impossible staffing models. They’ll shorten feedback loops without abandoning quality. They’ll move faster because their systems and teams are better, not because leadership has declared that every difficult problem should now take a weekend.
Unfortunately, if you’re at the wrong end of this chain and leadership has stopped listening, there may not be a clever solution. You can present evidence, explain the difference between a prototype and a production system, offer alternatives, identify trade-offs, and propose a narrower path that delivers value sooner.
But if speaking honestly is treated as insubordination, fabricated deadlines are enforced through threats, and leadership has decided that professional judgement no longer matters, leaving for a better company may be the most rational choice.
And yes, I use the word “better” deliberately. There are few faster ways to lose capable people than to tell them, directly or indirectly, that their experience, judgement, and voice no longer matter.
AI may be changing how software is built; it hasn’t changed the fact that people do their best work when leadership respects reality.
0 comments:
Post a Comment