# The Premature Primitive Problem: More AI Agents, Same Broken Delivery

Source: https://agentdrivendevelopment.com/the-premature-primitive-problem/
Agent-readable URL: https://agentdrivendevelopment.com/the-premature-primitive-problem/?agent=1
Published: 2026-09-07T15:33:13-05:00
Modified: 2026-09-07T15:39:26-05:00
Attribution: If you quote, paraphrase, summarize, or cite this material, credit agentdrivendevelopment.com and link to the source URL above.

## Summary

Friends who now lead engineering organizations keep asking about missing AI returns. I’d look at what their agents can actually test and deploy.

## Article

One of the weird things about having a long career is that people who used to work for you, and friends you have worked alongside, are now vice presidents and executives at other companies. I’m happy being the guy building things with AI. They still call, and we have some interesting conversations about what they are trying to do and what is actually happening.

Lately, a common one is about the return on AI. They have invested in the tools, the inference, and getting engineers to use them. There is plenty of activity. The business improvement is harder to find.

Let’s call one of these friends Rick. I’ve condensed the recurring conversation here; this isn’t a transcript of his call.

“We’re spending a lot on AI,” Rick says. “The engineers like it. They’re building agents. Why aren’t we seeing more come out the other end?”

“I’d start by looking at what those agents can actually test and deploy.”

There is something I’m seeing in repositories that I would want him to investigate. Lots of skills, prompts, and agent definitions. Somebody has put real effort into teaching the agent how to work. Then you go looking for basic test automation and deployment automation, and there isn’t much there.

The agent has a detailed job description. The team still doesn’t have a working test command. We apparently decided the new employee needed an onboarding packet before we fixed the building.

“Isn’t writing those instructions part of making AI useful?”

“Sure. But useful at what?”

I’m calling this the premature primitive problem. The primitives are the reusable skills, prompts, and agent definitions. They become premature when we keep building them before establishing a reliable way to test and deliver the software they will change. The people doing this are trying to make AI useful, but they may be missing the mark. Rick wants better business results, delivered faster and more safely. Another agent definition might help. We should be able to explain how.

“And you think they’re just working on the wrong things?”

“Maybe. Or they’re working on the things they’re allowed to change.”

An engineer may be able to edit a skill file without asking anyone. Improving the tests may require another team’s approval. Fixing deployment may require two managers to negotiate their backlogs. We gave the engineer an autonomous agent and left them needing a meeting to improve delivery.

Before I tell Rick to buy a better model, I’d like to know what his engineers can actually do with the one he already bought.

## “Can we see this in source control?”

Probably enough to know where to look. Find the repositories accumulating agent instructions, then look for their build, test, and deployment automation. Follow references to shared pipelines. The automation might live somewhere else; a missing file isn’t a finding by itself.

Look at the history, too. Who is writing the skills? When did they start? What have they been improving, and what happened to the tests during that same period?

“Then go ask those people why they aren’t writing tests?”

“Yes. And stay for the answer.”

They might have a good one. Ask what they’ve tried, what they expect the agent work to accomplish, and what is preventing them from improving the tests or deployment. Commit history can help you find the people. It can’t tell you their motives or how many hours the work took. If they seem to be doing it outside normal hours, ask about that. This may be what they could fit around everything you assigned them.

Have them walk through an actual change from a clean checkout into production. What builds? Which tests run? What happens by hand? Where does the change wait, and who could move it along?

A test directory can look pretty good until somebody explains that they rerun the tests until they pass. Apparently, the correct answer is whichever one eventually lets us merge. A deployment script can also have an impressive name for something that still needs the person who remembers what happened last month.

“What if the tests are fine?”

“Then we follow the change to wherever it gets stuck.”

Maybe manual verification is holding things up. Maybe the automation works and the change spends a week waiting for a product decision or release approval. Another hundred tests won’t make somebody answer the approval request. The repository gives us a place to start investigating, not permission to skip the investigation.

Suppose coding takes two working days and everything afterward takes eight. AI cuts coding to one day. We’ve gone from ten days to nine. The presentation can celebrate a 50% reduction in coding time. The customer gets to celebrate still waiting nine days.

“So that saved day doesn’t count?”

“It counts. It just isn’t five days.”

Recovered engineering time has value. Better quality can have value. We should account for both, along with the cost of getting them. But saved time doesn’t automatically come off payroll, and delivering sooner only helps if we’re delivering something the customer needs. If Rick expected twice the delivery speed, most of the process in that example hasn’t changed.

## “Why wouldn’t they use AI to fix that?”

That’s the conversation I want him to have with the team.

Maybe they don’t know how to write useful automated tests. An agent can help, but somebody still needs to understand what the test should establish. Work through the existing software together, agree on the expected behavior, and automate a check that would catch a real failure. Maybe they know testing and need help using AI on this particular codebase. Trying the work together will tell us more than another adoption survey.

Or they know exactly what needs doing, and another team owns it. Can they contribute a test? Can they change the pipeline? Can the people who own those things work with them this week?

“If the platform team owns it, doesn’t it belong in their backlog?”

“It can belong in their backlog for a very long time. How soon do you want the return?”

Somebody has to resolve the ownership and priority problem. The agent cannot negotiate a place in another team’s planning cycle.

There may also be a budget problem. Imagine an engineer with a $50 monthly AI allowance and a feature due Friday. They could spend what’s left investigating the build and getting tests running. They could also finish the feature their manager expects. Fixing years of neglected delivery work is apparently supposed to fit into the subscription after the assigned work is done.

They need time as well as tokens. Filling their week with features and telling them to improve delivery leaves them choosing which promise to break. Buying subscriptions was the part procurement could do. There is still an engineering organization to lead.

“And sometimes they just like building agents?”

“Oh, absolutely. So do I.”

It’s fun. Fixing a nasty repository is less fun. You can build a planning agent, an implementation agent, and a review agent, and now you have three agents discussing the repository nobody wants to fix. The new agent gets a name and a role. The broken build gets another week.

That’s the problem. We aren’t going to deliver faster until we fix the mess we made or inherited. Put that enthusiasm to work on the repair. Find out what help the engineer needs, agree on what they will finish, and stay involved long enough to see it work.

## “What would you have them do first?”

Initialize the agent for the repository and whatever coding harness they’re using. Give it the structure, conventions, commands, and boundaries. In a reasonably documented project, that should take a few minutes.

Then get the tests and deployment working before the next product-code change.

Have the agent help automate checks for the existing behavior in the area we intend to change. Agree on what that behavior should be. If the requirement and implementation disagree, investigate. Copying the current answer into a test can preserve a bug very efficiently. AI is quite capable of helping us be wrong faster.

Get those checks running in CI. Build the existing version, deploy it through a repeatable process, verify it in a test environment, and demonstrate recovery if deployment fails. Involve the people responsible for production so this becomes the team’s normal way of delivering.

“What if I need to step in to get it deployed?”

“Then step in. But if we need you every time, we should put your phone number in the deployment instructions.”

Leadership intervention can get the work started. We still need to remove that dependency.

Rick doesn’t need a perfect test suite for his entire company before anyone writes another feature. He needs a working way to verify and deliver the software the team is about to change. Once that process works, capture it in the agent instructions. Now the skill describes something we can actually do.

## “Isn’t this just continuous delivery?”

Yes. That’s part of what makes this an interesting conversation to be having now.

Martin Fowler’s Continuous Integration article (https://www.martinfowler.com/articles/continuousIntegration.html) dates back to 2001. Jez Humble and David Farley’s Continuous Delivery (https://www.martinfowler.com/books/continuousDelivery.html) explains how build, test, and deployment automation support reliable releases. We’ve had time to read it. Somewhere between then and the agent rollout, the tests were apparently going to write themselves.

I’d work through MinimumCD (https://minimumcd.org/) with the team: automated testing before and on integration, one deployment path through the pipeline, immutable artifacts, and rollback on demand. Compare those practices with what we just watched in the repository. Figure out what’s missing and what it will take to make it normal.

“We should call Bryan.”

Our mutual friend Bryan Finster is a MinimumCD contributor (https://minimumcd.org/#contributors). He would be a good person to talk to about this.

“We could,” I tell Rick. “Or we could invite his published guidance into the prompt without calling him. Then we don’t owe him a bourbon.”

With the repository open, start with this:

> Help me review this repository using Bryan Finster’s published guidance and https://minimumcd.org/ (https://minimumcd.org/). Read and cite the relevant sources. Before we change product code, help me build useful tests for its existing behavior and a repeatable way to build, deploy, verify, and recover it. Show me what works, what is missing, and which decisions or permissions the team needs. Ask me to clarify intended behavior where it is uncertain.

“Does that give me Bryan?”

“It gives you an agent with something useful to read. Bryan still gets to have opinions the model hasn’t thought of.”

The name doesn’t transfer the experience. The sources give the agent guidance we can inspect, and the engineer still has to judge the result. If we do call Bryan afterward, at least we can show up with a repository and a useful question. The bourbon may be unavoidable at that point.

## “How do I know the tests are any good?”

Mutation testing (https://en.wikipedia.org/wiki/Mutation_testing) is one way to find out. It introduces small, temporary changes into the code and checks whether the tests catch them.

“And if I don’t know what that is?”

“Now you have a link. If nobody is checking whether the tests catch broken behavior, we have a bigger problem than the vocabulary.”

Suppose shipping should be free at $100. A mutation changes the rule so it’s free only above $100. A useful test should catch the incorrect charge at exactly $100. If we mocked or stubbed the calculator, we may only be checking the answer we supplied. Very cooperative of it.

Ask the agent to find that gap and exercise the real behavior. Some mutations don’t change observable behavior and need interpretation; Stryker’s documentation (https://stryker-mutator.io/docs/) explains the technique. We want evidence that meaningful failures get caught, not a score improved by excluding the inconvenient code.

“So I shouldn’t accept the agent telling me it wrote excellent tests?”

“I’d let somebody else conduct its performance review.”

Here are the fuller prompts Rick can take back to the team. They focus on getting the existing software tested and deployable before asking the agent to change it.

Optional companion: prompts for test automation and deployment

### Invite Bryan’s published guidance into the work

Here is the longer version of the prompt I would give Rick. Use it with the repository open and access to the published sources. We are borrowing Bryan’s published guidance; the engineer still has to judge the result.

> Help me prepare this repository for the next product-code change using Bryan Finster’s published guidance and the practices at https://minimumcd.org/ (https://minimumcd.org/). Read the relevant sources, including the testing guidance, and cite what you use. Inspect the existing build, tests, and deployment pipeline, following references to shared automation. Before implementing the next feature or changing product behavior, establish the expected behavior with me and build useful automated tests for the area we intend to change. Identify disagreements between requirements and current behavior rather than treating existing output as automatically correct. Demonstrate that the tests pass on the agreed baseline and catch a deliberate, temporary fault. Run the checks in CI before and on integration. Automate building and deploying the existing version, verify the same tested artifact in a production-like test environment, and demonstrate recovery from a failed deployment. Identify ownership or permission barriers. Show the working test and deployment baseline and remaining gaps before we begin the product change.

### Check whether the tests catch failures

> Evaluate our test automation before we begin the next product-code change. Choose a mutation tool that fits this repository, verify the baseline tests pass, and run it on the existing code we intend to change. Show which meaningful faults the tests catch and which they miss. Briefly flag where mocks or stubs hide real behavior. Add useful tests for the important gaps and demonstrate that they catch the temporary mutations. Report uncovered code, tool errors, and possible equivalent mutations honestly. Don’t improve the score by excluding difficult code or changing expectations to match the implementation. Leave the original product code intact and show whether the tests give us a useful baseline for the next change.

## “What do you need from me?”

Pick one team and follow one change with them. Find out where it gets stuck, who can fix it, and what decision they need from you. Then give them the time and authority to do the work. Decide which existing commitment moves. Otherwise, we’ve just assigned another improvement everyone agrees would be wonderful someday.

Follow the next comparable change. Did it spend less time waiting? Did we catch problems earlier? Could the team deploy without calling in favors? Did the customer get the result they needed?

“And those prompts are going to fix it?”

“They’ll help you get started. You’re still going to have to run the company.”

I’ve given Rick the basics and a way to start working through them. What he finds may require changing priorities, ownership, or how his teams build software. Those decisions belong to him. His engineers can help discover the problem and do the repair, but they can’t make every organizational decision from the terminal.

The teams that already have reliable tests and deployment can put their agents to work inside that process today. Rick can get his teams there, too. He needs to make the repair possible and follow it through. Otherwise, the next model will arrive to find the same mess waiting for it. At least its onboarding packet will be excellent.

## Companion Artifacts

- Executive brief: https://agentdrivendevelopment.com/executive-brief/the-premature-primitive-problem/
- Executive deck: https://agentdrivendevelopment.com/wp-content/uploads/2026/09/the-premature-primitive-problem.html
- Podcast transcript: https://agentdrivendevelopment.com/transcript/the-premature-primitive-problem/