AI Programming Era: Design Judgment Is the Real Scarcity, Not Code

I have been doing technical work and remain on the front lines of development. Previous articles focused on ontology, data governance, and project retrospectives, but I also want to discuss practical issues in software engineering, system design, and AI programming, exchanging ideas with peers who still write code, architect systems, and lead projects.

This piece shares my understanding of AI programming over the past year.

For 35+ Programmers, LLMs Are a New Career Lever

Over the last year, large models have advanced rapidly in software development. I have used Codex, Claude Code, OpenCode, and mainstream models such as GPT, Claude, Qwen, DeepSeek, and GLM. Their capability boundaries differ, but one thing is clear: large models are substantially changing how software development works.

For a 40+ "programmer" still on the front lines, this change is especially noticeable. Previously, even with a clear direction, much time went into scaffolding, writing boilerplate, wiring interfaces, and tweaking UIs. Now, models can shoulder a significant portion of implementation, letting us focus on the truly hard parts:

Whether requirements are truly understood

How system boundaries should be drawn

How a complex goal should be decomposed into executable tasks

Which constraints must be baked into architecture, interfaces, and data rules

How results should be verified, not just whether "code runs"

I prefer to view large models as an engineering lever . They do not devalue experience; rather, they let long‑accumulated business understanding, architectural skill, and engineering judgment turn into running systems faster. In a sense, they extend the technical lifespan of senior developers who stay hands‑on.

LLMs Shift Not Only Coding Efficiency but Software Engineering's Value Center

Many equate AI programming with "writing code faster." That is true but incomplete. The deeper shift: as code generation cost drops, parts of software engineering that were easily ignored become more critical.

问题定义 -> 需求与边界 -> 架构设计与接口约定 -> 任务拆分 -> 代码实现 -> 测试与自动化检查 -> 反馈与修正

Here, "interface contracts" (often called contracts) are not legal agreements but rules that modules or services must jointly obey: inputs/outputs, data structures, error handling, permission requirements, and state transitions. "Testing and automated checks" cover not only unit tests but also integration tests, static analysis, build checks, regression tests, and validation that implementation matches design.

In the past, implementation consumed most time, and teams treated "code complete" as progress. Agile and XP tried to reduce change cost via short feedback loops, testing, refactoring, and CI, but in some teams "rapid iteration" devolved into "no design, just code." Now models can generate vast amounts of code quickly; if requirements, boundaries, and design are unclear, they will just produce a wrong, duplicated, unmaintainable system faster.

AI amplifies not only productivity but also requirement ambiguity, architectural defects, and false assumptions. Once direction is wrong, faster development spreads errors faster and may increase rework scope. The problem is not that AI inevitably creates more errors, but that high output speed demands earlier design validation and more complete testing and automated checks.

Therefore, what programmers really need to improve is not "how to write code" but "how to make the machine work under the right problem, the right boundaries, and the right verification standards."

Why Results Differ When Using AI Similarly

Many now program with large models, but outcomes vary widely. Some sustain cross‑module refactors, letting agents leave verifiable artifacts; others only generate snippets and dare not merge large changes. The difference stems not only from the model but from whether the user has established an engineered workflow.

Over the past year, concepts like Vibe Coding, Spec‑Driven Development (SDD), Harness Engineering, and Loop Engineering have appeared. They are often discussed together but operate at different levels.

Vibe Coding – Interaction & implementation style: how to complete low‑risk changes, prototypes, and POCs via rapid dialogue and instant feedback.

SDD – R&D method & lifecycle: how to make requirements, design, constraints, and acceptance criteria a stable baseline for development and evolution.

Harness Engineering – Agent execution environment & engineering support: how to provide tools, context, permissions, rules, tests, and feedback environments for agents.

Loop Engineering – Task execution & feedback mechanism: how to form a closed loop of plan, execute, check, correct until done criteria are met.

SDD solves "what basis drives the R&D process"; Harness solves "what environment and constraints the agent works under"; Loop solves "how a task converges via feedback." Harness and Loop focus on implementation, review, and verification, and can also be used for design document checks. They are not alternatives: long‑term projects can use SDD to manage requirements and design baselines while using Harness and Loop to keep agent execution controlled and verifiable.

Why I Lean Toward SDD

I personally align with SDD's direction. The reason is not a love for documentation, but that AI‑era software R&D needs a more stable source of truth than chat logs.

Linus Torvalds famously said: Talk is cheap. Show me the code. That emphasizes proving ideas with runnable code rather than vague discussion. But in the AI programming era, code generation cost is plummeting. Borrowing his phrasing, I would rewrite it as: Code is cheap. Spec is the asset. This does not mean code is unimportant. Code remains the final runtime artifact and must pass security, performance, maintainability, and production scrutiny. The real shift is in relative scarcity: code generation cost is falling, while high‑quality requirements, constraints, architectural decisions, interface contracts, and acceptance criteria are becoming the harder‑to‑replace assets.

A high‑quality spec should at least answer:

Why do this?

What problem does it solve?

What is explicitly out of scope?

What are the core objects and processes?

What are module boundaries, interface I/O, and exception contracts?

How are exceptions, permissions, and risks handled?

What evidence determines completion?

If these are clear, large models can rapidly complete much of the implementation. If they are missing, even the strongest model can only guess from local context.

From Spec Kit to LeanSpec: Tools Cannot Replace Methods

When people hear SDD, they think of Spec Kit, OpenSpec, Superpowers, mattpocock/skills, etc. I tried Spec Kit early on; its generated artifacts were thorough but document volume and context consumption were high, costing both model and human for low‑value context.

Later I tried LeanSpec. It emphasizes context economy, signal‑to‑noise ratio, and intent over implementation. That lightweight approach fits my daily workflow better. After using it for a while, I found it more efficient and easier to control context corruption and cognitive load.

I also experimented with combining GitLab, LeanSpec, and OpenCode into a team‑oriented AI R&D tool: team writes requirements and designs there, then AI assists development. I stopped halfway, not because it was technically infeasible, but because I realized forcing everyone into one workflow via tooling can weaken individual judgment and initiative.

Tools should lower the execution cost of correct methods, not replace human thinking. So I shifted focus from "which SDD tool to use" to "how to embed SDD principles into my own workflow."

My Actual Practice: Design First, Development and Testing Cross‑Verify

When building products or complex features, I stick to one principle: push design to a development‑ready state before writing code.

Design progresses from outline to detail:

目标与范围 -> 业务对象和流程 -> 总体架构 -> 模块与责任边界 -> 数据结构和接口约定 -> 异常、权限与审计 -> 任务拆分与验收标准

If a design gap appears during development, I do not let the developer patch it in code; instead, I create a design change proposal, update the design, then continue. This is not for documentation perfection but to prevent real design from scattering across code branches, chat logs, and personal memory.

In a project, I first define role responsibilities. Then I spin up independent threads for each role, each with stable context and clear boundaries:

Architecture design role – system planning, boundary design, design documents.

Frontend development role – pages, interactions, frontend state per design.

Backend development role – services, data, interface implementation per design.

Test role (cross‑check) – reviews design docs for completeness, consistency, verifiability; feeds issues back to architecture role.

Test role (implementation check) – verifies code against design, writes and runs test cases, reports deviations to respective dev roles.

Development roles – when they find design gaps, they propose changes; architecture role maintains the design baseline.

The point is not "open more chats" but to establish clear responsibility and feedback relationships:

设计草案 -> 测试角色交叉评审 -> 设计基线 -> 前后端并行实现 -> 实现一致性检查与测试 -> 反馈架构或开发角色 -> 修正文档或代码 -> 重新验证

From an SDD view, design docs are the stable baseline running through R&D. From Harness Engineering, roles, tools, permissions, and tests form the agent's controlled environment. From Loop Engineering, cross‑check, feedback, correction, and re‑verification close the task loop.

The Real Barrier for Technologists Is Often Mindset, Not Tools

I increasingly feel the hardest part of technical transformation is not learning new tools but changing default thinking patterns. This mirrors my view on data governance: traditional governance starts from existing tables/fields and tries to serve business upward; ontology‑driven governance starts from business objects, processes, rules, and responsibilities, then organizes semantics and data assets top‑down. The difficulty is not swapping tools but changing the modeling starting point.

Business system developers, even if fluent in databases, may struggle to switch from ER models to dimensional modeling for data warehouses. Application developers' first instinct is to add code; database developers may reach for stored procedures. Neither is wrong—long‑term tool use makes the familiar tool the default answer. AI programming is the same: if the first reaction remains "let the model write code fast," you only get faster code generation. Only by first clarifying the problem, boundaries, design rationale, constraints, and verification standards does the large model truly enter software engineering, rather than remaining a faster autocomplete.

Summary

Large models are lowering the barrier to code implementation, but they have not reduced the difficulty of complex software engineering.

Requirements still need understanding, architecture still needs trade‑offs, tasks still need decomposition, risks still need control, results still need verification. Programmers can hand off more mechanical implementation to machines and devote more energy to problem definition, system design, engineering constraints, and creative judgment.

So for programmers, what matters is not chasing every new tool or picking sides between Vibe Coding and SDD, but completing a mindset shift:

从“我怎么把代码写出来”，转向“我怎么让系统被正确地设计、实现和验证”。

Tools and models will keep evolving, but requirements, design, judgment, and verification remain the scarcest capabilities in software engineering.