From Prompt Engineering to Engineered Prompts: What We Should Really Be Wary of When OpenAI Starts Teaching Us to 'Tame' AI

目录

1. Deep Anxiety Sparked by a Technical Guide

A few days ago on Juejin I saw OpenAI’s official guide “How to Build Reliable AI Code,” and the phrase in the title — “moving from ancient-style programming to Agent programming” — made me pause. As a veteran who has written code for more than a decade, the words “ancient-style programming” stung like a thorn, pricking some hard-to-name, complicated emotion.

The guide’s core logic is clear: the traditional “write-debug-refactor” model is too inefficient, so it should shift to a new paradigm of “define the task boundary — design the Agent workflow — verify the output.” The architecture diagrams in the illustrations are as polished as an enterprise-consulting deck, with all kinds of Agent nodes, tool calls, and feedback loops, striking a pose of “this is the future.”

But what made me stop wasn’t the technical detail; it was the transfer of discursive power behind the phrasing. When OpenAI starts defining what counts as “ancient-style” and what counts as “modern,” when a commercial company tries to reshape the entire cognitive framework of software engineering, should we, as practitioners, embrace this efficiency revolution, or be wary about ceding cognitive sovereignty?

In this article I want to talk about the technical logic and commercial motives behind the Agent-programming paradigm, and about how we frontline developers can find a balance between “using AI” and “being used by AI.”

---

2. Agent Programming: A Carefully Packaged Paradigm Revolution

2.1 From “Writing Code” to “Orchestrating Agents”

Let’s first calmly look at what OpenAI is actually advocating.

The essence of traditional programming is deterministic control: the programmer uses precise logical expressions to make the computer execute as expected. Bugs arise from logical gaps or missed boundary conditions, and debugging is a process of gradually approaching the deterministic solution.

The core of Agent programming is probabilistic delegation: the programmer no longer writes business logic directly but designs an agent system capable of calling tools, planning tasks, and self-correcting. Code moves from being an “instruction set” to an “orchestration script,” and the core complexity shifts from “how to implement” to “how to constrain.”

The four key principles stressed in OpenAI’s guide are representative:

# Traditional programming thinking
def calculate_tax(income, deductions):
    taxable = income - deductions
    if taxable < 0:
        raise ValueError("Invalid input")
    return taxable * TAX_RATE

# Agent-programming thinking (illustrative)
tax_agent = Agent(
    tools=[Calculator(), TaxCodeLookup(), ValidationService()],
    instructions="Calculate tax accurately, verify all assumptions",
    max_iterations=5,  # allow self-correction
    human_in_the_loop=True  # human confirmation at key decision points
)

The technical rationale for this shift is obvious. When business logic grows complex beyond the working-memory capacity of the human brain, delegating details to an Agent with context-understanding ability really can lower the cognitive load. But the problem is: this delegation comes at a price.

2.2 The Cost Structure That Gets Covered Up

When I did infrastructure at UpYun, I saw far too many “looks beautiful” technology migrations. Distributed storage replacing local storage, containerization replacing virtual machines — every paradigm shift comes with the transfer of hidden costs. Agent programming is no exception.

Cost one: debugging complexity rises exponentially

Debugging a deterministic system follows a linear trace of “input-process-output.” But an Agent system’s failure may be a wrong tool choice, a truncated context window, a false assumption from hallucination, or accumulated drift across multiple iterations. OpenAI’s guide casually mentions “adding a verification step,” but in production I’ve seen a financial-calculation Agent give a completely wrong result after three rounds of “self-correction” because a tool’s return format had been subtly changed — while each round looked “reasonable” in the logs.

Cost two: a fault line in the skill structure

“Ancient-style programming” cultivates precise expression, sensitivity to boundary conditions, and algorithmic intuition. Agent programming requires prompt-engineering skill, tool-interface design, and the ability to anticipate failure modes. These two skill sets are not entirely compatible. On my team there’s a backend engineer with five years’ experience who writes business logic cleanly and neatly, yet when designing Agent workflows keeps sinking into the quagmire of “prompt tuning” — he’s used to precise control, but an Agent needs fuzzy correctness with clear constraints.

Cost three: a new form of vendor lock-in

This is the most subtle and most dangerous point. Agent programming’s “orchestration scripts” depend heavily on the behavioral traits of a specific model: Claude’s coding ability, GPT-4’s tool-calling format, Gemini’s long-context handling — each has subtle differences. When your system architecture is designed around a certain model’s “personality,” the migration cost may far exceed the traditional notion of “switching databases” or “switching frameworks.”

---

3. “PUA Your AI”: A Metaphor Worth Chewing On

The phrase “PUA your AI” in the original title looks at first like attention-grabbing rhetoric, but on reflection it reveals a real mode of interaction.

3.1 The Psychological Turn of Prompt Engineering

Early prompt engineering focused on information completeness: give enough context, specify the output format, provide examples. But the evolution over the past year shows that large models are highly sensitive to tone, role-setting, and incentive mechanisms.

The “Chain-of-Thought” prompting recommended in OpenAI’s guide is essentially inducing the model to display its reasoning; the “ReAct” pattern (Reasoning + Acting) simulates human problem-solving behavior. More aggressive practitioners have found that telling the model “you are an expert-level programmer and this code will run in production” markedly improves output quality — even though there’s no technical basis for it, purely psychological suggestion.

This reminds me of A/B testing experience from my game-operations days at NetEase: user behavior is often driven not by rational decisions but shaped by situational suggestion and emotional resonance. Large models replicate this irrational trait to some degree, and prompt engineers are unconsciously becoming behavioral psychologists for AI.

3.2 When “Tuning” Becomes a “Game”

During my Youzan days I was responsible for parameter tuning of a recommendation system. That was a clear optimization problem: define the objective function, gradient descent, converge to a local optimum. But prompt engineering is entirely different — you’re playing an iterative game against a black box.

# A real iterative process (simplified)
v1_prompt = "Please fix the bug in this code"
# Result: the model rewrote the whole function and introduced new problems

v2_prompt = "Please fix the bug with minimal changes, modifying only the necessary lines"
# Result: fixed the original bug but ignored edge cases

v3_prompt = "You are a senior code reviewer. Carefully analyze this code, find all potential problems, then give a minimal-change fix. Thinking process: 1) original intent 2) actual behavior 3) gap analysis 4) fix plan"
# Result: quality improved, but token consumption up 300%

v4_prompt = v3_prompt + "If you can't be sure, explicitly state your assumptions"
# Finally usable, but response time up 40%

The “PUA” flavor in this process is that you keep adjusting your phrasing, probing the model’s “personality boundary,” searching for the magic phrase that triggers the ideal behavior. This isn’t engineering; this is domestication — and the object of domestication is a cognitive system you don’t truly understand.

The deeper problem is: when this mode of interaction becomes the norm, what happens to developers’ thinking patterns? I’ve observed a dangerous tendency: an aversion to certainty. Young engineers are starting to get used to “trying a different phrasing” instead of “understanding the essence of the problem deeply.” Rapid iteration replaces deep thinking — and that is precisely the most core value of “ancient-style programming.”

---

4. Critical Embrace: My Practical Framework

Having said all this, I’m not out to deny the value of Agent programming. In my last project at Youzan, we used an Agent architecture to rebuild the customer-service ticket-classification system, raising accuracy from 87% to 94% while cutting manual-annotation needs by 60%. But the process led me to a set of conditional-adoption practical principles.

4.1 Decision Matrix: When to Use an Agent

I drew a simple decision framework:

Dimension	Suits an Agent	Doesn’t suit an Agent
Output verifiability	Clear right/wrong criteria (e.g., code compiles, tests pass)	Requires subjective judgment (e.g., UI design, user experience)
Cost of failure	Rollback-able, human-reviewable	Irreversible, high-risk decisions
Problem stability	Requirements change frequently; hard-coded maintenance is costly	Logic is stable; write once, run long
Domain-knowledge depth	Needs integration of multiple sources (e.g., regulation lookup + calculation)	Core algorithm needs extreme optimization

Customer-service ticket classification falls in the first quadrant: clear classification criteria (verifiable), misclassification can be corrected by a person (low failure cost), business rules change often (high variability), and it needs user profiles plus history (multi-source information). But for the risk-control rules at the core of payments, we insisted on keeping the traditional implementation — even if an Agent could write “seemingly correct” code, we couldn’t bear the risk of black-box decisions.

4.2 Engineered Prompts: A Methodology Beyond “Tuning”

There’s one point in OpenAI’s guide I partly agree with: prompt engineering needs to be engineered. But my understanding is more conservative — engineering means testable, version-controlled, and auditable, not more elaborate prompting tricks.

Our practice:

# prompts/tax_calculation/v2.3.1.yaml
name: tax_calculation
version: 2.3.1
test_cases:  # regression tests that must pass
  - input: {income: 50000, deductions: 10000, state: "CA"}
    expected_output: {tax: 4200.00}
    tolerance: 0.01  # tolerance for numeric computation

system_prompt: |
  You are a tax calculation assistant. Your task is to compute state and federal tax.
  
  CONSTRAINTS:
  - Always use the provided TaxCalculator tool for arithmetic
  - If state tax rules are unclear, invoke HumanApproval before proceeding
  - Output must be valid JSON matching schema: {income: number, deductions: number, tax: number, breakdown: string}

  FAILURE MODES to avoid:
  - Do not assume tax rates; always query TaxCodeLookup
  - Do not perform mental arithmetic; always use tools
  
  # version-history comment, changes must be recorded with reasons
  # v2.3.1: added HumanApproval requirement, fixes #1842 unauthorized calculation
  # v2.3.0: relaxed JSON schema, allows breakdown to be null

Key design:

• Prompt as code: version control, code review, regression tests in CI/CD
• Explicit constraints: not relying on the model’s “understanding,” but enforcing behavioral boundaries
• Failure-mode documentation: presuppose known risks rather than assuming the model handles them correctly
• Traceable changes: every modification must be tied to a business reason, to prevent “tuning drift”

4.3 The Human-Machine Boundary: Preserving the Dignity of “Ancient-Style”

The most important point: in our architecture, an Agent’s output is always a candidate, never the final decision. This isn’t just risk control; it’s protection of the developer’s subjectivity.

I require the team to follow a “three-stage verification”:

1. Automatic verification: compilation/tests/static checks pass
2. Diff review: the diff against the baseline version must be human-readable and understandable
3. Intent alignment: code comments must state “what problem this code solves”; Agent-generated comments tend to describe “what was done,” whereas what we need is “why”

The third point comes from a bitter lesson. During Youzan days, an Agent-generated cache-invalidation logic performed perfectly in stress tests but caused data inconsistency after release. In the post-mortem we found the code correctly implemented “rebuild the cache when it expires,” but what the business actually needed was “on cache expiry, fall through to the database and rebuild asynchronously.” The Agent understood the literal requirement but lost the implicit constraint in the business context.

---

5. A Deeper Worry: Cognitive Outsourcing and Skill Atrophy

Having written this far, I want to step outside the technical details and talk about what’s happening to this industry.

5.1 The Death and Rebirth of “Ancient-Style”

The irony of the phrase “ancient-style programming” is that it demeans the precise expression, logical-reasoning training, and systems-thinking methods humanity accumulated over millennia into an outdated craft. But ironically, the effectiveness of Agent programming depends precisely on the stock of these “ancient-style” abilities.

The engineers who can design reliable Agent systems are usually those who’ve been tempered by “ancient-style” practice — they know where the boundary conditions are, can anticipate failure modes, and can spot the subtle errors in hallucinated output. Can a new generation of developers who grow up entirely with Agent assistance still develop these abilities? It’s an open question, but I lean pessimistic.

The last apprentice I had at UpYun was a typical “AI-native” programmer. He could, within half an hour, use Cursor to stand up a fully functional web service, but faced with a memory leak, his debugging strategy was “let AI look at this code and see what’s wrong,” rather than systematically analyzing the stack, reproducing conditions, and examining resource life cycles. This dependency in the problem-solving path is harder to repay than any technical debt.

5.2 The Efficiency Trap Under Commercial Narrative

As a commercial company, OpenAI has every incentive to push the spread of Agent programming. Every “paradigm shift” means a new training market, consulting services, and certification system — and, deeper still, dependency lock-in on AI infrastructure.

But the efficiency-gain narrative often covers up the transfer of hidden costs. When CTOs applaud a demo of “3x faster development,” few ask: is this 3x speed sustainable? How is the quality debt repaid? How does the team’s skill structure evolve? Is the vendor-switching cost underestimated?

I lived through a similar cycle at NetEase. When the Hadoop ecosystem rose, “big data” replaced “databases,” and three years later many companies found their maintenance costs far exceeded expectations and gradually retreated to simpler architectures. Agent programming may be repeating this pattern, only this time the lock-in effect is stronger — you’re not depending on an open-source framework, but on a continuously evolving cognitive system whose behavior can’t be fully predicted.

---

6. Conclusion: Between the Tool and the Subject

Back to the question at the start: when OpenAI teaches us to “tame” AI, what should we really be wary of?

My answer is: beware of mistaking tool use for possessing ability, mistaking interaction tricks for domain understanding, and mistaking efficiency metrics for value creation.

Agent programming is a powerful tool that can unlock enormous productivity in the right scenarios. But it shouldn’t become the only tool, and it certainly shouldn’t define what is “modern” and what is “ancient-style.” A truly mature engineer should be able to switch freely between the two paradigms: use Agents to explore possibilities, use precise control to ensure reliability; use probabilistic systems to handle ambiguity, use deterministic systems to guard the bottom line.

Finally, to the young developers reading this: don’t be intimidated by the “ancient-style programming” label, and don’t be dazzled by the “AI-native” halo. Those fundamentals that require patient learning — data structures, algorithms, system design, debugging methods — won’t lose value because the tools change. On the contrary, in an increasingly probabilistic world, the ability to think precisely will become scarcer and therefore more precious.

The mission of our generation isn’t to choose a camp, but to stay clear-headed: use AI, but not be defined by it; pursue efficiency, but not sacrifice understanding; embrace change, but safeguard the things worth passing on.

After all, some late night ten years from now, when production has an outage, what saves you won’t be some Agent’s “self-correction,” but your own deep understanding of the system — the kind of understanding that can only be gained through the tempering of “ancient-style” practice.

---

Some cases in this article come from the author’s work experience at Youzan and UpYun and have been anonymized. The technical views represent personal opinions only and are unrelated to the author’s affiliation.

中英对照

文章作者：阿文

文章链接： https://www.awen.me/post/945c0e9e.html

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 阿文的博客！