Engineering notesAI-assisted engineering / five perspectives

Beyond “engineers still matter”

Code is cheap.
Understanding
is earned.

Five comments on what code ownership means when a plausible implementation arrives before a reliable mental model.

CounterexamplesObservability debtAtomicityLearning loopsDurable ownership

Discussion companion to Michal Stawarz’s “Engineering Leadership in the AI Era, Part 5.”
Original post: https://lnkd.in/p/dTEM2d2a
These are proposed responses, not quotations from the author. Code samples are illustrative, not the rejected PR or complete production implementations.

Read a perspective, copy the comment, and adapt it to your voice.

01 / Recommended conversation starter

Ask for a counterexample,
not just an explanation.

Michal, I’d add one requirement to code ownership: explain a scenario where your fix would be wrong.

An explanation can be generated as easily as an implementation. A counterexample makes the assumptions testable.

Take duplicate payments. Disabling the submit button looks reasonable. But what happens if the server charges the customer and the response is lost? The user retries. The button guard cannot tell whether the first payment succeeded.

if (isSubmitting) return;
setIsSubmitting(true);
await submitPayment();

Now the engineering question becomes: how does the server recognize the same payment intent across retries? That requires a durable idempotency mechanism, not just a UI change.

The revealing review question isn’t “Does this work?” It’s “What sequence of events would make this look correct while still failing?”

That tests understanding much better than a polished explanation.

02 / The silent failure

Some fixes remove the evidence,
not the defect.

One subtle danger is that a patch can improve the dashboard while making the system less truthful.

The exception disappears. The financial total may now be wrong.

Neither behavior is automatically the right product experience. The important question is whether “unknown amount” is allowed to mean “zero amount.” If not, the system needs an explicit incomplete-data state, rejection, or correction upstream.

# Before: missing data fails visibly.
total = sum(order["amount"]
            for order in orders)

# "Fix": missing data becomes zero.
total = sum(order.get("amount", 0)
            for order in orders)

I’d call this observability debt: we make the system look healthier by removing its ability to tell us something is wrong.

A useful review question: “Did this change eliminate the invalid state, handle it honestly, or merely hide it?”

03 / The boundary of correctness

The correct fix may live
outside the changed function.

Your example also highlights why reviewing only the diff is insufficient.

Suppose inventory occasionally becomes negative. A local stock check looks sensible. But two requests can both read the last available item before either updates it. Adding another local condition does not solve that race.

For a simple single-row inventory model, the operation could instead be expressed atomically. The caller must check whether one row was updated before treating the reservation as successful.

# A local check is not atomic.
if stock > 0:
    stock -= 1
UPDATE inventory
SET stock = stock - 1
WHERE product_id = :product_id
  AND stock > 0;

Correctness depends on where the rule is enforced, not how convincing the local code looks.

AI can make a function more elegant while leaving the system-level failure untouched. Review needs to follow the state across requests and storage, not stop at the function boundary.

04 / A better use of the agent

AI can compress the learning loop too,
if we ask for the right work.

I agree that implementation used to force some learning to happen. But writing everything manually was never a guarantee of understanding either.

The opportunity is to use AI to accelerate investigation, not just construction. Instead of immediately asking for a patch, ask:

For an intermittent timeout, for example, slow queries and connection-pool exhaustion can produce similar symptoms but require different fixes.

Identify two plausible causes.
Find an observation that distinguishes them.
Build a minimal reproduction.
Predict the result before running it.
Then propose the smallest supported fix.

The important distinction is a plausible story versus a prediction checked against the system.

Perhaps the new engineering skill is designing learning loops that are faster than coding loops.

05 / After the handover

An FDE’s understanding must
survive their departure.

The Forward Deployed Engineering connection is interesting, but I’d separate acquiring context from leaving it behind.

An FDE might discover that “one customer” means a legal entity to finance, an account to sales, and a subscription to the application. A technically correct integration can still reconcile the wrong things.

The valuable output isn’t just working code. It is that distinction captured in the data model, examples, tests, and operational documentation.

Otherwise, the organisation has temporarily rented someone’s understanding.

A useful success criterion would be: can the permanent team diagnose the next failure without calling the original implementer?

Code ownership becomes durable when understanding is transferred, not merely demonstrated.

Continue the discussion: https://lnkd.in/p/dTEM2d2a