Agentic coding increases throughput in ways that are now observable in practice. Tasks that previously required sustained effort can be implemented quickly, boilerplate largely disappears, and refactors that were once deferred become cheap enough to attempt.
By intent-driven development, I mean working at the level of describing outcomes and constraints while an AI agent generates the implementation. It is what many people call agentic coding, but the emphasis shifts from typing code to specifying intent.
The implementation phase compresses while verification does not compress at the same rate, and that shift changes the risk profile.
Abstraction Shifts Always Redistribute Risk
Every abstraction shift in software increased leverage and redistributed responsibility.
Managed runtimes reduced memory errors but made runtime behaviour and performance characteristics more important. Cloud infrastructure made distributed failure explicit and forced investment in reliability engineering. CI/CD replaced manual validation with automated gates that had to be trusted. Microservices fragmented systems and forced clarity around contracts and observability.
Each shift created new roles and new process discipline because the abstraction changed where mistakes surfaced. Those adaptations happened over years. Tooling matured gradually. Organisational practices caught up.
Intent-driven development follows the same structural pattern, but the rate of adoption is faster than the pace at which process usually evolves.
We Relied on Human Throughput More Than We Realised
Most delivery pipelines were shaped around human output.
Reviews are sometimes rushed, diffs stretch further than they should, architectural drift accumulates quietly, and technical debt builds because there is rarely time to address it systematically.
Production systems mostly held.
Part of the reason is that human implementation speed acted as a natural throttle. Writing code takes time, large cross-cutting refactors require coordination, and broad structural changes are effortful enough that they are usually deliberate.
Change rate limited blast radius, even if no one explicitly designed it that way.
Intent-driven development removes much of that friction. Wide refactors become cheap, cross-cutting changes are easy to attempt, and large diffs can be generated in minutes.
AI does not remove legacy complexity; it interacts with the system as it exists.
If a team is already carrying significant debt, increasing implementation velocity does not automatically create time to fix underlying issues. It increases the rate at which fragile areas are modified.
Pipelines Were Calibrated for Slower Change
Most CI/CD pipelines validate what they were designed to validate: syntax, contracts, unit tests, integration tests, and static analysis thresholds.
They were calibrated under assumptions about human effort. A large refactor required time and coordination. A pull request touching twenty files was noticeable and unusual.
With intent-driven development, it is trivial to produce a pull request that modifies forty files across multiple subsystems in a single session.
Consider a model asked to “standardise logging.” It replaces structured logging with string interpolation everywhere. Unit tests still pass because observable behaviour under test did not change. The logging contract degrades subtly, structured fields disappear, and observability suffers in production.
Similar patterns appear in broader refactors, where large cross-cutting changes pass automated checks but introduce integration or concurrency issues that only surface under real load.
The AI did not deploy those changes.
The pipeline admitted them.
When implementation happens at the level of intent, scope expands easily and execution is immediate. That raises the bar for architectural clarity and verification depth. If review capacity and verification discipline remain unchanged, the system is absorbing a different class of change than it was calibrated for.
A Practical Response at the Workstation Layer
In my own work, I introduced a constrained agentic workflow to compensate for the current state of both the tooling and the surrounding process.
Today’s coding agents are capable of producing wide diffs and cross-cutting changes with very little friction, while most delivery pipelines were not designed for that velocity.
The workflow operates at the developer workstation, before code reaches a pull request. It deliberately constrains scope through bounded tasks, explicit gates, one change at a time, and cleanup before PR.
It is a temporary constraint while the broader delivery system evolves. It does not replace architectural governance, security discipline, or structural debt reduction. It compensates for their current limits.
As review triggers, coverage enforcement, architectural checkpoints, and AI evaluation frameworks mature, those constraints can relax. Velocity should increase because the system can safely absorb it, not because local safeguards were bypassed.
That structure is documented here:
https://dev.to/danielbutlerirl/agentic-workflow-design-index-and-reading-order-4443
It outlines workstation-level guardrails designed to prevent wide, unreviewable changes from reaching PR in the first place.
The Practical Question
Intent-driven development is already happening.
Every abstraction shift required process evolution. This one is moving faster than most, and treating it as just another tooling upgrade assumes the system was already prepared for significantly higher throughput.
Increasing change velocity without recalibrating review and verification increases the likelihood that weaknesses in the pipeline become visible. Acceleration exposes whatever was previously tolerated.
Process discipline needs to evolve alongside it.
Top comments (0)