Definitions of “engineering excellence” are often just a list of practices. Test, review, small batches, observability, fast feedback. These are all part of excellent engineering, but not what makes engineering excellent.
Engineering excellence is about the people:
One of the most fascinating things to fall out of the AI apocalypse is seeing how abundant AI access amplifies the qualities of a company. IMO, Deno has always been more methodical, more focused (maybe too focused?) on standards. But now the Deno team is on the right track: using Claude extensively to improve the node.js compat which was absolutely herculean if not impossible before AI.
- mmastrac, Hacker News
You're touching on something I've been thinking about a lot lately. There's this notion that LLMs only increase volume and there's an inevitable intrinsic decline in quality. In reality, it's more like an amplifier as you mentioned; people interested in good engineering can iterate more deeply and focus more intently on specific problems than they could, and they aren't inherently forced to output more garbage.
- steve_adams_86, Hacker News
When people wrote the code, the engineer's standards and the software's quality were one and the same. Now, agents separate them. The engineer sets the intent,, and the agent writes the code; if the intent wasn’t “engineering excellence,” the agent can't add it.
The answer is obvious, and tough: excellence needs to stop being innate and has to be made deliberate.
AI amplifies your excellence, or lack thereof
AI takes the quality a team already has and scales it up or down. If your team is meticulous about standards, pointing AI at a hard problem produces more of that meticulousness. If your team is careless to begin with, it gets the same multiplier on its carelessness, just faster.
The agent has no stake in whether the result is good, and no way to answer for it when it isn't, beyond a “You’re right - and here’s why it matters.” Instead, the agent inherits your standards. More than that, because of the unconstrained volume of AI, it acts as an amplifier: AI takes the care, or the lack of it, that you brought to the work, and multiplies it across far more code than you could have written by hand.
AI has changed who writes the code but left ownership exactly where it is.
- Who writes the code? The agent. The authorship, the hours of typing, the boilerplate, and the first draft of almost anything.
- Who owns the code? The engineer. You can't hand over the accountability. An engineer is still on the hook for any screw-up, just at 10X the volume.
That ownership has two sides: what excellence looks like for the engineer who sets the standard, and for the agent who executes against it.
Engineers own excellence
Agents act on the context, constraints, and feedback loops you give them. If the quality bar lives only in an engineer’s head, the agent cannot reliably preserve it. Whatever you leave unspecified, it fills with a guess pulled from its training rather than from what your product needs.
So setting the standard means codifying it. The judgment you used to apply by hand, without ever stopping to explain it, now has to live outside your head, in a form precise enough that an agent builds the right thing without you in the room.
That form is a spec, and the most honest version of it is a test: your definition of correct, made executable and specific to your product. The agent shows up knowing only the average of the code it trained on. The test is how it learns what quality means in your particular case, as it iterates over runs correcting in relation to that test.
Writing one is a handful of moves, and precision is what separates a spec from a wish:
- Start with behavior. Say what the feature should do for the user before anything about how it's built. Behavior outlives the agent rewriting the implementation underneath, while a test tied to the code breaks the moment the code changes. This is the old argument behind behavior-driven development .
- Push past the happy path. The value is in the cases it doesn't obviously cover: the empty state, the timeout, the malformed input, and two users editing the same record at once. List the ones that actually happen in your product, because the agent won't think of them for you.
- Name the invariants. The things that have to hold no matter what path the code takes. Never double-charge a customer. Never show one user another's data. An agent will break either one without a second thought if you haven't said so, because nothing in its training tells it these are non-negotiable for you.
- Make every line checkable. If you can't tell from the spec whether an output passes, neither can the agent. "Fast" becomes "under 200ms at p95." "Handle errors gracefully" becomes the exact fallback sequence. Anything vague is a decision you've handed to the model.
- Keep it executable. Written as a test, the spec runs. It doesn't sit in a doc going stale while the code drifts away from it; it fails the build the moment intent and reality come apart.
Testing is not the whole of engineering excellence. It is the part that can be made executable, which is why it becomes the meeting point between human judgment and agentic execution. None of this is new work for a good engineer. It's the judgment they always had, written down at last, because written down is the only version an agent can act on.
Agents execute excellence
Once the standard is a test, the agent's job gets exact. The test is the truth it builds toward, the definition of correct rather than a doc checked against the code after the fact. A behavior named in a test has to be produced, and one that isn't carries no obligation at all. The spec went from something the agent reads to the thing its output answers to.
The test pins down behavior and leaves the implementation open. The agent can write the code, throw it away, and write it a different way, and as long as the behavior still matches the test, the result is correct. Match the test and it's right; miss it and it's wrong. Full latitude over how it builds, none over what.
Running that check inside the loop where the code is written, rather than at a gate the change reaches later, is what shift-left looks like once an agent is doing the writing . It keeps pace there only because verification itself is agentic. A few things make that hold up:
- It reads behavior across several signals instead of a single selector. A check like "change the date range and confirm the revenue chart redrew with the new data" can confirm the visual result, the network response, and a clean console at once, where a scripted test watches one brittle element and misses the rest.
- It re-resolves when the UI moves instead of breaking. When the agent renames a button or restructures a component, the check finds the element again on the live page rather than failing, so a refactor doesn't throw false failures across the suite.
- It sorts its own failures before they reach you. A failed run comes back labeled a real bug, an intended product change, or a flaky environment . The agent takes the first pass, and you confirm, so the review lands on the genuine breaks.
The reason this can't be a separate step that runs after the fact is timing. The application surface now changes faster than anyone can hand-write and maintain scripts to keep checking it , so the only verification that holds is one moving at the speed of the code. The agent executes against a standard it didn't set. Proving it meets that standard before it ships is the most it can do well.
The spec is where engineer and agent now meet
In the AI-native workflow, the spec is not documentation after the fact. It is the contract the agent builds against and the verification layer the engineer owns.
It's where the engineer's intent gets written down precisely, and it's what the agent's execution gets checked against. The test ends up doing double duty, defining what correct means as well as verifying it , which is what lets it serve as the shared source of truth for the engineer who owns the intent and the agent that executes it. Investing there pays off on both sides at once, which is why testing sits at the core of this,, even though the idea is broader than testing.
None of this is a new philosophy of engineering. It's the same ownership engineers have always had, pointed at a new division of labor. You define what good means and answer for the result; the agent does the building. Engineers own excellence; agents execute excellence.