AI-Assisted.
Human-Accountable.
We use AI coding tools every day, and we would rather tell you which ones than have you wonder. They have genuinely changed what a small team can deliver, particularly on greenfield builds. What they have not changed is who is answerable for the architecture, the security model, and every line that ships. After 20+ years, that judgement is the thing you are actually engaging us for.
What We Use, and What Each One Is Actually For
These are tools, not a methodology. Each earns its place on a specific kind of problem, and an engineer decides which one a task warrants — often none of them.
Claude Code
Agentic work inside an existing repositoryReads the codebase as it is, then makes multi-file changes against it: refactors, test suites, migrations, tracing a bug across layers. This is the one that earns its place on brownfield work, where the hard part is understanding what is already there.
Codex
Delegated, parallel tasksWell-specified units of work handed off and collected later — a batch of endpoint handlers, a test backfill, a mechanical migration across dozens of files. Useful precisely where the work is repetitive enough to be tedious and exact enough to be checkable.
Cursor
Editor-native, line-by-lineFor the work that is faster to steer than to describe. An engineer stays in the file, with the whole codebase as context, keeping the tight edit-run-check loop that actually produces working software.
Gemini
Very large contextReading a sprawling legacy codebase, a long specification, or years of documentation in one pass to answer a question about it. The tool we reach for when the problem is comprehension rather than authorship.
Lovable
Interface prototypes, fastTurning a screen idea into something clickable in an afternoon. On greenfield work the argument about what the product should do ends much faster when everyone is looking at the same working screen instead of a document.
Replit
Disposable environmentsStanding up a running instance to try an approach without touching anyone's machine or CI. Cheap enough to throw away, which is the point — the ideas that do not survive contact are the ones you want to discover early.
Where This Changes the Most
On a new build there is no legacy to respect and no existing behaviour to preserve, so the ceiling is simply how fast a team can produce and validate good code. That ceiling has moved.
Day one is not week three
Project structure, CI pipeline, authentication, database migrations, logging, error handling. The scaffolding every new system needs and nobody wants to bill you for now takes days rather than the first sprint or two. You start paying for the part that is actually your product sooner.
The prototype becomes the specification
A working screen settles arguments that a requirements document only postpones. Getting one in front of stakeholders early means the expensive change — the one to the data model — happens while it is still cheap.
Two approaches, then throw one away
When trying a second design costs hours instead of a fortnight, it becomes reasonable to build both and keep the better one. That was rarely affordable before, and it is where most of the real value sits.
Tests written alongside, not afterwards
Test coverage is usually the first thing sacrificed to a deadline. When writing them is no longer the slow part, they get written. Our current .NET 10 CRM build carries 550+ backend tests, 322 component tests and 31 end-to-end specs, with a build that fails on any compiler or analyser warning.
We are not going to put a multiplier on this. We have not measured it across a controlled sample, and anyone quoting you a precise figure has not either. What we will say is that the scope one team delivered on our current CRM build — 20 modules, ~180 endpoints, 56 entities, and the test suite above — would have been a materially larger engagement five years ago.
What These Tools Do Not Do
They do not make the architectural decisions
Where the transaction boundary goes, how the data model handles the case nobody mentioned in the requirements, what happens under load, which third-party dependency you will regret in three years. A model will produce a confident answer to all of these. Knowing which of those answers is wrong is the job.
They do not review their own work
Nothing reaches your repository that an engineer has not read and cannot defend in a code review. Generated code that nobody understands is a liability with a delayed fuse, and we treat it as such. If we cannot explain why a piece of code is the way it is, it does not ship.
They do not carry the accountability
When something breaks in production at 2am, the tool is not on the call. We are. That asymmetry is the whole reason the review discipline above is not negotiable.
Yes, these tools run against client code. We use paid business and enterprise tiers configured so that code submitted to them is not retained for model training, and we confirm those terms per tool rather than assume them. We never put client code into consumer-grade tools or free tiers. We tell you which tools we use before an engagement starts, and if you prohibit them we work without them, or restrict them to the parts of the codebase you nominate. That goes in the engagement terms rather than being left to individual judgement. Read the full security and data handling position.
Planning a Greenfield Build?
Tell us what you are trying to build and who it is for. We will tell you what is genuinely achievable, in what order, and where the risk actually sits — including if the honest answer is that you do not need us yet.