*Published July 19, 2026* --- Around the 300th note, I started seeing a pattern I wasn't looking for. I've been collecting notes on AI and software development for over a year. People from different companies and different decades of experience are describing the same structural change. --- ## What They're Saying Marc Brooker, Distinguished Engineer at AWS, in February 2026: the cost of turning written business logic into code has approached almost nothing. Connecting services and libraries is also nearly free. Ryan Dahl, who created Node.js and Deno: humans will stop writing code by hand. Software engineering value shifts from execution to architectural thinking. Chamath Palihapitiya: good software doesn't start in an IDE. The specification is the product. Code is its runtime expression. These three don't work together. They weren't responding to each other. But strip the context and the claim is identical: the hard part of software used to be writing the code, and that has stopped being true. --- ## What Replaces It If writing code is cheap, what's expensive? The answer depends on how far upstream you look. Nate Berkopec spent years on Ruby performance. He noticed QA shifting from whether the code works to whether it should have been built at all, and whether it feels right. When AI generates code that runs, the question changes. You stop asking whether it's correct and start asking whether it's worth having. Uncle Bob Martin put it more bluntly: you cannot be ignorant of the system's structure. Someone has to hold the architectural map. Delegate the code, hold on to the vision. Chamath's point extends further than the tweet takes it. If the specification is the product, then everything downstream of the specification is labor. AI does labor. The specification requires judgment about what matters, and that judgment is upstream of the code AI writes. Jensen Huang, at NVIDIA, observed that software engineering was the pinnacle of technical intelligence and became the first job AI targets. What remains is the anticipatory work: sensing problems before they exist, connecting patterns nobody asked about. None of them is describing a prompting trick. They're describing where the work went: to the decisions that happen before you open a terminal. --- ## The Taste Thread One specific word keeps showing up across these notes: taste. Obie Fernandez, reflecting on 10,000 hours of Rails: all those hours trained judgment and taste, not typing speed. AI writes the code, and Fernandez's bet is that it still can't judge whether that code is worth shipping. Hold that claim. I'm going to come back and test it. Chayenne Zhao, on the output side: the prize in AI-assisted coding isn't speed. It's distinguishing between 30 lines of AI-generated fluff and the 5-line kernel that actually solves the problem. Without that, developers aren't augmented so much as accelerated, generating technical debt faster than before. Amy Tam, on why AI can't learn taste from training data: taste is socially constructed and continuously evolving, legible only through participation. You absorb it from a community of practice, and you can't scrape it. It is learnable, but through reps and membership, not instruction. --- ## Why More Intelligence Doesn't Help Dario Amodei wrote a long essay last year about what powerful AI could achieve. He identified several categories of bottleneck that more intelligence can't power through. Map them onto software and three of them fit exactly. Missing data. AI doesn't catch the bug that only surfaces under concurrent load during peak hours. Operational patterns aren't in the codebase. Human behavior. AI generates a technically correct schema with naming conventions that will confuse every developer who reads it in six months. Naming is a social agreement, not a logical derivation. Irreducible complexity. AI can't tell you whether to build feature A or feature B. The answer depends on the market, the team, the timing, and factors that interact in ways no model simulates. More intelligence finds faster paths through those bottlenecks without removing them. And the bottlenecks that remain in software are the ones that sit in the judgment layer. When I first read Amodei's essay, I thought it was about biology. Then I realized it described every sprint planning meeting I've sat through. --- ## The List It helps to see them together. - Implementation cost has collapsed (Brooker, AWS) - Humans will stop writing code by hand (Dahl, Node.js/Deno) - The specification is the product (Palihapitiya) - QA becomes taste assurance (Berkopec) - Architectural vision can't be delegated (Martin) - 10,000 hours trained judgment, not typing (Fernandez) - Without taste, AI makes developers worse (Zhao) - Taste requires lived participation (Tam) - Technical intelligence is table stakes (Huang, NVIDIA) - Intelligence has structural limits (Amodei, Anthropic) Ten people. Builders, investors, a lab CEO, spread across different companies and different decades of experience. Not one of them is talking about prompting. --- ## The Convergence Problem Ten people agreeing should make me suspicious, not confident. I've written about echo chambers. A chorus can be a feedback loop instead of a signal, and most of these voices are tweets and blog posts, not evidence. So before I trust the pattern, I should look for the strongest case against it. There is one, and it's older than any of these takes. For seventy years, psychologists have found that simple statistical rules predict outcomes at least as well as, and usually better than, trained expert judgment. Meehl showed it in 1954. A meta-analysis of 136 studies confirmed it in 2000. Give an expert and a formula the same inputs and ask who reoffends or which candidate will perform, and the formula wins or ties almost every time. The expert's weakness is inconsistency: shown the same case twice, they often disagree with themselves. That should worry anyone claiming judgment is safe, because a lot of what these practitioners call judgment is prediction. Will this scale, will this hold up, is this good enough to ship. Prediction under noise is exactly where humans lose to arithmetic. And it's already happening in review. In controlled evaluations, a language model judges response quality at about the agreement level two humans reach with each other; on code specifically, AI reviewers now catch mechanical defects at rates comparable to human ones. So this is where I have to let go of Fernandez's claim. The quality-judgment layer, the one Berkopec and Zhao are pointing at, is the layer AI is closing first. That judge is a derivative, though. It's trained on human preferences, so it approximates our taste without originating any of its own. It removes the human from the loop without replacing what the human had. And even the premise underneath the whole chorus is shakier than the chorus admits: a controlled trial found experienced developers were 19% slower with AI on code they knew well, while believing they were faster. Implementation cost collapsed for the median task, not for every task. So the honest claim is narrower than the chorus makes it sound. The judgment that stays human isn't the predictive kind. It's the generative kind: not "is this good enough" but "is this worth building at all." Brooker's own framing points here. The decisions that matter are driven by the needs of the business and the problem, and those aren't decisions the model can make, because nobody has labeled what a specific company should do next quarter. That layer isn't safe because humans predict better. It's safe because the question has no training set. Yet. Here's the test I use now. If a judgment call could be scored against a known outcome, assume it's on its way to being automated. If nobody could label the right answer in advance, it's yours a while longer. --- A year ago I wrote about not writing tests anymore. I thought the story was about testing. The testing was just the first place the shift showed up. Every few weeks now, another practitioner writes about this from their own angle, like they just discovered it. They didn't discover anything. They ran into a bottleneck that was always there, invisible only because implementation was standing in front of it. And it isn't all of judgment. The predictive part, AI is already taking, and it will keep taking it. What's left is the generative part: knowing what's worth building at all. --- ## Sources The load-bearing claims, for anyone who wants to check them: - Marc Brooker, "You Are Here" (Feb 2026) — https://brooker.co.za/blog/2026/02/07/you-are-here.html - Dario Amodei, "Machines of Loving Grace" (2024) — https://www.darioamodei.com/essay/machines-of-loving-grace - Grove et al., "Clinical Versus Mechanical Prediction: A Meta-Analysis" (2000) — https://pubmed.ncbi.nlm.nih.gov/10752360/ - LLM-as-judge on response quality: Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" (2023) — https://arxiv.org/abs/2306.05685 - AI code review matching human reviewers on defect detection: DORA 2025 State of AI-assisted Software Development report, and controlled bug-detection benchmarks (chatbots comparable to, not yet surpassing, human reviewers) - Experienced developers slower with AI on familiar code: METR (2025) randomized trial — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ - Chamath Palihapitiya on specification-as-product — https://x.com/chamath/status/2026705629562417254 - Robert C. Martin on holding the architectural map — https://x.com/unclebobmartin/status/2026744255084114229 - Obie Fernandez on 10,000 hours training judgment — https://x.com/obie/status/2007906508412006641 Additional observations (Dahl, Berkopec, Zhao, Tam, Huang) are drawn from public posts and talks, February–March 2026. ---