Working with Artifacts

An Artifact is content Claude generates that is substantial and self-contained enough to deserve its own space: a specification, a schedule, a checklist, a report draft, an SVG diagram, a block of code, or a small working web page - a calculator, a checklist app - that actually runs. Instead of appearing inline and scrolling away as the conversation continues, it opens in a panel beside the chat, where you can see it whole, and it updates in place as you refine it rather than being re-printed over and over down the thread.

That placement is not cosmetic; it changes how you work. In a long chat, a table you generated ten messages ago is buried under everything since, and asking for a change gives you a fresh copy lower down, so you lose track of which version is current. An Artifact stays put and gets revised in place - there is one living document, always showing the latest state, with the chat beside it as the control panel. You direct in the chat ("add a column for fire rating," "make the tone more formal," "sort by room"); the Artifact updates. It is the direct-draft-judge-refine loop from Lesson 0.1, given a proper workspace: you can actually see what you are judging.

The kinds of things worth making an Artifact are exactly the deliverables of practice. A material or FF&E specification you will edit and issue. A door, window or finishes schedule as a clean table. A site-visit or QA checklist you reuse. A report or proposal draft you shape section by section. A diagram - an adjacency sketch, a simple flow. And, covered fully in Module 8.4, a small working tool - a rough area-and-cost calculator, a checklist app - that Claude builds as a runnable web page you can use and share. In every case the value is the same: the output is something you develop and keep, not a one-line answer you read and lose.

There is a quieter benefit too: an Artifact separates the thing from the talk about the thing. When the deliverable lives in its own panel, the chat is free to be messy - your half-formed instructions, your changes of mind, Claude's explanations - without cluttering the document itself. You get a clean output and a full record of how you got there, side by side. That is genuinely useful when you come back a week later, or when a colleague asks why the schedule reads the way it does: the reasoning is right there in the conversation, and the deliverable stayed uncluttered by it.

Not everything should be an Artifact, and forcing it is just friction. The honest test is whether the output is a deliverable you will develop, reuse or share, or a quick answer you just need to read. Reach for an Artifact when several of these are true: the output is long or structured (a table, a multi-section document); you will iterate on it repeatedly; you want to copy it out clean into your own tools; you will hand it to a colleague or client; or it is a small tool that needs to actually run. Stay in plain chat when you are asking a quick question, thinking out loud, exploring options you have not committed to, or doing anything where a standalone document would just be ceremony.

Examples make the line clear. "What's a sensible spec structure for engineered flooring?" is a chat question - you want to read the answer and think. "Now write the full spec as a document I can edit and issue" is an Artifact - it is a deliverable. "Which of these three finishes handles humidity best?" is chat. "Build me a reusable finishes schedule for the whole apartment" is an Artifact. Often you move naturally from one to the other in the same conversation: you explore in chat, then say "turn that into an artifact I can work with" once the shape is settled. That progression - think in chat, build in an Artifact - is the everyday rhythm.

Two honest caveats. First, an Artifact is a great container but the content still obeys every limit in this course: a spec Claude drafts as a beautiful Artifact can still cite a standard wrongly or invent a figure, so you check it exactly as hard as if it had come as plain text - the polished panel can lull you into trusting it more, which is a trap. Second, availability and the exact feel of Artifacts depend on your plan and evolve over time, and the runnable-tool kind is a lightweight prototype, not production software. Use Artifacts for what they are - a superb way to build and iterate on real deliverables - without mistaking presentation for verification.

The skill with Artifacts is iterating without losing ground. Because the document persists and updates in place, you refine it by telling Claude specific, targeted changes in the chat, and it edits the existing Artifact rather than generating a new one from scratch. "Add a column for lead time." "Change all the timber to a warmer species and update the finish notes." "The client cut the budget - flag anything now over 12 lakh and suggest a cheaper swap in a new column." Each instruction lands on the living document, so it grows and sharpens instead of fragmenting into a dozen near-duplicate tables scattered down the chat.

A few habits keep this clean. Make one substantive change per instruction when the Artifact is close to right - if you ask for five unrelated edits at once and dislike one, you have to untangle them. Be specific about where - "in the finishes schedule, in the flooring row" - so Claude edits the right part rather than rewriting the whole thing. If a revision goes wrong, you can ask Claude to revert the last change or simply restate what you wanted; and if you want to try a bolder direction without risking the good version, ask for a fresh Artifact so you can compare. When you are happy, you take ownership: copy the content into your own document or tool, because the Artifact is a drafting workspace, not your document-control system - your issued spec lives in your studio's files, under your version control, with your name on it.

This is where the loop pays off most visibly. In plain chat, iterating on a long table is painful; in an Artifact, you watch a real deliverable converge over a handful of turns - each correction visible, the latest state always in front of you. It is the closest Claude gets to sitting beside you at the drawing board, redrafting the schedule as you call out changes, while you stay the one deciding what is right.

Once an Artifact is good, you can share it. Depending on your plan, Claude lets you share an Artifact - especially the runnable-tool kind - by a link, so a colleague or client can view or use it without your having to paste screenshots or rebuild it elsewhere. That makes small internal tools genuinely useful: a quick area-and-cost estimator you built in ten minutes can be handed to the whole team by a link. Treat shared Artifacts with the same care as any output - check the content first, and remember confidentiality (do not share a client's brief or data more widely than intended, and mind your plan's data settings).

Here is the everyday flow end to end. You are doing a finishes schedule for a flat. You start in chat: "what columns should a finishes schedule have for a residential interior?" You read, adjust, then commit: "good - now build it as an artifact: a finishes schedule for a 3BHK, one row per room-surface, columns for material, finish, colour reference, supplier-to-confirm, and a notes column. Metric. Do not invent product names or prices - leave those for me." The Artifact appears. You iterate: "add the balconies," "split the living room into floor, walls, ceiling," "add a lead-time column." It converges. You skim every row with your professional eye - catching the one place it guessed a finish you had not specified - copy it into your studio template, and issue it from there. Ten minutes of directing replaced an hour of table-building, and you never once let un-owned output leave the building. That is Artifacts working as intended: fast, structured, iterative, and always under your judgement.