Faster, no corners cut

What faster means, and what it does not

Most software projects are not slow because people type slowly. They are slow because of waiting: for a decision, for a review, for a bug that should have been caught last month to be found and fixed. They are slow because senior engineers spend days on boilerplate that a junior could write, while the hard questions wait for them.

So when we say faster, we mean less waiting and less rework. We do not mean fewer tests, fewer reviews or thinner documentation. Those are exactly the things that make a project slow later, usually after launch, when fixing a problem is most disruptive.

You will not find a promise here that a project takes a fraction of the usual time. Every project is different, and a figure like that would tell you nothing about yours. What we can describe is how the work is organised and how it is checked, so you can judge for yourself, and the milestones in your own schedule are where you will see it.

Agents lay foundations, engineers direct

Every project has a large body of work that is necessary but not novel: the project skeleton, the standard screens and forms, the interfaces between parts, the code that reads and writes records, the connections to well-documented services, and the test suites that cover all of it. It has to be done well, but it does not need a senior engineer's judgment line by line.

In our agentic engineering workflow, AI agents build those foundations. They work to a specification our engineers write, inside the structure our architects set, and every change they make is reviewed by an engineer before it is merged. The agents do not decide what to build, how the system is shaped or whether a change is acceptable. People do.

• Scaffolding: project structure, configuration, build and deployment pipelines, environments.
• Interfaces: the typed contracts between the frontend, the backend and any outside services, written first so every part agrees on them.
• Standard features: forms, lists, detail pages, settings, records that are created, read, updated and deleted.
• Integrations with well-documented services, behind interfaces our engineers define.
• Test suites: unit and integration tests for all of the above, written alongside the code rather than after it.
• First versions of technical documentation, which engineers then correct and complete.

It starts with the specification

Directed agents are only as good as their directions. Before any foundation work starts, our engineers write down what each part must do: the data it holds, the interface it exposes, the rules it enforces, the errors it returns and the tests that prove it. That specification is the same document a human team would need, and it becomes part of the handover.

Writing it first has a benefit beyond the agents. Ambiguities in your requirements surface in the first weeks, as questions we bring to you, rather than months later as features that work but do the wrong thing.

What our senior engineers keep

Moving the foundations to directed agents is not about doing less engineering. It is about putting the most experienced people where their judgment matters most, for more of the project.

The result for you is that the people with the most experience are not spending their week on form validation. They are thinking about how your data is protected, what happens when two people edit the same record, how the system behaves when a third-party service is down, and whether the product does what your users need.

Tests first, and tests of the tests

Code that is produced quickly has to be checked thoroughly, and a test suite is only useful if it actually catches mistakes. A suite can run every line of code and still check nothing that matters. So we test our tests.

Mutation testing is how. A tool deliberately introduces small bugs into the code, one at a time, and runs the tests against each changed version. If the tests fail, the bug was caught; if they pass, the tests have a gap ^[1]. We run mutation testing on the code that matters most: permissions, money, data integrity and anything a regulator or an auditor would ask about.

• Unit tests for logic, integration tests for the parts working together, and end-to-end tests for the journeys your users take.
• Tests that run against a real database, rebuilt from the migrations every time, not against a simplified stand-in.
• Mutation testing on critical code, with surviving mutants treated as defects in the tests.
• Fuzzing and property tests where inputs come from outside: uploads, imports, public APIs and smart contracts.

Reviews at every level

NIST's Secure Software Development Framework makes the point that secure development practices usually have to be added to a team's process deliberately, to reduce vulnerabilities in released software and address their root causes ^[2]. Reviews are the main way we do that, at three levels.

1. 01

   Every change

   An engineer reviews every change before it is merged, whether a person or an agent wrote it. The reviewer checks that it does what the specification says, that it is tested, and that it does not weaken anything around it.

2. 02

   Every milestone

   Before a milestone reaches you, it is tested as a whole on a staging environment: the features, the edge cases, and the journeys from end to end.

3. 03

   Every phase

   At the end of each phase we run a full set of adversarial reviews: people deliberately trying to break the security, the permissions, the data handling and the assumptions. Findings are fixed before the next phase starts.

For web applications we check security against a published standard. The OWASP Application Security Verification Standard is a list of requirements for testing a web app's security controls ^[3], and it gives both sides a shared language for what has and has not been checked.

Verification you can see

You should not have to take any of this on trust. On our projects, the evidence is part of the delivery.

• Every change runs the full test suite automatically before it can be merged, and you can see the results.
• Each milestone is demonstrated on a staging environment you can use yourself before you accept it.
• Review findings and how they were resolved are recorded, so an auditor or your own team can follow them.
• The code, the tests and the history are in a repository in your name from the first week.

Where we slow down on purpose

Some work should never be hurried, and we do not try. A data migration from your old system is rehearsed on a copy before it touches the real thing. A smart contract that will hold value is frozen, reviewed and, where it warrants one, audited externally before deployment, because it cannot be patched quietly afterwards. A model that answers your customers is measured against an evaluation set before every change. Permissions and payments get a second reviewer.

Being quick on the foundations is what makes room to be careful here. That trade is the whole point of the workflow.

What this means for you

• Working software earlier. Foundations arrive quickly, so you see real screens and real data sooner and can correct course while it is still easy.
• More senior attention on what matters. The architecture, security and core logic of your project get more of our most experienced people's time.
• Fewer surprises after launch. Tested tests and phase reviews catch problems while they are still easy to fix.
• A codebase another team can take over. Consistent structure, typed interfaces and thorough tests make handover straightforward.

None of it changes who is accountable. Our engineers are responsible for every line that ships, however it was first written.

Questions to ask any studio about AI in its workflow

1. 01

   Who reviews AI-written code?

   Every change should be reviewed by an engineer before it is merged. Ask how that is enforced.

2. 02

   What is never delegated?

   Security, payments, data models and anything else critical should stay with senior people. Ask for the list.

3. 03

   Where does my code and data go?

   Ask which tools see your code, under what terms, and whether anything is retained or used for training.

4. 04

   How do you know the tests work?

   Coverage alone is not an answer. Mutation testing, or something like it, is.

5. 05

   What do I get to see?

   Test results, review records and a staging environment are reasonable things to expect.