I launched Claude Code for the first time in an empty sandbox folder, not a real project yet. I typed one line: create a script that asks for my name and greets me. It thought for a second, showed me the code it planned to write, and stopped. It waited for permission before touching anything.
That pause was the tell. Not the code itself, a five-line script proves nothing. It was the shape of the interaction: propose, wait, act. Prompt, plan, permission, execute. I had expected something closer to autocomplete. What I got behaved more like a highly capable, entirely literal collaborator who would not move without checking in first.
That first impression turned out to be the right one, and it is the reason I believe domain experts, not developers alone, are the ones who should be building with this generation of tools.
The Bottleneck Has Moved
The argument is straightforward: Claude Code compresses the distance between an idea and a working prototype so far that coding ability stops being the constraint. What remains as the bottleneck is knowing what to build, and understanding the domain well enough to judge whether the result is actually right.
This is not just a personal impression. Anthropic’s own 2026 research into agentic coding, an analysis of roughly 400,000 Claude Code sessions across 235,000 users, names verification as the rising bottleneck: the harder task is no longer writing code, it is judging whether the code produced is correct. The same research found something worth sitting with. When a session hit trouble, novice users abandoned it about 19% of the time. Experienced users walked away only 5 to 7% of the time. Knowing how to steer an agent through a stuck moment is itself a form of expertise, and it is not a coding skill.
Industry forecasting points the same direction. Gartner projects that by 2028, the share of software-building teams coming from non-traditional technical backgrounds will roughly double, as domain expertise in fields such as healthcare, finance, and logistics becomes the harder capability to source, not the coding itself.
The same Anthropic analysis breaks results down by occupation, and the detail is worth dwelling on. Software engineers reached a verified success rate of roughly 34%. Every one of the ten largest occupation groups in the dataset, lawyers, analysts, marketers, scientists among them, landed within about seven points of that figure. Management occupations scored highest of all, ahead of engineering roles. The people whose job is deciding what should happen, not how it gets built, extracted the most value from the same tool.
The real shift. Once the agent handles the how, knowing what to build becomes the whole game.
The First Judgment Call Came Before Any Code
The clearest illustration of where the real decision-making sat came early in the rebuild, before a single line of application code changed.
The AI Business Audit's original design gave each of twelve business areas three plain-text suggestions, ideas, not recommendations. Separately, I had access to a catalogue of more than 200 specific AI tools, exported from the earlier no-code build. The obvious technical question was how to bring the two together. The harder question, and the one that actually mattered, was whether they should be brought together at all.
Keeping them separate would have been the simpler build: two features, loosely related, shipped independently. Merging them meant every existing idea needed a defensible link to a specific, named tool, with a reason attached for why that tool fit, and it meant the underlying content had to hold up to scrutiny it had never faced before. That was not a coding decision. It was a decision about what kind of thing this tool should actually be, an advisor that gestures at possibilities, or one that recommends something specific enough to act on.
I chose to merge them. Claude Code executed the schema change, the migration, and the subagent updates that decision required, cleanly and quickly. But the decision itself, the part that determined whether the end result would be genuinely useful or merely more elaborate, sat entirely outside the tool's remit. That is what knowing what to build actually looks like in practice. It rarely arrives as a single dramatic moment. More often it looks like one ordinary-seeming choice, made early, that everything downstream depends on.
What Looks Finished Can Still Be Broken
That distinction is where the real work lives, and it is worth being specific, because the argument only holds if it is grounded in what actually happened.
I rebuilt an internal tool I call the AI Business Audit, a small-business assessment app that asks a handful of questions and recommends specific AI tools with reasoning attached, not a generic list. It is the spiritual successor to the AI Solution Advisor covered earlier in this series, rebuilt from the ground up on Claude Code. Everything that follows actually happened during that rebuild.
Early on, a rule reframed how I thought about reliability. A project-level instructions file, Claude Code calls it CLAUDE.md, lets you write your project's conventions in plain language, and the model follows them most of the time. But “most of the time” is not a guarantee. A hook, a small script that runs automatically before or after an action, enforces a rule every single time, without exception. That distinction between a convention and a guarantee mattered enormously once the stakes rose.
Later, an approval checkpoint looked like it worked, and did not. I built a safeguard meant to stop an agent from running a destructive command, such as pushing to a live repository, without my explicit sign-off. The first version passed every test I threw at it. Closer inspection found the “confirmation” was the AI appending a marker to the command based on its own reading of my chat reply, not anything I had actually typed. The mechanism looked like a locked door. It was a curtain. Finding the gap took no coding at all, only the discipline of deliberately trying to break the safeguard rather than trusting that it held.
Later still, a data problem no amount of careful code would have caught. While migrating a catalogue of more than 200 AI tools into the new system, the count came out higher than expected. A source spreadsheet contained fifteen duplicate rows, the same tool listed twice under slightly reworded descriptions. The parsing code was correct throughout. The problem sat upstream, in the data itself, and only someone who understood what the entries were supposed to represent could tell a legitimate second listing apart from a copy-paste error fifteen rows away.
And a status update said more than it had actually verified. A report came back reading “confirmed working end-to-end.” On inspection, that meant a pre-written option had been selected on a prompt, not that anyone had watched the feature run in a browser. Nothing had gone wrong yet. But the confidence in that sentence outran the evidence behind it, and that gap is exactly where real problems hide until they surface somewhere expensive.
None of these were coding failures. They were judgement calls, caught only because someone who understood what the system was meant to do for the business was paying close attention to what it actually did.
| What It Looked Like | What Was Actually True |
|---|---|
| "The safeguard blocks risky actions" | The AI was authorising its own actions |
| "225 tools migrated successfully" | 15 were duplicate rows from the source file |
| "Confirmed working end-to-end" | A button was clicked; nobody had watched it run |
When The Checks Actually Held
Not every part of this rebuild produced a failure story, and the successes are worth as much attention as the near-misses, because they show what the discipline looks like when it works as intended, not only when it catches something broken.
Midway through the rebuild, I deliberately asked a research subagent to draft ideas for three new business areas in a single batch, specifically to see whether the system would hold up under more pressure than usual. Two of the drafts, for a product-development area and a strategic-planning area, independently proposed near-identical tool suggestions: automated competitor tracking, phrased two different ways. Each draft had been checked against the business areas that already existed. Neither had been checked against the other new area being written in the same batch. That is a real design gap, not a coincidence, and it only surfaces when a system is deliberately pushed past the conditions it was built and tested under.
Before concluding anything, I checked whether the overlap was a symptom of the AI running low on working context, a plausible and common explanation. A quick check of the session's own usage statistics ruled that out directly: the entire batch had consumed a small fraction of available capacity. The overlap was a genuine gap in the checking logic, not a resource constraint, and knowing the difference determined what actually needed fixing.
A later test produced the opposite outcome, verification working exactly as intended. A research subagent flagged one of its own tool suggestions as a doubtful fit, an enterprise data-science platform attached to a small-business idea, before any review had taken place. A separate reviewer subagent, working independently, flagged the identical pairing as a weak match without having seen the first subagent's doubt. Two unrelated checks converged on the same real flaw. A follow-up test, deliberately attaching an image-generation tool to an unrelated inventory-forecasting idea, confirmed the reviewer caught the mismatch reliably, not as a one-off. That is what a verification layer looks like when it is genuinely doing its job, not decorative, not lucky, independently and repeatedly converging on the truth.
A Quieter Lesson: Speed Versus Ownership
Not every insight from this rebuild was about AI. One of the more useful ones was about deployment itself.
The AI Solution Advisor, covered in “Building the AI Solution Advisor: From Concept to Production,” was originally built on Base44, a backend-as-a-service platform I still hold in genuine regard for how quickly it turns an idea into something usable. That speed is real, and for a first version, it was the right call.
Rebuilding the same concept on Claude Code taught a different value: owning every layer of what gets built. The new version sits in a source repository under my control, deployed on Vercel rather than inside Base44's own hosting, backed by a standard PostgreSQL database I could move to a different provider at any point, running on ordinary code rather than logic that exists only inside one platform's boundaries.
Ownership came with its own new category of things to get right, and they were unglamorous in a way the earlier debugging was not. Provisioning a database, connecting a source repository, setting environment variables correctly, none of it involved a single line of application logic, and all of it could fail silently rather than loudly. A wrongly named secret produced no error message and no crash, just a database that behaved as though it were empty even when the underlying connection was working. Finding it meant checking actual network responses rather than trusting that a feature which loaded without complaint was therefore working. The lesson generalises past this one project: infrastructure you own is infrastructure you are now responsible for verifying, in ways a managed platform previously verified on your behalf without your ever noticing.
The distinction: a no-code platform optimises for reaching a working product quickly. Owning the stack optimises for long-term flexibility, the ability to change providers, renegotiate terms, or simply outlast whichever platform a project started on. Knowing which one a given stage of a product actually needs is itself worth learning.
What This Means In Practice
For a business owner or professional without a development background, the practical takeaways are these.
- Direction matters more than syntax. You do not need to know a programming language to work with Claude Code effectively. You need to describe what you are building clearly, and recognise when a result does not match what you actually meant.
- Domain knowledge belongs in CLAUDE.md. It is where a project's conventions and constraints get written down once, so every session starts already informed.
- Plan Mode is where judgement gets exercised. Reading the proposed plan critically, rather than skimming past it, is the single habit that separates a system that does what you meant from one that only did what you literally said.
- Verification is the scarce skill, and it is already yours. Checking a status code instead of trusting a summary. Deliberately testing a safeguard instead of assuming it holds. Opening the actual product instead of trusting a report that says it works. None of this is a developer skill. It is the same due diligence any competent professional already applies within their own field, aimed at a new kind of collaborator.
- Architectural decisions deserve the same scrutiny as outputs. The choice to merge two systems, adopt a new data model, or take on a new dependency is rarely reversible without real cost. It deserves the same deliberate pause Plan Mode encourages for a single change, applied one level up.
None of this makes Claude Code, or any agentic tool, a substitute for understanding a business. It makes the absence of that understanding more visible, and more costly, than it used to be. When coding was the bottleneck, a good developer with a vague brief could still produce something serviceable. When coding stops being the bottleneck, a vague brief produces a fast, confident, well-structured answer to the wrong question. The tools got faster. The cost of not knowing what you actually want got higher.
The technology compresses the distance between an idea and a working system. It does not compress the need to understand what you are building, or the discipline to check it properly. If anything, it raises the price of skipping both.
The Plugins And Skills Worth Installing
Claude Code's plugin system is worth a closer look than most people give it. A plugin can bundle commands, agents, hooks, MCP servers, and skills into a single installable unit, and where that plugin comes from matters as much as what it claims to do.
There are effectively four tiers of trust. The first is claude-plugins-official, Anthropic's curated marketplace that registers itself automatically the first time you launch Claude Code, no setup required. Roughly a third of what's in it is built directly by Anthropic: language servers, code review, security tooling, output styles. The rest is vetted partner integrations, GitHub, Playwright, Supabase, Figma, Vercel, Linear, Sentry, Stripe, Firebase among them.
The second tier is claude-community, third-party plugins that have passed Anthropic's automated validation and safety screening but aren't registered by default, you add that marketplace yourself. The third is knowledge-work-plugins, a separate Anthropic marketplace worth knowing about if your work is not primarily code: fourteen role-based plugins covering sales, marketing, finance, legal, HR, and brand voice.
Below all of that sits everything else, independent community marketplaces, some running past three hundred plugins, with no Anthropic review of any kind. The install count tells you about popularity, not quality.
From what I've actually used, a handful earn a permanent place. frontend-design generates interfaces with a deliberate aesthetic direction rather than the generic look most AI-generated UI defaults to. code-review and pr-review-toolkit cover reviewing your own work and reviewing incoming pull requests, which are different enough tasks that having both matters. commit-commands turns git commit, push, and PR creation into a single workflow instead of three separate steps. security-guidance runs in the background and flags roughly two dozen vulnerability patterns as you edit, not after.
skill-creator deserves a specific mention. Rather than writing a SKILL.md file by hand, it walks you through building your own custom skill, which is the fastest way I've found to turn a workflow you do repeatedly into something Claude Code can just do for you. mcp-builder is the natural next step from the MCP section above, it guides you through building a proper server rather than a half-working one.
The knowledge-work-plugins marketplace deserves one honest caveat before you install it. I tried the sales and marketing plugins specifically, since they are directly relevant to a lot of content on this blog, and the results were mixed. The marketing plugin's output overlapped heavily with a competitive-brief skill that was already covering the same ground, and the sales plugin produced output that looked polished but was built on the wrong data for the wrong tier of customer. Worth trying against your own real work before you trust either one, the same caution that applies to the MCP servers above applies here too.
Installing any of this is a single command once you know the name: /plugin install <name>@claude-plugins-official for anything in the default marketplace, or just /plugin on its own to browse interactively. Anything outside that default marketplace needs /plugin marketplace add <owner>/<repo> first.