How to become a 10x engineer with AI

In the previous post, I shared my perspective on the new 10x engineer in the AI era.

A modern 10x engineer creates outsized impact by turning unclear problems into safe, shippable outcomes with less friction across the team.

AI helps with that, but only if the engineer knows how to use it well.

This is a practical follow-up. Not a framework or checklist, just a set of habits that matter more now if you want to create real leverage with AI.

Build strong fundamentals first

Do not skip the basics because AI can generate code.

This is the biggest trap I see. AI makes it easy to produce something that looks correct. It can generate a feature, a test suite, a migration, a script, or a full page in minutes.

But if you do not understand the system, you cannot judge the output.

You still need to understand how APIs evolve. You need to understand data modeling, transactions, caching, queues, deployment, monitoring, debugging, performance, and security. You need to know how production fails.

AI can help you learn faster, but it should not remove your ability to think.

If you are early in your career, use AI as a learning partner, not as a replacement for learning. Ask it to explain the code. Ask it why a design works. Ask it what can go wrong. Ask it to compare two approaches.

Then verify the answer yourself.

A 10x engineer with AI is not someone who depends on AI blindly. It is someone who understands enough to guide it, challenge it, and correct it.

Write better context

The quality of AI output depends heavily on the quality of context. Before asking AI to implement something, slow down and write the problem clearly.

What are we trying to solve? What is the current behavior? What should change? What should not change? What are the constraints? What are the edge cases? What is the blast radius? How do we verify the result?

This sounds boring, but it is where a lot of leverage comes from.

A vague prompt creates vague output. A clear context creates better execution. That’s exactly why I use the dev-lifecycle skill, it forces the right questions, so the context becomes clear before any execution starts.

For example, “Add a notification when an order is completed” is too vague. A better context would explain when an order is considered completed, which events trigger the notification, which users should receive it, what should happen if the notification fails, which channels are supported, and what tests should pass before shipping.

The goal is not to write a beautiful document. The goal is to make the work executable.

Good context helps humans. Good context helps agents. Good context reduces rework.

Use AI for understanding before implementation

When you enter an unfamiliar codebase, don’t rush to ask AI to change it. Ask it to explain the system first.

Where does this behavior start? Which files are involved? What is the data flow? What are the important abstractions? What patterns does this codebase follow? Where are similar implementations?

This habit matters a lot.

AI can make changes quickly, but fast changes in an unfamiliar system can be risky. You may fix one thing and quietly break another. You may follow the wrong pattern. You may add complexity to a place that already has a simpler convention.

Understanding first, implementation second. If you don’t know where to start, try this skill.

This is also how engineers become more domain-agnostic with AI support.

You may not know the system at the start. That is fine. But with structured knowledge, code search, team agents, and good prompts, you should be able to build enough understanding to contribute safely.

The mindset shifts from “this is not my domain” to “I don’t know this domain yet, but I can inspect it and find a safe path”.

Ask for tradeoffs, not only code

Many engineers use AI like a code generator. That is useful, but limited. A better habit is to use AI as a partner before asking it to write code.

Ask it:

• What are the possible approaches?
• What is the simplest version?
• What can go wrong?
• What is the risky part?
• What is the blast radius?
• What should we test?
• What would make this hard to maintain later?

These questions force better thinking.

They also make you slower in the right part of the process. You spend a bit more time before implementation, so you spend less time cleaning up a bad implementation later.

This is especially useful for junior and mid-level engineers. AI can expose you to tradeoffs you may not naturally think about yet.

But again, don’t accept everything blindly. Use the output as input for your own judgment.

Review AI output like production code

Treat AI-generated code like code written by a fast junior engineer.

It may be useful. It may even be impressive. But it still needs review.

Check whether the code actually solves the problem. Check whether it follows existing patterns. Check whether it handles failure. Check whether it creates hidden coupling. Check whether the test proves the right behavior.

Do not only review whether the code works locally. Review whether it should exist in the system.

That difference matters.

A feature can work and still be the wrong abstraction. A test can pass and still test the wrong thing. A refactor can look clean and still break a subtle behavior in production.

AI reduces implementation time, but it does not remove the need for engineering review.

If anything, review becomes more important because the volume of generated code can increase quickly.

Build verification loops

The faster you generate code, the more you need strong verification.

Tests matter. Type checks matter. Linters matter. CI speed matters. Logs, metrics, alerts, feature flags, canary rollout, and rollback plans matter.

AI speed without verification is just a faster way to create problems.

This is where strong engineering teams will separate themselves from noisy AI adoption.

A weak team may use AI to produce more changes. A strong team uses AI to produce more reliable changes.

The difference is verification.

For every meaningful change, ask yourself:

• How do I know this works?
• How do I know it did not break existing behavior?
• How do I know production is healthy after release?
• How do I roll it back if something goes wrong?

That is not bureaucracy. That is ownership.

Improve the agent after every task

This is one of the biggest mindset shifts.

Do not only use the agent. Improve the agent.

If the agent misunderstood a convention, update the rule. If it misses context, improve the documentation. If it repeated a mistake, improve the prompt. If it needed a command, script, or checklist, create one.

This is how one task turns into a multiplier.

The average engineer uses AI to finish the task in front of them. A high-leverage engineer uses the task to make the next task easier.

That small difference compounds over time.

After a few months, your agents become better. Your docs become better. Your workflows become clearer. Your team spends less time explaining the same thing again and again.

That is real leverage.

Build reusable workflows

A 10x engineer with AI does not repeat the same manual prompting forever.

If a workflow works, turn it into something reusable.

It can be a command. A prompt template. A checklist. A test harness. A script. A repo convention. A team agent. A small internal tool.

The format does not matter as much as the habit.

When you find yourself doing the same thing three times, pause and ask whether it should become a reusable workflow.

For example:

• Requirement review
• Design review
• Test generation
• Code review
• Migration planning
• Incident investigation
• Release note generation
• Monitoring checklist

These are all workflows that can be partially standardized.

The goal is not to remove human thinking. The goal is to remove repeated setup cost so humans can spend more energy on judgment.

Think in systems

Delivering a ticket is useful. Improving the system that delivers future tickets is leverage.

The new 10x engineer does both.

They ship the feature, but they also improve the path. They fix the bug, but they also improve detection. They complete the task, but they also improve the agent, the docs, and the verification around it.

This is the practical meaning of leverage thinking.

You are not only asking, “How do I finish this?”. You are also asking, “How do I make this easier, safer, or faster next time?”

That is the difference between being productive and creating leverage.

Stay accountable for the outcome

The last habit is simple, but probably the most important.

Own the outcome.

AI can help you move faster. It can help you understand code, generate tests, write implementation, summarize logs, and draft documentation.

But the responsibility still belongs to the engineer.

If the code breaks production, it does not matter that AI generated it. If the test misses the real edge case, it does not matter that AI wrote it. If the rollout has no monitoring, it does not matter that AI suggested the plan.

The engineer owns the final decision. This is why I think AI will not reduce the importance of engineering maturity. It will increase it.

The more leverage we have, the more judgment we need.

Closing

Becoming a 10x engineer with AI is not about learning a magic prompt. It is about building the habits that let you use AI safely and repeatedly.

AI can make you faster, but speed alone is not the goal.

The goal is to create better outcomes with less wasted effort, less coordination overhead, and more reusable leverage for the team.

That is what the new 10x engineer should look like.

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.