Introduction: When “Prompt Engineering” Becomes a “Programming Paradigm”
A recent OpenAI guide on building reliable AI code has been stirring up a lot of discussion in our circles. The title is an eye-catcher — “Moving from ancient-style programming to Agent programming, or just PUA your AI.” As a veteran who has been slogging through piles of code for more than a decade, my feelings when I first saw that title were complicated.
“PUA your AI” — the phrase is both a joke and dead accurate. It nails an awkward reality: for the past two years, many of us really have been dealing with AI in a way that borders on cajoling — endlessly tweaking prompts, applying emotional pressure (“You are a senior expert”), even dangling “tips” as bait (“Give a good answer and I’ll tip you $200”). Do these methods work? To some extent, yes. But are they sustainable engineering practice? Obviously not.
The real value of OpenAI’s guide isn’t that it teaches you how to “PUA” your AI. It’s that it tries to establish a framework for the paradigm shift from “prompt engineering” to “Agent programming.” This is not just a tweak of technical details; it’s a reconstruction at the level of software-engineering methodology.
As a veteran who lived through the move from monoliths to microservices and from waterfall to DevOps, I know all too well how painful and how necessary a paradigm shift is. In this article I want to talk about the logic behind it, and about how we, as engineers, should find our place at this turning point.
Background: Why “Ancient-Style Programming” Is Failing
From Copilot to Agent: The Leap in AI Capability
To understand this paradigm shift, we first need to trace the evolution of AI programming tools.
Stage one: code completion (2021–2023)
The arrival of GitHub Copilot turned AI from a “search engine” into a “pair-programming partner.” But at this stage AI was still, in essence, a passively responsive tool — you write a comment, it fills in code; you write a function signature, it fills in the implementation. Its context window was limited; it understood local code fragments, not the whole system.
Stage two: conversational programming (2023–2024)
The explosion of ChatGPT’s and Claude’s coding ability brought “conversational programming.” You describe a requirement and the AI generates a complete code block. But the central contradiction here is that the code the AI produces is “one-shot.” It lacks an understanding of the existing codebase, cannot handle complex dependencies, and certainly cannot verify its own correctness.
Stage three: Agent programming (2024–present)
This is the direction OpenAI’s guide points to. An Agent is no longer a tool waiting for instructions, but a collaborative entity capable of planning, executing, verifying, and iterating on its own. It can call tools, read files, run tests, and even correct itself.
At this stage AI begins to possess the basic elements of engineering work: goal orientation, feedback loops, error handling.
The Core Predicament of “Ancient-Style Programming”
By “ancient-style programming” I mean the software-engineering methodology we’ve built up over the past few decades: precise requirements analysis, modular architecture design, rigorous coding standards, complete test coverage. In the AI era these methods run into a triple challenge:
First, exploding complexity and the cognitive bottleneck
Modern software systems have long since exceeded the cognitive limits of any individual. A mid-sized microservices system can involve hundreds of services, thousands of APIs, tens of thousands of lines of configuration. The traditional model of “human-brain modeling + manual coding” sees its efficiency plummet at this scale.
Second, the mismatch between change frequency and response speed
Business requirements change faster and faster, but the traditional development process has inherent latency. From requirements review to release, even the most agile team needs hours to days. An AI Agent can iterate from requirement to runnable code on a minute-level scale.
Third, the cost predicament of quality assurance
Test coverage, code review, security auditing — the cost of these quality-assurance measures is proportional to the amount of code. When AI can generate hundreds of lines of code in an instant, the traditional manual review model becomes unsustainable.
Key insight: The question we face isn’t “will AI replace programmers” but “how can programmers collaborate with AI to cope with the exponential growth in system complexity.”
Deep Thinking: What Agent Programming Really Is
The Heart of the Paradigm Shift: From “Instruction Execution” to “Goal Delegation”
There’s one easily overlooked but extremely important concept in OpenAI’s guide: the “delegation boundary.”
In traditional programming, the interaction between engineer and computer is instructional: you describe each step precisely, and the computer executes it strictly. Even with high-level languages, you’re essentially writing machine instructions with human-readable syntax.
Agent programming introduces goal delegation: you describe the desired outcome and the constraints, and the Agent plans its own path to achieve it. This sounds like an extension of “declarative programming,” but it’s fundamentally different — an Agent has uncertainty and autonomy.
|
This contrast reveals the key characteristics of Agent programming:
| Dimension | Traditional programming | Agent programming |
|---|---|---|
| Interaction granularity | Statement/function | Task/goal |
| Expression of constraints | Syntax rules | Natural language + examples |
| Determinism of execution | 100% predictable | Probabilistic, needs verification |
| Error handling | Caught at compile/run time | Iterative correction |
| Knowledge transfer | Docs + code | Context + feedback loop |
The New Definition of “Reliability”
OpenAI’s guide repeatedly stresses “reliable,” but the meaning of reliability here has changed.
The reliability of traditional software rests on determinism: the same input necessarily produces the same output, and code behavior is fully predictable. We can approach “zero defects” through formal verification, static analysis, and exhaustive testing.
The reliability of an Agent system rests on resilience: acknowledging the uncertainty of a single run, but guaranteeing the correctness of the final result through a verify-feedback-iterate mechanism. This is reliability in a statistical sense, closer to how biological systems operate.
This reminds me of my early days doing distributed systems. We once obsessed over “strong consistency,” only to discover that in the vast majority of scenarios “eventual consistency + compensating mechanisms” was the more pragmatic choice. The reliability model of Agent programming may be a similar shift in thinking.
A Critical View: The Overlooked Hidden Costs
As a technical decision-maker, I have to point out several costs that the current Agent-programming craze systematically underestimates:
1. Verification cost is transferred, not eliminated
Many people mistakenly believe that Agent programming reduces the need for testing. On the contrary, it moves verification from “upfront design” to “post-hoc iteration.” When the way AI generates code is opaque, you need a stronger automated verification system to backstop it. This cost is often masked by the surface impression that “AI writes code so fast.”
2. The redistribution of cognitive load
Engineers shift from “writing code” to “defining tasks + verifying results.” It looks easier, but in fact the nature of the cognitive load has changed. Reading code is harder than writing it, and verifying AI-generated code demands a stronger grasp of the system than verifying your own code. Junior engineers can fall into the trap of “I can’t understand it, but I don’t dare change it.”
3. Accelerated accumulation of technical debt
AI generates code far faster than humans can review and refactor it. Without strict architectural constraints, a system can quickly accumulate a mass of “AI-generated legacy code” — logically correct but poorly designed, runnable but hard to maintain.
Personal observation: Among the teams I’ve encountered, the project that used AI coding most aggressively developed severe architectural rot six months later. The problem wasn’t AI; the problem was that the team never established the engineering discipline that Agent collaboration demands.
A Practical Case: An Agent-Programming Experiment on a Real Project
Last year I took part in a refactoring project for an internal tool, and deliberately tried the Agent-programming approach. The project was moderate in size (about 20,000 lines of Python) but had complex business logic, orchestrating several external APIs.
Experiment design
We split the development process into three phases:
Phase one: traditional baseline (2 weeks)
Two engineers developed the core modules the usual way, logging hours, defect rates, and refactoring counts.
Phase two: AI-assisted enhancement (1 week)
The same engineers used Copilot + ChatGPT as aids, keeping identical code-review and testing standards.
Phase three: Agent-delegation experiment (1 week)
We tried delegating complete feature points to Claude Code (then still in beta), with the engineers’ role shifting to “task definition + result verification.”
Key findings
Efficiency data
| Metric | Traditional | AI-assisted | Agent delegation |
|---|---|---|---|
| Feature points delivered / person-day | 0.8 | 1.5 | 2.3 (first try) / 3.5 (after stabilizing) |
| Unit-test coverage | 78% | 75% | 62% → 85% (after supplementing) |
| Issues found in code review | 12 / PR | 18 / PR | 31 / PR → 15 / PR (after prompt tuning) |
| Production bugs (first month) | 3 | 5 | 8 → 2 (after optimizing the verification flow) |
A few counter-intuitive observations
The “startup cost” of Agent delegation is extremely high
On the first attempt we spent two whole days just writing an effective task description. The AI repeatedly misread the requirements and produced code that looked reasonable but was actually wrong. It wasn’t until we built a “task-description template” (including background, constraints, verification criteria, and reference examples) that efficiency improved markedly.
Context engineering matters more than prompt engineering
Rather than investing effort in the prompts, it pays to invest in structuring the codebase. We extracted the core domain model, API specs, and error-handling patterns into standalone reference docs, and the quality of the Agent’s output immediately jumped a notch.
Verification automation is the bottleneck
The Agent can generate code in seconds, but verifying its correctness requires running tests, checking logs, and comparing outputs. Only when we automated the verification flow too (based on pytest + custom assertions) did we truly unlock the Agent’s potential.
The “Agent-Programming Contract” We Settled On
Based on this experiment, the team formed a working agreement:
|
My Position: Three Survival Strategies for Engineers
Faced with the rise of the Agent-programming paradigm, I think engineers will split into three strategic choices. There’s no absolute best or worst, but you need clear-eyed awareness.
Strategy one: “AI trainer” — go deep in a vertical domain
Become the “AI-context provider” for a specific domain. Your core value isn’t coding speed; it’s the ability to structure and make verifiable the domain knowledge.
This requires you to:
- Deeply understand the tacit knowledge of the business domain
- Build domain-specific verification systems and quality gates
- Continuously optimize the “human-machine collaboration interface” (task descriptions, an example library, feedback mechanisms)
Strategy two: “Systems architect” — master complexity
When the volume of AI-generated code grows exponentially, controlling complexity becomes the scarce skill. You need to design architectural constraints that let AI collaborate effectively, rather than letting it run wild.
Key skills:
- Define clear module boundaries and interface contracts
- Establish automatically verifiable architectural rules (ArchUnit, custom linters)
- Design “AI-friendly” code structure (explicit dependencies, minimal side effects, testability)
Strategy three: “Critical user” — stay selective
Not every scenario suits Agent programming. Keep a clear awareness of where a technology is applicable, and use the right tool in the right place.
My criteria:
- Suits an Agent: algorithm implementations with clear boundaries, boilerplate code generation, test-case expansion, documentation sync
- Doesn’t suit an Agent: core architectural decisions, security-sensitive logic, modules requiring deep business innovation, key code for team knowledge transfer
My choice: I’m transitioning toward a hybrid of “strategy one + strategy two.” My coding time has indeed dropped, but the time spent designing verification systems, optimizing collaboration flows, and cultivating the team’s AI literacy has grown sharply. This isn’t “getting easier” — it’s a profound shift in the nature of the work.
Summary and Outlook: Back to the Essence of Engineering
The rise of the Agent-programming paradigm is, in a sense, a return to the essence of engineering.
We once fixated on “how to write code” while neglecting “why write this code,” “how do we know it’s right,” and “how do we let it keep evolving.” AI’s intervention forces us to confront these fundamental questions again — because once you’re no longer writing every line with your own hands, defining correctness and verifying correctness become the whole job.
OpenAI’s guide, and similar industry practices, are groping toward a new engineering methodology. It isn’t mature yet and it’s full of room for trial and error. But the direction is clear: from instruction-based interaction between people and machines toward goal-based collaboration between people and AI.
For individual engineers, my advice is:
- Start experimenting now: try Agent programming in your own projects and build first-hand understanding
- Invest in verification skills: learn property-based testing, contract testing, formal verification, and the like
- Cultivate “meta-skills”: code can be AI-generated, but the abilities of requirements analysis, architecture design, quality judgment, and technical decision-making cannot be replaced
- Keep a critical mind: don’t blindly worship new technology, and don’t stubbornly resist change — instead, continuously assess “does this apply in my scenario”
Finally, about that eye-catching “PUA your AI” — I think it’s just a stage metaphor. Truly mature Agent programming should be like excellent teamwork: clear goals, explicit boundaries, timely feedback, mutual trust. Neither a person lording it over a machine nor a person groveling before an AI, but two intelligences co-creating under shared constraints.
The road is still long, but it’s worth walking.
Some of the views in this article are based on discussions with team members, as well as public documentation from OpenAI, Anthropic, and others. The experimental data has been anonymized.
If you’re interested in the practical details of Agent programming, feel free to join the discussion in the comments. As a ten-plus-year engineering veteran, I’m really curious about everyone’s real experiences — after all, the truth of technological change is often hidden in the concrete predicaments of frontline practitioners.
评论
0 条评论