Agentic Development, Part 2: Making the Speed Useful

Making the sprint shorter is the obvious answer to AI speed.

Improving the technical specifications is the sustainable one.

We cut our sprints from two weeks to three days. It helped immediately.

In three days, we were already producing enough to run demos, prepare test environments, and get useful feedback. The first reaction to agentic speed is obvious: shorten the feedback loop.

But a sprint is not just execution time. It also has a preparation cost.

You still need to clarify the scope, align the team, prepare the environment, define what should be tested, and make sure people understand what actually matters.

If the only answer to AI speed is to make every cycle shorter, the bottleneck simply moves. Execution becomes faster, but preparation and synchronization become the new friction.

Going faster is easy.

Making that speed useful requires a new operating system for software teams.

A short sprint does not fix an unclear objective

Shorter cycles are necessary because agents can produce enough work in a few hours to make a two-week feedback loop dangerous.

Waiting two weeks to discover that the team moved in the wrong direction is no longer acceptable.

But compressing the calendar does not remove the work required before execution starts.

If anything, it makes that work more important.

An agent will not wait for perfect clarity. It will move.

If the objective is unclear, it will still make progress.

If the design direction is weak, it will still choose one.

If constraints are implicit, it will interpret them.

If trade-offs are not written, it will make them silently.

That is where teams start losing control.

The agent can be technically correct while moving the product in the wrong direction. It can implement the requested feature while weakening the architecture. It can solve the visible problem while creating a larger one elsewhere.

Execution speed increases the cost of ambiguity.

The technical specification becomes a control surface

The answer is better planning and much better technical specifications.

This can sound strange in a startup or scale-up environment, where more planning often sounds like slowing down.

But this is not about adding more meetings or turning every decision into a document.

It is about making the context that guides execution explicit before the agent starts moving.

In the agentic world, a technical specification has to carry much more context than before.

It has to explain:

• The expected behavior.
• The design intention.
• The constraints that matter.
• What should be tested.
• Which trade-offs have already been made.
• Which decisions should not be left to the agent.

A traditional ticket could remain vague because the developer carried company knowledge, product context, architectural history, and informal conversations in their head.

An agent does not share that background unless you make it available.

The specification is no longer only a description of the work. It is part of the control system.

The goal is not to describe every line of code. The goal is to frame the workspace so the agent can move quickly without silently redefining the objective.

Architecture must reduce collision and make change reversible

Better specifications are not enough when several people and agents operate on the same system.

The first structural response is to reduce collision surfaces.

Clearer ownership. Smaller shared surfaces. More explicit agent contexts. More automated guardrails. More separation between types of work.

To do that, you have to rethink your information systems architecture.

Architecture has to serve the client need, but also the way your team is organized.

When several developers can each produce the volume of a small team, broad shared ownership becomes dangerous. The architecture needs clearer boundaries so that one agent can move quickly without unexpectedly rewriting another person's work.

The same applies to environments and data.

Agents need safe places to iterate, break things, learn, and eventually ship. Test environments must be isolated enough that an experiment does not remove another developer's data or silently modify a shared dependency.

When speed increases, safety margins have to increase too.

Reducing collisions is only half of the answer. The changes that still happen must be inspectable and reversible.

Everything an agent works on must be versioned.

Code gives you diffs, history, rollback, and the ability to inspect changes. Binary artifacts and opaque interfaces do not.

This is why, if your build process relies on no-code tools, you should plan an exit strategy as soon as possible.

No-code tools slow down AI agents. Agents are far more efficient at generating and modifying code than operating through rigid interfaces built for humans.

The best tools balance both worlds: a no-code interface for user interaction, a UI layer you can drop at any time, and code as the single source of truth.

This principle extends beyond application code.

Infrastructure, permissions, data transformations, deployment workflows, tests, and documentation should be inspectable and recoverable.

Agentic development needs the ability to move quickly. It also needs the ability to understand what moved and to reverse it when necessary.

Traceability is not administrative overhead. It is a condition for autonomy.

The human role moves toward judgment

Claude Code feels like a senior engineer who does not care about the job.

It has senior-level technical skills and still misses the mindset:

• It does exactly what you ask.
• It adds features on top of messy code.
• It ignores bugs unless you explicitly insist.
• It will not test anything if you do not ask.
• It has no issue with antipatterns if that helps it finish faster.

One of the main skills seniors develop over time is caring.

But caring alone is not enough.

A great senior engineer has a strong sense of trade-offs: constantly deciding what must be done now, what can wait, and what can be ignored.

Most importantly, a senior engineer takes responsibility for those decisions.

An agent can produce senior-level code. That does not mean it carries senior-level responsibility.

The human still has to decide what deserves attention, what risk is acceptable, and what should not be built at all.

This is why hands-on team leads are particularly well prepared to work with development agents.

Look at their day-to-day work:

• Reading and validating code.
• Spotting risks in developers' code.
• Pointing out antipatterns and asking for fixes.
• Clarifying objectives before implementation.
• Discussing technical architecture before writing code.
• Asking for solution benchmarking before a final decision.
• Framing the workspace so developers have a safe environment to iterate, break things, learn, and eventually ship.

These are almost exactly the skills required to get useful work from an AI coding agent.

The advantage does not come from typing faster.

It comes from knowing how to frame work, review output, identify risk, and intervene at the right level.

Agentic development also changes the daily stand-up.

Before, the daily was often the place to ask for technical help. That made sense.

Increasingly, the machine will answer low-level technical questions.

The human discussion has to move higher:

• What are we building?
• What should not move?
• Where are the risks?
• What needs to be tested?
• Which decisions are still unclear?

I do not solve problems anymore. I enable AI to solve them.

Logic and reasoning are no longer where I spend most of my time.

My job is to frame problems, design systems, make the calls that still require judgment, and take ambitious bets on the future of my industry.

This is not a retreat from technical work.

It is technical work moving to a higher level of abstraction.

Reinvest the time into stronger systems

I have been reinvesting a large part of the time saved by AI agents into two areas: refactoring and capacity building.

Around 40–50% of my time now goes into improving the system rather than simply adding new features.

By capacity building, I mean strengthening the foundations:

• Better data collection and processing.
• More ways for the business team to access and use data.
• Internal tooling.
• Monitoring and analytics dashboards.

This investment is already having several effects: fewer production issues, less unnecessary support, better anticipation of heavy workloads, and faster development of new features.

Agents save time.

The real leverage comes from reinvesting that time into making systems stronger.

Shorter feedback loops help.

Better specifications give the agents direction.

Architecture reduces collisions.

Versioning and guardrails make autonomy recoverable.

Technical leaders provide judgment.

Going faster is easy.

Making that speed useful requires much better preparation before execution starts.

Read Part 1: The Bottleneck Is No Longer Code

Cover: Michelangelo's Study for the Fortifications of Florence, c. 1525. Public domain image.