Taste, Discernment, and Judgment Have Become Must-Have Engineering Skills

Writing code is no longer the limiting factor. Developers take a task, examine the repository, modify files across the codebase, and refine the build and test feedback that already exists. They cannot, however, determine if the outcome should be included in the system. That decision lies in the hands of engineering expertise, and it did not become simpler when the typing became more efficient.

The author spent years at Uber working on the components that decide whether a change is shipped, including the monorepo, the build, and the CI queue, as well as training models on the same codebase. Making it cheaper to produce changes shifts the responsibility downstream to the entities responsible for certifying the change's safety. This transformation has occurred rapidly over the past two years and caught most people off guard.

Taste in engineering is not mere preference, but rather the ability to discern how a change fits within the system it lands in. This goes beyond simply satisfying the request. An agent can carry out the request, but it lacks the understanding of architectural constraints, conventions enforced in reviews, and dependency directions.

Such knowledge resides in the heads of human engineers, who cannot simply prompt it into the model. Thus, taste is written down where the code lives, as rules and review guidance stored alongside the service they govern. Keeping the guidance in the same location as the code allows for consistent review and ensures the guidance remains relevant and up-to-date.

Having a vast amount of standards can be overwhelming, much like handing a model forty pages of guidelines, which would be applied as poorly as a new hire. The standards must be narrowed down to those applicable to the specific change being reviewed. An agent cannot pick from guidelines; it must average out the best course of action.

Discernment is the line between proposing changes and making decisions. An agent often produces code that appears correct but is unreliable, accounting for 61% of developers' concerns about AI-generated code. The costly mistakes occur when changes appear fine on the surface but have long-term implications on testing and operation.

Discernment comes from hands-on experience running the system in production, understanding call paths, and knowing how tests actually cover the functionality. The author's product now incorporates a boundary that separates the model's proposal of findings and the deterministic decision-making process, removing an entire class of bugs caused by reviewer requests on already resolved findings.

Judgment decides what ships and what is allowed to ship itself. The choice between two options - pushing a migration now with dual writes or deferring it to prevent schema rot - relies on the engineer's understanding of the system's behavior during failure. The judgment itself has not changed; the application of the decision has.

Previously, engineers applied decisions on a pull request basis, but now most decisions are made once, in writing, on the criteria for machine-initiated actions. This shift allows teams to focus on evidence derived from their own codebase rather than relying on benchmarks. The objective is to constrain scope by writing and enforcing criteria rather than relying on instructions or preferences.

When multiple reviewers are present, the arbiter can only reject candidates, never provide new suggestions. To ensure the probabilistic layer remains effective, the system should assign tasks with survivable risks while keeping the state machine deterministic.