We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect
Stop accepting AI output that "looks right." The other 17% is everything and nobody is ready for it.
AI News & Strategy Daily | Nate B Jones · 36.3K views · 1.2K likes
Analysis Summary
Strategic ambiguity
Leaving claims vague enough that different audiences each hear what they want. By never committing to a specific, falsifiable position, the speaker avoids accountability while supporters project their own preferred meaning.
Eisenberg (1984); dog whistling research (Mendelberg, 2001)
Worth Noting
Positive elements
- The video provides a useful mental model for shifting from 'generative' AI use to 'evaluative' AI use, emphasizing that domain expertise is the bottleneck for quality.
Be Aware
Cautionary elements
- The use of 'revelation framing'—suggesting this is a secret skill 'nobody is ready for'—to increase the perceived value of standard editorial judgment.
Influence Dimensions
How are these scored?About this analysis
Knowing about these techniques makes them visible, not powerless. The ones that work best on you are the ones that match beliefs you already hold.
This analysis is a tool for your own thinking — what you do with it is up to you.
Related content covering similar topics.
Transcript
Your most valuable AI skill is actually saying no. When was the last time you said no to AI? I I say no all the time. Not no to using AI, but no to AI output that sucks, that's not good enough. And I realize I reject much more AI generated work than I accept because it has the wrong framing, because it has sloppy reasoning, because it has confident sounding analysis that would not survive contact with anyone who actually understands the domain. I send it back. I explain why. And by the way, this is not necessarily a function of like superpowered prompting. You can prompt really well and if you know your domain, if you have high taste, you're still saying no a lot. When I want to see if someone is good at AI, I check how much they say no. And then I say no again because the explanation I gave last time might have gotten the model from 90 to 95% but my bar is higher. I believe learning to say no is one of the missing skills in this whole nebulous judgment and taste category that everyone's waving at. It's not necessarily prompting. It's not workflow design, although those are valuable. It's not even model selection. The ability to look at AI output and say this is wrong and this is why is a huge component of how you identify quality. And so I want to argue that we should treat rejection as the real AI skill. I want to argue that every skilled rejection creates institutional knowledge that did not exist before and that we as individuals and we in our teams can compound those rejections into much more durable constraints if we start to pay attention to them and we haven't been. I want to suggest to you that you probably don't track the patterns that you say no to. But there are patterns. If you start to keep patterns, if you start to find ways to scale your nose, you start to map the dimensions of rejection as a core competency, you start to think about what does recognition of something bad look like systematically? What does articulating what needs to change about something bad systematically look like? What does encoding that into a system that you can then hand to AI and say, "I've said this before. I don't need to say it again because you now see my nose as a system. What does that look like? And yes, we're going to get to that. Taste is a scalable asset. People love to say, but what people don't talk about is that taste, if it's locked inside your human brain, ends up stressing you out because you look at all of this pile of AI generated output that's gone up 10x or 100x or a thousandx and you're like, I don't know. I'm supposed to have taste across this, whatever that means. You're not going to get there if you don't learn how to both reject what's bad and also systematize your rejection so that you can start to scale that a little bit. Your rejections are more valuable than your prompts. Yes, I said it. So, what happens in this moment of rejection? The person applying domain expertise the AI doesn't have is able to identify a specific gap between, hey, this looks right and this actually is correct. and they can articulate a constraint that wasn't an explicit rule before they said it. So a strategy partner might send back an AI generated competitive analysis and say look where's our proprietary insight on customer switching costs here. Any firm with access to the same model could have produced the framing that I'm seeing here. And there you go. You're differentiating the firm's work from commodity output. or a loan officer that rejects a covenant tracking prototype might say you can't treat a debt service coverage ratio the same as a minimum net worth requirement. Those have completely different monitoring triggers and they're just specifying business logic that no requirements doc is going to capture. An editor might kill a draft saying the thesis is buried in paragraph 4. You got to lead with provocation. Now we're encoding an editorial standard. I'm including a range here. You notice I didn't lead with tech. I included a loan officer. I included a strategy partner. I included an editor because this is about knowledge work. This is about anything we do with computers. These kinds of rejections are not null. They're not void. They're actually knowledge creation events. We're not capturing them mostly, but they are. And the thing I'm not hearing anyone say is, hey, how do we take these and scale our nose? And how do we take these and let this moment of rejection become a valuable moment that scales in our AI workflow? Because the knowledge created in that moment, the constraint, the rule, the encoded taste, that compounds if you let it. But right now, for almost everybody, it evaporates. It lives in an email thread. It lives in a chat window. It lives in a Slack message. Nobody really captures it. Nobody compounds it. And so the same rejection happens tomorrow when the deck comes back and the strategy partner says, "Well, our proprietary insight on customer switching costs is missing." Again, most of the AI skill markets are focused on generation skills. If you take a course, it's all about what are your generative AI skills? Do you prompt? Do you design workflows? Do you select tools? Maybe it's multimodel orchestration. And they're all typically aimed at can you produce more? Can you produce faster? Look, production has been solved. You do need those skills, but fundamentally that is not the bottleneck. AI can generate a strategy deck or a competitive analysis or a product spec or a working application before lunch. The generation side is now effectively a commodity. OpenAI's GDP val, the most rigorous measurement we have against actual knowledge work, shows frontier models beating or tying professionals with an average of 14 years of experience. 70% of the time on head-to-head comparisons and they do it 100 times faster for less than 1% of the cost. And these tasks are created by those professionals, graded by those professionals in a double blind manner. And the models are still winning most of the comparisons. And everyone tends to read this as either a story of AI capability or a story of workforce demise. Both of these are much less interesting readings. The more interesting reading is, if AI now matches your best people's output 70% of the time on wellsp specified tasks, what determines the rest of the story? What happens to the 70% that looks right on the surface but leaves the lab and doesn't hit production correctly? What happens to the 30% where the AI just completely whiffs? The answer is the same in both cases. Someone has to look at the output and know. And it turns out that the way you look at the output and know is by saying the word no a lot. It's by looking at a product spec and saying this doesn't reliably encode business intent. It's by saying this code demos beautifully but it's not going to actually work in production and here's why. This analysis is technically correct but there's no so what here. And this is something that there is no good metric to measure on AI capability. And I want to suggest that if you're operating at that frontier, if you're trying to figure out how AI can be practically applied, then look at rejection. Look at no as a skill and look at it as a competency that you break down into multiple dimensions. Almost nobody's looking at this and measuring it deliberately. One, check in on your recognition. Look at the ability to detect that something is wrong. This is the part that depends on domain experience. It's hard to shortcut this. Junior analysts will not catch flawed regulatory assumptions without that deep experience that senior analysts have. Loan officers might not spot those covenant logic errors because they haven't seen enough deals. You get the idea. Recognition is the product of years of practice. And it's the reason experienced domain experts are becoming more valuable, not less. as AI floods every organization with lots and lots of output. So, the person who's reviewed 2,000 deals and can just feel when something is off is becoming the most important person in the building, not despite AI, but because of it. And recognition is the dimension most enhanced by AI. A domain expert with very strong recognition and access to AI tools can evaluate 10 times the output that they could before. The leverage is very multiplicative, but it only works inside the boundary of their expertise. Inside that boundary, AI is a force multiplier, but outside of it, AI multiplies confidence, not expertise. And that's worse. Articulation is another key skill in this sort of larger rejection skill set. It's the ability to explain why something is wrong in a way that produces a usable constraint. This isn't right. That's just a rejection. this isn't right because you're treating all of these requirements identically and the PRD actually needs to be structured this way. That's a constraint. It's the difference between taste that stays in someone's head and taste that we can start to encode and share with the team and begin to apply at scale. This is a learnable skill, but almost nobody's teaching it. Ironically, GDP val's methodology illustrates why this is important. Every task in GDP val went through five rounds of expert review. Every review had a rejection event. An expert looking at a task and saying this is not representative enough or this isn't clear enough for evaluation. That iterative refinement through rejection is what made the benchmark interesting and useful. The expert taste therefore didn't just evaluate the AI, it built the evaluation infrastructure. Articulation is what turns taste from a personal attribute into something that the organization can use as an asset. Encoding is the practice of making that constraint persist beyond the moment of rejection. And that's another skill in this cluster. This is where everything tends to break down right now because you have someone who articulates a constraint and it lives in an email and then next quarter a different team will make the same mistake because the constraint was never captured anywhere durable and the reasoning has to be recreated from scratch. and the time that you're spending is getting burned on that same fight with the AI over and over again. Andre Carpathy's framework that AI systems improve fastest where success can be verified has very direct implications here. Verification infrastructure that enables AI improvement does not just magically emerge. It's built often off of encoded rejections. When you have a test suite with multiple acceptance criteria, when you have quality gates, when you have business rules in your system that work, you are looking at outputs and saying no with enough precision that no could be made permanent. What you need to do is think about scaling that to the daily practice of rejection that every good AI practitioner now does today. Here's where things get interesting. If you start to do this, if you start to properly encode your rejection so they're durable, reusable constraints, then you are now building a flywheel, you're not really scaling experts, you're scaling the encoded residue of expert judgment. You're scaling the outputs of human judgment. And this starts to compound across an organization's footprint. So if you're a consulting firm that encodes partner rejections across thousands of engagement, you're effectively building a repeatable institutional bar for quality at that firm that no competitor can replicate by just subscribing to the same AI model APIs. If you're a media company, you can capture editorial judgment across thousands of pieces and start to develop a taste that helps individual editors scale their attention. The companies that have been doing this, often informally for years, already tend to dominate their markets. Epic Systems did not win in healthcare by having better technology. It won by spending decades encoding clinical workflows from thousands of hospitals into a deeply integrated platform. And the result decades later is very very clear. And clinical workflows were not always easy to discover. The development team from Epic had to go onsite shadowing doctors, watching workflows, absorbing domain constraints to build the systems that clinicians need. And the result is a system that can handle over 300 million patient records and a system that is so embedded in clinical operations that switching costs are structural. It's the ultimate system of record. And the mode here is not the software. It's the encoded judgment about what the software needs to get right. Built rejection by rejection, workflow by workflow, failure by failure across thousands of hospitals. This is a lesson that people who are panicking about software as a service need to learn. When you have a system that is built essentially out of encoded taste at scale to the point where it becomes structural for businesses, it is very difficult to rip out. Bloomberg did the same thing in financial data. When you have a vertical SAS company that really owns a niche, you're doing some version of this. What's new is that AI makes the encoding cycle much faster than it used to be. AI can generate a provocation. The expert can reject it. The rejection can get encoded. The library can grow. And the ratio of hours spent by expert to encoded constraints. And essentially, the taste bar improves every single cycle because you're saving all of those nos. But the infrastructure to make all of this possible has really not been there in the age of AI. As far as I can tell, almost nobody is talking about how you scale your nose. This is not a small oversight. It's the largest structural gap in the AI tool ecosystem. All of the organizations using AI are generating rejections at grassroots at the individual users see all the time. And every single one of those almost without exception is falling on the floor. And the right solution is not a separate tool. It's not a spreadsheet. It's not a database. It's not a dashboard because people won't context switch. I believe the capture has to happen where the work happens inside the conversation as a side effect of the rejection you're already performing. And I believe that so strongly I built something for it. If you head over to the Substack, I've put together a little solution that is designed at least at the personal or maybe a small team level to enable you to start to log and encode your rejections without ever leaving your chat tool. How are we doing that via MCP server and a nice database? It's not that fancy. You can set it up on your own, I'm sure. But for those of you who want a quick head start, I've got it. Simple. I want to stop dropping as many rejections on the floor as I've been doing personally, as others have been doing. It became so much of a pain point for me, I had to build something to solve it. And I realized as I looked around, nobody else was looking at it this way. And this has some really interesting implications if you're in hiring or if you're in talent upskilling. Because one of the things that you get for free if you start to create a taste bar like this and make it accessible via MCP server is you start to enable people who would otherwise not have access to the taste of a very senior person. They can get that just by hitting the MCP server and coming back with it. They can get that perspective. This means that junior positions where people develop recognition can be accelerated because juniors can get a sense of does this hit the bar or not very very quickly and start to access that accumulated context of taste that accumulated ability to articulate that their seniors have and that we have been losing in our talent and upskilling career ladders for the past few years. It's one of the reasons that juniors are in crisis is we don't have the mixing we used to have between juniors and seniors in various disciplines and we need to fix it because how is work going to get done in 10 years if no one has learned anything and so part of what I'm doing with something like a constraint library which is kind of what I call this is I'm trying to jumpstart the idea that taste is scalable taste is a learnable skill taste is something not only that AI can learn but humans can learn too and Because taste is individual typically to a particular team, a particular firm. You're going to need to build this for yourself. I can't give you a universal taste library because everybody has their own perspective inside their business, but I can show you how to build one and give you a kit for it and I can let you do it quickly. That part I could do. And I think it's really important to think about it intentionally regardless of whether you want to sort of grab my kit or do it yourself because if you're not thinking about your constraints, you're basically telling your AI, I'm willing to just iteratively work with you and waste my hours. And you're telling your juniors on your team, hey, it's okay. We're not really going to teach you and we're just going to hope you learn by osmosis on Zoom calls. And that doesn't work. So Andre Carpathy's framework, which is what you can verify, you can automate, has a correlary that should keep you up at night. The frontier of AI value is identical to the frontier of your organization's taste. Where your capacity to verify quality extends, AI can create more value. Where it doesn't, AI can generate more risk. Not theoretical risk, by the way, but compounding silent risk of an organization that generates more and more and more while understanding less and eventually doesn't know what's going on because the output kind of looks good, but you've forgotten where the bar is. So, your anti-slop strategy is not be more careful. It's not give people more lectures. It's not even write better prompts. is developing and institutionalizing and eventually automating the human skill of rejection so that the human skill of rejection can scale. It's not that we see a world where humans aren't going to have taste. It's actually quite the opposite. We love that humans have excellent taste and we want to give them more time to look at different kinds of mistakes because one thing I'm fairly confident of is that we're not going to run out of things to have a high quality bar about. And so if you're an exec, the competitive mode here is not which AI vendor you choose. Models are getting commoditized. The mode is going to be the depth and durability of your organization's encoded taste. The constraint library that makes AI output reliable in your domain. You're going to have to audit it and you're going to have to ask yourself where are the domain experts. Are those rejections being captured? Are they evaporating? You're going to have to start treating encoded domain judgment as an asset class because it is one. And if your job is managing a team, you're going to have to create space for articulation. When someone rejects AI output, you should be challenging them to be able to explain why and to be able to socialize that skill set. It's an investment, right? A team that can articulate rejections is building a shared understanding of quality that persists across projects that across personnel changes, across tool migrations. Whereas a team that is just silently and individually fixing AI output is not really growing at all. And if you're an individual contributor, your most valuable professional development isn't learning the newest tool. Tools are going to change. It's actually deepening your ability to recognize when something isn't working. Practicing the ability to articulate what is wrong and how to fix it and then making sure that you are part of or helping to stand up a system where that taste can scale. And if you're an entrepreneur, I would challenge you to think about building a product that enables us to start to scale taste. Look at how we can take these rejections and scale them out. And I'm going to say it can't be a special new pane of glass. It can't be a special new website. We're not going to context switch. We're not going to tool switch. This needs to be seamless. This needs to be something that does not cost us attention since attention is scarce enough. We all have the job of learning to say no to new and more interesting things. And that means we have the job of articulating what is wrong with our current AI outputs and a high level of fidelity, storing them somewhere and then using those to both improve AI outputs and also train folks who are younger in the career path. If we don't do that, we're going to regret it. That's the job now. So much else is becoming commoditized. But being able to say this is what's really excellent, that's something you can get excited about because you can raise your taste bar. So there you go. That's your challenge. If you're curious about sort of how to set that up quickly, I've put a kit together on the Substack. Uh and if you want, honestly, you could probably feed this transcript into your LLM of choice and get something coded up. That's just how wild and woolly this world is now. Best of luck.
Video description
My site: https://natebjones.com Full Story w/ Prompts + Guide: https://natesnewsletter.substack.com/p/the-most-expensive-ai-mistake-isnt?r=1z4sm5&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true ___________________ What's really happening when frontier models beat professionals with 14 years of experience 70% of the time but the output still doesn't survive contact with anyone who actually understands the domain? The common story is about prompting and workflow design—but the reality is more interesting when rejection creates institutional knowledge that did not exist before. In this video, I share the inside scoop on why learning to say no is the missing skill in the judgment and taste category: • Why your rejections are more valuable than your prompts • How recognition, articulation, and encoding break down into learnable dimensions • What Epic Systems teaches about scaling taste through thousands of encoded workflows • Where the structural gap in the AI tool ecosystem leaves every rejection on the floor For anyone watching AI flood organizations with output, the frontier of AI value is identical to the frontier of your organization's taste. Chapters 00:00 Your Most Valuable AI Skill Is Actually Saying No 02:15 What Happens in the Moment of Rejection 04:30 Why Generation Skills Are Now Commodity 06:30 GDPVal: AI Beats Professionals 70% of the Time 08:15 Recognition: Detecting When Something Is Wrong 10:00 Articulation: Explaining Why in Usable Constraints 12:00 Encoding: Making Rejections Persist Beyond the Moment 14:00 The Epic Systems Lesson: Scaling Taste Across Decades 16:15 Building Infrastructure to Scale Your No's 18:15 What This Means for Teams and Individuals Subscribe for daily AI strategy and news. For deeper playbooks and analysis: https://natesnewsletter.substack.com/