Software Engineering Fundamentals in the AI Engineering Skills Map

The second skill in Andrew Ng's AI Engineering Skills Map is the one people assume AI made obsolete: software engineering fundamentals. The opposite is true. When an agent can produce a thousand lines of plausible code in a minute, the scarce skill is the judgment to say what should exist, what the trade-offs are, and whether what came back is correct.

Why agents raise the bar instead of lowering it

Writing code was never the bottleneck in most teams — deciding what to write, and living with the consequences, was. Coding agents remove friction from the part that was already cheap and leave the expensive part untouched. A team that ships more code without more judgment simply accumulates the same debt faster.

Three things get harder, not easier:

• Review load. More code arrives per engineer per day, and none of it carries the author's mental model.
• Architectural drift. An agent optimizes the local task. Nobody but a human holds the shape of the system.
• Silent correctness failures. Agent code usually runs. Running is not the same as correct.

What the skill actually contains

Architecture and trade-offs. Choosing between cost, latency, scalability, and reliability with an explicit reason, not a default. In AI systems this includes model choice, caching strategy, and where to put a deterministic guard instead of another LLM call.

Debugging systems you did not write. Increasingly, the code under investigation was generated. Reading unfamiliar code quickly, forming a hypothesis, and isolating a failure is now a daily skill rather than an occasional one.

Testing calibrated to risk. Not blanket coverage — testing effort proportional to the cost of being wrong, with statistical evaluation where output is non-deterministic.

Operational discipline. Observability, CI/CD, rollback paths, and incident response. AI systems fail in ways traditional monitoring does not catch: drift, prompt injection, cost spikes.

Security posture. Agent-written code introduces dependencies and data paths nobody explicitly chose. Someone has to notice.

The failure mode: vibe-coding at scale

Vibe-coding is fine for a prototype and dangerous as a habit. The tell in an interview is a candidate who describes shipping something fast but cannot explain why the design is the way it is, what they rejected, or what would break first under load. That is not an AI problem — it is a fundamentals gap that AI made easier to hide.

How to screen for it

• Hand the candidate a piece of agent-generated code containing a real flaw — an N+1 query, a missing idempotency key, an unbounded retry — and ask what they would change before merging and why.
• Ask them to walk through the last system they debugged that they did not write. Listen for hypothesis-driven narrowing, not trial and error.
• Ask what they would delete from a system they recently shipped. Strong engineers have a list.
• Probe one trade-off decision end to end: options considered, the constraint that decided it, and what they would revisit at 10x scale.

Our Agent Skills library has a take-home challenge designer and a scorecard builder that make these prompts reusable across a hiring loop.

A worked example: the code-review prompt

The prompt we use most often is a short agent-generated endpoint that fetches a list of orders, then loops over them to fetch each customer, retries any failure indefinitely, and writes a payment record without an idempotency key. It runs. It passes a happy-path test. It is wrong in three separate ways.

What the answers sound like in practice:

• Weak. "Looks fine, maybe add error handling." No mental model of the system, no cost of failure.
• Adequate. Spots the N+1 query and suggests a join or batch fetch. Stops there — a real but purely local fix.
• Strong. Spots the N+1, bounds the retry with backoff and a dead-letter path, and asks what happens when the payment write is replayed. Then asks the question that matters most: what is the cost of a duplicate charge versus a dropped one, and which way should this fail?

The third answer is the whole skill. The candidate is not reading code faster than the others — they are reasoning about consequences the agent never modelled.

A scoring rubric you can reuse

Score each prompt independently and compare notes before discussing. Averaging scores after a group conversation mostly measures who spoke first.

Frequently asked questions

Does AI reduce the need for senior engineers? It increases it. Agents shift work from producing code to reviewing it, and review is a senior activity. Teams that thin out their senior layer while raising output usually discover the gap during an incident.

Should candidates be allowed to use AI in the interview? Yes, if the role uses it. Ban it and you are testing recall instead of the job. Watch how they supervise the tool: what they verify, what they reject, and what they never delegate.

How do we test this without a take-home? The code-review prompt above works live in 25 minutes with a pre-written flawed snippet. It needs no setup and produces sharper signal than most take-homes.

Where this fits in hiring

This skill is the clearest example of why the AI-First Talent framework puts craft depth before tool fluency. Expertise × AI is a multiplier: a strong engineer with agents compounds, a weak one with agents produces more of what you did not want. If your process still screens for framework trivia rather than judgment under trade-offs, start with the hiring maturity model and define what "good" means for the role before adding another tool to the stack.

Next in this series: using coding agents — the supervision skill that decides whether all of this compounds or collapses.