Digital transformation didn't quietly evolve. It hit a wall.
Over the last two years, and especially the past one, the act of creating software has changed more than it did in the previous decade. What once felt like steady optimization became forced adaptation. AI didn't just improve the way we build software. It disrupted the entire delivery value chain.
The familiar boundaries between vision, design, development, and delivery are collapsing. What used to be discrete phases are merging into a single, continuous capability. And in that shift, many of the assumptions behind Agile, SDLCs, and team structures are starting to break down.
Our Ground Truth papers cover the lifecycle stage by stage (Rewriting the Build) and the coordination roles around it (Rewiring the Role). This essay is about the parts that don't fit neatly into either: the blur between phases, what happens to Agile, and the culture that grows up when working software is cheap.
The blur: when vision, design, and code become one
One of the most profound, and least discussed, impacts of AI on software delivery is the collapse of the boundaries between vision, design, and implementation.
For decades, software delivery relied on translation layers. Product managers translated vision into requirements. Designers translated requirements into experiences. Engineers translated designs into code. Agile shortened the feedback loops between these steps, but the steps themselves remained intact.
AI is eroding those translation layers.
Today, intent can move directly to execution. A concept expressed in plain language can become a working prototype. A design idea can generate functional interfaces. A change in vision can ripple through code, tests, and deployment pipelines in near real time. What used to be a linear flow is becoming a continuous, two-way loop.
This blur is powerful, and it's destabilizing.
On the positive side, teams are moving faster than ever. Ideas don't stall in backlogs. Designs don't wait weeks to be validated. Working software becomes the primary artifact for thinking, learning, and decision-making. The distance between "what we want" and "what we can try" has collapsed.
But the blur also challenges long-held assumptions about roles and responsibility.
- When vision, design, and code are created simultaneously, who owns intent?
- When AI can generate interfaces and logic together, where does design end and development begin?
- When anyone can produce working code, who is accountable for quality, security, and long-term maintainability?
These questions matter because AI doesn't remove the need for judgment. It amplifies the cost of getting it wrong.
The risk isn't that teams move too slowly. The risk is that they move quickly without shared understanding.
Without clear intent, constraints, and validation, speed turns into noise. Working software may exist, but coherence, usability, and trust can quickly erode.
This is where discipline re-enters the conversation. In an AI-influenced delivery model, clarity of vision becomes more important, not less. Design intent must be explicit, even if the artifacts look different. Specifications may be lighter, but they must be sharper. Review, validation, and human oversight become continuous rather than episodic.
The most effective teams won't be the ones with the cleanest handoffs. They'll be the ones that can hold vision, design, and execution in the same conversation, at the same time.
A spectrum, set per task
AI adoption isn't binary. At one end is AI-assisted development: AI reduces syntax friction, generates tests and documentation, and the SDLC largely stays intact. At the other is AI-native development: systems are conceived, built, and evolved with AI at the core, and people provide intent, oversight, and judgment.
Most organizations live somewhere in between, often without realizing it. The mistake is treating that position as a single setting for the whole organization.
In our delivery work, we set it per task. Generating test scaffolding might run with AI drafting and an engineer approving every change. Summarizing a pull request might run with review by exception. Changing an authorization rule stays with a person, with AI assisting. That's the idea behind Earned Autonomy: four levels, from Assist to Act and audit, and a task only moves up when the evidence says it should.
Does Agile still work?
Agile was a breakthrough because it replaced rigid, linear planning with learning. It assumed uncertainty, embraced iteration, and shortened feedback loops.
But Agile also assumed, quietly, that humans were the primary producers of software, and that the costliest part of delivery was coordination: translating intent into requirements, requirements into design, and design into code.
AI changes the underlying math.
When working software can be produced in hours instead of weeks, the traditional cadence starts to feel misaligned. Two-week sprints become arbitrary. Backlog refinement struggles to keep pace with execution. Planning sessions lag behind what teams are actually capable of building.
This doesn't mean Agile is broken. It means Agile, as commonly practiced, is no longer sufficient on its own.
What still holds up are the principles: fast feedback, adaptability, collaboration, learning through iteration. What comes under pressure are the mechanics: fixed sprint lengths, heavy backlog grooming, and ceremony-driven coordination that assumes a slower rate of change.
- Sprint planning shifts from estimating effort to clarifying intent.
- Backlogs move from exhaustive lists of work to evolving hypotheses.
- Reviews become less about what was completed and more about what the demo taught us.
In AI-influenced environments, Agile begins to shift from a delivery framework to a guiding mindset. Flow matters more than cadence.
Predictability vs. AI variability
One of the biggest tensions sits around predictability. Agile planning relies on historical velocity. AI-driven development introduces variability. Outputs differ based on prompts, context, data, and even model behavior over time. The team now includes agents that are powerful, fast, and non-deterministic.
Planning based on past performance becomes less reliable. That forces a shift from process control to outcome control.
Instead of asking, "Did we complete what we committed to?" teams start asking, "Did we move closer to the intended outcome, and do we trust what we built?" Review, testing, security, and design oversight can't be end-of-cycle gates anymore. They have to be embedded throughout the flow.
Many organizations will keep the Agile vocabulary of sprints, stories, and retrospectives. The meaning underneath those words will change.
The demo-driven culture
As AI compresses the distance between idea and execution, one of the most visible shifts is the move from documentation-driven alignment to demo-driven decision-making.
In traditional delivery models, progress was communicated through artifacts: requirements documents, design specs, roadmaps, and status updates. Working software arrived later, often after key decisions had already been made.
AI flips that sequence. When teams can produce functional prototypes quickly, the demo becomes the primary vehicle for thinking, learning, and alignment. Instead of debating what should be built, teams react to what exists. Feedback becomes concrete. Assumptions surface earlier. Decisions are grounded in reality rather than interpretation.
This doesn't eliminate documentation, but it changes its role. Written artifacts shift from being predictive to being supportive. They clarify intent, constraints, and guardrails, while the demo carries the conversation.
A demo-driven culture also changes how value is assessed. Momentum is measured less by plans completed or stories closed and more by the steady production of tangible, testable outcomes. Confidence builds through visibility, not promise.
Speed cuts both ways. When demos are easy to produce, it's easy to mistake movement for progress. Teams can generate impressive artifacts that lack coherence, usability, or long-term viability.
The teams that succeed aren't the ones that demo the most. They're the ones that use demos deliberately: to learn, to align, and to decide.
As code becomes cheaper, experience becomes more valuable. The human role shifts from creator to curator, making sure what gets built is meaningful, usable, and trusted, for the developers maintaining it and the people using it.
The friction
AI introduces new risks alongside new speed.
The quality paradox
Model drift, hallucinated logic, and AI-generated technical debt threaten long-term sustainability. Code that nobody on the team fully understands is still code somebody has to maintain.
Governance, security, and validation
AI-driven delivery demands clearer specifications, stronger guardrails, and automated validation. Less ceremony doesn't mean less discipline.
The talent gap
Teams have to grow from writing code to orchestrating, reviewing, and thinking in systems. Skills don't evolve at the same pace as tools.
Without structure, AI amplifies chaos. With it, the answer isn't abandoning the SDLC. It's evolving it: starting from a constraint-based specification an agent can interpret, organizing around small pods of people working with AI agents, and turning QA from a phase into a validation gate that runs as the code is produced.
What's next
The software delivery value chain has already been disrupted. The question for every program is whether its process will evolve on purpose or by accident.
The tools have changed. The process is changing. The mindset has to follow.