How to Actually Get Good at Using AI

The pitch on AI is simple: delegate more, produce more. Spin up agents, fire off prompts, watch the output pile up. That pitch is only true for the few people willing to do the part nobody puts in the sales deck: reviewing what comes back, learning from it, steering it toward something actually correct, and building the harness that makes steering it possible in the first place.

Everyone else gets a pile of documents that look finished and aren't.

Are you using AI to be more productive, or to make your whole team less productive?

The Choice

AI is here, it's real, and it's revolutionary. Every one of us is choosing what to do about it, one way or another, you can: stand still and try to ignore it, use it badly, or use it well.

Standing still or assuming this thing doesn't exist is not a new kind of bet, and it's a very human reaction to resist change. It's the bet an accountant made in the 1980s or 90s, insisting on paper ledgers while everyone around them moved to spreadsheets. And a few decades or centuries ago it was a bet you could make: technology permeated slow enough for you to retire before the technology retired you. But these days the world moves faster now than it did then, so I wouldn't take that bet unless the years left before your own retirement can be counted on the fingers of one hand.

Using it badly is worse than standing still, and it's the harder trap to see yourself falling into, because it looks like progress the whole time. This group delegates without checking. They generate a steady stream of AI slop: documents that look complete and mostly aren't, that read fine on the surface and fall apart on inspection. This doesn't just fail to add value, it makes the org slower than doing nothing at all, because who receives the document still has to do the work of figuring out what's usable. Colleagues notice, and this group isn't well liked, for good reason: they quietly push the review work they skipped onto everybody else.

Using it well means getting somewhere the other two groups can't. This group lets AI get them 80-90 percent of the way there, then spends its attention on the other 10-20 percent: reviewing it, correcting it, understanding why the model did what it did, and ultimately applying their own judgement to the document. Over time, and with the right harnesses, they delegate narrow-scoped tasks, but still do a quick check. These harnesses are built over time, not assumed up front.

Assuming you're willing to lean forward and land in that third group, here are two habits that separate it from the other two: how you review what AI hands you, and building your own harnesses so you don't have to steering AI manually every time.

The 80/20 Rule Nobody Warns You About

I once assumed a model could actually do the research, dig into a market by scraping a dozen websites, pull in the company's own private data to understand not only what I was trying to do but what my organization's and partners' goals were, crunch the numbers, and come up with a report that would guide the strategy of a product for the upcoming year or two. Let me tell you, it didn't go well.

Thirty minutes later I had something that read like a real business plan, so I sent it to my boss. It used all the right key words and terms, but it was shallow, didn't deeply understand what our organizational goals were, and I struggled when my manager asked pointed questions about it. That's the pattern many have found: AI can produce output that is about 80 percent correct and 100 percent done-looking, but the author struggles to defend it in depth. The gap between those two numbers is invisible until you go looking for it, and it's exactly where quality and reputation are won or lost.

I call the fix for this problem the Double-Click Method: when a term, a claim, or a structural choice in the output is unfamiliar, don't wave it through. Ask what it is. Ask why the model chose it over the alternative. Then ask it to argue the opposite case, get the other side of the argument. This is something so many people miss; models are generally happy to defend whatever they just told you, so the only way to see the other side is to explicitly ask for it, and then it's up to you to judge which one is right or to use both.

Another powerful technique is running the same document through different personas. Ask the AI to review your product requirements as a senior product executive would. Then as an engineering manager. Then as a lead engineer. Then as a product marketer. Use skills like /grill me. Each pass surfaces a different set of gaps, because each role is optimizing for something the others aren't, and on each pass you use your judgement to curate and refine your understanding of the subject and the content of your document.

And it's your judgment that makes this work rather than just adding noise: don't apply all the feedback automatically. Read each pass, learn about the subject, and weigh it against what you actually know about your product and your org, then decide what to keep and what to discard. The goal was never a perfect document. It was for you to grow your knowledge and refine your judgement by surfacing gaps you couldn't see from inside your own head, and forcing yourself to sit with angles you'd otherwise have skipped. The outcome is a better document.

The payoff shows up twice. You save your colleagues real review time, because you've already caught what the engineering manager or the product marketer would have flagged before it reaches them. And you build your own understanding of the problem well enough to defend it in the room without notes. That second part is the one that compounds. More documents produced faster isn't the win condition; more judgment per document is.

Build Your Own Intelligence Harness

Every time we talk to an AI it runs into the same wall: the model knows an enormous amount in the abstract and almost nothing about your specific situation. A model is basically the world's knowledge compressed into a zip file, it is an archeologist, an engineer and a designer all at the same time. The only way to get real use out of it is to steer that knowledge toward your task at hand, your company, your customers, and what you already tried last week and ruled out, instead of leaving it to answer in the generic.

The people who get the most out of AI stop treating every session as a blank slate and start building what's worth calling an Intelligence Harness: custom instructions that encode how they like work done, skills that package a repeatable workflow instead of re-explaining it each time, MCP servers that connect the model to the actual tools and data they use daily, a CLAUDE.md or AGENTS.md file that carries standing context and preferences from one session to the next, and eventually memory and agent frameworks that let multiple specialized agents coordinate on their behalf. None of it makes the model smarter. It all makes the model more steerable, which is what separates a good one-off prompt from a system that keeps getting better without you re-explaining yourself every time. That's what the pros do.

You don't need to build all of that right away. If you're starting from scratch, go in this order: custom instructions first, skills second, MCP servers third, only then jump into agent frameworks. First three are supported across the major agents from every big name in the industry, so the time you put into them travels with you no matter which model or tool you're using next year. Memory and full agent frameworks are worth building toward eventually, but they're also where lock-in and complexity show up first.

These two habits, reviewing with real scrutiny instead of waving things through, and building the harness that steers and contextualizes AI as much as possible so that happens by default instead of something you have to remember every time, are really the difference between using AI to chase output at the expense of quality, and using AI to be better at your job.

Sovereign AI: the next cloud-sized wave for enterprise software

Disclosure: I'm a Product Manager at Microsoft, working on Azure Arc. The views below are my own, not my employer's.

AI is the biggest technological shift since the industrial revolution, and it's going to touch every company on the planet. That's a big claim, so here's why it isn't hyperbole: every previous enterprise-technology wave, cloud included, added capability to what a company already does, cheaper and faster. AI is different in kind, not degree, because what it produces is a working approximation of intelligence, and intelligence isn't a layer you sit underneath a business. It's a layer you sit inside of.

Every company draws a line between what it outsources and what it doesn't, and that line has always tracked competitive relevance, not cost. Payroll, IT helpdesk, facilities management: none of that is core to why a company wins, so it gets handed to a vendor without a second thought. Design and product architecture, manufacturing process, R&D: that never gets outsourced, because it's the edge a competitor would pay to know. Intelligence, as AI takes on more of what a company actually does, doesn't land on the payroll side of that line. It lands on the design-and-research side, and for a growing number of companies it starts to be that side: the actual mechanism by which decisions get made. That's not a layer any serious company can afford to rent indefinitely from someone else.

Compute and storage never forced companies to make that call, because compute and storage are commodity substrate: an enterprise that runs entirely on one cloud provider is making a real bet, but it's a portability bet — a VM or a storage bucket doesn't learn anything about the business running on it. Token generation is different by construction. Using a third-party-hosted closed model means feeding it the proprietary data and workflows that make it useful, and access to that model has already proven revocable for reasons that have nothing to do with the vendor relationship (more on that below). Single-sourcing a commodity is a supply-chain risk. Single-sourcing the intelligence layer of your business, one a competitor can absorb the fingerprints of and a government can switch off overnight, is a different order of exposure entirely.

That's the bet behind sovereign AI: enterprises owning their models, their data, and their deployment, rather than renting all three from a handful of closed-model providers. It's early. But the trajectory looks a lot like cloud's did in its own early years, and I think it's the next wave enterprise software companies should be building for.

How big, actually

Enterprise AI spend today is still a fraction of enterprise cloud spend: tens of billions ($24–33B) against enterprise cloud's $750–850 billion footprint today. But enterprise AI is compounding at roughly 35–38% a year against cloud's 12–17%, and the adoption curve is compressed: 78% of companies had at least one AI business function by 2025, up from 55% just two years earlier, with 71% running generative AI regularly across business functions. Cloud took the better part of a decade to reach that level of enterprise penetration. AI got there in about two years.

AWS launched in 2006, ChatGPT in 2022 — both landing in a market sitting at roughly $10–20B a year. Project that forward eight years: by 2014, pure enterprise IT spending on public cloud services reached $56.6 billion. Enterprise AI is forecast to reach $155 billion at its own year eight (2030). AI isn't just matching cloud's curve — it is projected to reach nearly 2.7 times the size of enterprise cloud at the same stage in its lifecycle.

Pasted image 20260726080652.png

AI is behaving like cloud did, just compressed and at a significantly higher enterprise volume.

This adoption curve is underpinned by multiple waves of AI, starting with technologies like vision models, which moved manufacturing quality assurance from manual inspection to automated, always-on defect detection, attacking a problem that causes 20 cents of every dollar spent in manufacturing to be wasted, roughly $8 trillion globally by Bain estimates. The next big wave is agentic control, where systems are given controlled autonomy to adjust production in real time, with humans shifting from operators to supervisors of a fleet of agents rather than the ones running the line. This is a reality at Xiaomi's smartphone plant running 24/7 with no one on the floor, powered by an AI platform (HyperIMP) that streams data from every machine, catches anomalies before they cascade, and resolves minor defects and process tweaks autonomously. A Chinese textile plant runs 5,000 looms the same way. Just two examples of enterprise AI's much faster adoption curve vs. cloud.

The AI control spectrum

Every enterprise sits somewhere on a spectrum of how much control it has over the AI it depends on:

Fully outsourced. A closed model, accessed via API, hosted on someone else's infrastructure. Zero control over availability, pricing, or what happens to your usage data.

Privately hosted, still closed. A closed model, deployed on your infrastructure or at the edge by its provider, but still their weights, still their terms.

Fully sovereign. An open-weights or custom model, deployed wherever you want, with nobody's permission required to keep running it.

Most enterprises today sit in the first category by default, simply because it was the only practical option until recently. The direction of travel is toward the second and third.

Why the first two options are shakier than they look

The first category's risk is perhaps the one people are now talking about the most: a closed-model provider can throttle access, change pricing, or lose the ability to serve you for reasons that have nothing to do with your business. This isn't hypothetical anymore. In June 2026, the U.S. government forced Anthropic to suspend access to two of its newest models for all users, worldwide, over export control concerns, reinstated a few weeks later, but not before enterprises that had built on those models got a very concrete lesson in what single-sourcing a government-reviewable technology looks like. OpenAI hit a version of the same wall days later, previewing its next model family to a short list of vetted partners rather than the public. Frontier models are being treated as national-security assets now, and that changes the calculus for anyone depending on one.

The second category, private deployment of a closed model, sounds like the answer, but it runs into a structural problem that has nothing to do with goodwill. A closed-model provider's business is built on two things: the model weights, and the telemetry of how those weights get used. Handing an enterprise a fully unrestricted, air-gapped copy of a flagship model gives away any telemetry, and potentially the weights as well, unless it's deployed carefully — orchestrating multiple products from different vendors across a nascent tech stack called confidential computing. Something closed-source model makers are still getting used to. That's not a policy a lab is likely to offer generously, and it's not a cheap solution either, pushing solutions to a seven-figure baseline for customers.

(Worth noting that this argument is about private and public companies. Governments are a different case entirely, with their own negotiated access to air-gapped models, a separate conversation.)

The only 'sustainable' option, enabled by open-weight models

Most enterprises are now realizing sovereign AI, where they control their intelligence and the infrastructure that makes it run, is perhaps the only sustainable option available to run their operations on.

This is where open-weight models stop being a side debate about model quality and become the mechanism that makes real sovereignty possible. Openness and air-gappability are close to the same property: if you have the weights, you can run the model anywhere, forever, with no one's permission and no telemetry flowing back to anyone. A restricted private deployment of a closed model can't offer that, by construction.

The performance gap between open and closed models has also been closing faster each cycle, reaching 90% of the performance on most tasks at a fraction of the cost. The qualitative trend is consistent enough that "open models are good enough for most of what enterprises actually need" is no longer a controversial claim. As that keeps happening, paying frontier prices and accepting frontier dependency risk stops making sense for a growing share of everyday token-enabled tasks.

The real moat is data, not weights

Here's the part that I think gets missed in most sovereign AI takes: the reason open models matter isn't just deployment freedom. It's that they're structurally better suited to capturing what's actually valuable, an enterprise's own data, on two counts at once: they're the ones you can actually tune on that data, and they're the ones that don't require handing it to a competitor to do so.

Start with the tuning case. A model acquires role-specific capability (the ability to act like a competent software engineer, or UX designer, or clinical analyst) in the final stage of training, where it's shown examples of what good work looks like in that domain. That requires domain-specific data. Software engineering is the one field where this data was given away for free, at scale, through decades of open source, which is a large part of why coding is the area LLMs became really capable at first. Other domains don't have that advantage. The data that would teach a model to be a great insurance underwriter, manufacturing quality engineer, or corporate lawyer sits locked inside the companies that do that work, and most of those companies haven't priced it as the asset it is.

On the ownership side, no enterprise can afford to hand its core competency to another company, and running proprietary data through a third-party closed model's API, whether for inference or fine-tuning, risks doing exactly that. Palantir CEO Alex Karp put this bluntly in a July 2026 CNBC interview: "The basic view among enterprises in this country is: I'm going to chillax and waste my time with tokens, I'm going to get no value, and they're going to get my IP." His word for what's at stake is alpha, the unique competitive edge that differentiates a business, and he says enterprise customers are increasingly unwilling to hand it over. Your data isn't just an input to a vendor's model; it's your business's edge, and once it's run through someone else's infrastructure, you no longer fully control what happens to it.

Satya Nadella is making the same point. In a July 2026 post, he calls this the "Reverse Information Paradox": you pay for intelligence twice, once in money and once in the proprietary knowledge you have to feed the model to make it useful. He quotes Karp's "alpha" line directly as the same concern.

Figma found this out directly. In April 2026, Mike Krieger, Anthropic's chief product officer and a sitting board member at Figma, resigned from Figma's board. Three days later, Anthropic launched Claude Design, a product that competed directly with Figma's core business. Figma's CEO later said, in front of Figma's own board, that Anthropic "were not consistently candid" with them. The lesson isn't that Anthropic acted in bad faith by some unusual standard: it's that "we won't train on your data" and "we won't act on what we learn about your business by watching you use our product" are two entirely different promises, and only one of them is usually made explicitly.

This is exactly where open models win on both counts. Fine-tuning a closed model through a provider's API doesn't fix the ownership problem: you're renting an adapted instance you can't take with you, still dependent on that provider's infrastructure and pricing, and still handing your training data to the exact company whose dependency you're trying to escape. Fine-tune an open model instead, and you own the resulting artifact outright: deployable anywhere, including fully air-gapped, with no one else's telemetry attached to it. The tuning capability and the IP protection aren't two separate benefits: they're the same property, because owning the weights is what makes both possible.

On top of that, you get efficiency gains. A 27-billion-parameter open model, fine-tuned on tens of thousands of domain-specific examples, outperformed Claude Sonnet 4, a much larger closed model, by 60% on a specialized clinical scribe task, while running smaller, faster, and cheaper. That's not an isolated result: fine-tuned open models in the 7–13-billion-parameter range routinely beat much larger general-purpose closed models on narrow, well-defined tasks. The honest caveat is that closed frontier models still lead on broad, open-ended reasoning and genuine edge cases, so the architecture most people are converging on is two-tier: a frontier model handling orchestration and the unexpected, fine-tuned open models handling the well-defined, high-volume domain work, with an enterprise's proprietary data never leaving its own hands.

Who captures the opportunity

Enterprise architecture moves in long pendulum swings. Everything sat on-prem through the 2000s. Then the cloud wave pulled it as far to the other extreme as it would go: for the last fifteen years, the default assumption has been "move everything you can off your own hardware." Sovereign AI is the swing back toward center: not back to on-prem, but to hybrid as the new steady state. Enterprises will keep running plenty of workloads in the cloud (there are many use cases where cloud makes sense), but the on-prem and edge share of the mix grows from here, pulled specifically by the sovereign workloads described above. Three groups are positioned to capture that shift.

The hardware layer. Dell, HPE, Lenovo, Supermicro, the OEMs that build the physical servers enterprises run on-prem, are in an unusually good spot for this cycle. Dell is already reporting share gains specifically among enterprises and sovereign-AI buyers building out their own capacity. More on-prem and edge deployment looks close to a straight tailwind for this group, not a shared one.

The hyperscalers. Their focus needs to go back to the edge: they need to make hybrid and air-gapped deployments feel like more cloud, not less, by offering a software stack that carries the same AI models, APIs, and tooling from their cloud straight onto an enterprise's own hardware. Microsoft's Foundry Local runs the same SDK and API surface as Foundry in Azure, on-prem or fully disconnected via Azure Arc, so a team can prototype in the cloud and ship the identical code to the edge. Google Distributed Cloud does the equivalent, now running Gemini itself on air-gapped, fully disconnected hardware for government and regulated industries. AWS covers the same ground with SageMaker-on-Outposts, extending SageMaker's training and inference tooling onto customer-owned hardware. All three are still early relative to the size of enterprise demand, and none has a clear lead yet; whichever hyperscaler gets sovereign AI right first gets to capitalize on a once-in-a-generation opportunity by keeping intelligence workloads at the edge that would otherwise migrate to competitors or smaller, sovereignty-focused vendors.

The systems integrators. The third group is the companies that go in and actually build and fine-tune an enterprise's sovereign models, and this one's already visible in the numbers, not just the thesis. Palantir pioneered the "forward-deployed engineer" model: send engineers to live inside a customer's operations and build the AI system alongside them, on their data, on their infrastructure. It's a real part of why Palantir's revenue grew 85% year-over-year in Q1 2026, its fastest growth since going public, with US commercial revenue up over 100%. The rest of the industry has now piled into the same model: AWS put $1 billion into its own forward-deployed engineering unit in June 2026, Microsoft launched a $2.5 billion "Frontier Company" employing roughly 6,000 embedded engineers days later, and OpenAI and Anthropic each stood up comparable units in May 2026: north of $9 billion committed to the same idea in about two months. That money isn't earmarked for sovereign AI specifically; it's a response to a broader problem: getting AI to actually work inside an enterprise has turned out to be harder than the industry expected, and off-the-shelf deployment keeps falling short of what customers need. Sovereign and edge deployments, with their added infrastructure and data-locality constraints, are simply the sharpest edge of that same problem, and they'll absorb a growing share of this forward-deployed capacity as they scale. Either way, a deployment this complex doesn't sell itself off a shelf; someone has to sit inside the customer and build it with them.

Cloud rewarded the companies that helped enterprises stop building their own data centers. Sovereign AI rewards the opposite motion: whoever helps them build, own, and scale the intelligence that matters most, instead of renting it on someone else's terms.

Sources

Market size and growth

  • Enterprise AI market, $23.9B (2024) to $155.2B (2030), 37.6% CAGR: Grand View Research
  • Enterprise AI adoption, 78% of companies with an AI function in 2025 (up from 55% in 2023), 71% using generative AI regularly: Cervicorn Consulting

Cloud market history (for the years-since-inception comparison)

Manufacturing and agentic AI

  • Bain estimate: 20 cents of every manufacturing dollar wasted, ~$8 trillion globally; Instrumental and Elementary case studies: BuildMVPFast
  • Agentic AI introducing "controlled autonomy" into quality systems, human-in-the-loop: Azilen
  • Xiaomi's "dark factory" and HyperIMP autonomous manufacturing platform: CIO Visionaries, Open Magazine
  • Chinese textile plant automating 5,000 looms, lights-out 24/7 operation: RoboHorizon

Fine-tuning: open vs. closed models

  • Fine-tuned 27B open model (Gemma 3) outperforming Claude Sonnet 4 by 60% on a clinical scribe task: Together AI / Parsed
  • Fine-tuned 7-13B open models outperforming larger general-purpose closed models on narrow tasks: MindStudio

Open models closing the gap with close models

  • Kimi K3 Model Overview: 2.8T Parameters, MXFP4 Quantization, and What the Open Weights Mean for the Community: Huggingface
  • AI open models have benefits. So why aren't they more widely used?: MITSloan

Frontier model access risk

  • June 2026 U.S. export-control suspension of Anthropic's Fable 5 and Mythos 5, restored July 1: Let's Data Science
  • Same episode, enterprise risk framing: Algo & Art
  • OpenAI's GPT-5.6 limited to vetted partners after government request: TechCrunch

Palantir / Alex Karp

  • Alex Karp's CNBC Squawk Box interview on enterprises' fear of losing IP and "alpha" to frontier AI labs: Yahoo Finance / Benzinga
  • Satya Nadella, "The Reverse Information Paradox" (July 2026), on enterprises needing their own trust boundary and learning infrastructure, quoting Karp on "alpha": sn scratchpad

Figma / Anthropic

  • Mike Krieger's board resignation and the Claude Design launch, timeline and Figma CEO's "not consistently candid" quote: Upstarts Media
  • Same episode, additional detail on dates and stock impact: CryptoBriefing

Hardware OEMs

Hyperscaler hybrid/edge software stacks

Systems integrators and forward-deployed engineering

  • Palantir Q1 2026 revenue growth of 85% YoY, US commercial revenue growth over 100%, driven by its forward-deployed engineering model: CNBC, Palantir investor release
  • AWS's $1 billion forward-deployed engineering unit (June 2026): CNBC
  • Microsoft's $2.5 billion "Frontier Company," ~6,000 embedded engineers (July 2026): Tech Times
  • Overview of Microsoft, AWS, OpenAI, and Anthropic's combined $9B+ bet on forward-deployed engineering: Let's Data Science

AI makes you faster. Anthropic's research proves it makes you dumber.

Everyone's using AI to work faster. Generate that document in seconds. Write that code in minutes. Crank out reports at lightning speed. We're all drowning in productivity gains.

But here's the problem: Anthropic's research on AI-assisted coding found that participants using AI scored 17% lower on comprehension tests than those who coded by hand. That's nearly two letter grades worse. They were faster, sure—but they learned almost nothing. And this lesson applies beyond coding tasks.

What if the real cost of AI isn't the subscription fee? What if it's your brain?

The Speed Trap

The promise is seductive. AI tools can write your documents, generate your code, research any topic in seconds. You're 10x more productive. Your output has never been higher. You're shipping faster than ever.

Then reality hits.

You're in a meeting, and someone asks you to explain that document you wrote—the one AI generated in 30 seconds. You stumble. The sentences are grammatically perfect but say too much and too little at the same time. No references, so you can't even check if the core claim is true. You've just shared AI slop with your team: verbose documents that extrapolate paragraphs from single sentences and similar words, gramatically correct but factually suspect.

Or worse: production breaks at 2am. You need to debug the code you "wrote" last week. You stare at it. The logic is clean, the patterns are solid. You have absolutely no idea what it does. The panicked realization: you can't fix what you don't understand.

Anthropic published a study this week that proved what many are discovering the hard way—using AI to produce content doesn't mean you're learning anything. The 17% comprehension gap isn't just a statistic. It's the difference between understanding your work and faking it.

Who's Really Getting Smarter Here?

Here's what the research actually found: using AI didn't guarantee lower scores. How you used it mattered.

The participants who retained knowledge didn't just copy-paste AI output. They asked follow-up questions. They requested explanations. They posed conceptual questions while working independently. They used AI to build comprehension and intent, not replace it.

These are the AI natives—people who understand that the tool isn't magic, it's a collaborator.

If you're early in your career, this is critical. You're supposed to be building foundations—learning frameworks, absorbing concepts, understanding how things work. Delegate all that to AI, and you're building a career on quicksand. You'll be fast now and incompetent later.

If you're experienced, the trap is different but just as dangerous. You can't articulate the concepts in documents with your name on them. You can't explain your code in code reviews. You can't debug your own work. Your expertise—the thing that makes you valuable—atrophies while your output multiplies.

The uncomfortable question: Are you using AI to amplify your skills, or are you delegating your learning away?

The Smart PhD Student Framework

I shared the Anthropic research with my team, and it sparked something: we needed a better mental model for AI.

Here's what works: Treat AI like a smart PhD student. Brilliant at research and writing. Great at finding patterns and generating drafts. Also prone to confidently going down completely wrong paths.

You wouldn't hand your PhD student a task and blindly accept whatever they produce. You'd collaborate. Review their approach. Challenge their assumptions. Ask them to explain their reasoning. Learn from their research while applying your judgment.

That's exactly how to use AI—not as a replacement for thinking, but as a tool that accelerates learning while multiplying productivity.

Example 1: Code Understanding with Learning Modes

Claude Code has [three output styles](https://code.claude.com/docs/en/output-styles) that illustrate this perfectly:

Default mode completes your software engineering tasks efficiently. Fast. Clean. Done. You ship code quickly, but you learn nothing about why it works.

Explanatory mode provides "Insights" between completing tasks—educational moments that explain implementation choices and codebase patterns. You still get the work done, but now you understand the approach and you can make corrections. You're steering and learning the "why" behind the code.

Learning mode takes it further. It's collaborative, learn-by-doing. Claude shares Insights while coding, but also asks you to contribute strategic pieces yourself. It adds `TODO(human)` markers in the code for you to implement. You're not just watching the work happen—you're actively participating in it.

This works for developers at all levels. Junior engineers can benefit from interacting and coding while learning patterns and best practices. Senior engineers can understand Claude's approach well enough to spot problems, make corrections, and improve the solution. Everyone can explain what the code does and debug it later.

The difference between these modes is the difference between delegation and collaboration.

Example 2: Debate and Challenge (Especially for Juniors)

When you are learning a new concept using AI tools, think about how you'd work with a smart PhD researcher in your field. You don't just accept everything they say. You debate. You bounce ideas back and forth. You challenge their assumptions and they challenge yours. You listen carefully to their perspective, then iterate on your own mental models.

That's exactly how to supercharge your learning with AI.

When AI explains a concept, don't just absorb it—question it. "Why this approach instead of that one?" "What are the tradeoffs?" "Where does this break down?" When it suggests a pattern, challenge it: "What if we did the opposite?" "How does this apply to edge cases?"

This is how you develop your own mental models and controversial takes, not just regurgitate what the AI gives you. You're not learning facts—you're building judgment. You're developing the ability to think critically about the domain, not just execute tasks in it.

For junior engineers and product managers, this is the difference between becoming someone who can only use the tools versus someone who understands when the tools are wrong. The best practitioners aren't the ones who accept AI output at face value. They're the ones who've developed strong enough mental models to know when to push back.

When AI tools don't give you what you think it's a good answer, don't throw the baby with the bath water, don't quit and go back to your traditional way of working of doing everything yourself. You are missing the opportunity to learn and leverage these incredible tools.

Example 3: Research Without Hallucinations

For research and writing, I've found a two-step approach that kills hallucinations while building real understanding:

Step 1: Search phase. Use AI to triage sources (like Google)—ask for information on a topic (I find Perplexity really good at this), get a list of links, skim for relevance. Fast triage to find what matters. 


Step 2: Deep dive with RAG. Use RAG tools (NotebookLM, Copilot Notebooks, or Claude Projects) to synthesize and build that report only the sources you've verified. 

Why this works: The AI only uses sources you've approved. Hallucinations drop dramatically because it's not inventing facts—it's synthesizing information you've already validated. You're saving time by not reading and synthesising 10-20 pages of web pages and PDFs yourself, but you are controlling the inputs and learning the new concepts as the AI explains them.

You end up with a valuable document and actual understanding. You can have productive conversations with your peers because you learned something, not just because you generated something.

Your 30-Day Experiment

Here's the test: Use AI differently for 30 days and measure what actually matters.

If you're junior: Switch to Learning Mode. Use Claude Code's Learning or Explanatory modes for one project. Use ChatGPT Study Mode when learning new concepts. Force yourself to engage with the AI's explanations, not just its output. The goal isn't speed—it's understanding.

If you're experienced: Adopt the challenge protocol. Question anything that looks "okay but off." Always check the references. Verify that sources are actually trusted and correct for the topic. When something feels wrong, dig deeper instead of accepting it.

For managers: Watch for team members who can't explain their AI-generated work in reviews. That's not a performance problem - it's a learning problem that compounds over time.

The measurements that matter:

- Why not alternative X?
- What happens if assumption Y is wrong?
- Can you explain what the code is doing?
- Will you be able to debug it later?

If the answer to any of these is "no,=" you're doing it wrong. You've optimized for output instead of outcome. You're faster but dumber.

The win-win: When you get this right, you produce valuable documents and code while actually learning. You create work you can defend. You have productive conversations with peers because you understand the topic. Your expertise grows alongside your output.

That's the real productivity gain—not just doing more, but becoming more capable while you do it.

The Real Productivity Unlock

The companies that win with AI won't be the ones that generate the most content the fastest. They'll be the ones where people get smarter alongside the tools.

AI tools have gotten dramatically better. They hallucinate less. They include references. They can be concise when prompted correctly. But none of that matters if you're just using them to avoid learning.

The research is clear: every time you use AI, you're making a choice. Delegation makes you faster and dumber. Collaboration makes you faster and smarter.

The race isn't to produce the most content. It's to build the sharpest judgment. AI doesn't have to make you dumber. It can make you faster and smarter. But only if you treat it like a sparring partner, not a shortcut.

The contrarian truth: The productivity gains are real and sustainable - but only if you redesign workflows to preserve learning loops.

The Enterprise Release Paradox: Why "Agile" Doesn't Mean Bombarding Customers

Enterprise infrastructure and platform teams are destroying customer trust in the name of agility. They've conflated 'ship fast internally' with 'release frequently to customers'—and it's killing retention.

The Fundamental Misunderstanding

Product teams conflating "agile development" with "frequent customer releases" are destroying value in enterprise software, particularly for infrastructure products that serve as foundational components in complex systems.

Agile is about internal development velocity and responsiveness—not about pushing every iteration to production customers.

When your enterprise platform releases monthly, enterprises face:

  • Unplanned testing cycles
  • Integration validation overhead
  • Deployment risk across critical workloads
  • Opportunity cost as engineering teams handle upgrades instead of building features

Enterprise Customers Don't Want You to Move Fast and Break Things

Enterprise infrastructure products succeed on a fundamentally different premise than consumer products: customers expect you to move consistently forward while ensuring nothing breaks in the process. Reliability, predictability, and backward compatibility aren't just features—they're the entire value proposition. When an image filter changes overnight, users shrug and move on. When a critical feature changes between releases without notice, enterprise customers don't lose a feature—they lose money. Their teams spend unplanned hours troubleshooting, workflows break, and the reliability they depend on evaporates.

This means breaking things isn't an acceptable trade-off for innovation. When you do need to shift things around—and you will—you must make the transition as easy and foolproof as possible. Provide clear migration paths, comprehensive documentation, and automated tools that do the heavy lifting. Give customers a way to roll back to previous behavior if they need to. This escape hatch isn't admitting defeat; it's acknowledging that you can't predict every edge case in their production environment.

This approach preserves the product's value. Customers can't confidently adopt new capabilities when they're uncertain about stability. They delay upgrades, defer feature adoption, and ultimately extract less value from their investment. Steady, reliable progress builds trust that enables faster adoption of genuinely valuable innovations.

I learned this firsthand as a teenager working in IT. Eager to provide "value," I upgraded the networking software at one of my clients—an accountant—with a major version bump to get them the latest features. The entire network stopped working immediately. For more than 24 hours, no one could work while we scrambled to restore the previous version. No one had asked me to do this upgrade. I thought I was being helpful. Instead, I destroyed value—the client lost a full day of productivity, and I destroyed their trust. That was the last time they called me. I had moved fast and broken everything.

A Better Framework: LTS, Semantic Versioning, and Two-Track Releases

The solution isn't to slow down development—it's to decouple internal agility from customer-facing stability through three complementary mechanisms.

Semantic Versioning makes the stability contract explicit through clear version numbering (major.minor.patch).

- Patch releases: Version 2.3.1 → 2.3.2 (Safe—only bug fixes—zero breaking changes, deploy immediately)

- Minor releases: Version 2.3.2 → 2.4.0 (Evaluate—new features and endpoints while maintaining backward compatibility, plan testing)

- Major releases: Version 2.4.0 → 3.0.0 (Plan carefully—breaking changes) 

This transparency lets enterprise teams instantly understand the risk level of any upgrade and make informed decisions about timing and resource allocation. Because patch releases require less extensive testing, they can be paired with automatic update mechanisms, allowing security fixes to be deployed promptly without manual intervention or lengthy testing cycles.

Long-Term Support (LTS) Releases establish a multi-year commitment to specific release lines. Instead of forcing customers to upgrade constantly, you designate certain releases as LTS versions with guaranteed support for 2-5 years. Customers can standardize on an LTS release and plan upgrades around their business cycles, not your development sprints. This removes the treadmill dynamic where staying current requires constant attention and testing resources. 

Two-Track Releases operationalize an approach to be agile and predictable at the same time: a Preview track available on monthly or bi-weekly releases for early adopters who want cutting-edge features, and a Stable track with annual or bi-annual releases paired with LTS designations, plus patch releases on demand for security hotfixes. Customers choose their risk tolerance—early adoption with preview, or stability with Stable versions that won't change unexpectedly (for years for LTS versions). Customers can also leverage both tracks strategically: running Preview releases in non-production environments to get a taste of what's coming, test changes thoroughly, and make informed decisions about when to upgrade minor or major versions in production. This allows teams to minimize surprises during production upgrades by validating changes in advance, giving them time to adapt workflows and prepare for breaking changes without emergency scrambling.

Reliability as Competitive Advantage

Enterprise customers using infrastructure software products don't want your latest features—they want infrastructure that works predictably for years. When your product releases break existing deployments, teams lose trust in the entire company. When your changes break customer workflows, you've just created a compelling reason for them to evaluate competitors.

Stability isn't a constraint on innovation—it's the foundation that makes innovation possible. It enables customers to confidently build on your platform knowing the ground won't shift.

Implementing this framework requires organizational alignment and a reframing of success metrics. Internally, this isn't about "slowing down"—it's about protecting customer value and building sustainable competitive advantage through trust. The metrics that matter shift dramatically: deployment frequency becomes less relevant; what matters now is customer upgrade rates and retention. Are customers actually adopting your stable releases? Are they staying longer? Are they expanding within your ecosystem?  

This shift requires alignment across three critical functions. Engineering needs to understand that backward compatibility and testing rigor are a core part of the value prop, not overhead. Sales needs messaging that emphasizes predictability and long-term partnership over feature velocity. Customer success teams need to shift from managing upgrade crises to proactively planning upgrade windows that fit customer timelines. When all three are aligned around retention and value extraction rather than churn and replacement, the entire organization pulls toward sustainable growth. 

The Path Forward

  1. Separate development cadence from release cadence
  2. Design releases around customer adoption timelines, not development sprints
  3. Invest heavily in backward compatibility and migration tools
  4. Measure success by customer retention and platform adoption, not feature delivery speed

Enterprise software succeeds when it becomes invisible infrastructure that teams can depend on. The moment customers start worrying about your release schedule is the moment you've lost their trust.

Your customers don't want to be your QA department. Give them the stable foundation they're paying for, and save the experimentation for customers who explicitly opt in.

A introduction to Solid, an evolution of the Web

Solid is a Web 3.0 protocol whose main goal is to reshape the relationship between users and their data. Solid is an evolution of the web as we know it, decoupling identities, data and applications. The goal of this new data architecture is to enable new user experiences where the data is organized around and under the control of the individual, with native consent and access control out of the box.

Solid is based on the following key concepts:

  • Decentralization: unlike traditional data architectures where data is stored around applications, creating silos of information, Solid introduces the concept of a Pod (Personal Online Datastore) where data is stored and organized around the identity who controls that data. This allows users to have fine-grained control over where the data is stored and who can access it.

  • Interoperability: data in Pods is stored using a standard and open format called RDF (Resource Description Framework) and can be accessed via common web protocols (HTTPS). This ensures that different applications can read and write data to the same Pod using a single universal API, promoting interoperability.

  • WebIDs: Web Identifiers are unique URIs that serve as an identifier for an entity in Solid. These IDs are an extension of OIDC, allowing for a frictionless integration with existing IdPs and seamless transition to Solid apps for users with existing platform identities.

  • Solid Pods: Pods are secure data stores where users can store their data. A Pod is a construct where a user can have multiple Pods and all data is discoverable by applications through the user’s WebID and available through the individual’s consent. From a user’s and application’s perspective a user’s Pod is the place where all the user’s information resides but from an implementation perspective there are multiple Pods where each Pod stores different information based on regulations and requirements. For example: a user might have a banking Pod where they store all their banking information like credit card transactions, a health Pod where they store their medical records and a Photos Pod for their family pictures, each in a different hosting provider, all linked to the user’s WebID.

  • Privacy and security: data is stored in fewer locations and under the user’s control, minimizing data duplication, the risk of data breaches and unauthorized access to personal information.

  • An evolution, not a revolution: Solid is an evolution of the web as it sits on top of existing technologies like HTTP, Web Servers, OIDC for authentication and RDF for data formatting. This makes it easier to integrate with existing applications and services, while benefiting from 30 years of technology maturity in terms of security, robustness, scalability and performance.

  • Open specification: Solid, being a W3C open specification, prevents vendor lock-in and sets a strong foundation for a thriving ecosystem of developers and vendors in the long term.

In a world where innovation stagnates under extractive data models, Solid proposes a new data architecture that creates value for consumers and producers of data. A way to organize information in a more equitable and scalable fashion for a world that lives and thrives on data sharing.