It invents its own patterns
A new helper appears next to the one you already had. Your reviewer now has two.
The harness
A good model is not enough. The setup around it does the real work.
The harness is everything around the agent: what it reads first, what it may not skip, and what has to pass before anyone sees the work. We set it up for your repo so you never have to.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
Reads your repo before it writes.
- 2
Follows the patterns already there.
- 3
Tests must pass before a PR exists.
- 4
A person checks before you do.
Without one
A bare agent is fast. Then someone has to clean up.
Most disappointment with AI coding is not the model. It is having nothing around the model.
It stops at "looks right"
Code that compiles is not a feature that works in a browser next to everything else.
It needs a babysitter
Someone has to prompt, re-run and check. That someone is usually your best engineer.
What it does
Four rails, every request.
Each rail exists because of a way agents fail when left alone.
- 1
Read first
Agents read the code around the request before planning anything. The PRD reflects how your product works today, not how a generic product might work.
- 2
Agree first
No code until you approve a PRD with stories and acceptance criteria. This stops the most expensive failure of all: building the wrong thing well.
- 3
Test as part of the work
Unit, integration and browser tests are part of the job and not an afterthought. When one fails, agents fix the code and run it again.
- 4
A person at the end
A person clicks through the feature against your acceptance criteria before the pull request is raised. Your team then reviews it as usual.
A coding tool needs an owner. We are the owner.
Seats are cheap because they are unfinished. The expensive part of AI engineering is the process around it, and that is the part we run.
| Who does the work | Claude Code / Codex seats | AgentCTO |
|---|---|---|
| Writing the PRD and edge cases | Your PM or lead | Included |
| Prompting, steering, re-runs | Your engineers, hourly | Included |
| UI and design decisions | Still a designer's job | Included |
| End-to-end QA and regressions | Manual, on your QA | Included |
| Accountability for delivery | Yours | Named account manager |
| Real cost | Seats + the salaries driving them | $5 per completed user story |
| Send your first user story | ||
| Send your first user story | ||
Your repo gets the same care on every change
- Picture the change that used to come back with notes. A helper was duplicated because nobody pointed the builder at the one already in your code. The tests covered the happy path and nothing else. The reviewer spent an hour sending it back, and the author spent the next morning fixing things that should never have broken. With a harness in place, that change arrives already shaped like the rest of your codebase.
- Every request passes through the same setup. The agent reads your repository before it plans anything. It follows the naming, the folder layout and the patterns already there. It cannot skip the checks that come after the build, so a change that fails them does not reach your reviewers as finished work.
- Your team stops doing the cleanup. Senior engineers stop acting as the prompt writers for your backlog. They stop running the same request three times to get one function right. Their hours go back to architecture, hard bugs and the reviews that need a human judgment.
- The setup travels with the work. It lives in the setup itself, not in one engineer's head, and it does not depend on someone remembering to paste a prompt in on a good day. A fix on a Monday and a new screen on a Friday pass through the same rules, which is why the results look alike from one request to the next.
- Over time, the repository reads more consistently, because each change follows what is already there. Your reviewers see the same patterns in every pull request, so they can spend their time on whether the feature is right, instead of whether it fits.
- That is the destination we design for: a backlog that moves, a codebase that stays readable, and a review queue that holds only changes worth a reviewer's time.
- Think about the first month after you start. Early requests are where the rules get tested, and the results show where your codebase needs a clearer convention. Those early results help you even when a change needs rework, because they point at the places your team has never written down. Each one becomes a fact the setup can follow next time.
- Consider also what a change costs you when it arrives cleanly. Your reviewer reads it once, approves it or asks for a small fix, and moves on to the next item. That rhythm is what a backlog needs to keep moving, and it is hard to reach by asking people to try harder. Your engineers stop being the only safety net, and the setup does the repeat work every time.
Fewer rounds of rework, and less babysitting for your best engineers
A bare agent is fast.
Speed is useful, but the scarce resource on most teams is careful review time, and unguided output spends a lot of it. Each missed pattern, each invented helper and each untested branch costs a round trip. The harness is there to remove those round trips before anyone on your team sees the change.
Patterns stay consistent.
New code reuses the helper, the validator and the error format already in your repository, so your reviewer does not have to choose between two ways of doing the same job. Your codebase keeps one way of working, and that one way is the one your team already chose.
Tests arrive with the change by default.
Unit, integration and browser tests are part of the job, so the pull request comes with proof that the feature runs. Your engineers start from a set of passing checks instead of building the safety net themselves after the fact.
Nobody has to babysit the work.
Agents re-run failing checks on their own, and a person on our team does the final manual check before the pull request is raised. Your best engineer should not be the one who prompts, waits and prompts again all afternoon.
There is one more benefit that is easy to miss.
A consistent setup makes the output predictable. When a result looks right on Tuesday, it looks right on Thursday too. Your team can trust the process, not only the last change it reviewed, and that trust is what lets a backlog keep moving.
Your own engineers still matter a great deal.
They decide what the product should do, they review what gets merged, and they know the parts of the system that no document describes. The harness handles the repetitive checking so their judgment goes where it counts.
There is also a plain time benefit.
A reviewer who does not have to repeat the same comment every week has more time for the work that needs a person. Your engineers can spend that time on the parts of the product that carry real risk, such as payments, permissions and data migrations, where a human has to own the call.
None of this asks your team to give up its judgment.
It asks them to spend that judgment where it matters most, which is the whole point of the setup.
Helpers you already have get reused, not copied.
Tests arrive in the same pull request as the code.
Failing checks get fixed before a person sees the change.
Your senior engineers review work instead of prompting it.
What the setup checks, in order
- The harness is a sequence of checkpoints. A request passes each one before the next one starts, and each checkpoint leaves a result you can read. Here is the order in plain terms.
- Nothing on that list is decoration. Each checkpoint exists because a bare agent tends to fail at that exact point when nobody is standing guard. Reading comes first because a plan written without the code in view is a guess. Agreement comes next because a wrong idea is cheapest to fix before any code exists.
- The order matters for your time too. Checks run before a person opens the change, so your reviewers see work that already passed the tests. The manual check runs before the pull request is raised, so the pull request you read has already been tried by a person against your criteria.
- The setup is written for your repository. The patterns it follows come from your code. The criteria it is checked against come from the PRD you approved. The tests it writes sit next to the code they cover, in the places your team already keeps them.
- You do not configure any of this yourself. We set it up for your repo and run it on every request. If your team relies on a rule that the code does not show, tell your account manager about it. Unwritten habits are often the first thing a new contributor gets wrong, and they are worth stating once.
- A checkpoint that fails gives useful information about the change. When a check catches something, the builders fix it and the check runs again. Your team only sees the change after it has passed each checkpoint in order.
- If you want to know what a checkpoint did on a given request, the answer is in the pull request and in the PRD. You do not have to ask a builder to remember a detail from three days ago. The record is there, and it stays there for the next person who opens the change.
- Ask for that record on any change you do not understand. A plain question about a checkpoint is a fair question, and the answer should point to the artifact that proves it.
Read first:
the agent studies the code around the request before it plans.
Agree first:
nothing is built until you approve the PRD and its criteria.
Match the patterns:
new code reuses the conventions, helpers and naming in your repo.
Test as you build:
unit, integration and browser tests are written alongside the code.
Fix before handoff:
failing checks send the work back to the builders.
Check by hand:
a person clicks through the feature against your criteria.
Hand over the pull request:
your team reviews what has passed every checkpoint.
The setup we run built seven live products
We have no customer quotes to offer you, and the harness will not produce them either.
What it has produced is the work behind seven live products: 60db.ai, Qcall.ai, Vrid.ai, Niyam.ai, Autoposting.ai, Firstsales.io and Communicate.so. Each one was built using AgentCTO and checked by hand before release.
Those products are different from one another.
One gives a product a voice, one answers inbound calls, one publishes search articles every month and one posts across social channels. Another sends cold email and follows up, a support product answers from help content, and one researches Indian case law and drafts contracts. A single setup handling that spread is a fair test of whether its rules hold.
Your part is simple.
Open one of the seven and read its screens the way a skeptical buyer would. Look at what happens when a form is empty, when a request fails and when someone tries something unexpected. Those moments show whether the rules reached the edges of the product, or stopped at the happy path.
Then hold what you see up against your own repository.
If a product holds up under those checks, the same kind of setup has a fair chance in your codebase. If it does not, tell us where, and we will take that seriously before we start your first request.
This is why the harness matters more to us than any single agent.
The model may change over time, and the tools around it may change too. The rules about reading first, agreeing first, testing as you build and checking by hand stay in place. Those rules are the part we set up and run for you.
The best proof is still the first request.
Ask for one feature, then inspect the pull request against the same rules you would apply to a colleague's change. If the setup did its job, the review should be about the feature and not about the clutter around it.
Judge the pattern across all seven, not one screen in one product.
A pattern that repeats across different kinds of product is the strongest evidence this page can offer, and it is evidence you can check yourself in an afternoon.
The same check works on your own code.
Pick a file your team respects, and set a new change beside it. If the new code looks like that file, the setup is doing what it should. If it looks like a stranger wrote it, that is the first thing to raise with your account manager.
How the setup differs from a tool, a hire or an agency
A coding tool gives you a capable agent.
It does not give you a setup built around your repository. Its output is only as good as the rules your engineers write down and enforce every time. For a team with that discipline already in place, a tool plus a strong reviewer is a good combination, and we would not talk you out of it.
A new hire brings habits.
Those habits are valuable, but they are personal. Two strong engineers working the same backlog often produce two styles, and your reviewers absorb the difference one pull request at a time. A harness keeps one style for every request, so the habits are shared by design rather than by luck.
An agency brings its own process.
Ask what checkpoints it runs, who writes the acceptance criteria, what its tests cover and whether a person checks the feature before it reaches you. Those answers tell you whether an agency has a harness or only a team with good intentions.
Each option sits on a different foundation.
The tool rests on your engineers' discipline. The hire rests on one person's habits. The agency rests on its own process, which you should read before you trust it. Our setup rests on the same written rules for every request, built around your repo.
None of these is the wrong choice in every case.
If your engineers already run a strong routine, they may get more out of a tool. If you need a person in the room every day, hire. The question to ask is where your rules live today, and who keeps them up to date when the team is busy.
A useful test is to write down your team's three most common review comments from the last month. If the same comment appears on most pull requests, the rule behind it belongs in the setup, not in the reviewer's memory. That list tells you more about what you need than any feature grid.
Write the list down before you talk to any vendor, agency or candidate.
Then ask each of them how their approach would handle those three comments. Clear, specific answers are the ones worth a second conversation, and vague answers about quality are a signal to ask again.
Keep your side of that conversation specific too.
When you tell a vendor or an agency what you need, say what your team already does well, so the talk starts from real strengths and not from a sales script.
Coding tool:
a capable agent, with the rules left to your team.
New hire:
strong habits, held personally, with a ramp-up period.
Agency:
a process you have to audit before you trust it.
Our setup:
the same written rules on every request, built around your repo.
Hard questions about the setup, answered in full
Does the setup slow down a small change?
It does not skip steps for small work. A small change still reads the repository, still follows the patterns and still runs the checks. The PRD for a one-screen change is short, so the path stays short too.
What if our conventions are unusual or inconsistent?
The setup follows what it finds, and an inconsistency shows up in review, where your team can decide which pattern to keep. Tell your account manager which way you want it to go, so the next request follows your choice.
What if the setup copies a bad pattern from our old code?
Reviewers can reject it, and that rejection is part of the normal flow. Tell your account manager as well, so the next request does not copy the same pattern without a reason.
Which AI model providers see our code?
Ask us. Our data processing and privacy pages say the same thing: we will give you the current list, including which model providers apply to your work. Do not assume the answer, and do not skip the question before you grant access.
Do the checks replace our own test suite?
The aim is to add to your tests, not to replace them. Your suite stays the source of truth for your product, and the checks sit alongside it so the change has to pass both.
Can we see what the setup checked?
Yes. The result of each checkpoint shows up in the pull request, and the tests come with it. If a person checked the feature by hand, the criteria it was checked against are in the PRD you approved.
What if our team does not trust agents at all?
That is a fair position, and it is one we respect. Start with one small request. Read the PRD, run the tests on your own machine and review the diff the way you would review work from a new contributor. Let the results decide, not our copy.
What if your stack has a part we have not listed?
Ask your account manager before you send the request. Clear answers come faster when the request names the language, the framework and the database in use, along with the version of each that your team runs today.
What if you need a rule that applies to only one folder?
Name the folder in the request. The PRD shows whether that rule is part of the scope, and you can approve it, cut it or change it there, before any code is written.
Give the setup your repo, and judge the first pull request
- The setup is easiest to judge on real work. Send one request that your team has been putting off. Include the stack and where the code lives, so the setup can start reading the repository the same business day.
- When the PRD arrives, check that it reflects how your product works today. When the pull request arrives, check that it reuses your helpers, carries its own tests and reads like your team's code. If it passes those three checks, you have seen the harness at work on your own repository.
- If it does not pass, tell us where. A setup that falls short on your code is information you need before you commit to more work, and we would rather hear it on the first request than on the tenth.
- A good first request has a clear outcome and a clear reviewer. If you can name who approves the PRD and who reviews the pull request, you have what the setup needs to start. The rest of the detail can be worked out in the PRD, where you can read it and change it before anything is built.
- Use the button on this page to send your first request by email. Write to us the way you would tell a colleague, and a person will answer. Include the three things below so the first PRD can start the same day.
- After the first request, decide whether to continue on the same terms. The story count, the cost and the quality of the pull request are all on the page, so the decision rests on evidence you can see rather than on a pitch. If the evidence is good, send the next request. If it is not, tell us what was missing.
The request you have been postponing.
Your stack and where the code lives.
Any convention your team relies on that the code does not show.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1How is this different from Claude Code or Codex?
Those are tools, and they need an owner. Someone on your team still writes the PRD, steers the agent, makes design calls and runs QA. We do all of that and hand you a tested pull request.
2Will this work on our old codebase?
Yes. PHP, Node, Python, Java, .NET and Go are all in scope, along with React, Flutter and SQL or NoSQL databases. Agents read your repo first and follow the patterns they find.
3Who owns the code?
You do. Work arrives as a pull request on your own infrastructure. Your repository, your stack, your review process. To do the work, our agents and team read your repository under the access you agree, and AI model providers may process it. See the security page for details.
4Is this right for us?
It fits if you have a repo, a backlog, and someone who can review pull requests. It does not fit if nobody on your side can review code, because your team makes the final call on every merge.
Send the feature your roadmap has carried for a quarter.
We open the PRD the same business day. Three business days after you approve it, a pull request is in your repo. Judge us on the merge.
Minimum 100 user stories a month, $500 prepaid. No mail app? Write to udit@tinycheque.com.