Today, as hyperscale engineering becomes the norm, the numbers emanating from the front lines are staggering – yet they are concealing a crisis. At Google, Alphacode has been able to create more than 75% of the new code. Amazon recently transited 30,000 production applications from Java 8 to Java 17, which is estimated to save 4500 developer years, and it took just few months. We believe by the end of 2026 AI agents will be able to work at the level of senior engineers.
The rub is: fast is not necessarily good. Engineering teams are reporting greater bug count, security incidents and technical debt compared to what it was 2 years ago. This is "Code Overload. It's a lack of understanding of costs at the core of it. AI has made the Decision Cost of software skyrocket, as checking, auditing and joining in the non-deterministic – sometimes “hallucinated” – software output has become much more expensive, and the Construction Cost of software has been greatly reduced.
My whole journey has been as a Developer Experience (DX) strategist and my aim has always been to try and get the message out there that technical excellence is a by-product of a human centric system. In this new world, DX is no longer the "nice to have" luxury, it's necessary infrastructure to take the leap from "vibe coding" to professional orchestration.
Moving from Writer to Orchestrator
The transition to an AI-native engineering culture requires a fundamental shift in identity. Andrej Karpathy’s "vibe coding", where non-engineers build software by simply describing desires, is a valuable democratisation of the craft, but it is not professional engineering.
Professional AI native engineering is all about commanding AI systems. Before AI tools can even start to be effective, it is essential to have a strong base of high quality DX. To break through this we need to turn to The Four Core Practices:
- Synchronised Context Engineering: This is the "USB-C for AI." It involves the systematic curation of architectural diagrams and coding standards into AI working memory. Tools like Anthropic’s Model Context Protocol (MCP) and the use of CLAUDE.md files are no longer optional; they are core infrastructure.
- Specification-Driven Development: Defining clear success criteria and milestones before an agent executes. If you provide a vague prompt, you receive a vague architecture.
- Critical Verification: Treating AI output with the scepticism of a senior auditor. Research shows 45% of AI-generated code contains security flaws. The bottleneck has shifted from writing logic to proving it works at scale.
- Problem Decomposition: Breaking complex tasks into manageable chunks to prevent "context pollution," where the agent drifts into circular reasoning.
"Real productivity gains come when engineers decide to make the leap from writing code to orchestrating it."
The 'Psychological Safety' Pillar
When engineering culture is unable to challenge the machine, automated tests can be a false god. But technical safety nets like CI/CD are simply not sufficient without a social safety net that allows developers to safely buck the trend of AI "slop.
Part of my mission is to show that culture is the best compiler around. But when the developer realizes there is something wrong with the PR created by the AI, but doesn't—and this is where the entire situation goes astray—that's where the team's emphasis on “velocity” over “validity” is problematic. Psychological safety is the “bread and butter” of effective teams and is made up of three pillars:
- No Blame: Treating AI hallucinations as learning opportunities for the AI not just the individual hallucinator.
- Openness: All team members are listened to regarding ideas, particularly when an idea is to reject an AI's suggestion.
- Collective Decision-Making: changing the form of liability from individual to collective "ownership" of the "agentic" product.
Generally the more time you spend, the more you do.But, in general, work and time are proportional to each other - the more time, the more work.
The Productivity Paradox (Satisfaction vs. Time)
A BNY Mellon study uncovered a startling gap that confirms my "Decision Cost" thesis. While developers feel faster, the clock tells a different story.
| Metric | Findings |
|---|---|
| Perceived Value (Satisfaction) | 86% are satisfied. AI reduces initial friction and keeps developers "in the flow." |
| Actual Velocity (Time Savings) | 60% report saving less than one hour per week. |
This paradox is due to the fact that the time saved in writing it is immediately utilized in the verification of the new tax. Further, there is a "danger of over-confidence. A study conducted by Stanford University showed that the AI assistants led to less secure code but more confidence in the security of the code. A lot of satisfaction is there, since there is no more hard part (typing) and the dangerous part (auditing) is an “invisible timesink”.
Defining DX for the AI Age
In the Greiler/DX Framework DX is: "Being empowered to do my best work, joyfully. In the AI age we need to look at it in the "Trilogy of the Mind":
Cognition: AI-native engineering is cognitively very demanding. It is no longer possible for them to depend on the base codebase; this has to be continually reassessed in an alert manner. This cognitive load can generate an “Engine of Decay” (affect). Constantly verify in order to frustrate and cause anxiety (Affect). Conation: This frustration can result in the loss of the developer's "Conation", which is his or her desire to value quality.
It's often a Coping Mechanism when the attitude of the organisation is to try and manipulate the system to make the estimates appear larger and thus give themselves more time to get a good job done, or to disengage from the roadmap and eventually walk out.
Ownership and Expertise are the Long-Term Trajectory.
In 2026, the ‘domain knowledge' is what ‘Engineer' will be all about, not ‘syntax'. There are two main risks that we are facing:
- Skill Atrophy: Do not take things for granted all the time, we don't want to lose the skill of analysing stack traces.
- Slopsquatting: Imagining the name of nonexistent packages; a terrifying new attack vector. Then, attackers sign up these names with malicious code, which then is recommended by the AI to the careless developers.
Strong deep expertise in maths, science, finance or law is the differentiator for the “Engineer of 2026”. The boilerplate is handled by AI, but retaining, eliminating, how and when is still a function of the human.
From SDLC to ADLC
Movement towards an Agentic Development Life Cycle (ADLC) from Software Development Life Cycle (SDLC). In this new world the human is the Architect of Context, not the Writer of Logic.
Design to 50%: build product with AI (v0, Replit Agent) to get to minimal functionality quickly, uncover the real product issues and fail quickly. This will help us to shift the focus from execution management to speeding up learning.
AI-native process optimisation is not about people, it's about better decisions. In an era where AI can write the code, are you building a culture that knows why the code matters?