AI does somewhere between 60% and 80% of the work on our projects. We lean on it hard, and that's how a small studio ships in weeks instead of quarters. We'd rather say so plainly than pretend every line was typed by hand.
But the other 20–40% is what decides whether the software is actually any good, and that part doesn't automate.
What AI does on a project
It writes first drafts of code, tests, and documentation. It explores options quickly: three ways to structure a feature, five versions of a layout, a dozen ways to word an error message. It reads through large codebases and log files faster than any person can. It handles the tedious parts, like migrations, boilerplate, and repetitive refactors, that used to eat whole days.
What stays with a person
Taste. A machine can make a hundred versions of something. A person has to pick the right one, and know why the other ninety-nine are wrong for this business and these customers.
Architecture and security. What breaks under load, who can get in, and what could leak. These are judgment calls about trade-offs, and the cost of getting them wrong lands on the client, not the model. Client data is never used to train a model. We set that up explicitly with every provider we use, rather than assuming it.
The small details. The thousand things nobody notices until they're wrong: the form that loses what you typed when you hit back, the email that lands in spam, the page that's unreadable on an older phone. Most of those get caught by a person using the thing the way a customer would.
Why we're telling you this
If you're hiring anyone to build software in 2026, they're using AI too. The useful question isn't whether they use it. It's who reviews what it produces, and who's accountable when it's wrong.
Our answer: nothing ships because a machine made it. It ships because a person read it, tested it, and stands behind it.
If you want to see what that looks like on a real project, start at /discuss or browse our work.