The new 10x Engineer with AI

The idea of the “10x engineer” has always been a bit controversial.

Some people see it as a myth. Some people see it as a harmful label that creates hero culture. Some people have worked with engineers who clearly create much more impact than others, and believe the idea is real.

I sit somewhere in the middle.

I don’t think a 10x engineer means someone who writes 10x more code than everyone else. That version of the idea was never useful to me. Writing more code is not the same as creating more value. Sometimes, the best engineer is the one who removes code, simplifies the system, or prevents a problem from happening in the first place.

To me, a 10x engineer is someone who creates much higher impact than expected.

That impact comes from how they understand problems, how they recognize patterns, how they design systems, how they debug issues, and how they make decisions with simplicity in mind.

What’s changed

Now, AI changes the equation a little.

Not because AI magically turns every engineer into a 10x engineer. It does not. In some cases, it does the opposite. It helps people produce more code, more documents, more prototypes, and more noise without necessarily producing better outcomes.

What AI really changes is where leverage sits.

Before AI, a lot of engineering time was spent on manual implementation. Writing boilerplate. Searching the codebase. Creating test cases. Reading unfamiliar files. Updating similar patterns across different places.

AI can compress a lot of that work.

But when execution becomes cheaper, the bottleneck moves somewhere else. The harder part is no longer only writing the code. It is deciding what should be built, giving the right context, supervising the output, verifying correctness, and making sure the change is safe to ship.

That is where the new 10x engineer starts to look different.

A modern 10x engineer consistently turns ambiguous problems into safe, shippable outcomes with minimal coordination overhead, while using AI agents to compress execution time.

That sounds simple, but it is not easy.

Because AI does not remove the engineering discipline. It makes the lack of discipline more visible.

If the requirement is unclear, AI will still generate something. If the system context is missing, AI will still make assumptions. If tests are weak, AI-generated code can still look correct while quietly breaking behavior. If the engineer does not understand the domain, the output may feel convincing but be completely wrong.

Fundamentals matter more

Engineers still need to understand systems deeply enough to judge what AI produces. They need to understand architecture, data flow, API contracts, failure modes, testing, security, performance, and production behavior.

AI can help you move faster, but it cannot own the judgment for you.

This is the part I think many people underestimate. If you cannot review the code properly, AI does not make you senior. It only makes you faster at producing things you may not understand.

Context engineering

The new 10x engineer has a few traits that matter even more in an agentic organization.

The first one is context engineering.

Good engineers already know how to explain problems clearly to other humans. In the AI era, this becomes even more important because agents also depend on context.

A strong engineer can turn a messy idea into a clear problem statement. They document assumptions, constraints, edge cases, success criteria, and boundaries. They make the work understandable enough for both humans and AI agents to execute correctly.

Good context reduces back and forth. It reduces hallucination. It reduces rework. It makes execution more predictable.

Problem solving

The second trait is problem solving.

A high-impact engineer does not just take a ticket and ask AI to implement it. They clarify what problem we are solving. They break the work down. They understand the system impact. They think about blast radius. They decide what can be automated and what needs careful human review.

AI helps with execution, but the engineer still needs to direct the work.

Judgment

The third trait is judgment.

Good engineers know when to go fast and when to slow down.

Not every change deserves the same level of review. A copy update, a small UI tweak, a low-risk refactor, and a payment-related logic change should not go through the same mental model.

The AI era needs engineers who can adjust the level of control based on risk.

Move fast when the risk is low. Slow down when correctness matters. Add more verification when the blast radius is high. Keep humans in the loop where judgment is required.

Ownership

The fourth trait is ownership.

AI can generate code. AI can write tests. AI can summarize logs. AI can draft rollout plans. But AI does not carry production responsibility.

The engineer still owns the outcome. Testing is part of the work. Observability is part of the work. Rollout is part of the work. Debugging after release is part of the work.

A strong engineer does not say: “AI generated it”. That is not an excuse.

If you merge it, you own it.

Ambition

The fifth trait is ambition.

I don’t mean ambition as in chasing titles or trying to look busy. I mean the ambition to solve the problem properly.

A high-impact engineer does not stop at fixing symptoms. They ask why the issue happened. They look for the root cause. They remove repeated manual steps. They improve the system so the same class of problem is less likely to happen again.

This is where AI can create a lot of leverage.

The best engineers think in leverage

The best AI-fluent engineers I see do not only use AI to deliver features faster. They use AI to improve the way work gets done.

They improve the agent. They improve the prompt. They improve the documentation. They improve test coverage. They improve the workflow. They create reusable patterns so the next engineer and the next agent can move faster.

This is a different way of thinking.

In the past, work scaled mostly with people. If you wanted more output, you added more engineers. Of course, that also added coordination cost, onboarding cost, and communication overhead.

With AI agents, some types of work can scale differently.

Work starts to scale with the number of useful agents we can add and orchestrate. But that only works if the agents have enough context, enough guardrails, and enough verification.

This is why the 10x engineer in the AI era thinks in leverage. They don’t ask only, “How do I finish this task?”

They also ask:

• How do I make the next similar task easier?
• How do I make the agent better next time?
• How do I make this knowledge reusable?
• How do I reduce coordination for the team?
• How do I turn this solution into a multiplier?

Domain-agnostic engineering

This also changes how we think about domain ownership.

In the past, it was common for engineers to say, “This is not my domain”.

Sometimes that was reasonable. Systems were complex. Knowledge was scattered. Documentation was incomplete. The fastest path was to find the person who already knew the answer.

But with AI support, team agents, structured knowledge, and better context access, I expect engineers to become more domain-agnostic.

That does not mean every engineer becomes an expert in every system.

It means engineers should be able to contribute across codebases more often. They should be able to ask the agent to explain the flow, inspect the code, understand the patterns, identify risks, and propose a safe path.

When structured knowledge is accessible, “this is not my domain” becomes less acceptable as the default answer.

The better answer is:

“I don’t know this domain yet, but I can use the available context, inspect the system, and figure out a safe way to contribute.”

That is a very different mindset.

The environment matters

One thing I’ve learned over time is that engineers don’t become high-impact just by trying harder. The system they work in matters more than we like to admit.

In an agentic setup, that system is everything around them: repo structure, documentation quality, test coverage, CI speed, dependency graph, observability, and how easy it is to understand the system.

If these are messy, even strong engineers slow down. If these are clean, engineers can produce much better outcomes.

Creating more 10x outcomes is less about finding rare individuals. It is also about building an environment where good decisions are easier to make and bad ones are harder to ship.

That is a leadership responsibility as much as an individual responsibility.

Closing

The AI era does not remove the need for great engineers. It changes what greatness looks like.

The new 10x engineer is not a solo hero sitting in a corner producing ten times more code. It is the engineer who combines strong fundamentals, clear judgment, good context, agent orchestration, and deep ownership to create outcomes that scale beyond themselves.

AI gives us more leverage. But leverage is only useful when someone knows where to point it.

In the next post, I’ll go deeper into the practical habits engineers can build to create this kind of leverage with AI. If this perspective resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.