AI Is Writing Code – So We Can Focus on Your Real-World Problems

Somewhere between 40 and 50 percent of the code written in 2025 was not written by a human. It was generated by an AI, reviewed by a human, and shipped into production. That number is rising. The AI developer-tools market is growing at above 25% CAGR, and every major IDE, code platform, and engineering workflow now has AI built into it.

The narrative that usually follows is one of two extremes: either AI is going to make engineers redundant, or AI is just an autocomplete toy that senior engineers do not really use. Neither is true, and both miss the more interesting thing that is actually happening.

What AI is doing — for the teams using it well — is shifting where human engineering effort goes. And for clients commissioning software, that shift has meaningful, practical consequences.

What AI Is Actually Taking Over

To understand what changes, it helps to be specific about what AI coding tools are actually good at right now. They are not good at everything. But they are very good at some things that used to consume a significant fraction of a senior engineer's day:

Boilerplate and scaffolding. Setting up a new service, writing CRUD endpoints, configuring a testing framework, generating TypeScript types from a schema — these are tasks with well-defined patterns that AI executes reliably and fast.

Repetitive transformations. Migrating an API from REST to GraphQL. Converting a class-based React component library to hooks. Renaming conventions across a large codebase. Tasks that are tedious and error-prone for humans are low-effort for AI.

Test generation. Given a function or a component, AI can generate a comprehensive suite of unit tests — including edge cases a tired engineer might miss — in a fraction of the time it would take to write them manually.

Documentation. Writing JSDoc comments, generating README files, producing API documentation from code — all tasks that engineers often deprioritise and AI can handle well.

These are not trivial tasks. Collectively, they represent a substantial portion of the hours that go into a software project. When they are handled largely by AI, the humans involved can do something else.

What Engineers Now Do Instead

The engineers on an AI-augmented team are not less busy. They are busy with different things — and, in our experience, more important ones.

System design and architecture. AI cannot tell you how to structure a distributed system for your specific scale and failure tolerance requirements. It cannot decide where the service boundaries should be, what data model will support five years of product evolution, or when an abstraction is premature. These are judgment calls, and they determine the maintainability and cost profile of a system for years.

Domain modelling. Understanding the business problem well enough to model it correctly in software — what entities exist, what rules govern them, what edge cases the domain inherently has — requires domain expertise that AI does not have. Getting this wrong is expensive. Getting it right is what separates software that ages well from software that becomes a liability.

Product thinking. The best engineers on a product team are not just implementers. They question requirements, identify simpler solutions, spot second-order effects of design decisions, and push back when the spec will produce a worse product. AI does not do this. Humans do.

Integration and governance. In complex systems, the hard problems are usually at the seams — where services meet, where third-party APIs integrate, where data flows across boundaries. This is also where security vulnerabilities, compliance risks, and data integrity issues live. AI-generated code at these seams requires careful review by someone who understands the full system.

The net effect is that a senior engineer working with AI is doing more of the work that only a senior engineer can do, and less of the work that is just execution of a known pattern.

What This Means for You as a Client

If you are commissioning a software project in 2026, the AI shift in how code is produced has three concrete implications for what you get:

Faster Delivery on Established Patterns

Projects that involve well-defined technical work — building a new service in an established architecture, migrating a platform to a new stack, rebuilding a UI to a design system — move significantly faster with AI assistance. The boilerplate that once consumed the first two weeks of an engagement now takes hours. New features that required a full sprint now require a day of focused work followed by review.

This is not a promise of cutting corners. It is a genuine reduction in the time cost of tasks that are mechanically complex but intellectually routine.

More Budget for the Work That Matters

When the implementation of known patterns costs less, the budget that would have gone to boilerplate can go somewhere more valuable. In practice, this means:

• More time on UX research and design quality — the parts of a product that directly shape whether users adopt it

• More time on domain modelling — getting the data structures and business logic right rather than just functional

• More time on observability and documentation — the work that determines whether the system is maintainable two years from now

Better products do not always cost more. They come from spending the available budget on the right things.

Lower Long-Term Maintenance Cost

Maintenance cost is determined primarily by two things: the quality of the original architecture and the quality of the tests and documentation. When engineers spend less time on repetitive implementation, they can spend more time on both. The compounding effect over a product's lifetime — fewer regressions, faster onboarding of new engineers, easier extensions of existing functionality — is significant.

A system built by an AI-augmented team that invested the time savings in quality is cheaper to run than one built entirely by hand that cut corners on tests and documentation to meet a deadline.

How We Do It: Our AI-Use Playbook

We are transparent about how we use AI in our work, because we think clients deserve to know. Here is the framework we operate by:

Every AI-Generated Change Paired with Senior Review

No AI-generated code ships without a senior engineer reading it. This is not a formality — it is the mechanism that catches the things AI gets wrong. AI is confidently wrong in ways that are sometimes subtle: a security assumption that does not hold in your specific context, an abstraction that is locally sensible but globally inconsistent, a test that passes but does not actually test the intended behaviour. Senior review is the quality gate.

Tests First, Always

We use AI to generate test suites, but we treat tests as a first-class output — not an afterthought. Before AI-generated implementation code is considered complete, the corresponding tests exist, pass, and cover the edge cases that matter. AI is actually useful here: generating tests for a piece of logic often reveals ambiguities in the specification that would otherwise surface as bugs in production.

What We Will and Will Not Automate

We maintain an internal AI-use playbook that defines where AI assistance is appropriate and where it is not. The things we will automate: boilerplate, test generation, documentation, repetitive transformations, scaffolding, code review assistance. The things we will not automate: architectural decisions, security-sensitive integration code without explicit human design, domain model design, and anything where a mistake has compliance or data integrity consequences.

The playbook is not static. We update it as the tools improve and as we learn from our own experience. But the principle behind it does not change: AI handles pattern execution; humans handle pattern selection and judgment.

Governance and Observability by Default

AI-generated code can accumulate tech debt faster than hand-written code if it is not governed. We address this by treating observability — logging, monitoring, alerting, and structured error handling — as a non-negotiable output of every project, not a nice-to-have. Systems we build are designed to be understood when they go wrong, not just when they work.

The Honest Version of the AI Story

The honest version is not that AI has made software development easy. It has made certain parts of it faster — and raised the stakes for the parts that remain hard.

If you are working with a team that uses AI to cut corners on architecture, security, and review, you will feel the consequences. The speed gain will be real, and so will the debt. The system will ship faster and age worse.

If you are working with a team that uses AI to move faster on the routine work and invests the time savings in quality, judgment, and domain understanding, you will get something better and more durable than you could have got before — often at a comparable cost.

That is the version we are building towards. If that is the version you want, the conversation starts with what you are actually trying to solve.