Ex-SpaceX Engineer: To Make AI Write Good Code, Don't Rush to Build a "Software Factory" — 5 Basics Matter Most

While the whole tech world races to build AI agents, multi-agent systems and "software factories" that write code automatically, an engineer who worked at SpaceX offers a contrarian view: "You don't need a Software Factory. What you need is good software engineering and knowing where to spend AI tokens." According to a post by Nguyễn Văn Nghĩa in the group Claude - Codex - Grok - Ai Agent VN, the view comes from Lauren Tan (@poteto), a software engineer who worked at SpaceX and on Grok-related projects. In her view, the term "Software Factory" is being inflated by marketing; rather than building a complex system of agents that plan, write code, test and fix each other's work, what matters more is a solid software-engineering foundation of five layers: Codebase, Static Analysis, Verification, Prose and Human Review.

Quick answers

• A strong AI does not equal good software: AI writes code very fast, but the quality of the final product still depends on architecture, requirements, testability and how humans control the system. With a weak engineering foundation, AI can also help you produce "a pile of bugs" faster — which is why Lauren proposes the five-layer model.
• Layer 1 — Codebase: for AI to understand code, code must first be organized. A codebase with clear architecture, consistent APIs and understandable modules helps AI pinpoint exactly what needs changing; a tangled codebase means AI may fix one bug while accidentally creating three more.
• Layer 2 — Static Analysis: do not make AI do what traditional tools already do very well. Linters, type checkers, compilers and automated CI/CD checks give deterministic, repeatable results and cost no AI tokens per check — let dedicated tools find errors first, then use AI to analyze causes and propose fixes.
• Layer 3 — Verification: code that runs does not mean code that is correct. Software must be verified to actually meet requirements — unit tests, integration tests, behavioral tests, verification of important properties — proving that AI-generated changes do not break critical functionality.
• Layer 4 — Prose: sometimes a good guidance file is more useful than a dozen AI agents. An AGENTS.md file describing the project structure, naming rules, off-limits directories, tests to run and security requirements saves AI from guessing intent — reducing unnecessary changes and saving tokens; but the document must be kept up to date, because stale guidance can make AI do the wrong thing.
• Layer 5 — Human Review: AI finishing does not mean shipping to production immediately. For features involving payments, security, customer data or system access, humans must review important changes, assess risk and decide when software is ready to deploy; review depth should match risk level, but final responsibility cannot simply be handed to AI.

Why is a "strong AI" not enough for good software?

The post opens with a familiar paradox of the AI coding era: today a few prompts can make AI generate hundreds or even thousands of lines of code, and tools like Claude Code, Codex and AI coding agents are speeding developers up considerably. But code-generation speed does not automatically become product quality.

Per the argument presented in the post, final quality still depends on four things that belong to humans and to the foundation: architecture, requirements, testability, and how humans control the system. A messily structured project makes it hard for AI to identify what needs changing. A system without clear rules can make AI produce inconsistent code. An application without tests can look beautiful in a demo yet produce a flood of errors in real use. And the post's sharp conclusion: with a weak engineering foundation, AI can also help you create a pile of bugs faster.

What are the 5 foundation layers?

Layer	Name	Role, in Lauren Tan's view
1	Codebase	Clear architecture, consistent APIs, understandable modules — so AI pinpoints what to change instead of fixing one bug and creating three more
2	Static Analysis	Linters, type checkers, compilers, automated CI/CD checks — rule-based, deterministic error detection that costs no AI tokens
3	Verification	Unit tests, integration tests, behavioral tests, verification of important properties — proving code not only runs but meets requirements
4	Prose	Guidance files like AGENTS.md: project structure, rules, off-limits directories, tests to run, security requirements — so AI guesses less and saves tokens
5	Human Review	Reviewing important changes, assessing risk, deciding when to deploy — review depth matched to risk level

Layer 1 — Codebase: code must be organized before AI can understand it

The post uses an easy analogy: handing work to a new employee in an organization where documents are scattered, processes are unclear and everyone works differently — no matter how smart that employee is, effective work is hard. AI is the same.

A well-organized codebase — clear architecture, consistent APIs, understandable modules — helps AI pinpoint exactly what needs changing. Conversely, when everything is tangled together, AI may fix one bug while accidentally creating three others. The lesson is simple: do not invest only in stronger AI; invest in making your project easier to understand, easier to control and easier to maintain. This is also the base layer the other four stand on: static analysis tools, tests and guidance files all work better once the codebase is organized.

Layer 2 — Static Analysis: let tools do tools' work, save AI for reasoning

One mistake in AI coding, per the post, is handing AI the job of checking everything: syntax errors, data types, code formatting, and problems automated tools have long been able to detect. Meanwhile, dedicated tools already exist:

• Linters — detect rule and code-quality issues.
• Type checkers — verify data-type consistency.
• Compilers — catch many errors during compilation.
• Automated checks in CI/CD — run checks as part of the pipeline.

These tools give deterministic, repeatable results and consume no AI tokens per check. The workflow the post proposes: let dedicated tools find errors first, then use AI to analyze causes and propose fixes when needed. The division of labor: whatever machines can check with clear rules should be handled by automated tools; AI should be reserved for tasks that genuinely require reasoning. That is exactly what "knowing where to spend AI tokens" means in Lauren Tan's opening line.

Layer 3 — Verification: running is not enough, correctness must be proven

This is the part the post calls most important for anyone using AI to build applications. Imagine asking AI to build a sales system: AI writes a beautiful interface, the buttons work, data saves successfully — everything looks perfect. But what if the system miscalculates discounts? What if two customers buy the last item and the system confirms both orders? What if one user can view another user's order information?

Those are problems that "code runs" cannot by itself prove solved. Lauren stresses the importance of Verification — confirming the software actually meets requirements. That can include unit tests, integration tests, behavioral tests, verification of important properties and other suitable verification methods. A trustworthy AI coding system does not only know how to generate code; it also needs a way to prove that generated changes do not break important functionality. This layer also bridges to the last one: good tests help humans review faster and with more confidence.

Layer 4 — Prose: a good guidance file can beat a dozen agents

This is the model's most practical detail. Many people who want AI to work better keep adding agents, tools and automation layers. But sometimes all AI lacks is clear guidance.

For example, an AGENTS.md file can describe: how the project is organized; naming and code-writing rules; which directories must not be edited freely; which tests must run before work is complete; security requirements and things to avoid. With good guidance, AI does not have to keep guessing the developer's intent — reducing unnecessary changes and potentially saving significant time and token cost.

But the post also warns of the flip side: guidance documents must be updated regularly, because outdated guidance can make AI do the wrong thing. The layer's message fits in one line: AI does not always need more autonomy; sometimes it just needs clearer assignments.

Layer 5 — Human Review: final responsibility stays with humans

In the diagram Lauren shared, the final layer is Human Review — and it is not a formality. For features involving payments, security, customer data or system access, a small mistake can have large consequences. AI can produce code that looks perfectly reasonable yet contains logic errors, security holes or assumptions that do not match reality.

So humans need to review important changes, assess risk and decide when software is ready to deploy. That does not mean every line of code must be checked manually: the depth of review should match the level of risk. But final responsibility for product quality and safety cannot simply be transferred entirely to AI.

The biggest lesson: foundational knowledge is becoming more valuable, not less

The post's conclusion is what its author calls most worth reflecting on. As AI grows stronger, it is easy to be swept into the race for the newest tool, the strongest model or the most complex agent system. But sometimes the biggest advantage is not how many agents you have — it is whether you understand what you are building:

• Someone who understands software architecture knows how to split tasks for AI to handle effectively.
• Someone who understands testing knows how to spot when AI produces wrong results.
• Someone who understands security recognizes risks a beautiful demo can hide.
• Someone who knows how to organize work knows when to use AI, when to use traditional tools, and when humans must decide directly.

The post also keeps a balanced stance: that does not mean the Software Factory or Multi-Agent model is entirely useless — for large systems, complex requirements and well-designed processes, they can still deliver significant value. But complexity should not become the goal; it should appear only when it actually solves a problem.

And the most important question of the AI coding era, per the post, is no longer "how do we make AI write more code?" but "how do we make AI produce software that is more correct, safer, easier to maintain, and actually solves the problem?" — because in the end, product users do not care whether you used 1 agent or 100 agents to build it; they care only whether the product works well, is safe, and meets their needs.

Frequently asked questions

Who is Lauren Tan, and what is her view?

Per the post, Lauren Tan (@poteto) is a software engineer who worked at SpaceX and on Grok-related technology projects. Her view, as presented in the post: "You don't need a Software Factory. What you need is good software engineering and knowing where to spend AI tokens." She argues the term "Software Factory" is inflated by marketing, and that a solid engineering foundation of five layers matters more: Codebase, Static Analysis, Verification, Prose and Human Review.

What are the 5 foundation layers for AI coding?

(1) Codebase — organized source code with clear architecture and consistent APIs so AI identifies the right part to change; (2) Static Analysis — linters, type checkers, compilers and automated CI/CD checks that detect errors deterministically without spending tokens; (3) Verification — unit tests, integration tests and behavioral tests proving code not only runs but meets requirements; (4) Prose — guidance files like AGENTS.md describing structure, rules, off-limits directories, tests to run and security requirements; (5) Human Review — humans reviewing important changes according to risk level and keeping final responsibility.

Why shouldn't AI check everything?

Because many error types — syntax, data types, code formatting — have long had dedicated tools that detect them with deterministic, repeatable results and no AI token cost per check. Per the post, let tools find errors first, then use AI to analyze causes and propose fixes; reserve AI for tasks that genuinely require reasoning — that is "spending AI tokens in the right place".

How does an AGENTS.md file help AI coding, and what is the risk?

An AGENTS.md file describes the project structure, naming and code-writing rules, directories not to edit freely, tests that must run before work is complete, and security requirements — so AI guesses the developer's intent less, makes fewer unnecessary changes, and saves time and token cost. The risk: the document must be updated regularly, because outdated guidance can make AI do the wrong thing.

Does this view reject Software Factories and Multi-Agent systems entirely?

No. The post states clearly: for large systems, complex requirements and well-designed processes, Software Factory and Multi-Agent models can still deliver significant value. The message is that complexity should not become the goal — it should appear only when it actually solves a problem, and a good engineering foundation must come before a complex system.

Conclusion

Lauren Tan's view, as presented in the post, is a timely reminder amid the software-factory hype: AI's code-generation speed only becomes quality on top of a good engineering foundation — an organized codebase, static analysis with dedicated tools, verification through tests, clear written guidance, and human review calibrated to risk. In the AI coding era, foundational knowledge does not become useless; it becomes more valuable, because it decides whether AI is used in the right place or merely produces errors faster. And the final measure stays unchanged: whether the product works well, is safe, and solves users' needs — regardless of whether 1 agent or 100 agents built it.

Source: a post by Nguyễn Văn Nghĩa in the Facebook group Claude - Codex - Grok - Ai Agent VN (12 November 2026), presenting the views of Lauren Tan (@poteto), an engineer who worked at SpaceX and on Grok-related projects; the statements and five-layer model are as presented in the post. Edited and structured by Wotech Electronics. Illustration: image attached to the original post.