AI-assisted development: how we use it to build tools faster
A behind-the-scenes look at how a small studio uses AI to build software faster - what we hand to AI, the spec-draft-review-test loop we keep humans inside, and what the evidence (GitHub's 55% study and the 2024 Stack Overflow survey) says about where the speed-up really lands.
Ornova Labs is a small studio with a catalogue that keeps growing, and people sometimes ask how a small team ships as much as it does. Part of the honest answer is AI-assisted development. We use AI tools every day to build faster, and we are happy to show how, because the reality is far less dramatic, and far more useful, than the headlines suggest. This is a behind-the-scenes look at where AI genuinely speeds up our work, where we deliberately keep it out, and what the evidence says about both.
It is a companion to our earlier, broader piece on where AI helps with engineering paperwork. The principle is the same in our own codebase: AI is excellent at the mechanical parts and untrustworthy on the parts where being wrong has consequences.
How a small studio ships a lot
A lot of software work is not deep thinking; it is repetition. Scaffolding a new page, wiring up a form, writing the same kind of validation again, looking up the exact syntax of an API you have used a hundred times but cannot quite remember. That work is necessary, but it is not where the value is, and it is exactly the work an AI assistant is good at. Handing it the boilerplate is how a small team frees its limited hours for the parts that actually need a person.
What the research actually says
The honest case for AI in development is not "it does everything", it is "it does the repetitive parts quickly". The evidence backs that up on both sides. In a controlled experiment run by GitHub, developers asked to build an HTTP server in JavaScript finished the task about 55% faster with an AI assistant than those working without one, and more of them finished at all. That is a striking number, but read the fine print: it was a single, well-defined task that everyone already knew how to do, the kind of bounded problem AI handles best.
Now the other side. The 2024 Stack Overflow Developer Survey, answered by tens of thousands of developers, found that 62% were already using AI tools, so adoption is real and widespread. Yet in the same survey roughly 45% of professional developers said those tools are bad at handling complex tasks. Both numbers are true at once, and together they tell the whole story: huge gains on the routine, sharply diminishing returns on the hard, novel, domain-specific work. That is exactly how we have experienced it.
The research and our own benches agree: AI is a fast junior who is brilliant at the boilerplate and out of its depth on the architecture.
Where we lean on AI
In day-to-day building, we reach for AI on the predictable, checkable work. It drafts the first version of a function so we can react to something concrete instead of a blank file. It scaffolds repetitive structure, which is exactly how the pages of this very website were generated from small templates rather than copied by hand. It reminds us of the syntax for an unfamiliar API or a fiddly bit of configuration. It writes a first pass of tests for code we have written. It drafts documentation we then correct. And it is genuinely useful for exploring two or three approaches to a small problem quickly before we commit to one. In every case the common thread is the same as in our paperwork tools: the task is reversible and easy to check, so a wrong suggestion costs seconds, not days.
Our loop: spec, draft, review, test
None of this works as "ask the AI, paste the answer, ship it". It works because it sits inside a tight loop where a human stays in control at every turn.
We start by describing what we want clearly, because a vague request gets a vague, confidently wrong answer. The AI drafts something. Then a person reads it properly, not skims it, and the rule we hold to is simple: we do not ship code we do not understand. Then it gets tested. If anything is off, we go round again. The loop is fast, but the human judgement in the middle is non-negotiable, and that is what keeps the speed from turning into a pile of bugs we do not understand later.
Where we keep humans firmly in charge
The decisions that shape a product stay with us. How the system is structured, what the data model looks like, anything touching security or user privacy, and the question of whether a thing is actually correct, none of that gets delegated to a model. This matters doubly for our products, because they carry real domain logic: railway and engineering rules that an AI does not truly understand and will cheerfully get wrong while sounding completely sure. So the closer the work gets to the substance of what makes a product right, the more it stays in human hands. AI helps us build the scaffolding around the hard part; it does not get to decide the hard part.
Where the speed-up actually lands
It helps to be clear-eyed about where the time is really saved, because it is not evenly spread. AI does not make the hard thinking faster. It compresses the boilerplate around it, which both shortens a task and shifts more of your attention to the part that matters.
The pitfalls we watch for
Working this way has real traps, and pretending otherwise would be dishonest. AI will confidently invent a function or an API that does not exist, so anything it references gets checked against the real documentation. It can produce code that works but is subtly insecure or inefficient, which is why review and tests are not optional. There is also the quieter danger we wrote about before, the pull to trust a fluent answer simply because it reads well, so we treat polish as a reason to look harder, not a reason to relax. And there is a skill cost worth naming: if you let AI write everything and never engage, you slowly lose the understanding you need to catch its mistakes. We use it to go faster on work we could do ourselves, not as a substitute for knowing how.
The honest bottom line
AI-assisted development is real, and for a small studio it is a genuine multiplier, but only in a specific way. It takes the repetitive 80% off our hands and gives us back hours for the 20% that decides whether a product is any good. It does not design our systems, it does not understand our domain, and it does not get to ship anything a person has not read and a test has not checked. The numbers line up with the experience: large gains on bounded, routine work, and little help on the hard, novel parts. Used with that clarity, AI lets us build more without lowering the bar. Used as a replacement for thinking, it would quietly do the opposite. We have simply chosen the first path, and built our whole way of working around keeping a competent human in the loop.