AI Writes Code, But Misses Trade-offs: Why Software Engineering Fundamentals Are Essential

Andrew Ng, in The Batch #368 (August 28, 2026), addresses a heated debate: with AI coding agents generating complete applications, do software engineers still need software engineering fundamentals? Ng's answer is a calm affirmative — fundamentals are more important than ever.

Even if you use a coding agent to write all your code, understanding software engineering fundamentals remains vital — because it helps you guide the agent to make the trade-offs you want, and even makes you aware that a trade-off exists here.

Core Insight: Agents Implement, Humans Decide Trade-offs

Software engineering is essentially choosing among competing goals: latency, availability, consistency, reliability, maintainability, simplicity, cost, plus security and privacy. A vibe-coding novice doesn't know these trade-offs exist, so they cannot steer the agent. The agent makes choices silently; the human must see the choices and judge them.

Ng breaks this capability into five modules (numbering is narrative order only; modules have no fixed dependency):

Building full-stack applications — Understand how system components collaborate, not just invoke agents

Managing data — Data architecture is harder to change than code; wrong choices have long-term impact

Designing system architectures — No standard answer; architecture evolves with product stage

Making systems secure and reliable — Security shifts left; every developer becomes half a security engineer

Scaling and operating in production — A working demo ≠ a production system

Module 1: Building Full-Stack Applications — Agents Widen the Engineer

Agentic coding lets frontend or mobile developers tackle full-stack work because the agent fills gaps. But Ng warns: full-stack knowledge is still required. The agent can implement components, but "how the whole system fits together" remains a human task. A mature developer must understand:

UI components, caching, page rendering

API selection and design, authentication

State/session management, async processing, data persistence

Testing, security, accessibility

Implementation goes to the agent; "knowing how the system should be assembled" is human work.

Full-stack in the AI era means not writing every layer by hand, but understanding how each layer collaborates.

Module 2: Managing Data — Why It Deserves Its Own Module

Two weighty reasons:

Data is the foundation of software construction.

Data architecture is relatively hard to modify — even with agent-assisted migrations, changing data models remains painful.

Code mistakes are quickly refactored; wrong data models require bone-breaking migrations. Managing data means answering:

What are the system's access patterns? What to store, for how long?

Which data model: relational, document, key-value, graph?

How do these decisions affect speed, scalability, availability, reliability, cost?

Deeper: understand transactions and concurrency to keep data clean, consistent, fresh; enforce privacy, governance, compliance; manage the full data lifecycle.

For AI applications, Ng highlights a unique causal chain:

Your AI system retrieves its own input context from your data sources. So if the data architecture is poorly chosen, the AI "doesn't know what it doesn't know."

Traditional software fails loudly when data is missing; AI systems confidently hallucinate with incomplete context. Building data infrastructure for agents (not just humans or traditional software) is a rapidly evolving field requiring continuous iteration of best practices.

The scariest outcome of a bad data architecture isn't a system crash — it's an AI that "doesn't know what it doesn't know," confidently proceeding with crippled context.

Module 3: Designing System Architectures — No Standard Answer

Good system design starts by clarifying what the software must achieve:

How many users?

How important are latency and cost?

What other constraints exist?

Only then can you choose: application platform, frontend/backend boundaries, system decomposition, state placement, architecture granularity — monolith vs. microservices. Then pick tech stack: language, runtime, frameworks, data technologies. Sometimes experiments are needed to evaluate options.

Key message: Correct architecture is a moving target; it changes with project stage.

The simple architecture you pick for rapid prototyping may not suit the first production system; as scale grows, the production architecture may need to change again.

Real engineering skill is knowing what to choose when, and when to change — not memorizing a "best architecture." Pure vibe coding fails here: the agent outputs a "seemingly working" system, but without understanding trade-offs among latency, availability, reliability, cost, you cannot judge why the agent chose that architecture or whether it's wrong.

Module 4: Making Systems Secure and Reliable — Security Shifts Left

Reliability demands a complete testing strategy. Ng lists decisions:

How to combine unit and integration tests? Which frameworks? What coverage target?

Design for failure:

How to handle API rate limits?

Can the system gracefully degrade when a service fails?

How to minimize blast radius of single points of failure?

On security, Ng states a clear trend: Security is shifting left — from "add security after writing software" to earlier in the lifecycle. Consequence: more developers must shoulder part of a security engineer's responsibilities.

AI tools help: scan code vulnerabilities, check supply chain injection in dependencies, probe cloud configuration attack surfaces. But Ng cautions:

Tools can surface issues, but you still need enough security knowledge to understand those issues.

Otherwise, a scan report dumps high-severity findings you cannot prioritize or explain.

Module 5: Scaling and Operating in Production — Demo ≠ Production

AI coding tools make demos trivial. Ng places "production operations" as the fifth module, marking the true watershed for engineering talent in the AI era:

Going from 0 to 1 becomes very fast; going from 1 to 100 still relies on engineering judgment.

Serving real users requires mastering the full SDLC: beyond build and test, includes deployment environment config, release strategies, CI/CD automation, IaaS. Post-launch: observability, alerts, incident response. As traffic grows: scale servers, load balancing, adjust data infrastructure via sharding, indexing, replication, possibly re-architect. Long-term: version control, code review, dependency maintenance, technical debt management.

This entire block is the widest chasm between demo and production. Running once and running continuously under real load are two completely different things.

Conclusion

AI hasn't made software engineering disappear. On the contrary, as AI participates in more development work, the importance of understanding software engineering, judging code quality, designing system boundaries, and verifying results is amplified.

Previously, engineers wrote limited code daily, so practices focused on "how to improve development efficiency." Now AI generates vast code quickly. New questions: how to make AI generate correct code? How to keep AI on the right track? How to review, verify, and constrain AI's output?

Thus, AI engineers don't need software engineering less; the fundamentals are shifting from "writing good code yourself" to "understanding code, designing systems, constraining AI, verifying results." This is the growing dividing line between AI engineers and developers who merely use AI to write code.

Next article: the fourth capability in Ng's AI Engineering Skills Map — using programming agents. When AI becomes not just a code completion tool but can understand tasks, modify code, run tests, call tools, and autonomously complete development workflows, how should engineers collaborate with coding agents?