It takes some guts to stand in front of a technology community and explain the wrong turns you took with a new tool. Sharing what went wrong, what it cost, and how you changed course gives other people a chance to learn without repeating every mistake themselves.
Kevin Jenkins brought that candor to Agile RTP on November 3, 2026, in his presentation, “The Constraints Will Move. You Have to Learn Your Way Into Them.” Catherine Louis organized and hosted the online meetup. Kevin, VP of Engineering at Metafora, a consultancy building software for transportation and logistics, walked through a year’s worth of hard lessons before explaining the practices that were working better for his teams. The improvements had been earned through experiments, expensive mistakes, and changes in how they worked.
One afternoon, Kevin opened an application and found a new menu tab. Nobody on the team could explain why it was there.
An AI coding agent, a software tool that takes instructions and makes code changes, had misread a work item and built something nobody intended. The change had passed review and reached the application. The team had shipped a surprise.
When a coding agent turns a description into working software so quickly, it’s tempting to take the time the build used to require, divide by something impressive, and promise an earlier delivery date. Kevin had done a version of that. He’d also lived with the estimate afterward.
His first project using AI throughout the software development process was estimated at twelve weeks. It arrived four and a half months late.
Kevin had made the original estimate. He put that on the slide, too.
A faster build, followed by a queue#
The coding speed was real. What Kevin got wrong was how much of the surrounding work would speed up along with it.
Deciding what to build, explaining it clearly, reviewing changes, and checking that the result helps a user all take time. Faster code generation can leave you with more work waiting at each of those steps. Kevin’s early experiments made that painfully visible.
The team let AI write its backlog items (the descriptions of work waiting to be done). Some became thousands of words long, stuffed with technical instructions. A person trying to understand the user’s problem had to wade through all of it. The agents then produced enormous pull requests, which are the packages of proposed code changes that teammates review before accepting them. Those packages were difficult to understand, difficult to test, and difficult to undo safely.
They hadn’t put a review agent in place before starting, so human reviewers were overwhelmed. Meanwhile, people were using the tools in different ways without enough shared instructions or standards. The unexplained menu tab came out of that environment.
Kevin’s correction began with the work description. A human now writes the intent, then asks AI what’s missing or unclear. Detailed technical specifications can live alongside the code without burying the human explanation of what a user needs.
He also wants work broken down until a single item takes no more than a day from start to done, preferably less. Within that item, several small pull requests can keep changes understandable. Frequent, focused commits (the saved steps in a codebase’s history) give the team places to return when an agent takes a wrong turn.
Review now happens in layers. Engineers run review instructions before submitting a change, automated reviewers inspect it, and the author works through the findings. The human who submits the change still has to explain everything it does.
Kevin was careful about one observation: in his team’s experience, an agent reviewing its own work found fewer problems than a teammate’s agent using the same instructions. He didn’t claim research establishing why, but he treated it as a reason to get another set of eyes on the work, including another person’s agent.
The tester he thought he wouldn’t need#
Kevin expected AI to help eliminate manual quality assurance. Writing automated tests had become so much easier that he thought the remaining human testing would finally go away.
Instead, he found himself valuing people who were good at breaking software.
Automated tests check the behaviors they’re written to check. An agent can generate a reassuring collection of tests around its own interpretation of a requirement. If that interpretation is wrong, the code and the tests can agree beautifully while the user is left with a problem.
Kevin still wants extensive automation, with tests written before the implementation and run throughout development. Alongside it, he wants someone exploring the whole application, trying awkward paths, and finding what the automated checks missed.
He draws a useful distinction here. A tester working continuously with the team is different from a queue that every completed item must wait in before someone declares it finished. He wants testing throughout the work, without a separate approval column on the board becoming the next bottleneck.
And even good testing leaves a further question: did the team build something worth having?
Audience member Laura Charland, speaking from her product management experience, described the pressure to build more features simply because building had become easy. She pointed out that the extra code and dependencies still need maintaining. Kevin picked that up and returned to his argument for product management: somebody has to understand the user, decide what’s worth building, and find out whether it helped.
That question reaches beyond whether a button works. A button can work perfectly in a feature nobody needs.
Give people something small enough to respond to#
Kevin’s answer draws heavily on continuous delivery: organizing development so small, tested changes can be put into production frequently and safely. He’d advocated these practices before AI, but the new volume of code made them harder to put off.
He favors trunk-based development, where people merge small changes back into the main shared codebase quickly. Long-lived branches (separate copies where work accumulates) become harder to reconcile when agents are producing changes rapidly.
Feature flags help make that practical. A flag is a switch that lets a team put code into production while keeping a feature hidden until it’s ready. Deployment, putting the code into the running system, can happen separately from release, making the feature available to users. A suitable flag service also lets someone turn a troublesome feature off without waiting for another deployment.
Those practices make the next conversation easier. The team can show a small piece of working software, hear what a stakeholder thinks, and adjust it while the change is still manageable.
Kevin has shortened his teams’ iterations to one week. They still use Scrum (a way of organizing work around short cycles and a shared goal), but he has cut exercises that stopped earning their time. They count completed items rather than assigning story points, the relative size estimates often used in planning. That only makes sense because they’re also keeping the items consistently small.
The weekly review puts working software in front of stakeholders more often. The daily team check-in is about progress toward the week’s goal, what they’ve learned, and where a decision or conversation is needed. A board that’s already current doesn’t need everybody to read their status aloud.
Catherine observed that teams can now prototype and make decisions faster than management keeps up with what’s possible. Kevin’s repeated concern was the cost of waiting for an answer. If a team can build a small working example quickly, that example may get a useful response sooner than another round of questions in email.
Sometimes, he said, making a reasonable assumption and rebuilding later costs less than waiting a day or two. His slides pair that practice with recording the team’s assumptions and decisions, then checking how many require rework. There’s something concrete to learn from, rather than a vague celebration of moving fast.
Smaller teams still depend on people#
Kevin described teams that now rely more on coding agents and less on adding several contract engineers around a senior engineer and a product lead. A three-person team, including someone testing the software, can get a lot done in the arrangements he’s using. Keeping people’s working hours aligned with their users also helps decisions happen during the same day.
He explicitly said they hadn’t cut people. They had more, smaller teams doing more projects. Later, answering a question about cost, he said the savings on contracted engineering had exceeded their AI spending so far. He didn’t offer a universal staffing formula or promise those economics would stay the same.
I asked where the next generation of experienced engineers would come from if these small teams depended so heavily on people who were already senior. Kevin didn’t have a settled answer. He recognized that the expertise they’re relying on has to come from somewhere.
That question remains open. The people guiding the agents still need to understand the problem, recognize a bad result, and work with each other. Kevin’s account of smaller teams depends on that judgment. It doesn’t explain how the industry will develop enough of it in newcomers.
Kevin was also opening up small code contributions beyond engineers. A product manager could change some wording, or a designer could adjust a color, with an agent helping make the edit. The same review and automated checks still had to apply, and an engineer still reviewed the change before it merged. If engineers routinely had to clean up afterward, he said, the savings disappeared.
A specification can still describe the wrong thing#
Toward the end, Kevin considered spec-driven development: writing structured specifications that guide an agent through planning, tasks, and implementation. He’d tried it and found value in it, particularly when the problem was already well understood.
His concern was the length of the feedback loop and who remained responsible for the product. A big technical specification can take the team a long way before a user gets something to try. If engineers own it in isolation, the agent may implement exactly what was specified while the user’s actual need goes unanswered.
Kevin didn’t see structured specifications and agile development as natural opponents. He wanted teams to try the tools, keep product people involved, and judge the fit. The same concern ran through his early unreadable tickets and his later comments on specifications: detail only helps if people can still understand, question, and correct what they’re building.
Follow one change all the way through#
Kevin ended with a practical way to find the next constraint. Follow one change from the first idea until a user is actually using it. At each step, measure how long it spent there, how much of that time someone was working on it, and how often it got sent back.
That’s value stream mapping in ordinary terms: look at the whole journey, including the time the work spends waiting. A review queue or an unanswered product question becomes visible when you follow the change instead of watching the coding tool.
His presentation was a snapshot of a year of learning. Models had improved during that year, and his teams had changed how they worked. He expected some of the practices to need revisiting as the technology continued to improve.
In the menu-tab example, code had moved all the way through the system before anybody could explain why that particular feature existed. Kevin’s subsequent changes put more opportunities to ask, inspect, and learn along that journey, while the pieces were still small enough to do something about.
Thanks to Kevin Jenkins for sharing the work, including the estimate that went wrong, and to Catherine Louis for organizing and hosting. You can find the November 3 event and follow Agile RTP for future meetups.