Your team uses AI. Why isn’t the roadmap moving faster?

For much of our first year with AI, our engineers got faster and our delivery didn’t.

We bought the tools. Engineers built their own setups. We wrote skills for tasks we thought we could automate. But features still got held up by unclear requirements, repeated discussions and code waiting for review. Generating code faster hadn’t removed those delays.

We’ve been using AI agents across our projects at Radency for about two years, inside everyday delivery on client software. The meaningful improvements came in the second year, when we changed what we agreed before implementation, which instructions agents followed, and what reviewers had to decide.

Getting there involved failed experiments, substantial preparation and a review process we had to rethink once AI started producing more code.

A custom form builder had been pushed back release after release. When we approached it with the revised workflow, it took 2.5 weeks to have a pull request ready for release.

Previously, a feature began with a short user story: a description and acceptance criteria. The product manager couldn’t see all the implications for the existing platform, so details emerged during implementation. Developers asked questions, requirements changed, and the team went through another round of discussion.

We moved more of that thinking ahead of implementation:

We configured an AI prototyping tool to follow our UI guidelines, giving the product manager something to examine before the requirements were finalized. The team reviewed the prototype together, asked questions and captured the discussion.

The developer then combined the design, meeting notes and references to the existing codebase into an implementation plan or architecture decision record (ADR). That went back to the product manager to finalize the requirements.

Only then did the agent produce the first implementation, with the developer reviewing and adjusting the algorithm.

The agent also had shared instructions describing the project’s recurring code patterns, conventions and architecture. These were saved as project skills: reference material explaining how an implementation should fit the system.

On one project, the client saw the application and realized the layout didn’t match what end users expected. A single grid needed to become a continuous feed of entities.

The models and API were already in place, so the change could stay in the presentation layer. The team had implemented the new layout by the following day.

Previously, feedback meant collecting notes, holding planning meetings, creating and assigning tasks, then preparing another demo.

Now each feature has a consistent set of working assets: the task description, prototype and implementation plan. Feedback updates that plan. With the existing context available, the agent can draft the implementation from the meeting recording.

We also cleared the CI/CD path so changes could reach staging automatically. The developer reviews the code; the product manager checks the application.

Writing code faster created another problem. More pull requests arrived, and review became the slow part.

Some sat for days under long comment threads. The same arguments kept returning: where a file belonged, which service should own a responsibility, why existing code had been duplicated.

Each engineer’s agent had a slightly different understanding of the project. Reviewers were spending time correcting those differences after the code had already been written.

We made two changes.

First, we described the rules around each service and committed them alongside the code, so everyone’s agent could work from the same reference.

Second, before starting a feature, two or three people discussed the approach and recorded their decisions in an ADR. The agent then worked from that agreement.

Simplified sequence of decisions and work. This is not a measured timeline.

The ADR was the change that made the biggest difference to review time. Reviewers could assess a change against an agreed approach without reopening the design discussion in every pull request.

Pull requests that used to wait for days now usually merge the same day.

Senior engineers still have to exercise judgment. Agreeing on the approach earlier gives them less reason to revisit the same decisions after implementation.

Shared project instructions also helped when we needed to bring functionality into an existing system.

From our early work with Cursor, we had seen agents make better decisions when they had relevant code to work from. Starting from an empty project was harder: a generated application could look convincing while its structure needed substantial rework.

We invested in describing the destination. Dozens of project skills documented what different parts of our architecture should look like. With that shared configuration in place, bootstrapping a working module took one to two hours.

Integrating existing functionality

When we needed to bring pages from a React application into our system, the inexpensive option was to embed them in an iframe.

Instead, the agent created a new module from our architecture description, then extracted the business logic from the React pages and moved it into that module.

The migration took two hours, followed by two to three hours of testing and checking that nothing had been missed. We ended up with a module built on our own architecture.

Changing an application’s framework

We used a similar approach to move an application from Flask to FastAPI while preserving its structure.

We described the target architecture, identified the places where application logic depended on Flask, and recorded those dependencies in a Markdown checklist. The agent worked through that checklist over multiple iterations. Existing API tests let us check that the migrated endpoints behaved like the originals.

The whole migration took under two days. It wasn’t an especially complex application, and the tests were essential to validating the change.

Both examples depended on making the destination explicit and checking the result. The reported implementation times only make sense alongside that preparation and validation.

Getting to these changes took longer than it needed to. We spent time building elaborate setups before fixing the inputs they depended on.

This is the sequence we now follow with client teams.

Once review improved, QA started struggling with the number of features arriving in each release.

On modernization work, implementation could take hours while testing and adjustments still took days. Validating a new API could take days to a week.

Faster implementation didn’t shorten the path on its own. It moved the queue further along it.

We haven’t reached a point where every part of delivery speeds up together. Each improvement changes the workload somewhere else.

That is why we keep looking at the whole path from requirements to production. The amount of code an agent writes describes one part of it.

To assess what AI adoption has done for your roadmap, follow a feature from its initial requirements through to production, including the waiting, rework, review and testing along the way.

You can use the same perspective to examine your own delivery process.

Choose a recent feature that took longer than expected and walk through it with the people who built, reviewed and tested it.

Choose a recurring source of delay to address first. Then follow the next comparable piece of work through the same stages, including review and QA.

This gives you a concrete way to examine whether a change helps the team deliver, and where further work is needed.