Why Software Engineering Fundamentals Matter More in the AI Era

If you’ve used Cursor or similar tools lately, you know the drill: describe what you want, hit Tab a few times, and a feature works. You didn’t type every line. It’s faster than before.

But here’s the question that creeps up later: when you no longer produce code line by line, how do you know your system won’t break in production?

Andrew Ng recently laid out a perspective in his AI Engineering Skills Map: understanding how software works is becoming the dividing line between those who can effectively steer coding agents and those who can’t.

A novice who “vibe codes” without any software fundamentals can indeed cobble together a working app. But in dimensions you may not even be aware of—latency, availability, consistency, reliability, maintainability, simplicity, and cost—the coding agent makes default trade-offs for you. You don’t know those trade-offs exist, so you can’t tell the agent which way to lean.

The problem isn’t the agent. It’s that you don’t know what you don’t know.

Below are five areas that Ng highlights as the most valuable software engineering fundamentals to strengthen in today’s AI engineering practice.

How Agentic Coding Changes Your Role

Agentic coding is pushing developers who once played specialised roles (front‑end only, mobile only) toward a broader full‑stack position.

An agent can help fill gaps in unfamiliar areas, but only if you have a mental model of the whole application landscape. You don’t need to memorise every API signature, but you should know which components exist on the front‑end and back‑end: UI components, caching, page rendering, API design choices, authentication, state management, session handling, asynchronous processing, data persistence, testing, security, and accessibility.

These aren’t things you must write yourself. They are things you need to evaluate when the agent proposes a solution. Given your user base and latency requirements, does that choice make sense?

Data Management: If You Get the Architecture Wrong, Even AI Can’t Save You

Data deserves its own section for a simple reason: software sits on top of data, and once a data architecture is set, it’s much harder to change than code. An agent can write migration scripts, but it won’t absorb the downtime or consistency issues for you.

An experienced AI engineer does several layers of homework on data.

First, think through access patterns. Which queries are most frequent? What’s the read‑to‑write ratio—10:1 or 1:1? These patterns determine what you store and for how long.

Second, choose the right storage type. Relational tables, documents, key‑value stores, graph databases—each excels in different scenarios. Pick wrong, and you affect speed, scalability, availability, reliability, and cost all at once.

Third, understand transactions, concurrency, data cleanliness, consistency requirements, and freshness. How these translate to your specific business context is something only you can provide to the agent.

Ng makes a crucial point: the input context for your AI system comes from your data sources. If the data architecture is poorly chosen, the AI doesn’t know what it doesn’t know. It gets skewed inputs, so outputs can’t be right.

Data lifecycle management, privacy, governance, and compliance—these become heavier, not lighter, in AI applications.

There’s also a rapidly evolving area: building data infrastructure for agents (rather than just for traditional software or humans). Best practices are still shifting, so stay tuned to updates in this space.

System Architecture: The Right Architecture Is a Moving Target

Knowing the full‑stack components and how to handle data sets you up for actual system design.

A good design starts with a set of questions: What does the software do? What’s the user scale? Is it latency‑sensitive or cost‑sensitive? Where do you draw the front‑end/back‑end boundary? How do you decompose the system? Where do you place application state? What granularity—monolith or microservices?

Ng notes one easily overlooked fact: the right architecture is a moving target. The simplest design for a quick prototype is rarely the right one for the first production version. And that production version may not survive a tenfold increase in users. You need to consciously evaluate which phase you’re in and adjust accordingly—not stick with one architecture forever.

As for the tech stack, you can now run small experiments with agent assistance to evaluate options, but the final call still relies on your understanding of the application context.

Security and Reliability: Shift Left, Then Shift Left Again

Reliability isn’t something you patch after launch.

Testing strategy is your first line of defence. What mix of unit and integration tests? Which frameworks? What coverage level? These decisions should be based on the system’s risk points, not cookie‑cutter templates.

Then, design for failures. Suppose an API you depend on starts rate‑limiting today—what happens? Ng’s suggested approach: explicitly design graceful degradation and limit the blast radius of failures. You can pass these intentions to the agent via comments or constraints, but only if you have that awareness in the first place.

On security, there’s a clear trend: shift left. Don’t wait until after the code is written for a security team to scan it. Incorporate security considerations early in the development cycle. AI tools can now scan your code for vulnerabilities, check dependencies for supply‑chain injection risks, and examine your cloud configuration for attack surfaces. They are magnifying glasses—you still need to know where to look.

Production: Deployment, Operations, and Scaling

Finally, you deliver the software to real users.

Deployment involves: environment configuration, release strategy (canary or full rollout?), CI/CD pipelines, and Infrastructure as a Service (IaaS) basics.

Once live, you need observability, alerting, and incident response procedures.

For scaling, Ng lists several levers: understanding actual load, horizontal scaling, load balancing, data‑layer tuning (sharding, indexing, replication), and even architectural changes when necessary.

There’s also a set of skills that runs through everything: version control, code reviews, dependency maintenance, and technical debt management. These become more important as agents generate more code—managing the evolution of the codebase is still a human task.

Actionable Checklist

• Before asking an agent to write code, confirm you have a basic grasp of the full‑stack components involved.
• Before choosing a data store, list 3–5 most frequent query patterns.
• For every architectural decision, note the current phase (prototype / production / scaled) and the reasoning behind your choice.
• Design a degradation path for every external dependency – at least think “what if this fails?”
• Run AI‑powered dependency and cloud configuration scans before deployment.
• Set up observability and alerting on day one of production.
• Dedicate ~20% of each iteration to technical debt and dependency updates.

FAQ

Q: If I’m vibe‑coding a personal project, do I really need all this?

If you’re building something for yourself only, with no user data or uptime requirements, you can skip it. Once you go to production with real users, it becomes a choice: either you make the trade‑offs consciously, or the agent makes them by default—and you probably won’t like the results.

Q: Can an agent refactor a poorly chosen data architecture?

An agent can write migration scripts, but decisions like downtime windows, consistency checks, and field‑mapping logic are yours. Moreover, if the data model changes, the input format for your AI application changes too—a chain reaction that you have to orchestrate.

Q: I’m not an ops person—how do I get started with scaling?

You don’t need to become a full‑time SRE. Start with three numbers: requests per second, database connection pool utilisation, cache hit rate, and API response time. Once you understand these, you’ll know when to scale and when to tweak indexes.

Q: What does “shift left on security” mean in practice?

Instead of having the security team review only after code is written, you do two things during development: use SCA tools to scan dependency vulnerabilities and SAST tools to find hard‑coded secrets and SQL injection risks. Most of these tools now have AI assistance and run in minutes.

Q: How do I know when to refactor if architecture is a moving target?

Ng suggests three triggers: a 10× change in user volume, a change in latency requirements, or a change in cost structure. Any one of these warrants a re‑evaluation. You don’t need to refactor proactively, but you must actively assess.

Q: Isn’t it too late to learn these fundamentals now?

You don’t need to read a computer science textbook cover‑to‑cover. Pick one of the five areas above, find a practical guide, and as you use your agent, gradually build the judgment for each. The agent writes; you judge whether what it wrote is right. That’s the most effective division of labour today.