How We Actually Use AI to Build Software

Understanding what you actually need is a conversation, not a prompt. It involves asking the questions you did not know needed asking: what happens when two users try to do this at the same time? What does this data mean when it is three years old? What does the workflow look like on the day everything goes wrong?

AI cannot have this conversation. It has no knowledge of your business, your users, or the constraints that make your system yours. We do not use AI here. This stage is Rob or Jason on a call or a video, with a blank document and a lot of questions.

• Business requirements gathered from the people who know the domain
• Edge cases identified before they become bugs
• Non-obvious constraints surfaced and documented
• What success looks like, in two weeks and in two years

Before any code is written, we design the system: the components, the data structures, the access model, the integration points. This is the work that determines whether the software survives contact with reality. AI cannot do this reliably because it requires understanding the business, not pattern-matching a schema that looks plausible.

We design the database structure by hand. We define what every table stores, what every relationship means, and what the query patterns will be. We index based on how the data will actually be used. We specify the access control model before a line of implementation code is written. These decisions are made by a developer who has read the requirements and understands the system.

• System architecture: components, boundaries, integration points
• Database schema: tables, relationships, indexes, constraints designed by a human
• Access control model: who can see what, enforced at the data layer
• Security model: threat surface identified, mitigations specified

This is where Claude Code and Cursor come in. We use them to implement the architecture and logic we have designed. Think of it as pair programming with a very fast junior developer: they write a first pass, a senior reads it, understands it, modifies it where needed, and accepts it when it is correct. Nothing ships that a developer does not understand and own.

Claude Code is particularly useful for larger implementation tasks: scaffolding a feature, writing the service layer for a defined API contract, generating the repetitive but necessary parts of a codebase. Cursor sits in the editor for line-by-line assistance. Both operate within a structure a human designed. Neither decides that structure.

The speed saving is real and it is what we pass on in project costs. The quality gate is unchanged: every line is understood before it goes in. A junior who writes fast but whose work is never reviewed is a liability. A junior whose work is reviewed by someone who knows what to look for is an asset.

• Claude Code and Cursor used for implementation within the defined architecture
• Every significant output reviewed and understood by a senior developer before acceptance
• Business logic written and owned by the developer, not delegated to the tool
• Security-critical code written by hand and reviewed separately

We use AI to accelerate test generation, particularly for generating test cases that cover the edge cases we have identified in requirements. The developer reviews every test to confirm it actually tests the intended behaviour, not just that the code runs without crashing. Tests generated without understanding are not tests; they are the appearance of tests.

• AI generates test scaffolding and common case coverage
• Developer writes or reviews tests for every edge case and failure mode
• Security tests written by hand: injection, access control, boundary conditions
• Tests are run against realistic data volumes, not just the happy path

Every significant piece of code is reviewed by a second developer before it goes anywhere near a production environment. The review checks that the implementation matches the specification, that security assumptions are correct, and that nothing has been introduced that the original developer missed. This is not a formality.

Security review is a specific pass: access controls checked end to end, input validation confirmed, any external data treated as untrusted. This is the stage where the "AI didn't add the authorisation check" problem gets caught, if it somehow occurred. It does not reach production without this review.

We use AI to accelerate documentation: generating first drafts of technical notes, summarising what functions do, producing inline comments. A developer reads every piece of documentation and corrects it where the AI has described what the code does rather than what it means in the context of the business.

The goal is that a developer who has never seen the codebase can understand the key decisions, find the relevant business logic, and make changes with confidence. This is not a vanity deliverable. It is what makes the software maintainable five years from now, when neither of us remembers writing it.