career

The 10x engineer

The 10x engineer

The 10x engineer is an old idea. Given the same tools and the same hours, some engineers get far more done than others, and for decades the industry has argued about whether that is real or a hiring slogan. AI brought the phrase back with a new meaning. Anyone with a subscription can now produce in a day what used to take a week, and it is tempting to call that 10x.

Last week I wrote about the three pillars the profession now stands on: the skills, working with AI, and the product. This post is about the engineer who has all three, because that is who the 10x engineer turns out to be.

Everyone got the same accelerator

AI is an accelerator, and it accelerates the work of all of us. The same models are available to every engineer at the same price, and the tools around them are a download away. A speed-up that everyone gets cancels out when you compare one engineer with another. What remains is the difference that was there before AI: how much each of them knows, and how much of the work around the code they can do.

So using AI is the smaller part of being 10x. The larger part is knowing more than the average engineer, having mastered the craft, and having expanded into the professions next to it. The model multiplies all of that, and it multiplies the gaps just as readily.

Knowing more than the average

A model writes what it is asked for, quickly and with the same confidence whether it is right or wrong. An engineer who knows the domain asks for the right thing. One who does not gets the wrong thing at the same speed, and has no way to tell the difference.

Mastering the craft is what closes that gap. It comes from years of building things, shipping them and watching some of them break, and with AI doing most of the typing, it is most of what an engineer adds to the work. An experienced engineer reads a model's plan and sees what is missing before any code exists: the failure case nobody mentioned, the migration that has to run before the deploy, the dependency that will not survive the first large customer. They know what done looks like, so they review a change in minutes and send it back with one precise sentence. Someone without that background spends an hour on the same change and approves it anyway.

The professions next door

Mastering one craft used to be the whole job. Engineers handed the design to a designer, the servers to operations, the priorities to a product owner and the testing to QA, and each of those was somebody's full-time work.

AI made those professions reachable. An engineer who already understands systems can now draw a credible mock-up, keep a design system the rest of the team builds against, write the Terraform for three environments, turn a customer's request into acceptance criteria, and decide which request is worth building at all. The model fills the gaps in each of them. The mastery from the first craft is what tells the engineer when a mock-up hides a bad flow, when an infrastructure change is riskier than it looks, or when a feature request is really a different problem.

Each of those used to be a role, and often a team. For the last year I have been the architect, the software designer, the UI and UX designer, the coder and the QA on the features I build, and usually the person who decided what to build and keeps it running in production. An engineer who can cover most of those roles, well enough and at AI speed, gets ten times more done than one who only writes the code faster, and the ten has more to do with how many roles one person covers than with the speed of any one of them. That engineer can take a feature from the first conversation with a customer to the server it runs on, without handing it to anyone along the way.

Deyan Peev

Founding Engineer in Sofia, Bulgaria. Currently at 1club.

© 2026 Deyan Peev