Eight Honors and Eight Disgraces for Software Engineering in the AI Era: From Saving Code to Expanding AI's Operational Space
2026-06-03
- Honor system requirements; Disgrace team constraints.
- Honor local autonomy; Disgrace global entanglement.
- Honor explicit logic; Disgrace implicit rules.
- Honor specialized implementations; Disgrace generic compatibility.
- Honor closed-loop verification; Disgrace human fallback.
- Honor controlled delegation; Disgrace cutting off your nose to spite your face.
- Honor parallel iteration; Disgrace single-line progression.
- Honor refactoring breakthroughs; Disgrace patching and complacency.
In software engineering for the AI era, what truly changes is not "who writes the code" but the fundamental shift in the cost structure of software engineering. In the past, coding was expensive, cross-team collaboration was costly, and hiring and knowledge transfer were high. Therefore, many engineering practices revolved around "writing less code, avoiding technology switches, minimizing forks, and reducing communication." Thus, full-stack homogeneity, unified databases, generic frameworks, shared business platforms (middle platform capabilities), minimal changes, and human fallback were rational choices at the time.
But with AI involvement, the old cost structure begins to loosen. Code generation costs drop, cross-language understanding costs drop, and the costs of one-off scripts, glue code, local implementations, and specialized tools also decrease. At the same time, the truly expensive things become: context understanding, system verification, runtime observability, responsibility boundaries, automated execution rights, and whether software can continuously evolve. Therefore, software engineering in the AI era should no longer center around "saving code," but around "expanding AI's operational space."
This is precisely the starting point of the "Eight Honors and Eight Disgraces for Software Engineering in the AI Era."
1. Honor system requirements; Disgrace team constraints
In traditional engineering, many technology choices were made not based on what the system itself needed, but on what the team already knew. The frontend team was familiar with JavaScript, so the backend also used JavaScript; the team only knew Postgres, so caching, analytics, cold data, and factual data were all stuffed into a single database; the team wasn't familiar with Rust, so they gave up languages better suited for high-performance backends.
This approach had its rationality in the past because labor costs were too high and cross-technology stack collaboration was too difficult. But AI lowers the cost of understanding across languages, frameworks, and tools. Now, software systems should return to the principle of "use whatever the system needs." The frontend can use TypeScript, the backend can use Rust, data analysis can use Python, hot data can use Redis, cold data can use Parquet, and transactional facts can use Postgres. The technology stack no longer needs to accommodate the team's existing inventory; it should obey the system's responsibilities.
2. Honor local autonomy; Disgrace global entanglement
"Local autonomy" here is not the traditional modular encapsulation or simple high cohesion and low coupling. Even well-encapsulated traditional modules often still depend on a larger system and cannot exist independently. What matters more in the AI era is business-scenario-level autonomous apps operating independently.
In the past, we favored building shared business platforms (middle platforms) to unify multiple similar business capabilities into a common system, aiming to reduce duplication and standardize interfaces. But this often creates new single points of failure: several business systems that could have evolved independently become entangled by a shared platform capability. A change in one place affects the whole; a failure in one place brings down multiple business lines; a rule change in one place forces all businesses to adapt together.
In the AI era, the cost of creating and maintaining multiple independent apps has decreased. Rather than forcing multiple business scenarios to share a heavy shared platform, it is better to let each become autonomous, evolve independently, and bear its own boundaries. The value of local autonomy is that it allows AI to act independently within a small context, small impact radius, and low entanglement.
3. Honor explicit logic; Disgrace implicit rules
Explicit logic does not mean that code must be simple; it means that the logical context should be placed right in front of you. The real criticism is not of configuration files, decorators, callbacks, lifecycle hooks, dependency injection, and these technologies themselves, but of the implicit rules they create that are beyond the common domain language.
In many systems, to write less code, rules are hidden inside frameworks, dialects, jargon, unwritten norms, dynamic injections, lifecycle hooks, and non-obvious terminology. Experienced humans may know these rules through practice, but AI faces an information barrier: it sees the code but cannot see the context that truly determines behavior.
In the past, the premise of "convention over configuration" was that the convention was already universal enough, even changing the way people think. But if a convention is just team jargon, a framework-specific dialect, or a legacy rule, then it is not saving code but creating a black box of understanding. In the AI era, the cost of explicit configuration, explicit judgment, and explicit workflows has decreased. Gathering information in one place where it can be directly seen is often more valuable than distributing logic across multiple injectable implementations loaded dynamically.
4. Honor specialized implementations; Disgrace generic compatibility
Software should serve specific problems. But in the past, to write less code, avoid forks, and reduce maintenance of multiple paths, we often forced different requirements, different inputs, and different business scenarios into a single generic compatibility layer. Superficially unified, the actual problems were distorted.
The greatest danger of a generic compatibility layer is that it requires all specific problems to first morph into a form it can accept. Consequently, specific business loses its original shape, dedicated capabilities are weakened, and the system revolves around an abstraction layer rather than around real problems.
In the AI era, the cost of writing one-time code, glue code, small scripts, and specialized implementations has dropped significantly. We no longer need to force a specific task into a generic framework just to save a bit of code. Often, a direct implementation tailored to the current task is clearer, cheaper, and more amenable to AI operation than an abstraction layer that tries to accommodate all possibilities.
5. Honor closed-loop verification; Disgrace human fallback
Closed-loop verification should not stop at CI/CD. Traditional CI can handle building, testing, and release checks, but this is not a complete closed loop for the AI era. What AI truly needs are "sensors": it needs eyes to see online status, detect system changes, and judge the outcome of its actions based on observability metrics.
If AI can only run tests before code submission but cannot see post-release online metrics, user behavior, latency changes, error rates, resource consumption, business funnels, anomaly alerts, then it is still blind. It can only wait for humans to tell it what's wrong; it still relies on human fallback.
Therefore, the core of closed-loop verification is not endlessly adding more validation rules but enabling the system to observe more dimensions of information. AI should not only know if "tests passed" but also whether "the system is healthy after going live." Humans define correctness and risk boundaries; machines are responsible for continuous observation, continuous verification, and continuous feedback.
6. Honor controlled delegation; Disgrace cutting off your nose to spite your face
Many teams fear that AI will cause damage, so they only let AI write suggestions, documentation, or code snippets, never giving it real system access. But this doesn't scale. If AI never gains execution rights, it will forever remain an advisor, not a true agent of engineering automation.
The correct approach is not to deny AI the ability to operate real systems but to start by assuming AI can touch everything: code, data, deployments, cloud resources, configuration, monitoring, rollbacks. Then add permission boundaries, auditing, dry-run, sandboxes, approval thresholds, rollback mechanisms, and risk isolation.
The key to controlled delegation is to give AI real execution power while keeping every action within controllable boundaries. The result of "cutting off your nose to spite your face" is that humans continue to manually copy commands, manually click through consoles, and manually troubleshoot issues, preventing engineering automation from truly scaling.
7. Honor parallel iteration; Disgrace single-line progression
Software evolution in the AI era should no longer be understood as a single-person, single-threaded engineering construction but as a solving process akin to an optimizer or solver. Facing the same problem, AI can propose multiple candidate solutions simultaneously: one local fix, one module refactor, one library replacement, one path rewrite, one performance optimization.
Traditional engineering is limited by human resources, only trying one path at a time. If it fails, you go back and try the next path. AI changes this. We can generate, deploy, verify, and compare in parallel, turning software evolution from linear progression into multi-path search.
Of course, machine evaluation is not always reliable. Software quality is often non-differentiable, non-attributable, and not instantly assessable. But the value of parallel iteration is not that machines can automatically find the absolute optimal solution; it is in expanding the exploration space, making more candidate paths affordable, comparable, and verifiable.
8. Honor refactoring breakthroughs; Disgrace patching and complacency
In the past, many engineering disciplines demanded minimal changes because human coding costs were high, refactoring costs were large, and verification costs were high. Minimal changes were once a way to reduce risk. But in the AI era, if we continue to force AI to always make minimal changes, we degrade AI into a patching machine.
Many systems' problems are not in a single line of code but in a structural dead zone: the harness becomes heavier, verification becomes more rigid, refactoring costs grow larger, and even slightly larger changes are rejected by the process. The system appears safe on the surface but is actually no longer iterable. Software improvement fails, leading to either slow death or a wholesale team rewrite.
In the AI era, coding costs have decreased, making refactoring actions that were previously unappealing to humans once again feasible. We should not trap AI in minimal patches; we need to allow it to break through structural dead ends under the protection of closed-loop verification. Re-draw boundaries when necessary, delete old paths when necessary, and refactor when necessary. Patching is not shameful, but continuing to patch after the system has entered a dead zone is simply complacency.
Conclusion: Make software an object that AI can operate, verify, and evolve
Software engineering in the AI era is not about making AI write old-paradigm code faster, but about redesigning software itself so that it is suitable for AI operation. New software systems should be more local, more explicit, more specialized, more observable, and should allow AI real execution rights for parallel exploration and structural refactoring.
Many past "bad architectures" were not due to engineers' ignorance but were rational compromises under the old cost structure. Full-stack homogeneity, one-database-fits-all, generic frameworks, shared platform dependencies, human fallback, and minimal changes all helped teams save labor. But as AI changes the costs of coding, understanding, execution, and verification, these old compromises are no longer inherently reasonable.
The core goal of software engineering in the AI era is to transform software from a static asset maintained by humans into a dynamic system that AI can operate, observe, verify, delegate to, explore in parallel, and break through via refactoring.
This is the common judgment behind the Eight Honors and Eight Disgraces: Do not let AI be merely an accelerator for old software engineering; instead, reorganize software engineering itself for AI.
