People ask us two opposite questions. Some ask whether AI means software should now be nearly free. Others ask whether AI-written code can be trusted at all. The honest answer to both is the same: it depends on which parts of the work you give to AI and which you keep with people. This post describes where we draw that line and why.
Why we build with AI
We use AI because it makes experienced developers faster at a large share of their work. A lot of software is made of familiar patterns: forms, lists, detail pages, API integrations, validation, tests, documentation. These patterns are well understood, and AI tools such as Claude Code and other AI coding assistants can draft them quickly and competently.
When that work speeds up, three good things happen. Clients pay less for familiar parts of a project. First versions reach users sooner. And our engineers spend more of their time on the hard parts, which is where quality comes from.
There is also a quieter benefit: AI makes the tedious parts of quality cheaper. Writing thorough tests, documenting a module and checking edge cases used to be the first things cut when a deadline got close. Now they take a fraction of the time, so they stop being optional.
What AI does in our projects
- Discovery: summarizes interview notes, existing documents and competitor products, and drafts first user stories for us to review.
- Design: produces layout variations and first drafts of interface copy, and helps check designs against accessibility guidelines.
- Build: drafts screens, forms, API endpoints, database migrations and integrations from clear specifications.
- Testing: lists edge cases and drafts unit and integration tests, which engineers extend with the cases that matter most.
- Documentation: drafts user guides, technical notes and handover documents from finished work.
- Maintenance: reads old code and explains it, which helps a lot with legacy systems.
What we still do by hand
Some work does not get faster with AI, or gets worse. We keep it with people.
Understanding the business
AI can summarize what a client wrote down. It cannot notice what they left out, sense that two stakeholders want different things or ask the awkward question that reveals the real problem. That takes conversations, and it is where most project risk is decided.
Deciding scope
Choosing what goes into a first version, and what waits, is a business judgment. It weighs budget, timing, users and risk. We make recommendations; clients decide. AI can list options, but it has no stake in the outcome.
Architecture and data design
How data is structured, how systems connect, where security boundaries sit: these decisions are expensive to change later. AI can propose designs, and sometimes good ones. An experienced engineer decides, writes down why and checks the design against real scenarios.
Security decisions
Access rules, authentication, handling of personal data and secrets are designed and reviewed by people. AI-generated code is checked specifically for security problems, because AI can produce code that works and is still unsafe. See our AI development security checklist.
Review of every change
Every change, whether written by a person or drafted by AI, is read by an engineer before it merges. Tests must pass. Nothing ships unread. Our code review guide describes the checks in detail.
Talking to clients and users
Updates, trade-offs and bad news come from people. When something turns out harder than expected, you hear about it from the person responsible, with options.
Where AI goes wrong
It is worth being specific about the failures, because they shape our process:
- Confident mistakes: AI can call functions that do not exist or misremember how a library works. Tests and review catch these. See hallucination.
- Plausible but wrong logic: business rules that look right but miss an edge case. Tests built from the client's real examples catch these.
- Unsafe shortcuts: missing permission checks or input validation. Security review catches these.
- Inconsistency: the same problem solved three different ways in one codebase. Clear conventions and review keep code consistent.
- Losing the thread: on large, ambiguous tasks, AI output drifts. We break work into small, well-specified pieces.
What this means for clients
Clients get the speed of AI with the judgment of experienced people. Estimates say which parts of a project AI will speed up and which it will not, so the budget is honest. And the code you receive is code an engineer has read, tested and can explain. For more on how this affects budgets, read how AI changes software development cost.
How this will change
AI tools improve every few months, and the line between what AI does well and what needs people keeps moving. We revisit it regularly. Tasks that needed close supervision a year ago now need less. Others, such as understanding a business or deciding what to build, have not moved at all, and we do not expect them to soon.
What will not change is the principle: a person is accountable for every decision and every line that ships. That is what clients are paying for, and AI does not change it.
Read more
For a complete picture, see where AI helps in development and where it does not, our AI-accelerated development page and the comparison with traditional development. If you are planning a project, tell us about it.
