We Gave Two AI Coding Agents the Same Spec. Here’s How Differently They Worked.

[
  {
    "id": "a",
    "score": 61.111117,
    "contributions": {
      "reach": 50.000007,
      "effort": 11.11111
    }
  },
  {
    "id": "b",
    "score": 68.749996,
    "contributions": {
      "reach": 18.750003,
      "effort": 49.999993
    }
  }
]

A coding agent can produce a working program in more than one way. Some take a compact path. Others read, write, test, and revise in many smaller moves. If you’re deciding how to bring one into a real project, that difference affects what you’ll review, how much activity you’ll see, and how you’ll work alongside it.

We gave Prime Agent and Claude Code the identical programming assignment, then checked the finished projects ourselves with the same five shell checks. Both delivered a working result. The interesting part was the route each took.

This content may include affiliate links. If you use them, ToolRiot may earn a commission at no extra cost to you.

Neither Prime Agent nor Claude Code was the overall winner here. This was a narrow comparison of working styles on one specified task, with the same model assigned to both. It tells us about process, not which tool builds better software in general.

The assignment: a small tool with real state and feedback

The brief was to build a Python command line program named calibrate. It had to score records using weighted features, save feedback about whether those records had good or poor outcomes, and adjust future scores based on that feedback.

That made it more meaningful than asking for a one page website or a simple calculator. The agent had to handle several connected pieces:

• Read candidate data from a JSON file and return scores from 0 to 100.
• Explain each score through feature contributions that add up to the stated result.
• Save weights and history to disk, so learning survives after the program closes.
• Change later scores in the expected direction after good and poor outcomes are recorded.
• Reject malformed input with a readable error, rather than exposing a Python traceback.
• Write a README and a passing pytest test suite.

We ran four controlled builds in total, two with each harness. The specification was identical each time, confirmed with the same file hash. Both agents used the same pinned model, claude-opus-5, and we verified that model from each run’s record.

That control matters. An agent harness and its underlying model are different things. If the models differ, a comparison can accidentally measure the model change more than the way each agent works.

What happened: both projects passed every independent check

Each finished project went through five checks that the agents did not write or grade themselves. Across four builds, that produced 20 checks in all. Every one passed.

Both Prime Agent and Claude Code produced projects that:

1. Included a README and passed their own pytest suite.
2. Scored two input records from a JSON file, with results in range and contributions that reconciled to each score.
3. Changed stored weights after outcome feedback, with the updated state visible from a separate process.
4. Raised the score of the profile linked to a good outcome and lowered the score of the profile linked to a poor outcome.
5. Rejected invalid JSON with a nonzero exit and a plain-language error message.

The behavior was concrete. In every controlled build, the candidate recorded as a good outcome scored higher afterwards and the candidate recorded as poor scored lower. In the Prime Agent build shown below, the two example candidates scored 61.11 and 68.75 before feedback, then 78.26 and 54.97 after it.

That shows both agents connected scoring, saved state, feedback, and later rescoring in a functioning program. It does not tell us that one generated a better calibration method, a more maintainable design, or a better fit for every codebase. The checks were built to confirm the required behavior, not to crown a champion.

The process difference was large and repeatable

The output results matched. The working paths did not.

Prime Agent completed each build in 12 to 13 tool calls. Every action was sent as an IPython submission, meaning it worked through a notebook-style execution environment rather than a long visible sequence of individual file reads, edits, and shell commands.

Claude Code took 48 to 49 calls. Its sequence used familiar development actions: inspecting files, writing and editing code, reading the results, and running shell commands to test and verify the work.

The difference held in both repeats. Within each tool, the second build differed by just one call. That makes the roughly four-to-one gap worth noticing as a process pattern for this assignment.

More actions are not automatically a downside. Claude Code’s more visible workflow can be useful when you want to see the agent inspect the project, make focused edits, and test as it goes. Its final project also included a larger test suite, which may be appealing if you want more examples of expected behavior to review.

Fewer actions are not automatically an advantage either. Prime Agent’s compact approach may appeal when you want an agent to carry a clearly scoped task through to a finished workspace with less back-and-forth activity. But you’ll still want to inspect the code, README, and test coverage before relying on it in a customer-facing or business-critical system.

Also, action count is not a speed test, a cost test, or a code-quality score. We did not measure elapsed build time, token use, pricing, long-term maintenance, or performance under a larger workload.

A useful correction: our first comparison wasn’t fair

We made an important mistake before running this controlled set.

An earlier attempt allowed each environment to use its own default model. One used an older Claude Opus version and the other used Opus 5. Any difference we saw could have come from the harness, the model, or both. It was not a clean comparison, so we did not use it to draw conclusions here.

That earlier run also led us to describe package installation inside an agent’s runtime as if it were a stable property of Prime Agent. It happened with the older model, then did not happen when Prime Agent used Opus 5. The more accurate reading is simple: it was behavior from that earlier model-and-environment combination, not something we can attribute to Prime Agent as a product characteristic.

This is a practical lesson if you’re evaluating coding agents at work. Keep the model, prompt, starting files, and acceptance checks fixed. Then repeat the run. Otherwise, an appealing demo can hide several moving parts.

Which working style may fit your project?

Prime Agent: for compact execution on a clearly defined build

Prime Agent produced a smaller workspace in this exercise: 7 files in one build and 9 in the other, with test suites of 30 and 31 tests. It completed the full program in a notably shorter sequence of agent actions while meeting all five outside checks.

That can be attractive if you have a contained assignment with clear acceptance criteria. For example, you might ask an agent to create an internal command line helper, automate a repeatable data task, or build a small component with a defined input and output.

The useful habit is to provide a written spec that states the interface, expected errors, saved data, and test cases. The calibrate assignment did exactly that. Clear constraints give an autonomous agent something concrete to implement and give you something concrete to verify afterward.

Prime Agent may not be your first choice if your team wants to follow a long chain of individual reads, edits, and terminal commands as the work unfolds. Its observed path here was more condensed. The final code remains reviewable, but the journey contained fewer separately visible development steps.

Claude Code: for a more step-by-step development trail

Claude Code produced the same required behavior, using a longer chain of conventional coding actions. Its finished project had 17 files in both builds, with 57 and 59 passing tests.

This working style may feel familiar if you already develop in a repository and want an agent to inspect context, make changes, run tests, then revise. Seeing those smaller steps can make it easier to pause, redirect the task, or review the agent’s choices during the work instead of only at the end.

The larger project and test count should not be read as proof of superior quality. They do show that Claude Code took a more expansive implementation path for this brief. For teams that value visible iteration and want more test cases to inspect, that can be a useful match.

Claude Code is not necessarily the most economical choice for a tiny, tightly constrained task where a shorter agent path is the main preference. We did not test cost, but its observed workflow involved many more individual actions.

A practical workflow for using either tool

The most useful outcome of this comparison is not a pick. It’s a repeatable way to use either agent responsibly.

1. Write the acceptance checks before prompting. State what must happen from a user’s point of view. For this project, saved learning across separate program runs mattered more than whether the agent’s code looked clever.
2. Give the agent a narrow first assignment. Start with a small utility, a contained feature, or a test-backed fix. Don’t begin with the most sensitive part of your business.
3. Run checks outside the agent’s conversation. Use a script, another developer, or a CI job. The same five commands checked both completed projects here.
4. Read the README and tests. Tests tell you what the program is expected to do. The README reveals the agent’s assumptions and any operating steps you’ll need later.
5. Review code before production use. Passing checks are encouraging, but they don’t cover security, privacy, unusual data, or future maintenance needs unless you explicitly test those areas.

For a small business, this can mean having an agent create a draft internal tool, then asking a technically comfortable contractor or employee to review it before it handles customer data. For someone learning software development, it can mean comparing the code against the specification and using the test suite as a study guide.

Who should not use these tools for this job?

Neither tool is the right starting point if you need to ship code without any human review. Both builds met our specified checks, but a five-check exercise cannot establish security, accessibility, compliance, scalability, or fit with an existing production system.

They’re also not a natural fit if the assignment is mostly unclear. Coding agents can help turn a plan into software, but they can’t reliably replace decisions that haven’t been made yet: what success means, who owns the data, which edge cases matter, and what risks your business can accept.

If you’re new to coding, you can still benefit from an agent, especially on learning projects and small internal tasks. Just plan to spend time reading the generated files and running the program yourself. The tool accelerates implementation. It doesn’t remove the need to understand what you’re deploying.

Technical details from the checks

Both projects passed a project-level test suite from the repository root. Prime Agent’s suite reported 30 passing tests; Claude Code’s reported 59.

For the scoring check, each project accepted two JSON candidates and returned a score plus a per-feature contribution map. The check confirmed that every score sat between 0 and 100, and that the contributions summed to the reported score within 0.01.

For persistence, we read saved weights, recorded one good and one poor outcome, then read weights again in a new process. The weights changed in both projects. We then rescored the original candidates in another process and confirmed the good-outcome profile moved up while the poor-outcome profile moved down.

Finally, we supplied text that was not valid JSON. Both programs returned a nonzero status and a readable error on standard error, without a Python traceback.

The bottom line

Prime Agent and Claude Code both completed the same stateful programming assignment and passed every independent behavior check we gave them. Prime Agent got there through a compact set of notebook-style actions. Claude Code used a longer, more visible sequence of development steps and produced a larger test suite.

Choose the working style that helps you review and guide the work comfortably, then bring your own acceptance checks. If you want to try the more step-by-step approach we observed, start with Claude Code on one small, well-defined task.