The Modern Engineer turns one this weekend. Our first issue was dated 8 November 2025. Fifty-two issues later, the questions have changed: from getting AI tools working to deciding what they should build, how to verify it, and what deserves to ship.
That brings us to engineering taste: the judgment to recognise a solution that fits its problem, its codebase, and the people who will maintain it.
A Year of Better Questions
Issue #1 began with coding tools and a private local setup. The early retrieval and agent projects asked how to turn model capabilities into useful software.
Issue #13 brought evaluation into focus. Guardrails, structured outputs, memory, and approval gates made behaviour more inspectable.
Repository instructions, project architecture, and last week's bug-fix harness sharpened the question: which constraints and evidence justify accepting the work?
The through-line became clearer: AI capability becomes useful through the decisions around it.
The practical projects helped make those decisions visible. Retrieval raises questions about which evidence belongs in an answer. Agents raise questions about authority. Evaluation raises questions about what success actually means. Each topic asks us to look beyond a convincing demonstration and inspect the assumptions holding it together. That is the progress I want this anniversary to recognise.
Taste Has to Survive an Explanation
Engineering taste shows up when you question an unnecessary abstraction, reuse a component the agent overlooked, or spot a patch that passes tests while making future changes harder. It may start as discomfort. It becomes useful when you can explain the coupling, hidden assumption, or operational cost behind that reaction.
The idea predates AI. Paul Graham explored it in Taste for Makers in 2002. What has changed is how cheaply we can produce plausible implementations, and how many decisions that leaves us to review.
Taste also needs practical judgment. An elegant architecture may be the wrong choice when its migration risk, maintenance burden, or delivery time exceeds what the problem warrants.
It also needs intellectual honesty. A factual defect, an uncomfortable risk, and a personal preference deserve different responses. A broken invariant should block a change. A risk needs an owner and a mitigation. A preferred coding style needs a reason to override the repository's existing convention. Calling all three "taste" makes review less useful.
Working Code Can Still Be a Poor Decision
An agent can add services, helpers, and configuration layers before anyone asks whether they belong. Kent Beck describes assistants extending large functions where design work would be more appropriate. Each addition can seem reasonable while the whole system becomes harder to change.
Russinovich and Hanselman describe a more dangerous example: an agent inserts a delay into code affected by a race condition. A passing run can hide the unresolved synchronisation problem. Recognising it requires understanding the system behind the diff.
In Own the Outer Loop, Addy Osmani puts responsibility at the acceptance boundary. The engineer needs evidence for the change and must be able to explain why it should proceed.
What Good Taste Protects
In an AI system, that judgment appears at several levels:
- User effort. A useful automation removes work. An answer that requires the user to repeat the investigation may simply move the burden.
- Repository coherence. Reusing an existing component can matter more than producing a cleaner-looking implementation in isolation.
- Clear boundaries. Model interpretation, tool authority, validation, and acceptance need distinct responsibilities.
- Honest failure. An explicit incomplete result can be preferable to a plausible answer assembled from missing evidence.
- Future change. Every dependency and abstraction asks the next engineer to understand and maintain it. The requirement should earn that cost.
These are review lenses, not universal architecture rules. A small service and a distributed platform can both be well judged when their responsibilities match their requirements.
A Concrete Design Review
Assume an invoice-intake service processes 30 documents a day, every payment requires human approval, and the team already runs a database and background worker. This is a design exercise, not a production case study.
One proposal adds specialist agents, a coordinator, dynamic tool selection, and a broker. Another uses the existing worker, one extraction provider, typed records, deterministic checks, and a review queue. Both could pass extraction tests.
I would start with the second: fewer new operational responsibilities, explicit review reasons, and a payment decision kept at the required human boundary. Greater scale or genuinely variable investigative work could justify more orchestration later.
Before accepting either proposal, I would trace an invoice through a failed extraction, a duplicate submission, and a rejected payment. Where does its state live? Can a reviewer see what needs correcting? How does processing resume? Those questions reveal whether an abstraction carries a real responsibility. A broker may solve a demonstrated delivery problem; its presence alone tells us little about the quality of the design.
A design that sends confidential invoices to an unauthorised provider fails regardless of elegance. Hard requirements are gates; architectural preferences need arguments.
An Engineering Review Card
Use these questions in a pull request, design note, or agent task. They make a decision open to challenge rather than leaving taste as an unexplained veto.
| Review | Question |
|---|---|
| Problem | Who benefits, and what outcome matters? |
| Constraints | What must hold, and how is it checked? |
| Reuse | Which existing capability can we use? |
| Alternatives | What is the simplest credible option? |
| Decision | What do we choose, based on which evidence? |
| Cost | What burden does this choice add? |
| Revisit | What observation would change our decision? |
| Owner | Who accepts it and checks the outcome? |
For the invoice service, a growing backlog could trigger reconsideration. Record that condition now, so today's reasonable choice does not become tomorrow's unquestioned rule. As Hamel Husain argues, AI products should make their outputs easier to verify; engineering decisions deserve the same treatment.
Keep the record short: one chosen direction, the strongest reason for it, and the cost you accept. Two reviewers may disagree about that cost without either being careless. The card gives them something specific to debate and a later outcome against which to revisit their judgment.
Can Models Learn This?
The September 2026 preprint The Tasteful Agent tests decisions at forks mined from engineering and research trajectories. Its best evaluated model chose the better direction on 59.7% of questions. Training improved performance, including on held-out coding tasks. These results describe that benchmark, not a universal measure of architectural judgment.
The October TasteVal preprint reports strong experimental-research performance under fixed problems and budgets, but its eight tasks have unusually clear, fast feedback. That does not settle repository-level engineering judgment. Neither study supports declaring taste permanently human or already solved.
For a team adopting an agent, the useful test is local: does its advice survive expert review, and do accepted changes behave as expected? Ask it to challenge a proposal, but check its objections with the same care as its implementation.
Practise the Judgment You Delegate
In Earning Taste and Judgment, Osmani argues for deliberately developing the experience that repeated implementation used to provide. Keep contact with the consequences:
- Read the diff before the agent's explanation. Predict a failure and test it.
- Compare a direct implementation with a general one. Name the requirement that earns the abstraction.
- Trace a real failure through code, logs, and recovery. Find the broken assumption.
- Review disagreements and revisit outcomes. Update the decision when the evidence changes.
An agent can help with each exercise. Learning depends on examining the evidence yourself.
For less-experienced engineers, review should include the reasoning behind a requested change. "Use the existing worker because it already owns retries and recovery" teaches a boundary. "This is overengineered" leaves little to apply next time. Turning intuition into a concrete explanation improves both the current system and the next reviewer.
Into Year Two
This year gave the newsletter a clearer engineering centre: useful work should leave something inspectable, whether code, a contract, a failure path, or a decision. Next year, I want to go deeper into why one approach was chosen, what was left out, and what would change the choice.
That means making room for comparisons and revisions alongside new implementations. A simpler design that meets the requirement, a rejected approach with a clear explanation, or a failure that changes our assumptions can teach as much as another successful build.
Thank you for reading, whether you started with the first local setup or joined through a later issue. The question I want to carry forward is why is this the right thing to build, and what evidence is enough to ship it?
Final Notes
Taste becomes useful when you can explain a choice, test its assumptions, and recognise when the evidence calls for a change. The review card is a small way to practise that discipline.
As AI makes implementation easier, keep investing in the judgment around it: what matters to the user, what fits the system, and who owns the outcome.
See you in the next issue.
Stay curious.