AI Programming

Standardize log formats, log levels, and trace instrumentation so that AI stops logging chaotically everywhere. As AI-assisted programming becomes increasingly common, an easily overlooked problem is emerging: AI is very good at writing logs, but not necessarily good at writing “useful logs.” Ask AI to implement a feature, and it will likely generate something like: logger.info("start") logger.info("processing...") logger.info("data loaded") logger.error("failed") Individually, these seem fine. But as the project grows larger, you’ll find your logs turning into something like this: start processing... loading data... done request failed retry... success When something actually breaks, it becomes very difficult to answer a few of the most basic questions: Which request caused the error? Which module caused the error? Which step caused the error? … The problem is rarely “too few logs.” It’s usually: There are plenty of logs, but no system behind them. Therefore, just like exception handling, dependency injection, and interface contracts, logging should also be part of the project architecture — not left to the free rein of developers or AI. ...

When AI writes code, it loves the “fastest way to make it run” approach, for example: db = Database() cache = RedisCache() mailer = EmailService() service = UserService() Create wherever needed. In the short term it’s convenient, but as the project grows larger, you end up with: Database instances created everywhere Cache clients created everywhere Configuration scattered Services instantiating each other Dependencies impossible to replace during testing The most obvious problem with this kind of code is: Objects hardcode their own dependencies. And DI (Dependency Injection) is exactly what solves this problem. ...

AI is very good at quickly writing API endpoints. For example, if you tell it: “Add an endpoint to create a user.” It can probably produce working code in a few minutes. But without unified standards in the project, different endpoints will quickly end up like this: { "success": true } Another endpoint returns: { "code": 0, "msg": "ok", "result": {} } When yet another endpoint encounters an error, it directly returns: { "error": "user not found" } Some places even throw raw database exceptions back to the frontend. Every single endpoint “works,” but the entire system becomes increasingly hard to maintain. So, there’s a very important but often overlooked category of foundational architecture in AI programming: Unified response values + global exception handling + unified parameter validation. Their purpose is to define upfront: How to return on success, how to return on failure, and where to intercept invalid input. ...

AI writing code has one very common problem: It knows how a feature should be implemented, but doesn’t necessarily know where the code should go. For example, if you tell AI: “Add a delete Agent feature.” Without a clear project structure, it might directly, inside the API endpoint: query the database, evaluate business rules, clear the cache… The feature might work quickly. But as AI writes code this way again and again, the project will eventually become: Business logic inside the API Database operations inside Services Business judgments inside Repositories Utility classes referenced everywhere At this point, we need another very fundamental yet extremely important architectural concept: Layering. ...

Getting AI to write a single feature is usually not difficult. What’s truly difficult is: After AI writes dozens or even hundreds of features in a row, can the code still remain clear? Many projects start with a decent structure — a bit of user functionality here, some permission handling there, order features over there, logging features somewhere else. As requirements grow, different modules start calling each other, referencing each other, modifying each other, and may eventually end up like this: user.py ↓ permission.py ↓ agent.py ↓ tool.py ↓ knowledge_base.py ↓ conversation.py ↘ calls user.py again There are plenty of files and lots of code, but who is responsible for what becomes increasingly unclear. Software architecture has a very vivid name for this: Big Ball of Mud And Domain-Driven Design, or DDD as we often hear, has one very important role: drawing boundaries clearly before the system starts to get messy. For AI programming, this role is especially critical. ...

AI is very good at writing code. But without clear architectural boundaries, it can easily develop one problem: Wherever it’s convenient to write code, that’s where the code gets written. Business rules that should belong to the backend might end up stuffed into Vue pages. API calls that should be uniformly encapsulated might scatter across various components. The frontend might even “invent” its own data structures inconsistent with the backend, based on page requirements. The code might run, but the project gradually loses its boundaries. And frontend-backend separation is the first important boundary to draw for AI. ...

In the previous article, we discussed a core principle: Define boundaries and rules first, then let AI exercise its capabilities within those boundaries. So here comes the question: How can these architecture rules actually be handed over to AI? The answer is the topic of this article — Project Rules. ...

With the development of large language models such as GPT, Claude, Gemini, and Qwen, software development is entering a new era. Coding tasks that once took hours or even days can now be completed by AI in a matter of minutes. However, many teams have noticed a puzzling phenomenon: The more code gets written, the faster the project falls apart. The reason is not that AI isn’t smart enough, but rather: A lack of architectural constraints. One important reason modern AI Agents can operate relatively stably is that: they do not let large language models run wild without any constraints. Mature Agent systems typically define clear behavioral boundaries for the model through mechanisms such as System Instructions (i.e., system prompts), Tool Specifications (i.e., tool specs), permission control, workflows, state management, and result validation. In essence, this is highly consistent with the philosophy of software architecture: Define the boundaries and rules first, then let AI exercise its capabilities within those boundaries. Even a highly capable model, when lacking clear constraints, dealing with ever-expanding context, or wielding excessive tool permissions, may gradually develop issues such as format drift, responsibility overreach, incorrect tool invocations, or inconsistent code style. ...