Deep Engineering Specials: Do you have good taste?
Opinions held lightly, business outcomes held closely: what “good taste” means with AI in the loop.
Welcome to a special edition of Deep Engineering.
According to Sean Goedecke, Staff Software Engineer at GitHub, “good taste” in software engineering is “the ability to adopt the set of engineering values that fit your current project.” Goedecke’s article triggered a good amount of discussion on Hackernews. The article and the discussion made us wonder, does the meaning of this good taste change with AI in the playing field? If so, how?
Goedecke’s article emphasizes the importance of recognizing trade-offs (e.g., readability vs. performance) and that many disagreements are really value differences rather than right–wrong proofs. He adds that “bad taste” shows up as inflexibility—pushing one’s preferences regardless of context—whereas “good taste” is harder to test and is best inferred from real projects that succeed across varied situations.
Let us take a look at four of the strongest themes that emerged from the discussion thread in response to this article, based on commenters’ real world experience:
1) Taste shows up in how we review code: ask before you assert
“I don’t ever tall a junior that they are doing something in a less-than-optimal way. I always ask them why they’re doing it that way. At the end of each conversation, one of us has learned something. Sometimes I learn an alternate approach, and sometimes they learn why their alternate approach won’t work in the long run. Either way, it’s never a confrontational conversation.”—stronglikedan
A highly upvoted subthread favored code reviews that start with questions, such as ‘why this way?’ over prescriptive edits. Reviewers who probe constraints first tend to surface better options and reduce defensiveness. That stance aligns with current practice as AI enters code review: Microsoft reports internal use of an AI PR assistant that handles routine checks so humans can focus on clarifying intent and higher-order trade-offs. GitHub’s recent guidance for leaders likewise frames AI as augmenting human oversight, not replacing deliberation.
Why this matters now. AI is already doing the first pass on many pull requests, so human taste is most useful when it clarifies intent and probes constraints rather than nit-picks. Microsoft reports an internal AI PR assistant that now “supports 90% of all PRs across Microsoft, reviewing ~600k PRs/month,” improving PR completion rates by “10–20%” and freeing reviewers to focus on higher-order judgement. GitHub, in their executive’s guide, likewise cautions leaders to balance AI reviews with human oversight for logic, context, and prioritization.
2) Exposure to contrast sharpens taste (and lowers cognitive load later)
“I think this is only half of it.
Years ago, I worked at a company where my time was split between working on a bespoke platform for an older client and a generic platform that would be used for all clients going forward. The bespoke platform was essentially being used to fund the development of the generic platform.
The contrast between the two was stark: the bespoke platform was legacy in all its weird glory, and the generic platform was considerably higher quality. Seeing that contrast up close, and flipping between working on each one, was immensely useful to me. It made it clearer why I favour certain approaches over others, and it made concepts easier to explain to others.
Since then, I’m of the opinion you should aim to work with both the good and the bad to clarify the “why” of things.” —johnh-hn
Alternating between “legacy” and “greenfield” work trains your instincts; you see where simplicity pays off and where it collapses. New research from Atlassian examines readability in the LLM era and concludes that as more code is generated, clarity and local reasoning become more—not less—critical for maintainability. InfoQ’s 2025 Architecture & Design Trends similarly highlights “socio-technical architecture” i.e. designing around the people who must read, change, and operate the system worth investing in.
Why this matters now. As LLMs write more code, readability and local reasoning are more, not less, important. The Atlassian/Monash industrial study by Tantithamthavorn et al. involving 118 practitioners, found 81% say readability remains critical, and LLM-generated code was comparable to human code on standard readability metrics across 144 real issues. InfoQ’s architecture trend reporting also stresses socio-technical fit—designing around the people or maintainers who must read, change, and operate the system.
3) “Best practice” is contextual; fitness functions make that testable
“…Most engineering decisions are indeed a tradeoff that should be carefully considered.
That said...
> I will always distrust engineers who justify decisions by saying “it’s best practice”. No engineering decision is “best practice” in all contexts! You have to make the right decision for the specific problem you’re facing.
There are indeed general best practices that are applicable to most, if not all, situations. E.g. version control and testing (arguably even the testing approach) are practices that every competent developer would agree are pretty much requirements.
Context does matter, but within specific contexts there are practices that can be generally considered “best”, because applying them delivers more value than not, and their drawbacks are manageable.
For example, after a certain team size, implementing a CI pipeline is a best practice. Yes, it takes time and effort to implement and maintain, but the benefits far outweigh the drawbacks. After a certain scale, implementing a robust and efficient infrastructure management and deployment solution is pretty much a requirement. Relying on ClickOps to provision infrastructure, and deploying with shell scripts over SSH, while technically “simple”, can only get you so far. And so on.
These practices become more evident with experience, and deciding when to vouch for them, even strongly, becomes more evident with wisdom. So I wouldn’t necessarilly always distrust engineers who want to promote best practices. I would listen to them, discuss it with them, and make a decision along with the rest of the team. If they do push back after a decision has been made, that would be a bigger issue. Not necessarilly with that specific engineer―it could also be a sign of communication problems, egos, politics, etc. Unfortunately, there are many dysfunctional teams and companies with toxic environments, but I suppose that’s just human nature.” —imiric
“Best practice” is not a trump card. A better pattern commenters argue is to state the quality you’re trading for—latency, operability, safety—and make that measurable. Thoughtworks’ Radar, published in April 2025, emphasizes architectural fitness functions as an objective way to encode those preferences and catch drift, including for AI systems.
Why this matters now. Taste becomes legible when values are encoded as measurable, automated checks. Rebecca Parsons, CTO Emerita of Thoughtworks, and Neal Ford, Director and Software Architect at Thoughtworks. argue fitness functions are the right way to govern evolving AI systems—turning vague goals (e.g., “safety,” “latency,” “cost”) into objective gates teams won’t argue about. In practice, that means debating numbers—p95 inference latency ≤ X ms; rejection-rate ≥ Y% for red-team prompts; SLO error budget ≤ Z%—instead of debating taste. Current AI security guidance, OWASP 2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps, also enumerates concrete failure modes worth codifying as checks.
4) End-users and business constraints are part of taste
“Since this is just arguing over a definition, the best take I can give is what definition has proved most useful to me in the past. That is thinking of taste as the ability to recognize something as good or bad when seeing or hearing a description of it, usually without it actually existing.
Let’s say I have a plan for a new feature and a way of building it, if I show it to someone with good taste, they will be better at telling me if it’s going to work out, and how valuable it will be to users, than someone with bad taste.
Viewed this way, it’s almost quantifiable, and at the very least: good developers can usually agree on who has good taste. You can tell based on their actions not words. They will go out of their way to get feedback from people with good taste. IME the people with the best taste for a product are power users and evangelists.”—alphazard
Discussions of taste risk ignoring whether the software actually serves users and the business. InfoQ’s 2025 report stresses decentralized decision-making and shaping systems around the teams that run them—both proxies for staying close to outcomes rather than tool fetishes. Even at the tooling layer, AI-assisted reviews are being judged by business-relevant metrics (cycle time, onboarding speed), not just code aesthetics.
Why this matters now. “Taste” is only credible if it shows up in outcomes you can measure for customers and the business. The 2024 DORA report ties stronger software-delivery performance to better organizational results, and the 2025 DORA study on AI finds that AI mainly amplifies your existing system—so reliability, security, and cost guardrails must be explicit. But effects aren’t universal: a METR study found experienced developers on familiar codebases were 19% slower with AI, underscoring the need to test your context rather than assume gains.
Wrapping up
If “taste” is judgment under constraints, then Goedecke has indeed made a point that is very relevant in 2025. The meaning of taste doesn’t change with AI having a seat at the table—taste is still judgment under constraints—but AI changes the constraints you must care about and how you prove that judgment. In AI-heavy work, taste looks less like style and more like discipline: naming the values you’re optimizing (latency, reliability, safety, cost), measuring them, and being ready to re-weight when evidence shifts. The human edge which is more important than before is in choosing intent, setting guardrails, and changing course quickly when the data contradicts preference. And from the passionate discussion on HN, and the sources we have cited, we have to agree that in the end, good taste in software engineering can only come from opinions, being held lightly; and successful business outcomes being held closely.
When did evidence last make you change your mind about a “best practice,” and what will you do differently next time? Let us know in the chat.
That’s all for today. Thank you for reading this special issue of Deep Engineering. We’re just getting started, and your feedback will help shape what comes next. Do take a moment to fill out this short survey we run monthly—as a thank-you, we’ll add one Packt credit to your account, redeemable for any book of your choice.
We’ll be back on Thursday with our regular expert-led issue.
Stay awesome,
Divya Anne Selvaraj
Editor-in-Chief, Deep Engineering
If your company is interested in reaching an audience of developers, software engineers, and tech decision makers, you may want to advertise with us.