{"schema_version":"1.0","service":"Publicasta","type":"article","id":252,"slug":"ai_productivity_expertise_cognitive_debt_2026_08_04","title":"AI does not replace expertise. It makes expertise the leverage point","excerpt":"The latest arguments about LLMs, cognitive debt and productivity gaps point to a practical rule: AI creates value when experts frame, verify and integrate the work.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=en","image":{"url":"https://publicasta.com/storage/projects/8/pages/252/2026/08/601879fd-5f28-4d8d-b2a4-59b52182fde4.webp","alt":"Expert knowledge worker directing AI assistant panels with checklists and workflow context"},"publisher":{"id":8,"slug":"ai_practice","name":"AI Practice","url":"https://publicasta.com/ai_practice"},"author":{"name":"Anton R"},"published_at":"2026-08-04T10:15:59+00:00","updated_at":"2026-08-04T10:15:59+00:00","content_markdown":"The most useful AI debate this week is not about a new model. It is about why the same model gives one person a useful draft, another person a pile of confident mistakes, and a third person a faster path to a product that still cannot ship.\n\n ![Expert knowledge worker directing AI assistant panels with checklists and workflow context](https://publicasta.com/storage/projects/8/pages/252/2026/08/601879fd-5f28-4d8d-b2a4-59b52182fde4.webp)\n\n Several discussions that rose together on Hacker News made the pattern unusually visible. Sean Goedecke’s “LLMs reward expertise” argued that domain knowledge is the most important prompting skill. Ankur Sethi’s “Prevent cognitive debt by manually retyping LLM-generated code” argued that letting an assistant write too much code can leave the human without a mental model. “The AI Productivity Gap” argued that faster code generation is only one slice of developer throughput. Martin Fowler’s refactoring case showed that old engineering hygiene still matters when agents write large codebases.\n\n The practical lesson for AI adoption is simple but uncomfortable: AI makes more people capable of producing something, but expertise still decides whether that something is correct, useful, maintainable and safe. The competitive advantage is not “we bought the model.” Everyone can buy the model. The advantage is knowing what to ask, how to frame the work, which output is suspicious, how to evaluate it and how to integrate it into a real system.\n\n That matters for more than software teams. Analysts, lawyers, support managers, designers, finance teams, sales operations and product leaders are all discovering the same pattern. A model can draft, summarize, brainstorm, transform and automate. It cannot by itself know the business context, the hidden constraints, the regulatory edge cases, the customer promise, the codebase history, the company’s risk tolerance or what “done” means.\n\n ## Expertise is not a prompt template\n\n A common mistake in AI adoption is to treat prompting as a bag of magic phrases. Add “think step by step,” ask for a role, request a table, attach context, and the model becomes useful. Those tricks can help. They are not the core skill.\n\n Goedecke’s point is sharper: the most important skill in prompting is expertise in the domain. An expert does not merely write a longer prompt. An expert knows which two details change the problem, which assumptions are dangerous, which vocabulary unlocks the right tool, and which answer is plausible but wrong. The expert also knows when to stop exploring and ship, or when a model’s answer should send them back to first principles.\n\n His example of Terence Tao using ChatGPT is useful for exactly that reason. The interesting part is not that Tao found a secret prompt. The interesting part is that a world-class mathematician can steer, challenge and filter the model because he understands the territory. A non-expert can read the same exchange and copy the words without copying the judgment.\n\n The same is true in everyday work. A senior engineer can ask a coding agent for a migration plan and immediately see that it missed a transaction boundary. A product manager can use an LLM to explore customer segments and notice that the segmentation ignores the buyer/user split. A lawyer can ask for a contract summary and spot where the model softened a liability clause. A finance analyst can ask for scenario analysis and recognize when the model confuses revenue recognition with cash flow.\n\n AI reduces the cost of producing first drafts. It does not remove the need to know what a good final answer looks like.\n\n ## The novice gain is real, but bounded\n\n It would be wrong to say AI is only useful for experts. Novices can do more than they could before. A non-programmer can prototype a small internal tool. A junior analyst can ask better questions about a dataset. A founder can draft a sales sequence, a privacy FAQ or a support macro. A student can get explanations from multiple angles.\n\n The boundary appears when the task leaves the tutorial path. Non-experts often do not know the vocabulary to ask for the right thing. They may not know which file type is needed, what a deployment step involves, which regulatory term is precise, why a statistical result is invalid, or why a piece of generated code passes the happy path but fails in production. Better AI interfaces will narrow that gap, but raw chat and general-purpose agents still reward users who understand the domain.\n\n That is why “everyone is now a developer” is a misleading business lesson. More people can make prototypes. Fewer people can turn prototypes into operated products with security, testing, observability, maintenance, data handling, customer support and cost control. The value chain did not disappear; it moved.\n\n For companies, the implication is not to keep AI away from less experienced employees. It is to pair AI access with scaffolding: examples, review checklists, safe environments, approved workflows, domain glossaries, templates, evaluation sets and mentors. AI can accelerate learning when it is used under feedback. It can also hide gaps when nobody checks the output.\n\n ## Cognitive debt is a real cost\n\n Sethi’s “cognitive debt” phrase captures a problem many teams feel but struggle to name. If an assistant writes a large change and the human accepts it after a surface review, the code may exist before anyone understands it. The team has gained implementation speed and lost part of its mental model.\n\n His proposed workflow is deliberately slow: let the LLM suggest changes in chat, then manually type or rewrite them into the project. He estimates that this may be only around twice as fast rather than a fantasy ten-times speedup, but it preserves understanding. Whether every team should literally retype AI-generated code is debatable. The principle is harder to dismiss: understanding is part of the deliverable.\n\n There are tasks where high-speed agent mode is appropriate. Mechanical refactors with good tests, repetitive scaffolding, documentation cleanup, log-message normalization, test-data generation and one-off scripts can be good candidates. The risk is lower when the change is bounded, reversible and easy to verify.\n\n There are other tasks where comprehension-preserving mode is better. Core business logic, security-sensitive flows, data migrations, architecture changes, billing code, customer-facing behavior and anything that teaches a junior developer how the system works should not be outsourced to a black box without deliberate review. In those cases, typing is less important than ownership: the human must be able to explain the change, its tests, its failure modes and why it fits the system.\n\n Teams should track cognitive debt as seriously as technical debt. Signs include reviewers who cannot explain generated diffs, repeated AI patterns that nobody owns, duplicated abstractions, tests that assert implementation accidents, long generated files that agents can edit but humans avoid, and production incidents where the root cause is “we merged something we did not really understand.”\n\n ## The productivity gap is about bottlenecks\n\n The “AI Productivity Gap” argument is a useful antidote to simplistic ROI math. If AI makes writing new code three times faster, that does not mean a team ships features three times faster. Writing code is only one part of knowledge work.\n\n A developer’s day also includes reading code, debugging, design decisions, architecture discussions, reviews, documentation, testing, CI failures, deployment, coordination, mentoring, product clarification and incident response. AI compresses some of those tasks and shifts others. It may even increase review and integration work if it produces more output than the team can responsibly absorb.\n\n This is why measuring lines of code, number of pull requests or model tokens consumed is dangerous. AI can inflate output while throughput stays flat. A team may feel faster because the implementation queue moves, while the real constraint is requirements clarity, product taste, test coverage, review capacity, data quality, approval latency or the ability to decide what not to build.\n\n Business leaders should therefore measure outcome throughput: validated features, resolved customer problems, reduced support time, shorter cycle time from idea to production, fewer defects, better documentation, faster analysis with correct decisions. If the metric rewards output volume alone, AI will optimize for volume.\n\n ## Old engineering practices become AI practices\n\n Fowler’s refactoring case is a useful bridge between classic engineering and AI workflows. He describes a 150,000-line application written by agents, mostly Claude Code and Cursor. One data-access layer grew to 17,155 lines in a single Rust file. In a representative experiment, refactoring reduced input tokens for a change from 159,564 to 27,360, an 83% reduction.\n\n The point is not that every team should chase token savings. The point is that structure matters even more when agents work with code. Clear boundaries, smaller files, tests, stable interfaces, named concepts and removal of duplication make the system easier for both humans and models to reason about. A messy codebase taxes the agent context window just as it taxes a human reviewer.\n\n The case also undercuts the idea that agents make architecture obsolete. Fowler’s write-up says the model was not good at deciding the refactoring strategy on its own. Human guidance mattered. That is the pattern again: AI can produce and transform at speed, but the direction of transformation still benefits from engineering judgment.\n\n For non-software teams, the equivalent is workflow hygiene. If a sales team has no clear qualification criteria, AI will generate more inconsistent follow-up. If legal has no clause library, AI will improvise. If customer support lacks a source of truth, the assistant will confidently mix policies. If finance has messy definitions of churn, revenue and cohorts, AI will make prettier confusion.\n\n ## What good AI adoption looks like\n\n Good adoption starts by choosing the right unit of work. “Use AI more” is not a work order. “Generate first drafts of support replies, with policy citations, routed through human approval for high-risk categories” is closer. “Let agents modify production code” is vague. “Use agents for test generation and mechanical refactors under CI and reviewer ownership” is workable.\n\n Second, teams should decide which mode they are in. Exploration mode is for asking questions, comparing approaches and learning vocabulary. Drafting mode is for producing a starting point. Automation mode is for repeatable, bounded tasks. Agentic execution mode is for tools that can act. Each mode needs different permissions, logs, tests and review standards.\n\n Third, the team needs evaluation before scale. For code, that means tests, static checks, small diffs and production telemetry. For analysis, it means benchmark questions, known answers, source requirements and review by domain experts. For customer support, it means escalation rules and audited samples. For legal or finance, it means explicit risk classes and human sign-off.\n\n Fourth, context should live in durable places, not only in chats. Repo documentation, decision records, style guides, domain glossaries, API contracts, data dictionaries and examples help both humans and models. If the only person who knows the context leaves, or the only prompt that worked disappears in chat history, the workflow is fragile.\n\n Fifth, review burden must be budgeted. A team that doubles draft output may also double the amount of material that needs checking. If review remains the bottleneck, AI adoption can burn out the experts whose judgment makes the system safe. Good workflows protect expert attention: smaller batches, clearer diffs, automated prechecks, risk-based routing and enough time for real review.\n\n ## What managers should stop asking\n\n “Did AI make each employee faster?” is too narrow. A better question is: where did the bottleneck move? If coding got faster, did review slow down? If research got faster, did fact-checking become the constraint? If support replies got faster, did quality monitoring keep up? If prototypes got faster, did deployment and maintenance become the gap?\n\n “Can we replace junior people?” is also the wrong first question. AI changes the junior pipeline, but it does not remove the need for people who learn the domain. If juniors only accept generated work, they may accumulate cognitive debt. If they use AI under mentorship to ask better questions, compare alternatives and receive feedback, they can learn faster. The management task is to design the second environment, not accidentally create the first.\n\n “Which model is best?” matters, but it is rarely the only blocker. Many organizations have enough model capability and too little workflow discipline. They lack evaluation sets, clean source-of-truth documents, permission boundaries, ownership rules and shared definitions of quality. Upgrading the model may hide those gaps for a week. It will not remove them.\n\n ## A practical checklist\n\n Measure outcome throughput, not text volume, PR count or lines of code. Ask whether AI reduced the time to a validated result.\n\n Require human ownership of final decisions. The reviewer should be able to explain the output, not merely say the model produced it.\n\n Keep diffs and work units small. Small changes are easier for models to generate, for tests to cover and for humans to review.\n\n Use high-speed agent mode for low-risk, well-tested, mechanical tasks. Use comprehension-preserving mode for core systems, architecture and learning.\n\n Write domain assumptions into durable artifacts: repo docs, data dictionaries, policy pages, examples, tests and checklists.\n\n Create evals before scaling agents. If you cannot tell good from bad output reliably, more automation only increases uncertainty.\n\n Track review burden and cognitive debt. If experts spend all day cleaning AI output, the process is not working.\n\n Protect learning. AI should help juniors build mental models, not become a shortcut around understanding.\n\n Do not let chat become the product interface by default. For non-experts, guided workflows, forms, domain-specific checks and constrained tools may be more valuable than a blank prompt box.\n\n ## The real shift\n\n AI adoption is entering the post-demo phase. The question is no longer whether a model can write code, text, analysis or plans. It can. The question is who can make it produce the right thing, in the right context, without creating debt for everyone else.\n\n That makes expertise more visible, not less. Experts know what matters. They can specify the task, judge the output, build the harness, maintain the system and notice when speed is hiding risk. Non-experts can gain new powers too, but they need scaffolding and feedback.\n\n The best AI workflows do not remove the human from the loop. They move the human to a more responsible point in the loop: framing, evaluation, integration and preserving understanding. Companies that recognize that will get more value from the same models than companies that treat AI as a substitute for knowing what they are doing.","available_translations":[{"language":"ar","title":"AI لا يستبدل الخبرة؛ بل يجعلها نقطة الرفع","html_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=ar","markdown_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=ar","json_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=ar"},{"language":"de","title":"AI ersetzt Expertise nicht: Sie macht sie zum Hebel","html_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=de","markdown_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=de","json_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=de"},{"language":"en","title":"AI does not replace expertise. It makes expertise the leverage point","html_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=en","markdown_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=en","json_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=en"},{"language":"es","title":"AI no reemplaza la experiencia: la convierte en palanca","html_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=es","markdown_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=es","json_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=es"},{"language":"fr","title":"L’AI ne remplace pas l’expertise: elle en fait le levier","html_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=fr","markdown_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=fr","json_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=fr"},{"language":"pl","title":"AI nie zastępuje ekspertyzy. Wzmacnia ją","html_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=pl","markdown_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=pl","json_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=pl"},{"language":"ru","title":"AI не заменяет экспертизу — он делает её рычагом","html_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=ru","markdown_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=ru","json_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=ru"},{"language":"zh","title":"AI 不会取代专业能力，而是放大专业能力","html_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=zh","markdown_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=zh","json_url":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=zh"}],"_links":{"self":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=en","html":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=en","canonical":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04?lang=en","markdown":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.md?lang=en","json":"https://publicasta.com/ai_practice/ai_productivity_expertise_cognitive_debt_2026_08_04.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/ai_practice","channel_articles":"https://publicasta.com/api/public/v1/channels/ai_practice/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}