I used to rail against the myth of the 10x engineer: the idea that some developers could generate 10x as much code as the average developer. In my experience, anyone claiming to be a 10x engineer usually generated 10x the mess for the rest of the team. The real 10x engineer was the one with the judgement to work on the high leverage points to make the rest of the team more productive.
Well irony of ironies, AI tools have turned us all into 10x engineers. Not only can we generate code 10x faster, or maybe even more, than before, but we can also generate 10x the tech debt and security vulnerabilities if we don’t do things right.
Take these two recent examples
- GitClear analyzed hundreds of millions of commits and found throughput gains due to AI are real but so is the debt it accrues. Even scarier, the debt concentrates among developers who have not recognized the failure modes. [1]
- Veracode tested how over 100 models performed on 80 security-sensitive tasks and found that ~45% of AI-generated code introduced a known vulnerability even across two years of model generations [2]
Clearly, just taking AI code generation tools and saying “go” introduces serious risk. It might be fine for a weekend hobby project, but it’s reckless to do so in business. But there are some things we can do to take advantage of the productivity gains from AI while also being responsible and safe.
Avoid the siren call of one-shotting
Given the power and speed of tools like Claude Code and Codex, it’s very tempting to just throw a problem at the AI and tell it to build the whole thing while you go get coffee.
But research in the field has shown that people who go slow, plan first, and work incrementally actually end up with better results and deliver the project faster in the long run. Seems counterintuitive? Not really if you understand how the AIs work.
AI models need context or they make guesses and often they guess wrong. And the context window for AIs is not infinite. So it’s important to provide proper context to the AI but not overload it. If you overload the AI, it will make incorrect assumptions and you’ll spend more time trying to correct problems and mistakes.
The first best practice is to prioritize writing solid documentation and make this part of your infrastructure, not an afterthought. The specs become a “load bearing” part of how you build, because without it your AI is working off insufficient information. It’s fine to use the AI to help you write a spec, design doc or test scenario, but the important thing is that you review it, ensure it’s not missing any details, and commit it to source control. As you build more features and your app evolves, make sure to also update the documentation (possibly with AI’s help).
Ironically, the industry spent fifteen years fleeing heavyweight specs and favoring working software over documentation. But AI agents have brought back the importance of documentation in a new form: version-controlled, testable, and consumed by machines.
The second best practice is to stop “one-shotting” the problems and instead learn to break them down into small pieces. Remember - AIs do better with smaller problems. This is where having software development experience actually matters. Seasoned engineers will be able to better understand how to break the goal down into manageable chunks that the AI can reason through well.
The third step is to leverage chain-of-thought (CoT) prompting to work through the problem. You ask the AI to walk through its thinking, validate its assumptions, and consider different aspects, and provide recommendations.
[Your question or task]
Break this down step by step:
1. [First aspect to consider]
2. [Second aspect to consider]
3. [Third aspect to consider]
4. [Final recommendation/answer]Or
[Your question or task]
Analyze this by:
1. Identifying the core problem
2. Listing constraints and requirements
3. Evaluating potential approaches
4. Recommending the best solution with reasoningOr even just
[Your question or task]
Let's think step by step.The last piece of advice is to put the above steps together and implement in small, iterative agentic loops:
- Analyze the problem and break it down into small pieces
- Plan (using chain of thought) and document
- Implement & Review
- Test
- Commit
- Repeat
Keep your tasks small and avoid the trap of smushing a bunch of changes together. This ensures that you can be confident that:
- the changes are what you intended
- the code is clean
- the increment can be understood by humans
- if there’s a bug found later, the issue can be easily traced back to the PR that introduced it
This is essentially agile done even faster, because the old constraint of code velocity has been shrunk. But we are still keeping the advantages of agile.
Compensate for human laziness
We humans like to optimize for the easiest path, and it’s easy to think that the AI can ensure the code is safe and accurate. After all, testing and QA is hard, boring, and tedious. But a Stack Overflow survey found that 66% of respondents reported that AI generated code was almost right, but not quite [3]. We have to remain vigilant to catch the code that’s close but not quite right.
But it’d be ridiculous to think that humans have to review all AI-generated code, especially since the models keep getting better and better. The key is to prioritize human-in-the-loop effort based on a risk severity matrix:
- Use purely mechanical review (linters, SAST, test coverage, etc) for simple, low risk changes
- Use AI agents for medium risk, structural changes
- Require a senior human review for important changes and to review whether large changes are correct, fit the architecture, will scale, etc. Enforce a checklist of review items that force devs to actually think deeply about the code.
In addition to review, all PRs must come with actual verification of correctness. Ensure tests are written and passing before review.
Make sure the process also enforces that documentation is updated with each PR, otherwise how can we trust that the AI crafted the PR based on accurate information? This also makes it easier for humans to understand the PR.
Don’t let skills atrophy
In the past, software developers’ skills would be constantly tested and improved by the everyday work of building software. Now with AI, that is no longer the case. The AI is doing the work that used to help us sharpen our tools. If you do nothing, then developers’ skills will sublimate over time.
Research is already backing this up. Anthropic’s own investigation found junior engineers using AI scored 17% lower on mastery without finishing faster [4]. In other words, they stopped learning and gained nothing. Meanwhile 80–90% of engineering questions are now posed to an AI instead of to a nearby colleague, which removes the learning that previously came from struggling through a problem with a mentor.
The only solution is to prioritize and emphasize deliberate continuing education. This means setting aside time for developers to build things without AI. It means setting up case studies of feature breakdowns or production incidents that walk developers through the code with the sole intention to teach. It means making mentorship a core part of seniors’ performance evaluation, and the mentorship needs to be explicitly assigned and tracked.
If we don’t work hard at keeping our skills honed, we will discover in a few years that we are unable to understand our own code and are dependent on the AIs (and AI companies) just to function.
Next Steps
For any software organizations moving to agentic AI coding, there are a lot more best practices and they are constantly evolving. The important part is to not be reckless or naive to think that AI is a silver bullet. Keep having conversations with your teams about the importance of traceability, reliability, trustworthiness and sustainable code. Keep discussing what you can do to ensure that your team is not just 10x as fast, but also 10x as responsible.