Claude AI Workflow  ·  Real Case Study

How We Use AI in Production Engineering

Most people are using Claude wrong. They treat it like a chatbot. I use it like a production system — and it ships hours of real work every week.

This guide is for people who already opened a Claude tab, got an answer that almost worked, and walked away thinking AI is overhyped. It's not overhyped. You're using it like a search engine when you should be using it like a junior engineer who never sleeps.

Below is the exact workflow I use to ship production code, audit databases nobody documented, and harden the things I have already shipped. The same loop, every time, across every domain.

What Most People Get Wrong About Claude

Three failure modes account for almost every "Claude isn't that useful" complaint I see online:

• They one-shot it. They paste a vague request, take the first answer, and use it. No iteration, no verification, no second pass. Then they're surprised when the output is generic.
• They feed it summaries instead of artifacts. They describe their problem in English when they should paste the actual error, the actual query, the actual log line. Summaries leak the exact signal Claude needs.
• They treat the chat as the system. They run 40-message threads until compaction breaks them. The chat is a tool. The system is your workflow around the chat — your scoped tasks, your context files, your verification loop.

If you fix only those three things, your Claude experience improves more than switching models ever will.

My Actual Claude Workflow (Step-by-Step)

People keep asking me for my "prompt template." There isn't one. The thing that matters is the loop, not the wording. Here it is, in full:

Define the outcome → Claude drafts → Test against reality → Specific feedback → Ship or repeat.

The critical insight: most people stop at step 2. They get a draft and try to use it. The real value is in steps 3 and 4 — testing against your actual environment and giving feedback precise enough that the next iteration converges instead of wandering. That's it. That's the engine. Below is what each step actually means in production.

1. Define the outcome (before you type a single word)

This is the single most important step and the one people skip. You must know exactly what "done" looks like in production reality. Not "a good query." Not "a legal-looking brief." Done means: copy-paste into the live environment with zero errors, or filed with zero procedural defects, or a function that logs real probes and blocks nothing legitimate.

Write the definition in plain English first: "After this loop, I will have a single script that replaces the legacy ones, runs in under two seconds on a 10k-row dataset, and requires zero user training." A model is a pattern-matcher, and a good one. If the target pattern is fuzzy, the output is fuzzy. Clarity here is the entire game.

2. Claude drafts

Feed the crystal-clear outcome plus all the real data — never summaries. Paste the actual query text, the actual docket entries, the actual log lines, the actual analytics exports. State your hard constraints up front. One-shot draft. No hand-holding yet. Let it go full creative. You'll fix it in the next steps.

3. Test against reality (this is the step that gets skipped)

Correction, 21 August 2026. This heading said “this is where 95% of AI users fail.” Nobody measured that, and an article about testing claims against reality does not get to publish one it invented. The figure is removed; the point it was decorating stands.

You become the merciless QA department. Run the code in a real dev environment. File the draft in test mode. Deploy the function and hit it with real traffic. Check the indexing tools for the new content.

Document every failure with surgical precision. Do not say "it's wrong." Say: "Line 47 throws an invalid handle on the temp buffer because the query uses an alias that only exists in the older code path."

4. Specific feedback (the convergence engine)

This is the art. Your feedback must be so precise that the next draft cannot possibly make the same mistake.

• Bad: "Make it better."
• Good: "The script fails on records where the invoice number contains a hyphen because you assumed all invoice numbers are numeric. Add a string check and handle that case explicitly."
• Even better: "Reproduce the exact error I just saw, then fix it, then show me the before/after diff so I can verify."

You are training the model on your exact domain reality in real time. That training only works if your descriptions are reproducible.

5. Ship or repeat

Two choices only. Ship = it passes your production test with zero caveats. Repeat = go straight back to step 3 with the new failure data. No "maybe one more prompt." The loop is sacred.

You keep repeating until the output is production-ready every single time. That's why the audit work delivered measurable gains, and why the exposures and silent faults described below were found at all.

Why This Loop Crushes Every Other AI Workflow

• It forces you to stay the domain expert. You define done. You test reality. The model can't hide behind vagueness because you removed it.
• It turns hallucinations into fuel. Every failure becomes training data for the next iteration.
• It compounds across domains. The more loops you run on one kind of work, the faster the next kind converges, because precise feedback becomes a habit rather than an effort.
• It's model-agnostic. Swap Claude for Grok, Gemini, GPT — the loop still works because the human is the constant.

Pro Tips to Make Your Loop Tighter

• Keep a "war room" context file. Paste it at the start of every new session: definition of done, previous failures, system constraints. Externalized memory beats hoping the model remembers. This is a Project — see what moved.
• Build a personal pattern library. After every successful ship, save the final output plus the exact feedback that got it there. That library is more valuable than any prompt template you'll find online. This is an Agent Skill — see what moved.
• Include one worked example of a finished output. Not a description of the format — an actual instance of the thing. This is the single highest-yield addition I have made to the loop since writing the original version of this article, and it was missing from my own template for two years. An example pins length, tone, structure and level of detail simultaneously, in a way that no amount of adjectives does. If you don't have a real one to hand, write a fake one; a fabricated example of the right shape works nearly as well as a real one.
• Say that "I don't know" is an acceptable answer. One sentence in the brief. A model with no explicit permission to report a gap will bridge it, because producing something is the default behaviour and the bridge is usually plausible. A model that has been told an admitted gap is a valid deliverable will hand you the gap — and a gap is actionable in a way that a confident wrong answer is not.
• Time-box every loop to 15–20 minutes. If it isn't converging, the outcome wasn't defined clearly enough. Go back to step 1. Don't keep prompting.

That's the entire methodology. It's boring, unsexy, and brutally effective — exactly like real engineering. Everything else in this article is what happens when you run this loop, hard, against real problems.

Professional: A 27% Performance Gain Across 70 Rewritten Database Views

Correction, 27 August 2026. This heading said “Across Hundreds of Database Views.” Hundreds were audited; the ~27% is aggregated over the 70 that were actually rewritten, which is a different and smaller population. The audit figure and the gain figure sat beside each other in the summary below and the heading merged them.

I work on line-of-business systems built on relational databases. Custom views accumulate over years. Reports get slow. The interesting question is never "is this view slow" — it's "is the join order wrong, is there a non-sargable predicate, is the index even being used."

Working with Claude on the audit, I batched the changes into discrete change sets and treated each one as a unit of work with a baseline, a hypothesis, and a rollback. Two patterns came up over and over:

• Date math wrapped around an indexed column in a WHERE clause kills sargability. Rewriting it so the column appears bare on one side makes the index usable again.
• Scalar functions in SELECT lists silently force row-by-row execution. Inlining them is ugly but fast.

How the gain was measured: elapsed time, against a baseline captured with a SQL Server trace, aggregated over the 70 rewritten views rather than over everything audited, on 10 March 2026. The 99%+ match rate above is the same audit, measured differently: each rewritten view’s result set compared against the original’s, with a match defined as exact equality on every field. The reconciliation rate further down this article is a different measurement on different work.

None of those patterns are clever. The leverage was running the loop fast enough that we could touch dozens of change sets in the time a single audit normally takes. Claude wasn't doing the optimization — I was, with Claude as the rubber duck that could also write the rewrite. If you want the reverse-direction story — pulling data out of complex systems for real reporting — that's exactly what we build at the SiegeStack ETL Showcase.

Professional: Retiring Nine Spreadsheet Macros

The other professional win was an architecture change disguised as a cleanup.

The process ran on nine spreadsheet macros. Each one had to be opened by a person, on a particular machine, in a particular order. They broke in the way macros always break: someone had the file open, or a column moved, or the workbook was on a laptop that was at home that day. When it failed there was no log, only a person noticing that something downstream looked wrong.

The replacement has three parts, and the separation between them is the whole point.

PowerShell does the work. One script instead of nine macros, watching for input, querying the database directly, and reconciling records. It runs on the server rather than on somebody's desktop, so it does not care whose machine is on or who has a file open.

SQL Server Agent runs the schedule. This is the choice people skip past, and it is the one that mattered. The obvious option was the operating system's task scheduler. Agent was better for reasons that have nothing to do with elegance: it already lived next to the data, it keeps job history without anyone building logging, it has retry and failure notification as configuration rather than code, and it is somewhere the people who look after the database already look. A scheduled task on a random server is invisible until it has been failing for three weeks.

A web service delivers the result. Previously the output was a file that got sent to people. Files go stale the instant they are sent, they fork into six slightly different versions, and nobody can tell which is current. Exposing the result over a service inverts that — consumers ask for it when they need it and get the current answer, and other systems can consume the same endpoint instead of someone re-keying numbers out of an attachment.

Reconciliation runs at 99%+. The remaining percent is genuinely ambiguous and is surfaced for a human rather than guessed at, which is the same errors-versus-warnings distinction as the tool above. Anything a machine cannot decide honestly should be handed to someone who can, not resolved quietly on its behalf.

How that rate was measured: the new script’s output compared against the legacy output the macros produced, row by row, with a match defined as exact equality on every field, on 4 May 2026. It is a different measurement from the match rate in the view-audit summary above, on different work — the two share a figure and nothing else.

Claude co-authored all three parts. What Claude did not do was pick the architecture. The decision to put orchestration in Agent rather than a scheduled task, and to deliver over a service rather than as a file, came from knowing which failures actually hurt — and those decisions are most of the value. The code was the easy part.

Professional: Mapping a Schema Nobody Had Documented

Before the performance work above could start, there was a more basic problem: nothing described how the pieces fit together. Hundreds of view definitions had accumulated over years, each one joining tables that joined other tables, and no map existed. You cannot safely change what you cannot see.

So the first project was building the map. Claude wrote a parser that read every view definition, extracted the join relationships, and cross-referenced them against the declared key constraints. Output went to flat files rather than a dashboard, deliberately — a queryable artifact beats a pretty one when you are about to make seventy changes against it.

The part that mattered was the parse log. Any definition the parser could not confidently interpret got written to a failure list instead of being silently skipped. That list was short, but everything on it was a genuine edge case worth a human decision. A parser that quietly drops what it does not understand produces a map that is confidently wrong, which is worse than no map at all.

Claude wrote the parser. I decided what counted as a join in the ambiguous cases, and those decisions are the only reason the output was trustworthy.

Professional: A Tool and Its Manual, Built Together

A recurring manual task involved taking an export out of one system, reshaping it by hand into several differently-formatted files, and loading it back in. It worked, it took a long time, and it broke in quiet ways — a mistyped identifier or a date in the wrong format would fail halfway through a load and leave a partial mess behind.

The replacement runs entirely in the browser. No backend, no upload, nothing leaves the machine. Drop the export files in, and the tool detects which is which, stamps the batch identifier down every row, normalizes the date formats, drops the header the exporter adds, and writes out the correctly-named files.

The validation design is the part worth stealing. Failures are split into two tiers: conditions that guarantee a broken load are errors and stop you, while conditions that are merely suspicious are warnings and let you proceed. Collapsing those into one category is what makes people ignore validation entirely.

Then the manual — a two-part slide deck, with every slide individually linkable so a colleague can be sent to step nine rather than to the document.

Illustrating it produced the most instructive failure of the whole project. The obvious approach was to have the browser screenshot itself. That does not work: the captures could not be retrieved to disk. Second attempt, having the page capture its own DOM, also failed. What eventually worked was dropping out of the browser entirely — an OS-level screen capture driven from a shell script that brings the right window forward, switches to the right tab, grabs the pixels, and crops them. Three approaches, two dead ends, and the working one was the least elegant.

That is the loop doing its job. The first idea was reasonable, it was wrong, and finding that out took minutes instead of an afternoon.

Personal: Taking a Security Policy from B to A+

The same site scored a B. Not because anything was wrong with the server configuration — the headers were all present — but because the content security policy carried unsafe-inline, and a policy with unsafe-inline in it is not a policy. It is a header that looks like one. It permits precisely the class of injection the policy exists to stop.

Removing it is not a configuration change. It means removing everything that made it necessary, and on a site that has grown organically that is a lot:

The end state has no unsafe-inline and no unsafe-eval in any directive, and the grade went from B / 75 to A+ / 125.

The interesting part is the exception. Two hundred and three structured-data blocks stayed inline and that is correct: browsers never execute them, and the script directive does not govern them at all. A sweep that "fixed" those would have broken every piece of structured data on the site in exchange for nothing. Knowing which rule does not apply is worth as much as knowing which one does, and it is the kind of judgement a model will not make for you unless you already know the answer.

Personal: Closing a Data Exposure I Had Shipped Myself

This one is uncomfortable to write up, which is the reason to write it up.

A members table held real personal data — names, email addresses, phone numbers, cities. The signup page talked to the database directly from the browser, using a key printed in the page source, scoped by an email address that the database had no way to verify. Row-level security had never been enabled. From an unauthenticated browser on the other side of the internet, that table returned success and every row in it.

The fix has two halves and both were necessary. On the code side, every operation moved server-side into a function that takes the caller's identity from a verified ID token — signature checked against the identity provider's public keys — and ignores whatever email the request body claims. The browser key and the client-side database SDK came off the page entirely. On the database side, row-level security was enabled and forced, and the public grants revoked. Verified from an outside browser: the table now refuses. Thirty-six assertions cover forged, expired, unsigned, wrong-audience and tampered tokens.

Two things came out of it that transfer to anything with a database behind it:

• Check for existing policies before enabling row-level security. That table already had four access policies on it, written at some point and completely inert because the feature was switched off. Enabling it would have activated them. Revoking the grants is what actually closed the hole, because privilege denial is evaluated before policies are.
• A policy that matches a token claim does nothing if your identity provider is not the database's own. The claim is null, so the policy matches no rows, and it looks exactly like working access control in the dashboard. This is the most convincing kind of broken security: it reads correctly, it deploys cleanly, and it protects nothing.

The Bugs That Report Nothing

Three separate production faults on the same project, none of which produced an error, a log line, or a failing check. All three read correctly in every file involved. I am grouping them because the lesson is identical.

A 404 that lasted six months. The platform supports two redirect configuration files and one silently takes precedence over the other. A rule in the losing file never runs, and nothing anywhere reports this — both files are individually valid and both read as if they work. One endpoint returned 404 for six months. Another for two days.

Two hyphens. A -- inside an XML comment is illegal and makes the entire document not well-formed. Search Console reported "couldn't fetch" and zero pages indexed, while the URL returned 200, the correct content type, the correct length, and fetched perfectly when requested as the crawler. Nothing in the HTTP response reveals it. Only parsing does. I spent real time looking at headers for a problem that was four bytes of comment syntax.

A year-old stylesheet. Static assets served immutable for a year with no filename fingerprinting, so every reference carries a version token. Ship markup that depends on a new CSS class without bumping that token and returning visitors get unstyled pages for up to a year — while it looks perfect to you, because your first visit fetched both fresh. The same trap bites during debugging: edit a stylesheet, retest without bumping, and a correct fix appears to have failed because the browser served you the cached copy.

Never Put a Credential on the Critical Path of a Public Form

Two public forms on that site sent an email and returned success only if the send succeeded. When the mail credential died, every submission returned a 500 and was destroyed — the handler logged only the domain of the sender's address, never the address itself, so there was nothing to recover from afterwards. Two real people who wrote in over two days were lost that way. Not a theoretical data-loss bug; a specific one, with specific people on the other end who think they were ignored.

Both forms now post to a platform form handler that records the submission before any mail is attempted. Read it, write it down, then try to send it. Anything that can fail independently of the user's intent belongs after the durable write, never before it.

The same project produced a second lesson about mail that is worth having in advance: the SMTP handshake time was measured at 28.7s, 2.3s, 21.5s, 22.4s and 1.5s. The timeout was set to 7 seconds, which meant roughly half of all sends aborted — and it failed only in production, while identical code worked locally every time. I initially wrote the slow handshakes off as an artifact of my home connection. That assumption cost considerably more time than the bug did.

Proving a Refactor Changed Nothing

Removing 1,316 inline styles is a mechanical change across dozens of files, and "I read the diff and it looks equivalent" is not a claim anyone should accept, including from themselves.

So the verification was measurement rather than reasoning. Check out the pre-change tree into a temporary directory, serve it and the working tree on two local ports, and for every rendered element on every page read about twenty computed properties, concatenate them, and hash the result. Compare the hashes. Compare the geometry too — bounding rectangles and document height — because identical computed styles will not reveal a font-metric shift.

It caught two real bugs that looked fine in the diff and produced no console error:

• Three pages had a <style> block inside an inline SVG. Replacing it with a stylesheet link in place does nothing at all — SVG has no such mechanism — and those diagrams would have shipped unstyled.
• Six declarations were silently lost to higher-specificity rules when inline styles became classes, because an inline style attribute outranks nearly everything and a class does not.

One detail makes the technique trustworthy: always measure a control file the change never touched. If the control reports differences too, your instrument is broken rather than your site. That is exactly how a run of false positives got caught before it buried the one real error underneath it.

Personal: Rewriting a Reference Site, and Catching Four Errors In It

A separate long-running project is a public reference site explaining a narrow area of procedure. Recently I put a full day into deepening it — several guides roughly tripled in length, each claim tied to a specific rule or decision rather than to a summary of one.

The useful part was not the writing. It was what the rewrite surfaced.

Checking existing pages against primary sources turned up four substantive errors that had been live for months. One of them appeared on four separate pages and was the kind of mistake a reader could act on and be harmed by — a widely repeated shortcut that is true in a narrow case and misleading in most. Another described a cited authority as supporting a position when it had in fact decided the opposite. A third stated a deadline rule that applies to one category of matter as though it applied to a different one.

Every one of those was found the same way: by pulling the actual source and reading it, rather than asking whether the earlier draft was right. Asking a model to check its own work tends to produce agreement. Comparing its output against something external produces corrections.

That is the diagnosis. The fix follows from it, and it took me embarrassingly long to state it plainly: make opening the source a tool call, not a resolution. Instruct the model to fetch and quote the primary text before it asserts anything about that text, and to say explicitly when it could not reach the source. A resolution — "I'll be careful about citations" — fails on the day you are tired or in a hurry, which is the same day the error ships. A step the model has to execute leaves a quote in the transcript that you or anyone else can check against the original. It converts a discipline problem into an artifact problem, and artifacts are the only kind of problem this article has ever been able to solve.

The same day also produced a small interactive tool for the site — the user enters two dates and gets back which options remain open to them and how long each has left. It replaced a wall of prose that answered the same question badly. Most of the effort went into the branch nobody thinks about: what to show when the answer is that every option has already expired.

What I Got Wrong in My Own Article

This was written in April 2026. The method held up. Several product facts underneath it did not, and an article whose central argument is verify against the primary source does not get to leave stale claims standing because they flatter its own narrative. Everything below was checked on 10 August 2026; if you are reading this much later, check it again rather than trusting me.

I said Claude had no memory between sessions. It does. On paid plans it searches past chats and generates a memory summary automatically, scoped per Project, cited back to the chats it drew from. Incognito writes nothing; free accounts have none.

That wrong claim sat inside this page's FAQ structured data — the machine-readable block that search engines and assistants quote back verbatim. Further down, this same article argues that the worst of four errors I found on another site was the one inside structured data, for exactly that reason. I then shipped the identical class of mistake here and left it live for four months, where it was quoted back as current. That is not a footnote. It is the best evidence in this article for the argument the article is making.

The advice survives intact, because it was never really about the feature: curated memory beats extracted memory for anything you cannot afford to lose. Automatic memory summarises what you happened to say. A context file states what must be true. Only one of those is a specification.

Thirty-odd thousand words about working with AI that never named a model. Not a correction — an omission, and the expensive one. For two years I sent everything to the largest available model, which is the same mistake as running every report against production because it is the server whose name you know. Route by difficulty: the mechanical, high-volume, diff-verifiable work goes to the cheapest tier; the ambiguous, high-consequence work goes to the most capable. It is the delegation rule you already use with people. If these were staff, nobody would need to explain it.

Most of the hard work here was an agent with a terminal, not a chat window — the schema audit, the two-port comparison, the control file that proved a checker worked before its output was trusted. Naming that is not an endorsement; it is the difference between a reader reproducing this and a reader assuming it came from pasting into a text box. It also raises the stakes on everything above: an agent that runs its own tests is far more useful, and is also an agent that can be confidently wrong and have already deployed.

The Honest Limitations

Everything above is real. So is everything below. Anyone selling Claude as a magic co-founder is lying.

Compaction is not lossless

When the context window fills, older parts of the conversation get summarized. That summary drops nuance and edge cases. You will lose things. Plan for it: checkpoint your decisions in external files, restart sessions deliberately, don't rely on Claude to remember what happened ten thousand tokens ago.

As sharpened above, this is three different mechanisms rather than one ambient property — auto-compaction and /compact in Claude Code, an opt-in beta with a configurable threshold on the API, and automatic context management on claude.ai that requires code execution to be enabled. The warning holds for all three. Which one you get depends on where you are working.

Confidently wrong, often enough to matter

Claude will produce answers that sound right and aren't. Citations get fabricated. Working code gets rewritten unnecessarily. The human is the verification layer — always. If you don't have the domain expertise to catch the wrong answers, you cannot use Claude safely for that domain.

An earlier version of this article put a number on that — "roughly 20% of the time." I have removed it, because I never measured it and neither has anyone else quoting you a figure. It was a plausible-sounding number in an article about not trusting plausible-sounding things. The correct statement is that it happens often enough that verification has to be a step in your process rather than something you do when you feel uneasy.

A concrete version of this: across a single reference project, four separate factual errors survived multiple review passes because each one read as authoritative. The one that mattered most had been repeated across four pages. None of them were caught by re-reading the text or by asking whether it was correct. All four were caught by opening the primary source and comparing. Plausibility is not a signal you can use — the failure mode is specifically that wrong answers sound exactly like right ones.

Instructions get ignored in long sessions

"Don't change X" gets violated. "Use the function we wrote earlier" gets ignored. Re-state critical constraints in every meaningful turn. Treat the assistant as memoryless even when it isn't.

It will bridge a gap rather than report one — unless you say otherwise

This is the limitation with the cheapest fix in the whole article, and I left it out of the original entirely. A model's default behaviour is to produce something. Absent explicit permission to return "I don't know" or "I could not verify this," it will construct the most plausible available answer and hand it to you in the same confident register as everything else — which is exactly the failure mode described two sections up. Put one line in the brief stating that an admitted gap is an acceptable, expected deliverable. You will get gaps back instead of inventions, and a gap tells you precisely where to go and look.

Memory is real now — and still not your system of record (corrected)

This section used to read: "Default chat has no cross-session memory. What feels like continuity is you re-establishing context every time." That is no longer true, and it is corrected rather than deleted — the full correction and its sources are above. On paid plans Claude searches past chats and generates a memory summary automatically, scoped per Project, with citations back to the chats it drew from.

The limitation that remains is narrower and more useful than the one I originally wrote. Automatically generated memory is an extraction — a summary of what you happened to say across past conversations. It is not a specification of what must hold. For anything load-bearing, keep authoring the context deliberately, because the failure mode of extracted memory is that you find out what it kept at the moment it matters. Incognito chats write nothing; free accounts have no memory at all. Design for what you control.

From Prompting to System Design

This is the actual leap, and it's the part most articles miss. Stage 1 thinking is "how do I write a better prompt." Stage 2 thinking is "how do I build a system around the model." Power users live in Stage 2.

Don't:

• Write giant kitchen-sink prompts
• Run long messy chat threads until compaction breaks them
• Trust the model to remember what happened last week
• Skip verification because the answer "sounds right"

Do:

• Break work into discrete phases with checkpoints
• Externalize memory: docs, files, system prompts, MCP tools
• Restart sessions with clean, curated context
• Use real tools (file I/O, APIs, databases) — not just chat
• Verify every claim against reality before shipping

Claude vs ChatGPT: When to Use Each

People keep asking me "Claude vs ChatGPT — which one should I use?" The honest answer is both, for different things. They're not interchangeable. After running serious work through both daily, here's the split I actually use:

Use Claude when:

• You need long, structured reasoning. Long-form writing, multi-file code refactors, legal drafting, anything that has to hold a coherent thread over thousands of words. Claude's long-context behavior is its strongest feature.
• You're co-authoring code or text. Claude tends to follow precise editing instructions more reliably than ChatGPT in my experience — it rewrites less aggressively when you tell it not to.
• You need a careful, conservative voice. For legal filings and technical writing, Claude is less likely to over-claim or sprinkle in marketing fluff.
• You're using tool-calling / agents. Claude's tool-use API and Anthropic's agent SDK are well-designed for production agent workflows.

Use ChatGPT when:

• You need fast, breadth-first ideation. Brainstorming, naming, quick research summaries — ChatGPT is faster to first draft and willing to free-associate.
• You need images generated. Corrected August 2026 — this bullet used to read "image generation, voice, or DALL-E inline" and claim general multi-modal parity favoured OpenAI. That was too broad. Every current Claude model takes image input and has vision, Claude reads PDFs, and voice mode runs in the Claude mobile, desktop and web apps. What Claude does not do is generate raster images natively — it builds SVG, charts and code-based artifacts instead, or calls an image model through MCP. If you want a photograph produced from a prompt, that is the real dividing line, and it is narrower than the one I originally drew.
• You need niche plugin integrations. The ChatGPT plugin/GPT ecosystem is broader for end-user automations.

Worth noting that the more interesting routing question is not Claude-versus-ChatGPT at all — it is which Claude. Routing across tiers inside one provider is cheaper and higher-leverage than routing across providers, and I spent two years not doing it.

My personal split is roughly 80/20 Claude/ChatGPT for production work and roughly 50/50 for exploration. Both have their place. Anyone telling you "X is better than Y, period" is selling you something. The official documentation is also worth reading directly — most people skip it, and most "Claude tips" articles you see are downstream of it. It lives at platform.claude.com/docs for the API and code.claude.com/docs for Claude Code; the docs.anthropic.com link that used to sit in this paragraph now redirects.

Common Mistakes That Break Claude

If your Claude session feels like it's going nowhere, check this list. Nine times out of ten one of these is the cause:

• Prompting in summary form. "Help me fix my login bug." Wrong. Paste the actual error stack, the actual code, the actual reproduction steps. Real artifacts only.
• Defining "done" in the middle of a session. If you don't know what success looks like before you start, the model can't help you converge on it.
• Letting compaction happen silently. Long sessions hit the context limit, older history gets summarized, and that summary loses your earlier constraints. Restart deliberately. Don't drift. And know which compaction your surface actually performs — it differs between Claude Code, the API and claude.ai.
• Trusting citations without verifying. Claude will fabricate case law, library names, function signatures, and config flags. Verify everything against the source — and verify it by opening the source, not by asking whether it was right. Better: make fetching and quoting the source a required step in the task, so the check produces an artifact instead of relying on your diligence.
• Never granting permission to say "I don't know." One line in the brief. Without it you get a plausible bridge over every gap; with it you get the gap, which is the thing you can actually act on.
• Sending everything to the biggest model. Route by difficulty. Mechanical, high-volume, diff-checkable work does not need your most expensive tier, and the ambiguous high-consequence work should never be on your cheapest.
• Skipping the test-against-reality step. "It looked right" is not a test. Run the code. File the draft. Deploy the function. The model lives in word-space. Reality lives in error-space. Bridge it yourself.
• Re-prompting instead of correcting. When Claude gets it wrong, don't say "try again." Say "you got X wrong because Y; the fix is Z." Specific corrections converge in one round; vague ones loop forever.
• Asking it to remember things it can't. Default chat has no cross-session memory. Re-establish context every time. Or use a project file / system prompt to externalize it.

Claude Workflow Template (Copy/Paste)

Here's the literal template I paste at the top of any new serious Claude session. Steal it. Modify it. The point isn't the wording — it's that you've forced yourself to answer every question in it before you start prompting.

# Session brief

## Outcome (definition of done)
- [What artifact will exist when this session is over?]
- [What test will it pass?]
- [Where will it be deployed/filed/shipped?]

## Constraints (hard rules)
- [Language / framework / version]
- [Things you must NOT change]
- [Style / tone / format requirements]

## Context (real artifacts only)
- [Paste the actual code / log / document / data — never summaries]

## Example of output that would count as done
- [One worked instance of the thing I want. A real one if I have it,
   a fabricated one of the right shape if I don't. Not a description
   of the format — the format itself.]

## Prior failures (so we don't repeat them)
- [What did the last attempt get wrong?]
- [What was the precise reason?]

## Verification plan
- [How will I test this output before shipping?]
- [What command / step proves it works?]
- [Where a claim rests on an external source: fetch and quote that
   source before asserting anything about it.]
- ["I could not verify this" is an acceptable and expected answer.
   Report gaps; do not bridge them.]

That's it. Six sections. If you can't fill all six in before you start prompting, you're not ready to prompt — go figure out the missing piece first. I can't overstate how much faster work moves once you internalize this.

The example section was added in August 2026 and it was the biggest omission in the original. Few-shot prompting is one of the highest-yield techniques available and my template had no slot for it — five sections describing what I wanted and not one instance of it. A single worked example pins format, length, tone and level of detail simultaneously and does it better than any quantity of adjectives. The two additions to the verification section are the other half of the four-errors lesson: make source-checking a step the model performs rather than a standard you hold, and say out loud that reporting a gap beats inventing a bridge.

Frequently Asked Questions

What is Claude AI used for?

Claude is used for long-form writing, code generation and refactoring, structured reasoning over long documents, legal and technical drafting, data analysis, and as the LLM behind agent / tool-use workflows. Its strength is holding coherent context over many thousands of tokens, which makes it well-suited for production engineering work and complex documents.

Is Claude better than ChatGPT?

Neither is universally better. Claude tends to win on long-context work, careful editing, conservative tone, and agent and tool-use workflows. ChatGPT tends to win on fast breadth-first ideation, the plugin ecosystem, and native image generation. Don't use "multi-modal" as the dividing line — every current Claude model takes image input and has vision, Claude reads PDFs, and voice mode runs in the Claude apps. Image generation specifically is the real difference. Most serious users keep both open and route work to whichever fits the task. See the comparison section above for the split I use.

How do you write good prompts for Claude?

The best Claude prompts aren't clever — they're specific. State the outcome, paste real artifacts (not summaries), list hard constraints, and include any prior failures so the model doesn't repeat them. Then iterate with precise corrections, not vague "try again" prompts. The Claude workflow template above is exactly this, formalized.

Can Claude replace developers?

No. Claude amplifies developers — it doesn't replace them. Without domain expertise to verify output, catch hallucinations, and define what "done" actually means, you get confident-sounding garbage. The human is the quality gate. The 27% performance gain in this case study only happened because a human knew which patterns mattered and could test the rewrites against a real database.

What's the biggest mistake people make with Claude?

Treating it like a search engine instead of a junior collaborator. They paste a vague question, take the first answer, and walk away. The leverage is in the loop — defining done, drafting, testing against reality, giving precise feedback, and repeating until production-ready. Skip the loop and you're just chatting with an autocomplete.

Does Claude have memory between sessions?

Yes, on paid plans — this answer was corrected in August 2026. Claude can search and reference your past chats, and can generate a memory summary from your chat history automatically, carrying forward details such as your role, your preferences and your ongoing project context. Memory is scoped separately for each Project, references are cited back to the original chats so you can inspect and delete what it drew from, and there is an experimental import and export for moving memory between Claude and other assistants. Incognito chats write nothing to memory. Free accounts do not have it. Earlier versions of this page said default chat had no persistent cross-session memory; that was true when written and is no longer true, and it is corrected here rather than quietly deleted.

The workflow advice underneath the wrong fact survives intact: for constraints you cannot afford to lose, deliberately externalized memory — a context file, Project instructions, a skill — still beats an automatically extracted summary, because you choose what persists rather than discovering afterwards what was kept. Use memory for the ambient context you would otherwise re-explain; author the hard constraints yourself.

Should I use Claude Code or the Claude chat app?

Use the chat app for thinking, drafting and reasoning over documents. Use Claude Code when the work involves reading and writing files, running commands and verifying its own output — audits, refactors, migrations, anything where the test-against-reality step can be automated. Cowork is for handing off a multi-step task and reviewing finished work, and Claude for Microsoft 365 puts the same capability inside Excel, PowerPoint and Word, with Outlook in beta. The iteration loop is identical on all of them; the surface only changes who executes the verification step.

Which Claude model should I use?

Route by difficulty rather than defaulting to the largest. Haiku is the fastest and cheapest and suits high-volume mechanical work that is easy to check. Sonnet is the best balance of speed and intelligence and handles most day-to-day work. Opus is for complex agentic coding and enterprise work where a subtle error is expensive. Fable is the top tier, aimed at long-running autonomous agents. Routing across tiers within one provider is usually cheaper and higher-leverage than routing across providers.

What are Agent Skills, and do I need them?

A skill is a folder built around a SKILL.md file — instructions plus optional scripts and reference material — that loads on demand when the task matches, so long reference material costs nothing until it is needed. Personal skills live at ~/.claude/skills/<name>/SKILL.md and apply across all your projects; per-project skills live at .claude/skills/<name>/SKILL.md and can be checked into the repository. On claude.ai you upload a .zip of the skill folder under Customize → Skills. You need them once you notice you are pasting the same instructions repeatedly — a skill is that paste, automated, firing when relevant rather than when you remember. The format is an open specification other vendors' agents also read, so it is not a lock-in decision, but custom skills do not sync between surfaces.

What I'd Tell Someone Starting Today

You're the expert. Claude amplifies domain knowledge. If you don't have the knowledge, you get confident-sounding garbage. The human is the quality gate.

Specificity compounds. One precise correction saves five rounds of guessing. Invest the time to describe exactly what's wrong.

Ship real things. The gap between "playing with AI" and "using AI" is whether something goes into production. File the motion. Deploy the script. Push the site live.

Side projects matter. Work done outside the day job sharpens the day job — log analysis, writing, and verification discipline all cross-pollinate.

AI levels the playing field — up to a point. Someone with no legal training produced filings a thirty-year attorney had to brief substantively rather than dispose of on the pleadings. That wasn't possible five years ago. The court still granted the dismissal. Access to the argument is not the same as winning it, and the gap between those two things is where the honest version of this whole article lives.

Corrections Record

Corrections on this page are marked where they appear rather than quietly edited. This one is kept here because the section it originally belonged to has since been removed, and deleting a correction along with its subject is how a record stops being a record.

Sources

Every product claim added or corrected in the August 2026 revision, with the page it came from. All checked 10 August 2026. An article that tells you to open the primary source owes you the primary sources — and if you are reading this a year from now, the honest instruction is to check them again rather than to trust this list.

• Memory: Use Claude's chat search and memory to build on previous context — the two controls, per-Project memory spaces, citations back to source chats, import/export, incognito exclusion, and per-plan availability.
• Compaction on the API: Compaction — opt-in beta, configurable trigger threshold, supported models.
• Context management on claude.ai: How do usage and length limits work? — automatic summarization near the limit, and the code-execution requirement for it.
• Models and tiers: Models overview — the tier descriptions quoted above, plus context windows and per-token pricing.
• Skills in Claude Code: Extend Claude with skills — the on-disk paths for personal, project and plugin skills.
• Skills on claude.ai: Use skills in Claude — the .zip upload flow and the no-sync-across-surfaces caveat.
• The Agent Skills format: the open specification, with reference material at github.com/anthropics/skills.
• Surfaces: Cowork · Claude for Microsoft 365.
• Documentation hosts: platform.claude.com/docs and code.claude.com/docs. Both docs.anthropic.com and docs.claude.com redirect to the former.