It has been three weeks since I started my new role at a company that actively embraces AI for productivity improvement and niche technologies. I would like to share some insights I’ve gained recently on AI-supported efficiency improvement as a software engineer. The main topic of this post is to introduce three preconditions to accelerate software development using AI. In other words, you need to meet these preconditions to make AI serve you better in your software development job.

AI-friendly Codebase

The first precondition is an AI-friendly codebase. This ensures the AI builds upon your intentions instead of generating random ideas.

Introduce Rules & Context

If you’ve used Cursor or a similar code editor, you already understand what I mean. You need to provide global rules that apply to the whole project, acting as a guide or a long-term prompt to require the AI to think within a certain framework.

In this rules file, you need to introduce at least the following:

1. Business scope: What is the project for? What is its functionality boundary? (Although this might change, you can update it as you go).
2. Project context: What kind of application are you building (web, iOS, etc.), and what are your technical choices?
3. Your vision: Ideally, what should the project look like?
4. Best practices: Specify tasks you want the AI to follow (e.g., for every API implemented, you must also write the relevant OpenAPI documentation).

Code Comments > Documentation

In short, there are two reasons for this:

1. Compared to plain text, AI can understand code better because code is unambiguous.
2. Code is always up-to-date, while documentation can become stale.

Therefore, never regard the comments in your codebase as merely unused code or simple functional introductions. They can contain critical business logic as well. You can use comments to explain the reasoning behind a block of code, like why the workflow is designed a certain way, what it used to be, and even who made the decision for these changes. While Git records changes, these in-code comments provide explicit, informative clues for both AI and human developers.

Another reason I think documentation for a code maintainer is becoming less important is because of AI. You can question the AI about anything you need to know as a new code maintainer. Don’t get me wrong, I’m talking about maintainers, not project users or other developers who rely on this project. You still need documentation for those audiences, but it will be much lighter since they don’t care about implementation details. Again, for this to work, you need sufficient contextual comments.

Clean & Semantic Codes/Structure

Just like a human developer, AI prefers code with high cohesion and low coupling so it can add or edit code confidently. No one likes chaos, so this rule is really a code quality concern, regardless of whether you use AI. The code an AI generates will heavily rely on the existing code: garbage in, garbage out. This should be a concern from the commencement of the project and should be maintained at all times. Once the codebase becomes an AI-assisted “shit-mountain,” believe me, nobody will want to touch it.

Strong Build-in Checks

AI has very low retry costs, especially for parallel coding AI tools. Human engineers have limited energy and might forget to perform cumbersome checks that identify minor glitches. This is where strong, built-in checks come in handy. For example, in NodeJS projects, these checks should be configured by developers during project initialization.

1. Linting: Checks code style and prevents unsafe code with bad practices.
2. Formatting: Enforces consistent code format (e.g., indentation).
3. Type Checking: Ensures type safety if TypeScript is used.
4. Testing: Automated tests that indicate logic or functional issues.

These checks must provide feedback with specific file names and line numbers to help the AI locate the cause of a problem, so it can keep retrying until the problem is solved. You are helping the AI increase the quality bar for its output. The most fabulous part is that the human engineer won’t be disturbed, allowing you to plan your next move. You see? Efficiency improved.

Domain Knowledge

The more I work, the more I realize that technical skill isn’t everything for a software engineer, even if you are responsible for key components that are highly sensitive to performance metrics. Product Mindset and Own Your Product are two qualities mentioned frequently. The key principle to gain trust from your project managers is to ensure your delivery meets their expectations, which requires you both to be on the same page. This is why domain knowledge is so highly valued.

1. Shared terminology brings consensus and efficiency.
2. You can identify gaps in understanding between you and your PM early on.
3. It’s beneficial for long-term thinking, especially when you are responsible for system design.

Yes, these principles existed long before AI was invented, but they shine even brighter in the AI era.

1

Product Manager ----> Human Engineer ----> AI

The human engineer now acts more like an interpreter: you rephrase requirements from the PM, add your technical insights, and communicate this to the AI through your prompt. Obviously, the better your understanding of the domain knowledge, the more accurate and effective your prompts will be. Your domain knowledge also helps you break down work into a feasible action plan with clear priorities. Once the scope and context are clear, it’s time to ask the AI to do your tasks simultaneously in the background.

Technical Review

Just like any other skill, the more you work with AI, the better you understand how to work with it. No one will condemn you for having AI generate your code, but the baseline is that you must always know what it is doing. Therefore, the technical requirements for software engineers still remain. Junior software engineers must now inevitably review AI-generated code, a task that was previously beyond their typical scope. Your role shifts to controlling the direction and system design, rather than focusing solely on implementation.

AI is like a performance scaler—a coefficient in your performance formula. The more and deeper your technical knowledge, the more you can drive and the faster your pace. I won’t be surprised to hear the concept of a 50x software engineer in the future. Professor Andrew Ng made an interesting new finding: the ratio of Product Managers (PMs) to Software Development Engineers (SDEs) in Silicon Valley has shifted from the traditional 1:4 to as much as 1:0.5, implicitly proving my point.

Are Software Engineers Cooked?

In short, no—if you adapt to the changes.
AI is changing the way we work, but it’s still far from becoming fully autonomous, which means AI still plays an assistant’s role in software engineering. AI significantly improves delivery speed, so there might be fewer positions in the job market. On the other hand, the emergence of AI flattens the technical gap between people, allowing anybody to create their own product and potentially fill these missing positions with new ventures.

Suddenly I recalled words said by Jacky Zeng (Former CEO of SAGI GAMES): When you plan to replace carriages with cars, have you ever asked opinion from horses?