A Tab Is Faster Than Ten Lines

We’ve been using GitHub Copilot for a few months now and I want to write down what it actually changed, because the discourse around AI coding assistants is full of extremes: either “it writes all my code” or “it’s useless and gets everything wrong.” Our experience is neither.

What it’s good at

Boilerplate. The stuff you’ve written a hundred times and will write a hundred more. A while loop with an accumulator. An each_with_object that builds a hash. A method that validates an attribute, raises if invalid, and returns self. These are patterns your fingers know but still take ten or fifteen seconds to type out. Copilot completes them in a tab. It’s not thinking. It’s pattern-matching on code it’s seen before, and for common patterns it’s right almost every time.

We’ve been starting work on a new artifact registry to replace Nexus, and the reduction in typing friction is noticeable. Not transformative. The hard parts are protocol understanding and architecture decisions, which Copilot can’t help with. But the mechanical parts, like parsing a gem, iterating over versions, building a response hash, those go faster.

AI-assisted research

The other place it’s genuinely useful: figuring out how things work. When we needed to understand the Docker v2 registry protocol, the official spec is dense and the documentation assumes you already know the concepts. Asking “how does a chunked blob upload work in the OCI Distribution Spec” and getting a coherent explanation with example HTTP requests saved hours of spec-reading.

Same for the RubyGems compact index format. It’s barely documented outside the rubygems.org source code. Having an AI assistant that could explain “what does a negative version number in the versions file mean” was genuinely useful. It pointed us in the right direction, even when the details needed verification against the actual source.

What it’s not good at

Architecture. Design decisions. “Should the blob store be a separate model or a concern on Repository?” Copilot doesn’t know our codebase, doesn’t understand our product requirements, and can’t weigh trade-offs. It completes the line you’re writing, not the system you’re building.

It also struggles with anything novel. Our HERB template language isn’t in its training data. Sirius2 components aren’t in its training data. When we’re writing HERB templates with Sirius2 components, Copilot either suggests ERB (wrong syntax) or hallucinates component names that don’t exist. For our custom stack, it’s often more distracting than helpful.

The honest assessment

Copilot is a typing accelerator. It doesn’t make us better engineers, but it makes the mechanical parts of engineering faster. The time we save on boilerplate goes into the parts that actually matter: thinking about data models, debugging protocol edge cases, reviewing each other’s code.

That’s a good trade. I’ll take it. But I’m curious where this goes. Code completion is useful. What I really want is something that can participate in the design conversation. Something that understands the codebase, reasons about architecture, suggests approaches. That feels like a different capability than “complete this line.”