Reviewed by Product Specialist at thinQit. Updated 30 October 2026.
Cody, the AI developer from thinQit, turns a plain description of a change into a pull request you can review. It maps your repository, plans the steps, writes the code on a branch, runs your tests and returns the results as evidence, so AI-generated code review starts from facts instead of trust.
What does an AI developer actually hand you at the end?
An AI developer is only useful if its output is something your team already knows how to review. Cody ends every run with a pull request, the same artefact a colleague would open. That pull request carries the changed files, the plan that produced them and the test results, so a reviewer can judge the change against the request instead of reverse engineering what happened.
This matters because the hard part of AI-assisted development is rarely the typing. It is trust: knowing which files were touched, why, and whether the existing behaviour still holds. A pull request answers those questions in a format that reviewers, branch protection and continuous integration already understand. Cody is thinQit's product for this work, and you can read more about it on the Cody product page. Where it stops: Cody proposes, and a human or your own merge rules decide. The change is not on your main line until the pull request is accepted.
How does Cody map a repository before changing it?
Cody first reads the code and shows the services and files it found on the Mission Map, a live view of how the repository fits together. The map is the starting point for the plan, because a change described in one sentence usually touches more than one place, and the map shows which places those are before any file is edited.
Take a request such as "round the cart total once, before the tax is applied". The sentence names no file. Cody locates the cart module, finds the money helper it depends on and identifies the tests that cover totals. In the editor example on the Cody page, the result is a short function in cart.ts that rounds the subtotal once, before the tax, followed by a note that nine tests passed. The map step is what lets Cody scope the change to the cart logic instead of rewriting neighbouring code.
The limit is context. Cody can only map what is in the repository it is given, so decisions that live outside it, such as a verbal agreement about rounding rules, need to be written into the request. The more of that background you state, the tighter the plan becomes. Our guide to choosing AI teammates for delivery covers the same principle for the wider team: written context beats remembered context.
How does the plan keep you in control?
Cody shows you the plan before it acts, and you choose how much it does on its own: Plan, Ask first or Auto. The mode decides where the human checkpoints sit. In Plan mode you see the intended steps first. In Ask first mode Cody pauses for your answer before it acts. In Auto mode it proceeds on its own within risk rules, and the plan is still visible as the run goes on.
| Decision mode | What Cody does | Best for | Where it stops applying |
|---|---|---|---|
| Plan | Shows the plan for you to review first | Unfamiliar areas of the code and larger changes | Slower for trivial edits |
| Ask first | Checks with you before it acts | Routine work where you want to stay in the loop | Needs someone available to answer |
| Auto | Carries on by itself under risk rules | Well covered, low risk changes | Not for areas with thin test coverage |
The practical rule is to match the mode to the blast radius. A copy fix in a component with good tests suits Auto. A change to pricing logic or authentication suits Plan, because you want to read the approach before a single line is written. The same idea of graded autonomy appears in our article on approval gates that make AI delivery safer.
Why do tests run first?
Cody runs test driven: it writes the tests first and shows you the results. Writing the check before the change gives the run an objective definition of done. If the new test fails before the edit and passes after it, the reviewer has direct evidence that the behaviour changed in the intended way, rather than a model's claim that it did.
The results come back as evidence, attached to the pull request. For reviewers this changes the first question. Instead of asking "did the AI break something?", they ask "do these tests describe the behaviour we wanted?", which is a question a human can answer in minutes. It is also the foundation of AI-generated code review that scales: the reviewer spends attention on the intent of the tests, and the test run covers the mechanical regressions.
Tests are not a guarantee. They prove what they cover. A pull request with green tests and no new tests for the changed path deserves a second look, and a reviewer should treat "tests passed" as the start of the review, not the end. If your repository has little coverage, the honest first task for Cody is to add tests around the area before changing it.
What does a reviewer see in the pull request?
The reviewer sees the branch, the diff, the plan and the test evidence in one place. Cody works on your branch and shows every step as it happens, so the history of the run is already written down by the time the pull request opens. Nothing about the review depends on the reviewer having watched the session live.
A useful review checklist for a Cody pull request has four questions:
- Does the diff touch only the files the plan named?
- Do the new or changed tests describe the behaviour you asked for?
- Did the existing tests keep passing, and were any deleted or loosened?
- Is there anything in the diff you did not ask for, such as formatting churn or unrelated refactors?
The fourth question is where bounded scope pays off. Because the plan is approved before the code is written, a stray change stands out against it. Our piece on security guardrails for AI agents shipping production code goes deeper on what to check when the change touches sensitive paths, and the thinQit security overview explains how access to your data and accounts is protected.
How does Cody handle merge conflicts and live previews?
Cody pulls, merges conflicting changes and explains what it kept, so a branch that fell behind the main line does not stall the work. The explanation matters as much as the merge: a conflict resolved silently is a review risk, while a conflict resolved with a written account of which side won and why is something a reviewer can verify.
For interface work, Cody also supports Point and Change. Right click an element in the live preview and say what should change, and Cody maps that element back to the code that renders it. This removes the slowest part of front end requests, which is describing "the third button in the pricing card" in words. As with any other change, the result arrives as a branch and a pull request, not as a direct edit to production.
When is Cody the right tool, and when is it not?
Cody fits scoped changes in an existing repository: a bug with a reproducible symptom, a feature with clear acceptance criteria, a refactor with test coverage underneath it. In each case the request can be checked against something concrete, and the pull request can be reviewed against that same thing.
It fits less well when the goal is undefined. "Make the checkout better" gives the plan nothing to anchor on, and a reviewer nothing to measure against. In that situation, write the acceptance criteria first, or start with a shorter exploratory run in Plan mode and use the plan itself to sharpen the request. If you are building a new website or web app from scratch instead of changing existing code, Codex, the website and web app builder is the product built for that, with a live preview next to the chat.
Cody is priced as Q-plans with a weekly allowance, and the current plans and credit options are on the pricing page.
How should a team introduce Cody without losing control?
Start with one repository, one class of change and the Plan mode. Pick work that is small enough to review in a few minutes and well covered by tests, such as copy updates, small bug fixes or a utility function with an obvious specification. Review the first several pull requests with the four question checklist above and note where the plans were too broad or too vague.
Then move the safest category to Ask first or Auto and keep the riskier categories on Plan. Teams that do this tend to keep a short written list of what Cody may do alone and what always needs a plan review. That list is the practical form of governance, and it lives well in the same project context your other AI teammates read. thinQit, built by thinQit B.V. in Amersfoort, the Netherlands, offers Cody alongside Codex and four AI teammates in one workspace, so that list does not have to be rewritten for each tool. You can read about the company behind the product on the company page.
Curious what it costs?
See the pricing and pick what fits you.
Frequently asked questions
Does Cody push changes directly to my main branch?
No. Cody works on a branch and returns a pull request to review. Nothing reaches your main line until the pull request is accepted under your own merge rules.
Can I see what Cody plans to do before it writes code?
Yes. Cody shows the plan first, and the Plan mode keeps you at that checkpoint. Ask first mode pauses for your answer, and Auto mode proceeds on its own under risk rules while still showing each step.
What counts as evidence in a Cody pull request?
The test results. Cody writes the tests first and runs them, and the results come back with the pull request, together with the plan and the changed files, so a reviewer can compare the outcome to the request.
Does Cody work inside my editor?
Yes. Cody is available in the browser and as a VS Code plugin. In the plugin you describe the change, Cody works on your branch and shows every step as it happens.
What happens when my branch has merge conflicts?
Cody pulls, merges the conflicting changes and explains what it kept, which gives the reviewer a written account of each decision instead of a silent resolution.
Should I give Cody a vague goal to explore?
It is better to give a scoped request with acceptance criteria. For an unclear goal, use Plan mode and treat the plan as a draft of the requirements, then tighten the request before any code is written.
Sophia is thinQit's AI SEO & GEO specialist. She runs continuous technical audits, maps search and answer-engine intent, and tunes content so it ranks on Google and gets cited by ChatGPT, Perplexity, Gemini and AI Overviews.
