Half a year ago, our team began to implement AI programming for all employees.
From Claude Code and Cursor to self-developed Agent scripts, almost all daily business iterations are transferred to the AI-assisted development pipeline. At that time, everyone was very excited, and the words in the daily weekly report changed to “efficiency increased by 200%” and “demand was delivered two days in advance.” Some students even lamented at their work stations: According to this rhythm, the CRUD work that used to be done in a week can now be completed in one afternoon. The good days of programmers have finally come.
But the excitement period only lasted for more than two months.
In the third month, things began to change: the delivery rate in the weekly report was still good, but the integrated joint debugging of the test environment was directly stuck; after finally getting online, alarms began to sound frequently at night. What’s even more terrible is that several core senior developers are pulled online to work as “firefighters” to put out fires every day. Not only do their average working hours not decrease, but they get off work later than before.
At that moment I suddenly woke up:
Code is indeed being produced faster and faster, but system corruption is also increasing three times as fast.
These six months of intense practice and pitfalls have completely shattered my original illusions about AI programming. In the process of reviewing accident codes and online rescues countless times, I experienced three profound cognitive overturns, and finally got a low-level epiphany about programmers’ survival cards.
1. The first cognitive overturn: prompt word superstition shattered, physical slicing is the real skill
When they first start programming with AI, almost everyone will fall into the obsession of “prompt word tuning”.
I have also written system instructions that are thousands of words long. CLAUDE.md Or the rules file lists everything in detail: “It is forbidden to use magic numbers” “Exceptions must throw a custom BusinessException” “Controller is prohibited from injecting Repository” “Each method must have JavaDoc”… Trying to rely on an extremely perfect “Prompt Bible” to let the model directly spit out impeccable production-level code.
As a result, reality slapped me hard.
When the prompt words pile up and get longer, the AI’s performance not only does not get better, but becomes extremely weird: it starts to focus on the beginning and ends, and the attention window is diluted by a large number of irrelevant details. It even leaves fatal logic loopholes in the main business logic in order to meet the format requirements of a certain detail in the prompt words.
Later I figured it out:In the face of large models, trying to use natural language rules to replace engineering physical boundaries is purely a matter of course.
What really makes a qualitative difference in AI programming is never the metaphysical prompts you write, but theDoes your code base itself have clear physical slices?：
- Does your module follow high cohesion and low coupling, and does it have a clear domain boundary (Bounded Context)?
- Is your interface contract strictly determined, and do DTO and VO have strong type constraints?
- Do you keep your core business methods short and single-responsibly so that the AI only needs to read 200 lines of context to complete the change, rather than forcing it to understand 3,000 lines of legacy code at a time?
When the architecture slice is sharp enough, you even only need to send a simple sentence to the AI: “Impotent verification of payment callbacks, relying on the local order table state machine”, and it will be able to accurately deliver perfect answers; but if the code itself is a chaotic mountain of shit, and you write a 10,000-word prompt to it, it will only add another layer of more hidden garbage to the chaos.
2. The second cognitive overthrow: junior developers were not replaced, and senior developers were driven crazy by Review first.
There is an argument in the market: “AI will eliminate junior programmers first, and architects can kill a R&D team with a few agents.”
After half a year of practice, I found that the opposite is true:Not only did junior programmers not disappear, but senior developers and architects were dragged into hell first.
In the past, junior programmers were slow to write code. Although they occasionally had grammatical or formatting flaws, because each line of code was typed by themselves, when a problem occurred, you could follow his train of thought and ask, “Why did you design it this way?” The chain of responsibility and thinking logic were clear and traceable.
After using AI, many students with little experience have become “Tab blind people”: whenever the AI prompts code, they will hit Tab wildly, and if the local unit test fails, they will directly submit a Pull Request.
On the surface, the code format is neat, the variables are well-named, and the comments are detailed and complete. But once you get down to the architectural level, disaster reveals its fangs:
- There is no designed timeout for cross-service calls, and an avalanche will occur as long as the downstream jitters;
- Redis distributed locks are issued wildly in the loop body, and a piece of data is measured locally very quickly. During the concurrent stress test, the connection pool is instantly exploded;
- In order to save trouble, the logic that should be asynchronously decoupled from domain events is stuffed into a huge main library single transaction.
The mental cost of reviewing a piece of AI code that “can’t find faults on the surface, but hides a fatal murderous intention underneath” is three times higher than writing a piece of code by hand.
Senior engineers have become round-the-clock human compilers and architecture nannies. If strict architectural red lines and interception fences are not established, uncontrolled AI efficiency improvements will only directly bring down the architectural quality of the entire team.
3. The third cognitive overturn: the code asset theory is shattered, and code has become the cheapest consumable.
When we first entered the industry ten years ago, old engineers always taught us: “We must treat code as the core asset of the team and accumulate it.”
We carefully design general tool classes, build underlying abstract frameworks, pursue elegant inheritance systems, and regard writing exquisite and complex code as the core source of technical honor.
But in the AI era, the biggest shock I have experienced is:Code has been completely devalued from a “high-value asset” to a “low-value consumable item with almost zero production cost.”
When a large model can spit out 500 lines of implementation in two seconds, lines of code itself, skill, and even syntactic elegance are no longer scarce. On the contrary, the more code, the heavier the maintenance burden of the system.
What are the assets that truly cannot be replaced by AI and become more valuable over time?
yesTrade-off and Domain Boundaries behind system architecture。
- Should this business use strong consistency or eventual consistency?
- In high-concurrency scenarios, how much data visibility window are we willing to give up for availability?
- How to achieve strong fault isolation in the physical deployment of payment links and notification links?
AI cannot give you any of these top-level decisions that determine the life or death of the system. It has no business common sense, no pain of real loss of online assets, and it will not be legally responsible for the P0 accident call at three in the morning. Transferring the power of architectural thinking to AI is gambling with the company’s core lifeline.
4. An existential epiphany: from typewriter to system arbiter
After experiencing these three overthrows, I finally touched upon the crucial survival epiphany on the ruins of production:
AI is indeed the most powerful amplifier of this era, but the only determining factor in how large the product of the entire calculation is is the previous base number – that is, your architectural design thinking.
If your architecture base is 10:
If you have a clear division of DDD domains, a standard state machine anti-corrosion layer, and strict idempotence and disaster recovery plans, AI is a god-level booster. It can help you smooth out the trivial implementation costs and allow you to have the combat effectiveness of a group in the past.
But if your base is negative:
If you lack a basic system view, do not understand concurrency models, and cannot distinguish boundaries and trade-offs, then AI will only become the most ferocious engineering disaster amplifier. It will help you write errors ten times faster until the system completely collapses.
From this moment on, the survival position of programmers has completely changed:
We are no longer “code typewriters” who earn their working hours by typing on keyboards, we must evolve into“The ultimate designer of system state machines and the chief arbiter of engineering sites”。
The cheaper the tools are in this era, the more valuable the underlying system knowledge is.
FAQ
Q: If newbies are learning programming now, should they just focus entirely on learning prompts and using agents?
A: Quite the opposite. If you don’t even understand the TCP three-way handshake, MySQL clustered index and transaction isolation level, and Redis memory eviction strategy, you won’t be able to tell when the code spit out by AI has hidden dangers. The underlying hard-core computer science and server-side architecture cognition are the “perspectives” you have when using AI. Without this foundation, you can only be a blind porter of AI products for the rest of your life.
Q: How can the team prevent members from abusing AI and causing the code base to get out of control?
A: Rely on rules and tool chains, not on self-awareness. First, cut the domain boundaries into small pieces and implement strict lightweight contracts; secondly, introduce strong verification into the CI process (standardized static scanning, single test coverage access control, automated architecture redline detection); finally, the focus of the team review must shift from “how to write this line of syntax” to “whether the architecture status flow and boundaries are compliant.”
I have been writing back-end for ten years and published “Redis Master’s Tips”. I have seen too many technological ups and downs.
From monoliths to microservices, from local deployment to cloud native, every time a technology wave hits, laymen see the hustle and bustle of tools, while experts stick to the unchanging nature of engineering. What AI changes is the syntax of how we interact with computers, but it never changes the underlying physical laws of “high availability, high concurrency, and consistency of distributed systems.”
In the past six months, many readers have asked me in private messages:
“Brother Ma, I usually find articles on public accounts very inspiring, but fragmented content makes it difficult for me to build a system architecture that can truly withstand the test of production.”
“I am also using Claude Code and Cursor, but how to use architectural thinking to control AI in actual work, there is no systematic practical approach.”
In order to consolidate this set of real engineering experience that I gained through hard work, I created my own knowledge planet——“Ma Ge’s AI Growth and Evolution Camp”。
Here, we will not do superficial conceptual science popularization, but only focus on two things:Use the most cutting-edge AI tools to double efficiency, and use the most solid architectural foundation to guard the bottom line of the project。
In the planet, you will get:
- AI programming and engineering efficiency improvement practical column:from
CLAUDE.md/AGENTS.mdTeam specifications are implemented, and the production-level prompt chain and Hook safety fence are implemented to help you truly control AI; - Hard-core architecture and high concurrency evolution guide: In-depth integration of “Redis Expert Tips” and the bottom layer of MySQL source code, dismantling distributed locks, sub-databases, sub-tables and multi-level caching under tens of millions of traffic;
- How to advance as an architect and how to get promoted in a large factory: How to review technical solutions, how to write an architecture film approved by the boss, and the key path for technicians to break through in the workplace;
- Exclusive private technical circle and daily Q&A: If the plan is questioned, occasional bugs cannot be found online, or technology selection is uncertain, feel free to ask questions on Planet, and I will personally provide you with decision-making reference from an architectural perspective.
The growth of an excellent engineer is never done behind closed doors, but through constant overturning and iteration in the context of high-density actual feedback.
Long press below or scan the QR code to join, and join me in completing the transformation and transition of core competitiveness in the AI era.
Add me on WeChat and join the exclusive technical group. Readers are welcome to provide comments. If you like it, please follow the blog and personal public account: Code Byte
