An evidenced position on the tools
You will be asked what you think of v0, Claude Code, Cursor and Figma Make, and “I have not tried it” is a disqualifying answer for the person hired to set the standard — how to build a position from your own timed runs rather than from vendor claims or benchmarks nobody can reproduce.
The question arrives casually and it is not casual. Somebody at Vista asks what you make of v0, or whether Cursor is worth standardising on, or why the design team should not just use Figma Make. You are being hired to set the standard for how ninety-plus portfolio companies prototype, and there are exactly two disqualifying answers. The first is I have not tried it. The second is worse, because it sounds better: a fluent summary of the vendor’s own marketing, delivered as though it were experience.
The timed runs are what separate you from both. A position built from six afternoons is traceable, specific and survives follow-up questions. A position built from product pages collapses on the first “when?”
There is no benchmark waiting for you
The natural move is to go looking for the comparison somebody has already run. On 5 September 2026 this course opened v0’s documentation, Anthropic’s Claude Code product page, Cursor’s homepage and its docs pricing page, Figma Make’s marketing page and Figma’s help-centre article on local codebases. None of those pages carried a productivity or benchmark number with a stated methodology behind it. That is an absence claim, so here is its scope: it covers those pages on that date, not the entire web and not every page each vendor publishes.
What those pages do carry is adjectives and customer testimonials — quantified savings with no described method, and phrases like production-ready doing the work a measurement would otherwise do. This course repeats none of those numbers, hedged or otherwise, and neither should you. Every one of these pages is a vendor describing what it sells.
So the evidence has to be yours. That is not a workaround; it is the only kind of evidence that answers the question actually being asked, which is never “which tool is best” but which tool would you reach for at eleven in the morning with a cold domain and a demo at four.
The four, as of 5 September 2026
Facts decay faster in this course than anywhere else in the academy, so each of these carries its fetch date. If a live page disagrees with what follows, the page is right and this lesson is stale.
v0
Vercel, documenting its own product. “an AI agent that helps anyone create real code and full-stack apps and agents”, emitting React, Next.js, Tailwind and shadcn/ui — which is to say, the stack your kit already sits on. It documents a GitHub import that builds against an existing repository on a working branch, so the loop back to real code is a documented feature rather than a copy-paste. Note that v0.dev now redirects to v0.app and the docs have moved off Vercel’s docs domain; a stale bookmark is the first sign your opinion is a year old.
Claude Code
Anthropic, documenting its own product. “Work with Claude directly in your codebase… from your terminal, IDE, Slack, web, and more”. The framing is the differentiator: it edits an existing repository in place rather than producing a standalone artifact you then have to land. For a three-hour run starting from your own kit, that is the shortest distance between a prompt and a commit — and for a run where you want to see what a generation tool produces from nothing, it is the least informative.
Cursor
Anysphere, documenting its own product. The homepage headline is now “Cursor is your coding agent for building ambitious software”, and the AI-code-editor framing that defined it is gone from the front page. That repositioning is worth noticing on its own: the three tools above are converging on the same description of themselves, which means the differences you care about are not the ones on the marketing pages. Sub-tier prices are hidden behind an interactive control there and published plainly in the docs pricing page. Annual pricing could not be verified from the vendor’s own pages during research — the toggle is there and the amounts never render — so no annual discount figure appears in this course.
Figma Make
Figma, documenting its own product — and the one this course got wrong. Figma’s help centre now documents a local-codebase loop: “You can use Figma Make to ship the UI changes you want directly into your team’s real codebase”, by connecting a local repository or cloning one from GitHub. The article describes support for GitHub and GitHub Enterprise Cloud, with partial GitLab and Bitbucket support over SSH, and pushing a branch and opening a pull request without leaving Figma.
Read the constraints as carefully as the capability. It is a closed beta, it requires the Figma Beta desktop app and is Mac only, access is gated behind a waitlist, and pull request creation is GitHub only for the duration of the beta. Meanwhile Figma’s own Make marketing page still presents the local-codebase feature as coming soon. One vendor, two live pages, opposite tenses, same day.
This course asserted the opposite two days ago
Until this lesson was written, this course’s source list said that no GitHub integration or existing-codebase import was documented on any Figma page, and called the missing loop the sharpest contrast with v0 and Claude Code. That was wrong. The help-centre article documenting it was live, and contemporaneous reporting dates the beta’s announcement to late May 2026 — months before this course looked.
The correct version is narrower and duller: the contrast has narrowed but not closed. v0 and Claude Code’s repository integrations are generally available; Figma’s is closed beta, platform restricted, and waitlist gated. If you are reading this months later, check whether it has left beta before repeating any of it.
The reason this is in the lesson rather than quietly fixed is that it is the failure mode of every tool opinion. Nothing about the earlier claim was careless when it was made — it was a fetch, on a date, that missed a page. The only defence is the fetch date next to the claim, which is what lets a wrong statement be identified as stale rather than argued about.
What your six runs can and cannot establish
Be careful here, because it is easy to walk out of this course with a stronger claim than the log supports. Each run uses a different domain by design, and if the tool also varies, both variables move at once. Six runs cannot isolate the tool, and calling them a comparison would be the same overclaiming this course refuses from vendors.
What they can produce is worth more in the room anyway:
- Traceable claims. “On a lease-abstraction run in August, v0 got me a working surface in forty minutes and I dropped out of it when the mock protocol needed hand-editing.” That is a sentence nobody can argue with, because it is a report of an event.
- Named handoff points. The tool question in practice is never which one, it is where you stop using each. The log’s handoff field is the most valuable thing in it for this purpose.
- Failure modes you have actually hit. Every one of these tools fails somewhere. Having hit it yourself is the entire difference between a position and a preference.
One discipline makes those claims cleaner: hold the tool fixed for a whole run rather than switching when something gets annoying, and record the moment you wanted to switch. That moment is the finding.
The sentence that carries a position
Draft each claim to this shape, and delete anything that cannot fill in the third slot.
[tool] is strong at [specific job] and weak at [specific job],
which I know because [run, date, domain, what happened].
Falls back to a vendor page only for facts about the product itself,
with the date it was fetched:
[tool] documents [capability] as of [fetch date] — I have not run it.The second form is honest and perfectly respectable. “Figma documents a local-codebase beta as of early September; I have not been through the waitlist” is a good answer. “Figma Make ships to your repo now” is not, and the difference is one clause.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
You are asked, on the spot, which of the four you would standardise on for portfolio companies. You have run three of them once each. What do you say?
Check your answer
You say what you have and what it supports. Three runs, named domains, named dates, what each tool did well and the point at which you left it — then, explicitly, that three runs with the domain changing each time cannot rank tools, so you are describing behaviour rather than declaring a winner.
Then answer the question they actually asked, which is about standardising. That decision is not won on speed. It is won on which tool leaves a repository the receiving team can keep, which is a property you have observed directly in every run you did. Saying the evidence stops short of a ranking, and answering anyway, reads as judgment. Producing a ranking three runs cannot support reads as marketing.
Hands on
Draft the position
Done when: A tools section in PRACTICE-LOG.md holds a short position on each of the four, where every claim is tagged either with a run (date, domain, what happened) or with a vendor page and its fetch date — and any claim that is neither has been deleted.
- Write one paragraph per tool: what it is strong at for this specific job, what it is weak at, and where you would hand off. Keep each under a hundred and fifty words. Length here reads as padding.
- Tag every sentence with its source in brackets: a run, or a vendor page plus fetch date. Do this literally, in the file, even though it looks ugly. The ugliness is the audit.
- Delete every sentence that ends up untagged. Expect this to hurt and expect it to remove the most confident sentences you wrote.
- For any tool you have not run, write the honest one-liner: what its own documentation claims, as of when, and that you have not run it. Then put a run against it in the plan.
- Re-open the four vendor pages and check the taglines, prices and capabilities in your draft against what is live today. Note any that moved. On this material, something usually has.
- Bring the tagged draft into the chat. I will push hardest on any sentence tagged to a run that does not appear in the log, and on any comparative claim your run design cannot support.
What this does not cover
This lesson treats the log as a source of quotable events. It does not treat it as a dataset, and there is more in six runs than a set of anecdotes about tooling: a pattern about where your hours go, which is the thing the kit was built to change and the thing you are least able to predict about yourself. Reading the log back as data is the last lesson of this course, on reading the practice log back.
It also stops at the four tools named in the mission. Model choice, agent frameworks and orchestration libraries are deliberately out of scope for this whole course — the kit fakes the backend on purpose, and a prototype that takes a position on a framework has stopped being a prototype.
Read this next — primary source
Make in your local codebaseFigma Help Center — fetched 5 September 2026. Figma documenting its own product, and the page describes a closed beta the company is recruiting for.
Read this one because it is the page that made this course wrong. Two days before this lesson was written, the course asserted that Figma Make had no documented path to an existing repository, and this article documents exactly that path: connect or clone a GitHub repo, edit, push a branch, open a pull request. Read the access constraints as carefully as the capability — closed beta, Mac-only, waitlist, pull requests on GitHub only — because the gap between what a page describes and what you can actually run is where most tool opinions go wrong.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.