Reject Vibe Coding, and the experts reveal 8 AI programming models.

Well - known Silicon Valley developer Simon Willison recently released a special guide.

Note, programmers who only do vibe coding, please step aside! This is for professional engineers.

When AI tools like Claude Code and OpenAI Codex can run code on their own, are traditional engineering habits still applicable?

Generating hundreds of lines of code has been shortened from a whole day to just a few minutes. All the past criteria for judging "whether it's worth writing" are completely invalid.

What will happen when the cost of writing code is zero?

Simon Willison said bluntly at the beginning:

Code has always been expensive. Producing hundreds of lines of clean code used to take a whole day or more. Now, it's a magnitude leap from 8 hours to 5 minutes.

All engineering habits are based on the premise that writing code is expensive.

Product managers measure the priority of features by development cost. Programmers weigh the same question before writing each piece of code - is it worth spending an hour on this?

Now, this set of logic has collapsed.

Refactoring takes only 30 seconds, generating tests takes only 1 minute, and creating a debugging interface takes only 2 minutes - all judgments of "whether it's worth it" need to be re - examined.

Simon Willison suggests:

When your intuition says it's not worth it, just try sending a prompt. The worst - case scenario is that you find it's not worth those few tokens after 10 minutes.

Simon Willison then poured cold water on it: Although code has become cheaper, good code is still expensive.

It should be able to run, have tests, be maintainable, handle errors gracefully, keep documentation in sync, and leave room for the future.

AI can generate code, but it can't guarantee these.

8 Patterns to Reconstruct the Workflow

Pattern 1: Writing code is cheap. The cost of code generation is almost zero, but the cost of delivering good code is still significant.

Pattern 2: Hoard known techniques. Archive all the problems you've solved.

Simon Willison's personal blog, TIL, and thousands of GitHub repositories are all "technique repositories".

Why hoard these techniques? Because AI can recombine them.

He gave an example: If you want to make a browser - side OCR tool that can handle PDFs, what would you do?

He had previously studied Tesseract.js (an OCR library) and PDF.js (PDF to image conversion) separately, but had never combined them.

So he fed two pieces of code to Claude 3 Opus and input: "Combine them. Drag in a PDF, convert each page to JPEG, and then perform OCR." It ran perfectly.

Once AI understands a technique, it can look it up, reuse it, and recombine it.

Pattern 3: Use Red - Green TDD

This four - word prompt condenses the entire test - driven development process: first write the test (fail/red), confirm the failure, then write the implementation (pass/green).

Why is it particularly effective for AI? Because the biggest risk with AI is writing code that "runs but is incorrect" or code that "is never used".

Testing forces AI to first define what is correct and then implement it.

Pattern 4: Run tests first

This is another four - word prompt.

Every time you start a new session, the first sentence is: Run tests first.

Use this sentence to tell AI that the project has tests. The number of tests implies the scale of the project and puts AI in a testing mindset.

Pattern 5: Linear walkthrough.

Let AI generate a structured code explanation document.

Simon Willison spent 40 minutes vibe - coding a SwiftUI slideshow app with Claude Code without looking at the code at all.

The app did run, but he didn't understand SwiftUI at all.

So, Simon Willison let the Agent cooperate with the Showboat tool to generate a walkthrough document, which explained all the.swift files in detail. He said:

I learned a great deal about SwiftUI and Swift from it.

In this process, AI not only didn't reduce learning, but became a learning accelerator.

Pattern 6: Interactive explanation. When text explanations are not intuitive enough, ask AI to generate visualizations.

He encountered the word cloud algorithm "Archimedean spiral placement" and still didn't understand it after reading the documentation.

So, he asked Claude to generate an animated demonstration page to show how each word finds its position along the spiral.

This animation made the principle of the algorithm truly easy to understand.

Pattern 7: GIF optimization case.

Use a complete prompt example to show how to let Claude Code build a WebAssembly tool.

Pattern 8: Commonly used prompt library

"Cognitive debt" is the real problem

Simon Willison proposed a key concept: cognitive debt - the code runs, but you don't understand the principle.

This is different from technical debt. Technical debt means poor code quality that needs to be repaid in the future; cognitive debt means you don't understand it yourself and need to learn it in the future.

He spent 40 minutes vibe - coding a SwiftUI app (conversation record). The app ran, but he knew nothing about it.

If this is applied to the core business, it's a huge hidden danger.

The core of the application becomes a black box, making it difficult to reason confidently and plan new features.

So, how to pay off the debt? The answer is : use linear walkthrough + interactive explanation to improve understanding.

If you're worried that LLMs will slow down the learning process, I strongly recommend adopting this kind of pattern.

Divergence on Hacker News

Simon Willison's guide sparked discussions on Hacker News.

Developer mohsen1 shared his real - world experience: using AI.

Code portal: https://github.com/mohsen1/fesh

He summarized and shared 4 pieces of experience:

1. Don't micromanage AI, let AI explore on its own
2. Testing is everything, without verification, the cycle will go astray
3. Let AI experiment freely, allow failure, and failure is also knowledge
4. Use.md for memory between sessions, AI has no cross - session memory, use Markdown as external memory

Another camp, "Dark Factory", advocates a more radical approach: throw tokens at the problem, verify as you go, and don't need to write tests in advance.

The two camps seem to be opposed, but they can actually complement each other - use strict TDD for core business and rapid iteration for prototype exploration.

But both sides have a consensus: verification cannot be omitted.

Simon Willison said that this set of patterns will be continuously updated, with the goal of 1 - 2 new chapters per week.

In this situation, we can't help but think: When writing code is no longer expensive, where lies the core value of engineers?

It may be three abilities: knowing what to write, knowing what good code looks like, and knowing how to keep AI on the right track.

Simon Willison's 8 patterns are essentially training the third ability.

But the first two still require deep engineering experience to support.

Code has become cheaper, judgment has become more expensive.

This may be the new value of software engineers in the AI era.

Reference materials:

https://news.ycombinator.com/item?id=47243272https://simonwillison.net/guides/agentic-engineering-patterns/https://simonwillison.net/guides/agentic-engineering-patterns/code-is-cheap/https://simonwillison.net/guides/agentic-engineering-patterns/hoard-things-you-know-how-to-do/https://simonwillison.net/guides/agentic-engineering-patterns/red-green-tdd/https://simonwillison.net/guides/agentic-engineering-patterns/first-run-the-tests/https://simonwillison.net/guides/agentic-engineering-patterns/linear-walkthroughs/https://simonwillison.net/guides/agentic-engineering-patterns/interactive-explanations/https://simonwillison.net/guides/agentic-engineering-patterns/gif-optimization/https://simonwillison.net/guides/agentic-engineering-patterns/prompts/https://simonwillison.net/2026/Feb/23/agentic-engineering-patterns/

This article is from the WeChat official account "New Intelligence Yuan". Author: New Intelligence Yuan, Editor: Qingqing. Republished by 36Kr with authorization.