AI Programming on Interesting AI

[Collection] Architectural Foundations: The Underlying Methodology for Mastering AI-Assisted Programming

Sat, 01 Aug 2026 00:00:00 +0000

AI handles the “speed,” humans handle the “blueprints.”
This column outlines common software architecture design techniques, aiming to teach you how to tame AI to write industrial-grade, highly maintainable, high-quality code through “architectural design” and “rule constraints (Prompt / Rules),” avoiding the pitfall of “the more code you write, the faster the system crashes.”

Architect + AI: The Career Leap from Coder to System Orchestrator

Mon, 17 Aug 2026 00:00:00 +0000

In this series, we have discussed a range of engineering practices: frontend-backend separation, DDD (Domain-Driven Design), layered architecture, DI (Dependency Injection), RESTful (Representational State Transfer), async & concurrency, SSE (Server-Sent Events), plugin architecture, and Project Rules.

It may look like a lot of technology, but they all ultimately point to the same question:

Now that AI can generate large amounts of code, what is still the most important capability for a programmer?

The answer is shifting from:

“How to write the code”

to:

“How to design a system in which AI can write code correctly.”

Plugin Architecture and Extension Points: Guiding AI Toward Modular, Pluggable Development for Decoupled, Iterable Features

Mon, 17 Aug 2026 00:00:00 +0000

AI writes code fast, but it is also prone to a typical problem:

Every time a feature is added, more if/elif branches pile into the core code.

For example:

if domain == "legal":
    ...
elif domain == "finance":
    ...
elif domain == "medical":
    ...

With few features this is fine, but as the types keep growing, the core module becomes increasingly bloated, and every new feature risks affecting existing logic.

A more reasonable approach is to define upfront:

Plugin Extension Point

And let AI follow one principle:

New capabilities should preferably be added as new modules, not by modifying the core flow.

Long-Lived Connections and Streaming Push: Standardizing SSE / WebSocket Implementations to Replace Inefficient Polling

Sun, 16 Aug 2026 00:00:00 +0000

In web systems, there is a type of requirement that is especially prone to being implemented by AI as “it runs, but it’s dumb”:

Frontend:
Ask the server every 1 second
"Is the task done?"

Server:
"No."

Ask again 1 second later:
"Is it done?"

This approach is called:

Polling

Querying a status occasionally is fine, but for real-time scenarios such as AI streaming responses, OCR progress, document parsing, knowledge base construction, and background task status, high-frequency polling generates a large number of useless requests.

A more appropriate solution is usually:

SSE (Server-Sent Events)

Or:

WebSocket — a full-duplex, long-lived connection protocol

The core idea boils down to one sentence:

Don’t make the client keep asking “Got any message yet?” — let the server push messages proactively when there is something new.

Async and Concurrency Architecture: Fixing AI's Synchronous Blocking Patterns to Improve System Throughput

Sat, 15 Aug 2026 00:00:00 +0000

There is a very common problem with AI-generated code:

The code runs, but slows down as soon as multiple users access it.

Especially in Python Web projects, even when using FastAPI and functions are written as async def, operations such as database queries, HTTP requests, and large language model (LLM) calls may still block synchronously.

The key issue is:

async def is merely the entry point of an asynchronous function — it does not automatically turn the synchronous code inside it into asynchronous code.

For systems that heavily rely on external I/O — such as web services, knowledge bases, and agent platforms — establishing a unified async and concurrency architecture is an important foundation for improving system throughput.

Centralized Configuration and I18n: Strictly Forbid AI Magic Values and Hardcoded Parameters

Fri, 14 Aug 2026 00:00:00 +0000

AI (Artificial Intelligence) has a very common problem when writing code:

It loves to “hardcode things on a whim.”

timeout = 30
max_retries = 3
model = "qwen3:14b"
raise ValueError("User does not exist")

Individually, there’s nothing fundamentally wrong with any of these lines.

But when dozens of modules each have their own 30, 3, model names, and prompt text, maintainers start getting headaches:

What do these values mean? Where should they be changed? What happens when switching environments? How do we support English?

Therefore, AI programming projects should establish a clear architectural rule upfront:

Values with business significance, environment-specific differences, or user-visible meaning are not allowed to be scattered across business code.

This problem is primarily addressed through two mechanisms:

Centralized Configuration + I18n (Internationalization).

Caching and Multi-Level Storage: Don't Let AI Blindly Hit the Database

Wed, 12 Aug 2026 00:00:00 +0000

When AI writes business code, it has a very typical tendency:

async def get_user(user_id: int):
    return await user_db.get_by_id(user_id)

Functionally correct. But if every read in the project becomes:

Read user → Database
Read permissions → Database
Read model → Database
Read Agent → Database
Read knowledge base → Database
Read config → Database

The system soon enters a state where:

Every function is correct, yet the overall architecture grows increasingly inefficient.

The problem is not merely “whether there is a cache”, but:

The AI never first asks: what I want to reuse — a “value”, or an “already-built runtime object”?

This is exactly what’s most worth borrowing from miniagent’s current caching architecture.

It doesn’t just build one cache — it explicitly splits into two categories:

Object Cache
Object caching

Value Cache
Value caching

These two solve fundamentally different problems.

Unified Authentication and Authorization: Standardizing AI Token Issuance and Verification Logic

Tue, 11 Aug 2026 00:00:00 +0000

In AI programming, there is one category of code that easily “grows and grows messier”:

if user.role != "admin":
    raise HTTPException(status_code=403)

Switch to another endpoint, and the AI writes:

if "user:delete" not in user.permissions:
    raise ForbiddenError()

Yet another endpoint:

if current_user.id != owner_id and not current_user.is_admin:
    raise HTTPException(status_code=403)

Each snippet looks defensible on its own. But once dozens of variations of these ifs appear across the project, the permission system has effectively gone out of control.

The mature solution is not “make the AI write its if-statements more carefully”, but to establish a unified:

Authentication + permission model + permission enforcement mechanism

The most common permission model here is RBAC (Role-Based Access Control).

Aspect-Oriented Programming: Guiding AI to Extract Cross-Cutting Logic So Logging, Auth, and Instrumentation Are Never Written Twice

Mon, 10 Aug 2026 00:00:00 +0000

In the age of AI programming, there is one kind of code that gets copied around with abandon:

logger.info("Start processing request")

if not token:
    raise UnauthorizedError()

start = time.time()
result = await service.do_something()
logger.info(f"Execution time: {time.time() - start}")
return result

At first there is only one endpoint, and it looks harmless enough.

But once the project grows to dozens or even hundreds of endpoints, things quickly become:

User endpoints
  ├─ Authentication
  ├─ Logging
  ├─ Parameter validation
  ├─ Business logic
  └─ Instrumentation

Agent endpoints
  ├─ Authentication
  ├─ Logging
  ├─ Parameter validation
  ├─ Business logic
  └─ Instrumentation

Knowledge base endpoints
  ├─ Authentication
  ├─ Logging
  ├─ Parameter validation
  ├─ Business logic
  └─ Instrumentation

  ...

The only truly different part is the few lines of business logic in the middle. As for the rest, every time the AI writes another endpoint, it dutifully copies it all over again.

This is exactly the problem that AOP (Aspect-Oriented Programming) set out to solve.

RESTful and Contract First: Standardizing Interface Definitions and Unifying API Design Paradigms

Sun, 09 Aug 2026 00:00:00 +0000

Define the API rules clearly first, then let AI write the code.

In AI-assisted development, interface design is an area that easily “looks like it works, but gets increasingly messy over time.”

Ask AI to write a few APIs for you, and it might quickly generate:

/getUser
/createUser
/update_user
/delete-user
/userList

They all work functionally. But as the project continues to grow, you easily end up with:

Same resource, different naming
Same action, different HTTP methods
Same error, different response structures
Same pagination, different field names

Eventually, frontend developers, backend developers, testers, and even AI itself start guessing:

“How exactly should this API be called?”

What’s truly missing here is not coding ability, but:

A unified API contract.

Logging Architecture: Making Every Log Line AI Writes Valuable

Sat, 08 Aug 2026 00:00:00 +0000

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.

Dependency Injection: Forbid AI from Hardcoding Instantiation, Improve Testability and Extensibility

Fri, 07 Aug 2026 00:00:00 +0000

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.

Exception and Unified Encapsulation Architecture: Standardizing Unified Return Values, Global Exception Handling, and Parameter Validation

Thu, 06 Aug 2026 00:00:00 +0000

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.

Layered Clean Architecture: Standardizing Project Directory Structure to Prevent AI Boundary Violations

Wed, 05 Aug 2026 00:00:00 +0000

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.

Domain-Driven Design: Drawing Context Boundaries for AI to Say Goodbye to "Big Ball of Mud" Code

Tue, 04 Aug 2026 00:00:00 +0000

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.

Frontend-Backend Separation: Constraining AI's Division of Labor to Avoid Interface Coupling and Responsibility Confusion

Mon, 03 Aug 2026 00:00:00 +0000

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.

How to Define Coding Boundaries for AI Using Project Rules

Sun, 02 Aug 2026 00:00:00 +0000

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.

The More You Rely on AI to Write Code, the Less You Can Afford to Skip Architecture Design

Sat, 01 Aug 2026 00:00:00 +0000

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.