Loading
Every factual claim in this course traces to something here, grouped by the module it serves. Where a source is a vendor describing its own product, it is marked vendor-self and the lesson says so in prose. No vendor productivity or benchmark claim is repeated anywhere in this course, even hedged — on the pages fetched, all four generation-tool vendors offered testimonials and adjectives rather than measurements, which is itself worth knowing.
Where the hours go, what is allowed into a kit, and what it costs to keep one alive.
WhyThe randomised controlled trial behind the perception-gap argument: 16 developers, 246 tasks on their own mature repos, February–June 2025, using Cursor Pro with Claude 3.5/3.7 Sonnet. Developers forecast 24% faster, measured 19% slower, and after finishing still estimated 20% faster. The write-up’s most valuable section is the explicit list of claims the result does not support — including that AI does not speed up most developers, and noting the finding is consistent with greenfield work seeing substantial speedup. Primary source for the opening lesson; also reused in the read-back lesson (practising against the clock) strictly as an analogy the course draws, not as new evidence for that module. Do not cite the 19% without the update below.
WhyThe paper behind the blog post. Source for the exact before/after forecast numbers and for the note that the result contradicts predictions from economics experts (39% shorter) and ML experts (38% shorter). The authors concede that experimental artifacts cannot be entirely ruled out.
WhyMETR walking back the strength of their own headline result, which is why the lesson does not lean on the effect size. Supplies the original confidence interval retroactively (+2% to +39%, barely excluding zero) and reports a larger follow-up — 57 developers, 143 repositories, 800+ tasks — whose intervals straddle zero in both cohorts. Their stated cause is selection bias: 30–50% of developers declined to submit tasks they did not want to attempt without AI. Anyone citing the 19% as settled is citing a number its authors have qualified.
WhyAn independent critique published days after the study, raising the narrow participant pool, the exclusion of boilerplate tasks as unrepresentative, self-selection of tasks, and time-to-completion as an incomplete productivity proxy. Notable because the task-selection objection was confirmed by METR themselves seven months later — a useful worked example of a methodology criticism that turned out to be the right one.
WhySurvey of nearly 5,000 technology professionals; still the most recent edition. Vendor-adjacent: Google Cloud publishes DORA and sells AI coding tools, so this is research about its own market. Used for the belief/measurement gap at industry scale. The freely readable pages give the direction of the throughput and instability relationships but no effect sizes, so no percentage should be attached to either.
WhyVendor-self. Source for the adoption figures the lesson quotes: 90% of respondents use AI at work, more than 80% believe it has increased their productivity, and 30% report little or no trust in AI-generated code. That last figure sitting next to the second is the whole point.
WhyStates the 2025 finding directly: higher AI adoption is associated with an increase in both delivery throughput and delivery instability. The throughput half reverses DORA’s own 2024 finding; the instability half persists across both years. DORA’s framing is that AI amplifies existing organisational strengths and weaknesses.
WhySource for “duplication is far cheaper than the wrong abstraction,” and more importantly for the mechanism: a step-by-step account of a good abstraction rotting through a sequence of individually reasonable parameter additions. Primary source for the inclusion-test lesson, because a starter kit is that mechanism with the feedback loop cut.
WhyVendor-self. Source for “This is not a component library. It is how you build your component library,” and for the stated rationale that installing a library leads to wrapping components and writing style workarounds. The lesson uses it as the clearest published statement of the copy-in-rather-than-depend-on posture, while naming the cost the vendor does not emphasise: owned code receives no upstream fixes.
WhyVendor-self. Current commands, including the migrate subcommands that exist because owned copies drift. Cited in the kit manifest as evidence that the copy-in posture has a maintenance bill attached rather than as a criticism of it. Note the package is shadcn, not shadcn-ui, and init now takes a framework via -t.
WhyVendor-self, but purely mechanical. The load-bearing facts for the whole course: a repository created from a template starts with a single commit, and branches created from a template have unrelated histories, so you cannot create pull requests or merge between them. That is why a kit mistake propagates permanently, and why the template is never exercised by the prototypes generated from it.
WhyDefines dependency freshness as the difference between the version in use and the version the system would ideally use. Reports systems with outdated dependencies as four times as likely to have security issues — a correlation across 75 Java/Maven systems from 30 clients, published by researchers at Software Improvement Group, which sells code-quality assessment. Not causal and not npm. The finding that actually transfers is the base rate: 64.1% of dependencies had over 365 days of update lag, and only 16.7% had none. Primary source for the maintenance-tax lesson.
WhyThe popular time-based operationalisation of dependency freshness: a single number summing how many years behind current your dependencies are. Worth knowing that the ICSE paper above considered a time-based measure and rejected it, because it penalises a dependency whose maintainers simply went quiet — so libyear is inspired by that work rather than endorsed by it. Use it as a prompt to look, never as a score.
WhySource for the claim that semantic versioning does not protect a drifting kit: around 12% of dependent packages and 14% of their releases were impacted by a breaking change during non-major updates, and 44% of manifesting breaking changes were introduced in minor and patch releases. A “95% of breaking changes are in non-major releases” figure circulates online and is not supported by this paper — do not use it.
WhyThe npm-specific counterpart to the Java/Maven freshness study: over 1.4M releases across roughly 120K packages with 8M dependencies. Establishes that packages routinely lag behind the latest release of their dependencies, which is the base-rate claim the maintenance-tax lesson needs on the ecosystem the kit actually lives in.
WhyVendor-self, and the most concrete evidence in the course of what one major version costs a kit: middleware renamed to proxy, synchronous params/cookies/headers removed, next lint removed, Turbopack default with a custom webpack config now failing the build, revalidateTag requiring a second argument, runtime config removed, AMP removed. Page metadata read Next.js 16.3.4, last updated 25 August 2026. A vendor has no incentive to overstate how much its own upgrade breaks, so the bias here runs toward understatement.
WhyVendor-self. Current setup is a PostCSS plugin plus @import "tailwindcss" — no config file, no init command, no @tailwind base/components/utilities directives. Docs stamped v4.3 when fetched. Any kit or tutorial snippet showing those three things is teaching v3 and will silently not work.
WhyVendor-self. Confirms --example accepts an arbitrary GitHub URL, which is the one-line clone path for a Next-based kit. Also documents --disable-git and --agents-md (on by default, emitting AGENTS.md and CLAUDE.md), both worth a decision in the manifest rather than an accident.
WhyThe framework-agnostic alternative clone path: downloads the latest commit as a tarball with no .git folder left behind, with caching and subdirectory support. Actively maintained — the npm registry showed 3.9.0 published 1 September 2026 when checked. Included because a kit that outgrows Next.js still needs a clone path.
WhyVendor-self, no outcome claim. Automated update PRs configured by a dependabot.yml committed to the repo, with a default cooldown after a release before a PR is opened. Necessary for a kit nobody touches between prototypes, and insufficient — nothing in a bump PR walks the path a new prototype takes from a cold clone.
WhyVendor-self, no outcome claim. The alternative to Dependabot: scheduled update PRs including lock files, shareable config presets, and replacement PRs for deprecated dependencies. Pick one or the other for the kit, not both — two bots opening overlapping PRs is its own maintenance tax.
A mock agent that streams convincingly, so the surface can be built before any graph exists. Almost everything here is a vendor or a project documenting its own tool, which is flagged per entry — and two of these pages contradict each other, which is itself one of the module’s lessons.
WhyVendor-self: Vercel writes the SDK, publishes this page, and sells the platform its examples deploy to. Primary source for the lesson on a graph that does not exist yet. It enumerates the stream parts a frontend consumes — start/finish, start-step/finish-step, text-start/text-delta/text-end, reasoning-*, tool-input-start/delta/available, tool-output-available/denied, tool-approval-request/response, error, abort, and the [DONE] terminator — which is the entire contract a mock has to honour. Also the source for the v7 statement that the data stream is carried over Server-Sent Events for “improved standardization, keep-alive through ping, reconnect capabilities, and better cache handling.”
WhyVendor-self. The primitives a mock imitates — generateText, streamText, useChat, useObject — and the page carrying the current major. The ai package was at 7.0.93 on 5 September 2026, three days after this course recorded 7.0.91. The version churn is not incidental here: it is quoted in the fake-backend module for the same reason the maintenance-tax lesson quotes libyears, as the normal metabolic rate of this stack.
WhyVendor-self. The tool-call lifecycle both the latency lesson and the trace-and-gate lesson lean on: tool-input-start through tool-input-available, then tool-output-available or tool-output-denied, with the input-delta callback firing only in streaming contexts. Also the per-tool toolApproval status values — not-applicable, approved, denied, user-approval — and the field shapes of tool-approval-request (approvalId, toolCall, reason, isAutomatic) and tool-approval-response (approvalId, approved, optional reason).
WhyVendor-self, though a vendor has no incentive to overstate how much its own upgrade breaks. Primary source for the lesson on wiring the trace and the gate once. States that the needsApproval property on tool() and dynamicTool() is deprecated for generateText, streamText and ToolLoopAgent, and that approval moves to a toolApproval setting on the call. Worth reading as a document rather than a lookup: it is the fastest way to date any AI SDK example you find online.
WhyVendor-self, and stale as of the fetch date: it demonstrates needsApproval set directly on the tool definition, the shape the SDK’s own migration guide deprecates. Cited only as the worked example of a vendor disagreeing with itself — copying it verbatim today ships the old API. Do not treat it as the current approval pattern.
WhyThe project documenting itself; open source with no paid product behind the page, so the bias is weaker than a commercial vendor page but still worth naming. Describes MSW as an API mocking library for browser and Node.js that intercepts outgoing requests, observes them, and responds with mocked responses. Load-bearing for the distinction the module insists on: interception happens through the Service Worker API in the browser and through class extension, not module patching, in Node. Registry showed msw 2.15.0 on the fetch date.
WhyPrimary source for the lesson on faking latency and failure honestly. Two overloads — delay(duration?: number) and delay(mode?: “real” | “infinite”) — and the trap underneath them: called with no argument it applies a realistic server response time of roughly 100–400ms, but that implicit delay is deliberately suppressed inside Node test runs so it does not slow the suite. The same handler is therefore slow in a dev server and instant in tests unless a duration or mode is passed explicitly.
WhyThe ReadableStream response-body pattern the latency lesson builds on. The point the lesson takes from it is what the library does not do: delay() waits before one response, so cadence across many chunks is whatever spacing you put between enqueue calls. No API in this stack knows what a plausible token rate looks like, which is correct, because that rate is a design decision about the surface.
WhyThe higher-level sse namespace, positioned by its own docs as abstracting away stream management and message encoding. Offered in the latency lesson as the alternative to hand-assembling event frames — with the caveat that the pacing between messages remains yours either way.
WhyVendor-self. Confirms request interception through page.route(), with routes fulfilled by route.fulfill(), passed through with route.continue(), or killed with route.abort(). Cited alongside the mocking page below for an absence claim stated at exactly the strength it was established: both pages were read and neither documents a delay or latency-injection primitive. That is not proof none exists elsewhere in Playwright’s documentation tree.
WhyVendor-self. The second of the two pages checked for a latency primitive; it documents the same route-interception API and no delay helper. Every delay recipe found during research wrapped route.continue() in a setTimeout promise and came from third-party blog posts, not from Playwright’s own documentation — so the latency lesson treats hand-rolled timing here as a workaround rather than a supported feature.
WhyThe one normative source in this module rather than a vendor describing its own product. Defines “a standard, programming language-agnostic interface description for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code.” Cited in the lesson on when the mock starts lying as the mechanism that turns divergence between a mock and a real service into a diff rather than a discovery.
WhyVendor-self: Stoplight documents and sells API tooling. Describes Prism as “an open-source HTTP mock server that can emulate your API’s behavior as if you already built it,” with mock servers generated from OpenAPI v2/v3 documents and both request and response data validated against the description. Named in the drift lesson as the OpenAPI-shaped answer to mock divergence, and explicitly as something that does not belong inside a three-hour prototype.
WhyThe project documenting itself; the open-source tool has a commercial broker product behind it, so read the positioning accordingly. Source for “a code-first consumer-driven contract testing tool” whose contract “is generated during the execution of the automated consumer tests,” and for the deliberate narrowness the drift lesson borrows: only the parts of the communication actually used by consumers ever get tested.
WhyPrimary source for the lesson on when the mock starts lying, cited as an existing engineering answer to the problem rather than as evidence for the lesson’s own argument. Supplies the verification mechanism: each recorded request “is sent to the provider, and the actual response it generates is compared with the minimal expected response described in the consumer test.” The lesson uses it to name what a prototype cannot have — verification needs a running provider, and the premise of this module is that there is not one yet.
The generation tools, what deliberate practice actually requires, and the retraction that removed the most-cited experimental prop for deadlines from the literature entirely. Every tool page here is a vendor describing what it sells, and the module’s prose says so each time.
WhyPrimary source for the three-hour-rule lesson. The forensic analysis that ended Ariely & Wertenbroch (2002): an effect size of roughly 2.5 standard deviations called implausibly large for the design, 18 of 20 participants in one condition having a “Corrections Twin” exactly ten ID positions away, correlations strongly positive in replication data and near zero in the original, and only 11.7% of estimated minutes falling on round numbers against 85% in the honest replication data. Their conclusion is that the data “were severely tampered with or fabricated.” Cited for its method as much as its finding — it is a worked demonstration of reading a claim rather than counting its citations.
WhyThe retraction of record. Coauthor Klaus Wertenbroch requested retraction on 23 July 2026; Psychological Science retracted the paper in full — both studies — on 2 September 2026, with Wertenbroch quoted saying much or all of the data, and therefore the results, are false. Reported independently by the Duke Chronicle and the Chronicle of Higher Education as well. The three-hour-rule lesson cites this for the retraction date and scope.
WhyA separate finding from the fraud analysis, and the three-hour-rule lesson keeps the two apart deliberately. The replication found that “the results of the paper do not replicate… changes in the deadlines have a negligible effect on the three performance metrics.” It also notes Bisin & Hyndman (2020) found performance worse with deadlines, and Burger et al. (2011) found intermediate targets made performance worse. This is why the course makes no claim that timeboxing improves output — and, equally, no claim that it hurts.
WhyListed so the record is unambiguous, and cited nowhere in this course as support for anything. A paper retracted for fabricated data is not weak evidence or dated evidence; it is not evidence. If you meet it cited approvingly elsewhere — and you will, given how widely it travelled for twenty-four years — this entry is the reason not to repeat it, even hedged as “influential but contested.”
WhyPrimary source for the evidenced-position lesson, and the page that corrected this course. Figma documents connecting a local repository or cloning one from GitHub — GitHub and GitHub Enterprise Cloud, with partial GitLab and Bitbucket support over SSH — then pushing a branch and opening a pull request without leaving Figma. Read the gates as carefully as the capability: closed beta, Mac only via the Figma Beta desktop app, waitlist gated, pull request creation on GitHub only during the beta. This narrows but does not close the contrast with v0 and Claude Code, whose repository integrations are generally available.
WhyCode-backed prototypes that stay visually editable on the canvas. Cited in the evidenced-position lesson for a specific reason beyond the product: on the day it was fetched this page still presented the local-codebase feature as coming soon, while Figma’s own help centre documented it as live in closed beta. One vendor, two live pages, opposite tenses — which is the argument for putting a fetch date next to every tool claim.
Why“an AI agent that helps anyone create real code and full-stack apps and agents,” emitting React, Next.js, Tailwind and shadcn/ui — the stack the kit already sits on. The documented GitHub import builds against an existing repository on a working branch, which is the loop the evidenced-position lesson compares across the four tools. Note that v0.dev redirects to v0.app and the docs have moved off Vercel’s docs domain. Its “production-ready” framing is adjectival with no methodology behind it and is not repeated in the course.
Why“Work with Claude directly in your codebase… from your terminal, IDE, Slack, web, and more.” Cited in the evidenced-position lesson for the framing that distinguishes it: it edits an existing repository in place rather than producing a standalone artifact you then have to land. anthropic.com/claude-code redirects here and the docs live at code.claude.com. The customer testimonials on the page quantify savings with no described method, and none of those numbers appear in the course.
WhyThe headline is now “Cursor is your coding agent for building ambitious software” — the AI-code-editor framing is gone from the front page, which the evidenced-position lesson uses to make a point about three tools converging on the same self-description. Sub-tier prices are hidden behind an interactive control here and published plainly on the docs pricing page. Annual pricing could not be verified on any of Cursor’s own pages — the toggle exists and the amounts never render — so no annual discount figure appears in the course.
WhyPrimary source for the target-selection lesson, used strictly for the four criteria: individualised training designed by a well-qualified teacher, a communicated goal the trainee can internally represent, an activity giving immediate feedback, and repeated revised attempts approaching the goal. It studies neither software nor practice-target selection, so it motivates caring about task design in general and supports no claim about toy versus realistic targets — the lesson says so explicitly. Also carries Ericsson’s own account of why the ten-thousand-hours framing misrepresents his work: Gladwell never used the term, and included activities such as public performance and ordinary work that violate the criteria.
WhyThe ceiling stated alongside every deliberate-practice claim in this module. Across 88 studies and 11,135 participants, deliberate practice explained 26% of performance variance in games, 21% in music, 18% in sports, 4% in education and under 1% in professions. Software development is a profession, so the target-selection lesson uses this as a caution in both directions: pick targets well because a bad one wastes an afternoon, not because target selection is the lever that decides the outcome. The authors note professions is also where measurement is weakest.
Every claim on these pages links to its source. If a source looks wrong or out of date, check the resource list and tell your teaching agent — the course is meant to be corrected.