Fundamentals that must remain strong

5.1. Understanding code: semantics before memory

The engineer needs to read a piece of code and understand what it does, what state it modifies, what assumptions it relies on, and how it can fail. This requires familiarity with types, scope, mutability, error handling, resources, concurrency, and the execution model of the language relevant to their work.

This mastery makes it possible to select what to investigate and which controls to require. It does not presuppose a full human re-reading of everything the agents produce; section 7 describes how to distribute verification and attention.

AI can produce the syntax of an asynchronous routine. The judgment required includes noticing whether cancellation is propagated, whether a task is left orphaned, whether exceptions are lost, and whether resources are released. These problems require a mental model of execution.

Practical criterion: given new code, be able to predict an important behavior, create a case that confirms or refutes the prediction, and explain the result. You can use AI in the investigation; the understanding needs to become demonstrable.

The CS2023 curriculum, developed by ACM, IEEE-CS, and AAAI, already distinguished changing activities from enduring fundamentals: greater abstraction, comprehension, verification, and decomposition coexist with the need to evaluate algorithms and programs. It is curricular guidance from experts, published in 2024, and not a measurement of current model capabilities. F14

5.2. Algorithms, complexity, and representation

The study of algorithms should serve choice and evaluation. What matters is recognizing when a data structure changes the order of magnitude of the cost, when volume makes an implementation infeasible, and when an approximation changes the product's answer.

An engineer can delegate writing a search or a sort and still need to notice that composing two seemingly simple operations created quadratic cost. They also need to distinguish asymptotic performance from concrete costs: allocation, network, disk, cache, serialization, and contention can determine the observed behavior.

Priority: understand classes of problems and resource limits, use measurement, and examine adversarial cases. The number of algorithms one can recite from memory is a very limited indicator of this mastery.

5.3. Data modeling and correctness under concurrency

Data requires attention to meaning, identity, cardinality, invariants, authorization, history, and schema evolution. A query that runs without error can duplicate records in a join, mix customers together, or count the wrong entity. A transaction can be syntactically valid and still insufficient for a concurrent business rule.

The PostgreSQL documentation shows, for example, that Read Committed isolation works with per-statement snapshots and has specific behaviors in the face of concurrent updates. The choice of isolation level and constraints needs to match the intended invariant; “put it in a transaction” does not describe the whole solution. F28

Practical criterion: explain what happens when two requests arrive together, when one fails after writing, and when a migration needs to coexist with different versions of the application.

5.4. Distributed systems and side effects

Timeouts, retries, ordering, consistency, queues, load control, and partial failures remain a central part of many systems. The engineer should understand that the absence of a response does not mean the absence of an effect.

The Amazon Builders' Library describes idempotency as a contract that allows calls to be retried without adding the unwanted effect, with identification of intent and explicit handling of repeated requests. The relevant skill is defining that contract and verifying that it holds, including under concurrency. F29

This knowledge also applies to agents. If a tool fails after sending a request, retrying may duplicate an action. Tools that expose operation identifiers, queryable states, and clear retry rules enable more reliable recovery.

5.5. Architecture as the definition of useful constraints

Architecture should make responsibilities, dependencies, and hard-to-reverse decisions clear. In an environment with abundant execution, these boundaries help prevent local solutions from harming the whole.

It is worth going deeper into API contracts, separation of domain and infrastructure, compatibility, schema evolution, and component isolation. The goal is to enable independent changes and reduce the knowledge needed to perform each task correctly.

It is equally necessary to recognize abstraction without benefit. AI can produce layers, adapters, and services quickly; the engineer should demand a reason for their existence. An architecture needs to respond to observed needs or concrete constraints. The degree of formalization should track the lifespan and consequences of the system.

The treatment of time, scale, and trade-offs in Software Engineering at Google helps frame this judgment: building software includes sustaining its ability to change over time. F35

5.6. Debugging as causal investigation

Debugging well involves formulating hypotheses, seeking evidence that discriminates between them, and narrowing the problem down. AI expands the ability to surface causes, locate code, and prepare experiments. It is up to the engineer to keep the investigation connected to the real phenomenon.

If a request is slow, you need to separate CPU wait, I/O, locking, queuing, network, and dependencies. Adding a cache without understanding the cause can hide the symptom and introduce inconsistency. The useful question is which observation would change the current hypothesis.

Mastery exercise: before running an experiment, predict which signal should change if the hypothesis is correct. Then compare prediction and observation. This teaches you to recognize when a fix merely moved the problem elsewhere.

5.7. Operations and observability

The system needs to be understandable while running. Logs describe events; metrics make it possible to track aggregate behavior; traces relate the steps of an operation. OpenTelemetry provides a common foundation for producing and correlating these signals. F31

The engineer should know how to choose the relevant signals, interpret latency tails, distinguish error from success, and relate a change to the observed behavior. The monitoring chapter of Google's SRE book highlights latency, traffic, errors, and saturation, combining internal observation with external experience. F32

Generating a dashboard can be delegated. Knowing whether the dashboard answers the operational question remains technical judgment. This includes limiting sensitive data in telemetry and avoiding metrics whose cardinality makes observation expensive or hard to use.

5.8. Product, domain, and user experience

The easier it is to implement an idea, the greater the need to choose the problem well. The engineer needs to understand who uses the system, what task they are trying to accomplish, which constraints matter, and how to recognize improvement.

The HEART framework, presented by Google researchers, proposes translating product goals into user-centered signals and metrics. It is a reference for connecting engineering to observable outcomes. F37

This connection requires concrete skills: talking with users, observing usage, interpreting feedback, negotiating scope, and evaluating accessibility. A screen can look complete and still fail at keyboard navigation, in error states, or in making an important decision understandable. AI can explore alternatives; the success criteria need to represent real people.