--- title: "The Skill Is Knowing What to Ask, and What Not to Trust" slug: "ai-skills-are-real" language: "en" date: "2026-10-28T12:54:52.246Z" updated: "2026-10-28T12:54:52.000Z" description: "Goedecke argues AI skill is durable: context supply, capability maps, failure patterns. The skimming skill is really a tax on output design." canonical: "https://fix.slopit.io/ai-skills-are-real/" tags: ["ai", "engineering", "work", "learning"] --- There's a popular view that getting good at AI is trivial. Early models needed tricks — chain-of-thought, "you are a skilled engineer" — but current models don't. And any tricks that still work will be obsolete with the next generation, so why learn them? Just tell the model what you want. Sean Goedecke's response is that the tricks were never the skill. The durable skills are real, they take practice, and they're mostly about knowing things that aren't in the prompt. ## The four he names **Supplying context.** New users expect the model to read their mind: "solve my issue" without saying what the issue is, or asking about a Slack problem without connecting the agent to Slack. The agent guesses, the guesses are wrong, and the user concludes the model is bad. The skill is noticing what context is missing and backtracking — and reflexively explaining *why* you want the thing, so the agent can make decisions you didn't specify. **Knowing what the model can and can't do.** This is the one I find most useful. Capabilities are weird: Goedecke knows he can ask an agent for architectural ideas but not for new product features. And crucially, new models improve most where the old models were already good, and only a little where they were bad. That means the capability map depreciates slowly — which is exactly what makes it worth building. **Knowing the failure patterns.** Reviewing AI code is a different skill from reviewing human code. Off-by-one errors are rare in generated code; over-engineering, invented requirements, and traded-away constraints are common. Human-written code that looks fluent earns trust; AI-written code that looks fluent should earn suspicion, because the fluency is cheap. The specific example is good: a mutex introduced to satisfy an edge case nobody cares about, in code so well-commented that a reviewer assumes judgment. **Skim-reading.** Once you've read enough generated prose, you can let your eyes flow until you hit claims and evidence. If you can't, you waste time and emotional energy cutting through foliage. ## Where I'd push The first three are genuinely durable, and they share a structure: they're all about *the boundary* between what you specified and what the model supplied. That's the real skill — not prompting, but noticing the gap. The fourth is different, and I think Goedecke undersells the critique by filing it as a skill. Needing to skim is a tax imposed by output that's optimized for the appearance of thoroughness. A tool whose output requires a specialized reading technique to extract the claims is a tool with a formatting problem, not a user with a skill gap. It's worth learning to skim; it's also worth asking why the interface makes it necessary. The closing claim — that people avoiding AI are being left behind, and that advising others to avoid it does them no favors — is where I'd separate two things. The skill claim is well supported: if you never practice, you won't be good at it. The employment claim is a different empirical question, and the evidence is mixed. Plenty of people are practicing and still being laid off; plenty of people are not practicing and still employed. "You're being left behind" is doing double duty as a description and a threat, and only the first is established here. That said, his strongest point is the one that cuts against both camps: LLMs reward expertise. The people who get the most out of these tools are the ones who already know the domain well enough to recognize a bad answer. That's an argument for depth, not against it — and it means the "learn AI instead of the fundamentals" reading is wrong. ## The centaur point His analogy is the right one: software's centaur age — where a human-plus-model beats either alone — may last decades, the way chess's did. If that's true, the skills are worth building even if they look temporary, because the period in which they pay is long. And the practice is how you find out what the tools can actually do. Goedecke's own examples — asking Copilot to install its own MCP servers, having agents run local tests, scheduling a 6am job — are things he discovered by trying, not by reading a capability list. The map is drawn by walking. ## The takeaway The skill isn't prompting. It's knowing what you failed to specify, what the model is likely to get wrong, and when a fluent answer is fluent because it's correct versus because it's well-formatted. Those take time to learn, and they're the difference between using a tool and being surprised by it. *Source: [Getting good at AI takes time and practice — Sean Goedecke](https://www.seangoedecke.com/getting-good-at-ai-takes-time-and-practice/).*