👋 Welcome back to my series: Make it Better. Make it Faster.

This is Part II. If you're just arriving, start with Part I, How AI Coding Actually Works, which covers the vocabulary this piece builds on.

There are two loud stories about what AI has done to software.

One says the job is over: the AI writes the code now, so the smart move is to stop learning how and just tell it what you want. "Vibe code" your way there, forgetting the code even exists. For a weekend project it's genuinely fast and fun, and plenty of impressive demos have been built this way. The trouble shows up later, when that code meets real users and real scale, and "move fast" turns into something unmaintainable.

The other story is the reverse: that most of what these tools produce is "AI slop," plausible-looking code nobody really understands, and the responsible thing is to keep it away from anything that matters.

What I've found, after a year of building almost entirely this way, is that these tools genuinely can make you faster and change how you work for the better without giving up quality, but only on top of sound software practices and a lot of diligence.

My last year using AI exclusively

I've spent the past year building a ton of software, in stretches of genuine amazement and spurts of real frustration. In that time I've hand-written almost no code. I guide AI and review its output. And in that same stretch I've built more software than I ever have: six months of it on a high-performance team at Amazon, then six months on a three-person team at Coniferous. In barely six months at Coniferous I added more than half as much code as I did across nearly a decade at Amazon. Raw lines of code is a crude measure, and I'd never hang an argument on it alone, but a gap that size is hard to ignore. And I believe this software, on average, meets or beats the quality of what I wrote and reviewed as a Principal Engineer at Amazon.

⤢

⤢

A sample of what the last six months turned into:

Spruce

A native desktop app that pulls planning, code, terminals, and AI coding agents into one workspace, with every plan stored as plain markdown in your git repo instead of a cloud silo. Built for small teams who want agents working as real collaborators. It's the product-delivery tool my own team lives in every day, and you can try it at buildwithspruce.com. Status: open beta — free and local-first.

⤢

Tamarack

Screen capture for builders: a desktop studio that turns multi-window screen recordings into polished demos, bug reports, and guides. Every video is described in a small, custom text language, so a recording becomes something you can edit, re-run, and even hand to an AI to annotate. Status: private beta (waitlist).

⤢

A content management system

The docs-and-blog engine behind our websites (used for this post). It renders markdown, then lets you edit any element visually right on the live page: click a paragraph, change it, and it writes the exact lines back to the source file as an ordinary git diff. No database, no separate admin portal. Status: powering our own sites; the rendering half published as open libraries.

⤢

A terminal emulator

Spruce streams live agent and command output inside the app, so we wrote our own VT/ANSI terminal core from scratch in Rust — parser, screen, scrollback, the works, backed by 200+ tests and a fuzzer. Exactly the kind of thing that wasn't worth building before writing code got cheap. Status: in daily use inside Spruce.

⤢

Client projects

A handful of engagements building and untangling software for other teams. Status: ongoing.

But am I actually faster?

It felt fast, and its undeniably significantly more code. But feeling fast, being fast, and delivering more value aren't the same thing. For example, when the research group METR ran a careful study on experienced developers doing real work in codebases they knew well, the developers expected AI to speed them up by about 24%. They came out 19% slower. And even after finishing slower, they were sure the tool had sped them up, by about 20%.

In contrast, in a controlled experiment from GitHub, developers building a web server from scratch finished about 56% faster with an AI assistant. A Google study of its own engineers measured a 21% gain, but the results varied so much from developer to developer that the study couldn't rule out the real effect being zero.

They disagree because they measured different worlds. The GitHub task was small and built from scratch, in a common language, with no existing code to understand and little that could go wrong: the easy end. The METR study took seasoned open-source developers and had them work on their own large, mature projects — repositories they'd maintained for years, where any change has to thread through a mountain of existing code and conventions, and where the bar for merging is high. Against that bar the AI's suggestions often needed so much correcting and reworking to be acceptable that they cost more time than they saved: the hard end.

So where do I land? I believe I'm quite a bit faster with AI, but there are a few reasons why:

It isn't all shipped. Call it 80% of the way there. Some is live, some is close, some is still being shaped. Getting some of these projects ready to release will take quite a bit more effect (the last 20% is usually the hardest bit).

It's all greenfield, and built for AI from the start. No decade of legacy to fight. I got to choose a foundation that plays to an agent's strengths: clean structure, sound naming, high quality from day one because it was written that way, and languages like Rust that pair well with these tools while pushing you toward simpler, safer code.

The environment is unusually clear. A small team, no waterfall, no gauntlet of approvals, the freedom to move fast. Drop the same tools into an org where every change waits on a sign-off and a two-week planning cycle, and you'll find typing was never the bottleneck.

Some code now exists only because writing it got cheap. When the cost of writing code drops, you can build libraries, tools, and features that weren't pragmatic before: a linter for a custom SQL dialect, a terminal emulator, a couple of small domain-specific languages, more robust testing. I wouldn't have taken these all on prior to AI coding tools. And then there are extra bits of polish, the quality-of-life improvement, the nicer user experience, and the "nice to have" I'd have cut for time before — now they get built because building it barely costs anything.

I've stayed disciplined. Its easy to let an agent run and rubber-stamp whatever it hands back; staying on top of what it's actually doing — reading the changes, catching where it went wrong instead of waving it through — is hard work. You need to break the work into pieces small enough to review, keep each change small, and not let the codebase sprawl just because the code is suddenly cheap to produce. You need to refactor regularly. And because an agent leaves you idle while it works, running several streams at once to fill that time is exhausting.

My last six months at Amazon were spent building with these same tools (although the models and tools have also improved quite a bit). That stretch felt faster too, but not nearly at the level of my time at Coniferous so far. I was working in a huge, mature landscape with more microservices, sprawling code bases, layers of leadership review, and the politics of a big org. The typing was never the bottleneck.

So, how has the job changed?

Less than you might expect. AI compresses almost every step: research, design, scaffolding, drafting tests, a first pass at review. But it compresses them unevenly. The mechanical parts collapse toward instant, while the judgment-heavy parts (deciding what to build, choosing the approach, catching what the agent missed, knowing when "done" is actually done) speed up far less. So my days didn't get faster so much as they changed shape: less time typing, more time deciding and guiding and reviewing and verifying. The share of the work that's pure judgment went up signifcantly.

And because each task now spends long stretches waiting on an agent, the way to use that time is to run several at once. Working many things in parallel might be the single biggest change: the job becomes less about finishing one thing than about keeping several moving.

The practices behind good AI development — breaking a problem into small pieces, keeping every change reviewable, holding a high bar for quality — are the same ones good engineering has always had. The teams and developers who already work this way have the least to relearn. For them, adopting AI isn't a reinvention but pointing good habits at a tool that rewards them. You are more likely to struggle without a strong foundation, because the tools tend to expose that gap. My nine years at Amazon gave me a head start on exactly that. Long before any of these tools existed, my team built and ran critical systems by starting from the customer's problem and working backward, shipping small reviewable changes with eyes on each, keeping things simple, and reaching for complexity only when the problem genuinely demands it.

That is part of the reason why one person gets a speedup where the METR study showed otherwise. DORA's research, across thousands of teams, lands on exactly this: AI is an amplifier. It magnifies an organization's existing strengths and weaknesses rather than fixing anything, and the biggest returns come from the underlying system, not the tool. Point it at good practices and they compound. Point it at a mess and you get a faster mess.

From here, the series gets practical. Each post that follows takes one of those long-standing disciplines and shows how to bring it to building with AI: deciding what to build, shaping software an agent can actually work on, breaking the work down, running the review loop, and holding the quality bar high now that the typing is suddenly cheap.

Next: what we actually mean by "quality," and why, when the cost of writing code falls, the cost of writing the wrong code goes up. (Part 3.)

Work with us

We build software this way every day at Coniferous, and increasingly we help teams who want to too, including the ones digging out of a codebase that got away from them. If that's you, we'd genuinely like to hear about it.