AI Coding: A Concise Guide for Software Engineers

AI-assisted programming is evolving fast. AI agents such as Claude Code and Codex have become essential tools for many software engineers. But when it comes to using AI well inside real projects, the field still looks like a free-for-all.

If engineers on the same team cannot align on the big questions around AI tools, collaboration friction follows, and the project pays the price.

This article summarizes recommended practices for AI-assisted programming for software engineers. It deliberately downplays specific tools and tactics, such as whether to use a spec-driven workflow, and focuses instead on broader questions, such as whether junior engineers should fully delegate bug fixes to an AI agent.

The article has two parts: one for everyone, and one for junior engineers. The second part focuses on that career stage and offers more tailored guidance.

Note: Parts of this article were co-created with jianan and wklken. The views here come from the author’s working environment and may not fully apply to every team or project. Use your judgment.

For Everyone

Remember: the Agent Is Not Accountable for the Code

• AI agents extend human capability. They act like an extra pair of hands, but they are not responsible for the code. You are still the final owner.
• Review AI-generated code and make sure you understand it. Do not commit code you cannot explain.
• A useful test is the Feynman technique: can you explain it clearly to someone without the same background?
• Do not rely on someone else, including AI, to be the final safety net during review. That is not responsible engineering.

Collaborate More, Delegate Less

• There are two mental models here. In a collaboration model, you understand the other party and make decisions together. In a delegation model, you only care about the end result.
• Do not act like a product manager who throws requirements over the wall in natural language and ignores implementation details.
• ~~“I don’t care how it works. This requirement is simple.”~~
• Go deep into the design and structure of the program. Work through the problem with the agent and push toward a better answer.
• One more time: AI is not accountable for the code, and it is not accountable for the project’s long-term maintainability either.

Split Up Your PRs

• AI writes code quickly and in large volumes. It is easy to end up with a PR that changes thousands of lines.
• Large PRs make review much harder. Reviews become shallow, and engineering quality becomes harder to control.
• Do not save everything for one giant drop. Keep PRs small, ideally under 600 lines, move in small steps, and ship in stages.
• If a PR truly cannot be split, provide a design document, such as in the design_notes directory, to help reviewers understand it.

Note: A design document here does not mean a line-by-line spec. It means a higher-level, human-readable explanation of the feature. The core content or structure should ideally come from a person, with AI helping fill in details.

Use Plan Mode and Do More Upfront Exploration

• When building something new, first learn the relevant modules and domain context, and understand the current implementation. AI can help investigate and organize that information.
• Do not let AI start writing code before you truly understand the requirement.
• One more time: use the Feynman technique to check whether you really understand the problem.
• Ask questions first, or use plan mode to clarify the requirement with AI. Learn how to prompt effectively.
• Do not let AI lead you blindly. Think independently. Stay skeptical. Use follow-up questions to open up the solution space.
• Only when you see the problem clearly can you judge whether the AI’s implementation is sound, and good judgment is priceless.

Prefer Stable Libraries Over AI Reimplementing Things From Scratch

• For utilities and libraries, AI tends to “just build it” instead of using a dependency.
• Reinventing the wheel is not always wrong, but...
• For common, well-understood problems, such as gjson, lean toward established libraries instead of asking AI to build a new solution from scratch.
• How do you know which libraries are worth using? Talk to AI, or do the research yourself. Ongoing accumulation matters.
• If several libraries are available, people should choose the best fit for the project based on functional fit, activity level, long-term evolution, and related factors.

Use AI Review Before Opening a PR

• Before opening a new PR, have an AI agent review the current changes and revise the code based on its feedback.
• An AI review before human review can reduce later review load and speed up iteration.
• You can do this with any review skill or with a simple prompt.

Here is an example prompt:

You are an expert code reviewer. Compare the current project against the master branch to understand all changes, then review those changes and produce a report. I care most about:
- logic errors or missed edge cases;
- designs or coding patterns that violate common best practices for the language;
- overly complex class, interface, or function designs that could be simplified;
- code that may create security risks, such as SQL injection;
- places where mature libraries or existing project modules were reimplemented instead of reused;
- any other issues that violate project standards, break consistency, or otherwise look problematic;

Note: reviewing code before opening a PR does not replace later AI review or human review. It is simply an earlier round of self-checking.

Make Changes Verifiable, and Always Verify Them

• For AI-generated code, invest in automated tests and manual verification.
• Never submit untested code and wait for review to catch problems.
• Code review will never catch everything. Some issues only appear when the code actually runs.
• The later a bug is found, the more expensive it is to fix.
• Write automated tests whenever practical, including unit tests and API tests, so the AI agent can enter a verify-fix loop on its own.

Other Advice

• Stay curious. When AI produces a library, pattern, or code fragment you do not know, dig into it until you really understand it.
• Expand your boundaries. Use AI to take on tasks you would probably never attempt without an agent.
• Do the right thing. If the requirement is wrong from the start, AI will help you race down the wrong path even faster. Getting the direction right has never been more important.

For Junior Engineers

Junior engineers usually have less experience with the programming language and the project domain. At that stage, overreliance on AI can hurt learning efficiency and long-term growth. So this group needs more specific guidance:

Quality Matters More Than Speed

• AI is a productivity tool, but early in your career, quality should matter more than speed.
• Shipping low-quality code quickly is usually less efficient in the long run because it leads to repeated review cycles and more technical debt.
• If a slower path helps you learn more, choose the slower path, assuming expectations and deadlines are aligned.

Try Fixing Bugs Manually

• AI agents are very good at fully automated bug fixing, but for junior engineers...
• It is usually not a good idea to hand everything to an agent and let it “fix the bug” without supervision.
• Use chat mode. Bring your own thinking and questions into the process, and deepen your understanding of the project while analyzing the bug.
• That will help you understand the code and architecture faster and more deeply.

One more time: treat the agent as a collaborator, not something you fully delegate work to.

Think for Yourself First, and Look Beyond the AI’s First Answer

• For any task, AI usually gives the answer that is most likely to work, but that does not mean it is the best answer for you.
• If you follow it blindly, you lose the chance to broaden your technical perspective.
• Spend a fixed amount of time, such as 30 minutes, designing your own approach first. Then compare it with the AI’s answer. Have your own solution before you “check the answer.”
• Push hard on the boundaries of what AI can do.

Other Advice

• Let AI question you back. Use Q&A to strengthen your understanding of the project and the related technologies.
• Think of it as having AI run a mock interview about the project with you.
• Read the official docs. AI knowledge has a cutoff date and can hallucinate. Documentation is still the best way to deeply learn a technology. Slow is fast.
• Strengthen your foundation in software design and architecture. Learn design patterns, domain-driven design (DDD), and related concepts.
• At this stage, AI is still not especially strong at end-to-end system design. It performs better when the framework is already clear and the task is a concrete implementation at the function level.
• Good design and a robust, flexible architecture are what make sustainable iteration possible, and that still requires a human in charge.
• Build your own knowledge system through books and deliberate study.
• Watch non-functional requirements. AI often defaults to “the feature works” and overlooks engineering concerns such as security, maintainability, concurrency safety, and extensibility. Pay attention to those on purpose.

Closing

If you have a different view or want to add to this list, discussion is welcome.