Translated by AI Assistant
TL;DR
- opus 4.8 > GPT 5.5/opus 4.6 >= GLM 5.2 >= dpskv4pro/gpt5.4mini
- claude code > codex > cursor »»» copilot (well, actually I mainly use cc and codex)
- Quality code = document first, then develop + full review
- The era of fully automating requirement-to-code conversion has not yet arrived
When I wrote this, 5.6 wasn’t out yet, maybe I’ll try it later (probably…)
Introduction
Having finally graduated from the “problem set” zone, I started my internship. When I first opened Codex at the company and typed in my requirements, having only used Copilot’s autocomplete before, I was shocked and paralyzed, that moment felt like witnessing an atomic bomb explosion (not really).
However, after burning through a lot of tokens, I found that, obviously, I’m still slightly better than the agent.
Agent Capabilities in 2026/7
Actually, not much different from 2026/4
Because of the rapid improvement in LLM coding capabilities and the popularity of Agent harnesses, no one questions whether agents can be used in production environments anymore. From various perspectives:
- Writing code: With complete context and correct guidance, it can produce correct and clean business code, and it’s better than most junior programmers.
- Reading code: Much faster than humans, and almost no hallucinations.
- Automation: With Skills/MCP, it can handle most daily tasks.
So it seems like programmers are indeed useless. However:
- The above (especially writing code) refers to the capabilities of opus4.8/GPT5.5; weaker models easily produce buggy code.
- Complete context does not exist in any software engineering project.
- Unless requirements never change, it’s impossible to provide correct guidance from the start.
So programmers can still play some role with the help of AI, including but not limited to remembering numerous unwritten rules in projects, arguing with stakeholders, and most importantly, you are cheaper than Fable.
Agent: Also a “Problem Set” Drone
The biggest problem with using agents is that LLMs, as end-to-end systems, only care about whether the output looks correct. An agent judges code correctness in two ways: whether it compiles without errors, and whether all tests pass.
This introduces two issues. First, the code agents produce often contains subtle, hard-to-notice bugs (though better and more expensive models are less prone to this now), and some agents even modify the build process or test code to pass. The second issue is more fatal: current agents have almost no concept of software architecture design. Without properly standardizing interfaces and designing abstraction layers, the code will rapidly bloat into an unmaintainable mess.
Moreover, projects often have many unwritten rules and multiple ways to implement the same logic. If left unchecked, agents are likely to use deprecated APIs or reinvent the wheel repeatedly, producing all kinds of throwaway code and glue code. Changing this adds extra mental burden and does not achieve efficiency gains.
So What to Do?
To better utilize agents, my workflow is roughly as follows:
Unwritten Rules and Project Conventions
To handle the many existing and potential unwritten rules in a project, we must include some documents in the project to preserve cross-session conventions for the agent. (Note: these files should be committed to git.)
Of course, use the special file like AGENT.md that every agent has. In Codex it’s AGENT.md, in Claude Code it’s CLAUDE.md. Note: to prevent the agent from stuffing its context with messy content and introducing noise, the agent used for coding should have memory disabled and maintain a project-level memory. The agent will automatically add this file to its context at the start of each session.
What to Write
Here’s the template I currently use:
# This is a sample template for PROJECT.md; if you see this line in an actual project, overwrite this file with the project's actual content.
# Preliminary Requirements
`PROJECT.md` should be written in Chinese, unless commands, paths, code identifiers, or external specifications must remain in their original language.
`PROJECT.md` must not contain any content that cannot be uploaded to the cloud, including but not limited to tokens, keys, credentials, internal addresses, sensitive local paths, personal information, device information, customer data, or undisclosed business information.
# Project Structure
Describe the overall structure of the project, and what each major directory, module, or file is responsible for.
Only record information necessary for the agent to understand the project and locate code later. Do not invent non-existent directories, modules, or responsibilities.
# Rules
Record stable rules that must be followed in the project.
Can include coding standards, technology choices, module boundaries, runtime conventions, testing conventions, implicit side effects, and behaviors that are not explicitly stated in code but must be considered when making changes.
Only write rules that already exist or have been decided. Do not include speculation, temporary solutions, or designs not yet implemented.
# Update Rules
After modifying code, you must check and update `PROJECT.md` in real time, but only record stable information that subsequent agents must know.
Do not include design documents, temporary discussions, implementation processes, one-time troubleshooting records, or lengthy backgrounds.
Updates should be minimal: add necessary information, delete outdated information, and avoid repeating what the code already clearly expresses.
The main points are three: write the unwritten rules inside, synchronize updates with every modification, and keep everything else out. You’ll notice this file is simple and contains almost no development-related content. Don’t worry, there’s a second part:
# Software Engineering Guide
This is a software engineering guide.
If an agent sees this file in an actual project, it should follow the requirements in `PROJECT.md`, organize and migrate the stable rules still applicable to that project into `PROJECT.md`, and then delete `software.md`. Do not copy irrelevant content or include any information that cannot be uploaded to the cloud.
# Development Process
Software development follows this sequence:
1. First, define the requirements document.
2. Then, write the development document.
3. Finally, write the code based on the development document.
At each step, before writing or implementing, you must confirm with the user.
Documents are named uniformly:
- Requirements document: `<name>.req.md`
- Development document: `<name>.dev.md`
## Requirements Document
The requirements document describes the implementation path, input/output requirements, and possible side effects of a feature. It must clarify the technical stack, input/output specifications, and the feature's relationship with the whole system.
## Development Document
The development document must detail the specific implementation steps of the feature, at least including:
* Which module the feature belongs to / what new module needs to be created, and what modules it will affect.
* What code needs to be added/modified in sequence, down to specific functions with their input/output requirements and side effects.
* If modifying existing code, clarify the modification purpose and location.
* If adding new code, clarify the insertion point and functional details.
## Code Implementation
Code implementation must strictly follow the development document. If modifications are needed, revise the development document first, then the code, ensuring consistency between the document and code throughout development.
After development is complete, check the development and requirements documents for any content that cannot be directly reflected in the code (such as unwritten rules or side effects). If found, add comments near the relevant code.
After code review, delete the development and requirements documents.
# Code Rules
When writing code, each module, class, and function must have necessary comments.
Comments don't need to be very detailed, but should at least indicate what the module, class, or function does.
# Testing Approach
Test development also follows the development process:
1. First, write the test-related development document.
2. After user confirmation, write the test code.
Testing should at least include the following levels:
- Unit tests (test all pure functions)
- Module-level smoke tests (test the entire flow of a module, with steps broken down when writing)
- Full smoke tests (test the entire program flow, with steps broken down when writing)
So, drag both files to the project root, then tell the agent to follow them. The agent will generate a project-specific PROJECT file.
Cross-Platform
Wait, what is PROJECT.md? Isn’t it AGENT.md?
This is mainly for cross-platform compatibility. For example, the accompanying CLAUDE.md:
Please read the content of `PROJECT.md`. If modifications are needed, modify them in `PROJECT.md`.
Reference Library vs. Single File
Many agent-related blogs and official documentation of some tools suggest adding an index in the main markdown, placing documents in other markdown files, and implementing a layered structure to save context.
However, I personally think this is not a good practice: first, it means any code modification requires synchronizing updates to the docs, which adds extra token consumption and mental burden; second, documentation is mainly for humans, because humans can’t quickly read the entire codebase, but AI doesn’t have this limitation. With the methodology described later, AI can get enough context just by reading the source code. The purpose of this convention file is mainly to standardize the code produced by AI and record unwritten rules that are not suitable to put in the code.
Pair Programming!
Next, let’s talk about how to assist the agent and together produce high-quality, modular, human-readable, and correct code.
The whole process is simple: write requirements document → write development document → write code → review → test.
Requirements Document and Development Document
Agents produce code too quickly; if you throw a requirement at them directly, it often leads to rapid code bloat. In actual development, implementation usually takes shape step by step during coding; thinking while coding leads to reasonable and high-quality code.
Writing documents before development is already a very common methodology for using agents. Here, the requirements document and development document serve similar roles; for straightforward requirements, you can even go straight to the development document.
- Requirements document: mainly describes the development goal, what tech stack/API/SDK to use, which module to integrate with or what new module to create, and finally how to verify.
- Development document: refines the requirements document into files/API interfaces to be produced, algorithms to use, etc. The development document should ensure that anyone writing code based on it will produce structurally similar results.
This process actually simulates the traditional coding process of writing, thinking, and refactoring as you go. And you’ll find that with good development documents, even Doubao (a weaker model) can get it right!
This methodology also frees up context; the three steps can be done in entirely different contexts, and you can even use an expensive model for the development document and a cheap model for implementation.
Full Review
However, AI-written code can still have many errors or suboptimal parts, so a full review is unavoidable. Don’t be lazy; you can open a session and have the AI review with you.
The Sword of Damocles Over (Game) Programmers
Around April this year, anxiety in the programmer community (especially among the unemployed) began to swell, with everyone worried about whether AI will directly replace entry-level programmers’ jobs. I’m relatively familiar only with the game industry, and the following opinions are mainly aimed at game programmers.
First, the most at risk right now are not recent graduates, but older experienced hires. If a regular soldier loses their job now, it’s very difficult to find another. What I observe is that AI anxiety within companies is widespread; not only are employees worried about being replaced by AI, but management is also worried about falling behind in AI development. Companies with money seem to trust the creativity and plasticity of newcomers more than the experience of veterans.
Secondly, whether a company hires depends on its financial situation, how many projects are running and their revenue, and whether shareholders want to use AI to cut costs and increase efficiency. Overall, large (game) companies are unlikely to use AI to cut costs. It seems that the game industry is gradually emerging from a winter and starting to warm up in 2025, but what will the next 3-5 years be like? I don’t know; after more than three months, I’m still very uncertain about the future direction of the game industry.
Games are arguably the most complex type of software engineering. At the same time, at least half of a game programmer’s job is battling wits with designers understanding and implementing the wild ideas of designers. AI cannot solve requirements with one click, nor can it help you implement a designer’s vision with one click (after all, at first, even the designers themselves probably don’t know what their vision is). Moreover, large projects are still beyond AI’s ability (at least not something programmers without experience can solve), and game code… is full of parts that only colleagues can tell you how to handle. Overall, it’s still relatively safe.