AI coding assistants, one year in

We’ve had AI coding assistants in our daily workflow for a while now: Copilot in the editor, Claude Code and Cursor for the bigger lifts, the various “coding agent” features that file pull requests on their own. Enough time has passed to say something more useful than the hype or the backlash. This is what actually changed, written for two audiences: developers deciding how much to lean on these tools, and the non-technical owners paying for software built with them.

The numbers are real

GitHub’s Octoverse 2025 report is the closest thing to a sector-wide scoreboard, and it’s striking. Roughly a billion commits pushed in 2025, up about a quarter year over year. Pull-request volume up a similar amount. Something like 36 million new developers joined GitHub in 2025, close to one a second. Around 80 percent of new developers use Copilot in their first week. A Copilot “coding agent” was credited with over a million merged pull requests in five months. TypeScript became the most-used language on the platform.

So the tools are not a curiosity. They’re woven into the default way software gets made now, and the volume of code being produced has genuinely jumped.

What’s genuinely better

For us, day to day, the wins are concrete and unglamorous:

• Boilerplate and scaffolding. The CRUD layer, the form validation, the API client, the test fixtures. The stuff that’s tedious rather than hard.
• Unfamiliar territory. “How does this library’s auth flow work,” “write the regex for this,” “what’s the idiomatic way to do X in this framework.” It’s a faster, more patient way to read documentation.
• One-off scripts. The migration, the data-cleanup pass, the throwaway tool. Things where correctness matters less because you’ll run them once and look at the output.
• First drafts. Of documentation, of a function, of a test suite. A first draft to react to is faster than a blank page.
• Bounded agentic tasks. “Add this endpoint following the pattern in that file.” “Bump these dependencies and fix whatever breaks.” “Rename this thing everywhere.” A human reviews the diff, but the agent does the typing across twelve files.

Used this way, an AI assistant is a fast typist and a tireless rubber duck. We’re not giving that back.

What didn’t change

The honest part.

It doesn’t architect your system. It will happily generate a plausible-looking solution to the wrong problem. Deciding what to build, how the pieces fit, what the data model should be, where the seams go: that’s still the job, and the tools don’t do it.

It doesn’t know your business. The thing that makes small-business software hard was never the typing. It’s that the real world is messy: the legacy spreadsheet everyone actually uses, the supplier whose API is held together with tape, the regulation that applies only on Tuesdays. AI helps least with exactly that part.

The failure mode got worse, not better. A junior developer who’s stuck writes code that obviously doesn’t work. An AI that’s “stuck” writes code that looks completely fine and is subtly wrong: an off-by-one, a missed edge case, a security check that’s present but ineffective. The bugs pass a glance. They don’t pass careful review. Which means:

Review matters more, and the data suggests it’s slipping. The same Octoverse report that shows commits up shows commit comments down about a quarter. More code, reviewed less. That’s not a productivity win; that’s debt with a delay on it.

Nobody we know fired an engineer because of Copilot. They shipped more per engineer. A year in, “AI replaces developers” is still a sales pitch, not a thing that happened. What did happen is that a developer with good judgment got faster, and a developer without it got more confident, which is not the same thing, and is arguably worse.

If you’re paying for this, or paying a shop that uses it

A few things worth knowing as the person writing the cheque:

• Yes, your developers should be using these tools. A shop that refuses to is leaving speed on the table for no good reason. This is table stakes now.
• No, it doesn’t make the project a third of the price or a third of the timeline. The bottleneck in most small-business builds was understanding the problem, integrating with the messy real world, and not shipping bugs. AI helps the first the least and the last the least. It compresses the boring middle. That’s worth real money; it’s not a 3x discount.
• The question to ask a shop isn’t “do you use AI.” Everyone says yes. The question is “how do you review what it produces,” because that’s the part that determines whether you get faster delivery or faster bug accumulation.
• Be wary of anyone selling “we built it entirely with AI” as a feature. Built with AI, reviewed by people who understand it: good. Built by AI, shipped because it compiled: that’s the codebase you’ll be paying someone to untangle in eighteen months.

How we use it

The rule we land on, internally: treat the output the way you’d treat a fast, well-read junior’s. Use it constantly. Trust it never. Review every line that’s going to production with the same eyes you’d use on a pull request from someone you’re still getting to know, because, functionally, that’s what it is.

That’s not a grudging take. We’re genuinely faster than we were two years ago, and the tools are a real part of why. But “faster” only stays a good thing if the review keeps up. The studios that get burned by this won’t be the ones that adopted AI. It’ll be the ones that adopted it and quietly stopped reading the diffs.

If you’re evaluating a software project and want a straight answer on what AI does and doesn’t change about the scope, send us a note.