The Multiplier

‍The Multiplier

A couple of years ago the AI conversation was about autocomplete. Now it is about whether your engineers are actually getting better or just getting faster at shipping things they don’t fully understand, and I’ve been watching both happen on the same teams, with the same tools.

What you bring in is what gets multiplied

AI doesn’t add skill, it multiplies what’s already there. If you bring deep knowledge of your domain, a clear sense of what good looks like in your stack, and an instinct for when something smells wrong even when it compiles, AI gives you more leverage on all of that. If you bring surface-level familiarity and a backlog of tickets to close, it gives you confident output that looks right until it doesn’t, and by the time you find out, the problem is usually buried three layers deep in a system nobody fully owns anymore.

The engineers I’ve seen get genuinely better using AI treat the output the way a good reviewer treats a PR: with a perspective already formed, reading to understand what it actually does rather than what it appears to do. When the output diverges from what they expected, that’s the interesting part. Why did it do that? Is that approach better, or is it a pattern the model learned from a tutorial that doesn’t apply here? What does the difference reveal about the problem? Every one of those questions is a chance to build something, and the engineers skipping past them to merge and move on are accumulating debt they don’t know they have yet.

What it can’t do for you

There are things AI cannot accelerate, and the list is worth being upfront about.

Judgment about what to build is one of them. You can describe a feature in a prompt and get a working implementation back, but you cannot hand off the question of whether the feature is worth building, whether the abstraction you’re reaching for is the right one for the system’s direction, or whether the thing you’re designing will still make sense in eighteen months. That requires knowing the domain and the users well enough to have opinions, and having been burned enough times to know where the hidden costs tend to live.

System intuition is another. The mental model of how a system behaves under real load, how failures cascade across service boundaries, where the edge cases actually live in production rather than in the spec: that comes from incidents, from long debugging sessions, from reading code other people wrote years ago and trying to understand not just what it does but why it was written that way. AI can help you move faster inside a system you already understand deeply. Building that understanding is still your job, and there’s no version of that process that doesn’t take time.

The third thing, and the one that compounds the most, is knowing what to ask. Getting real value out of AI means being able to frame precise questions: not “implement this feature” but “implement this using these constraints, following this pattern, and avoiding these specific failure modes.” That precision is a direct function of how much you already know about the problem space. The engineers getting the most out of AI are the ones who could have written a detailed spec before they opened a prompt, and what AI gives them is speed, not direction.

How the fast learners are actually using it

The engineers I’ve watched compress years of exposure into months are not generating more, they’re reading more and comparing more and treating the output as a starting point for thinking rather than an endpoint for a ticket.

They ask for multiple approaches to the same problem and spend time on the tradeoffs between them. They use AI to review their own code before sending it to a human reviewer, not to get a green light but to surface the questions they haven’t thought to ask yet. One practice that seems to matter a lot: write the implementation yourself first, then ask AI to do the same thing, then sit with the difference between the two versions. That gap is a map of your own assumptions. Sometimes AI shows you a better way and you understand why. Sometimes your version holds up and you finally understand why that too. Either way you’ve learned something you wouldn’t have learned by generating first.

What this looks like on a team

At Fetchly, I've watched this play out across enough projects to have a clear read on what separates teams that grow from teams that plateau. The ones that compound fastest are the ones where senior engineers have encoded their knowledge into shared conventions, review patterns, and constraints that the rest of the team works inside of, so that junior engineers aren't just learning what working code looks like but what good code looks like, which is a different thing and a harder one to pick up from output alone.

The real risk isn’t that AI makes engineers lazy, it’s that teams start treating shipping velocity as the signal and quietly stop measuring whether understanding is keeping pace with it. At some point the system you’ve built becomes the system you can’t safely change without a week of archaeology first, and by then it’s expensive to fix and hard to explain to anyone who wasn’t there for it.

The engineers who are still getting better in five years will be the ones who used AI to understand more, faster, while holding onto the judgment and domain knowledge and system intuition that the tool still can’t build for them.

The multiplier only works if there’s something to multiply.

‍