Internet Menace, Again

v1.4.0: The template library grows to fifty

Mon, 10 Aug 2026 00:00:00 GMT

Nine templates became fifty: payments, auth, email, analytics, deploys, data pipelines, integrations, and a bench of new agents. Every one is a markdown file you copy, fill in, and hand to your agent. Section 9.2 still applies: write the fifty-first and send it back.

v1.3.0: Internet Menace Foundations

Wed, 22 Jul 2026 00:00:00 GMT

The original 2024 curriculum is back, reorganized as sections 0.7 through 0.17. If you finished v1, it's a reunion; if you didn't, it's the 180-day foundation this whole site quietly assumes.

v1.1.0: This is not an AI guide

Tue, 21 Jul 2026 00:00:00 GMT

"AI" is a shelf, not a genre. The new manifesto page is about asking which record is actually playing before you pay for the shelf.

v1.2.0: Stacks: eight opinionated ways to build

Tue, 21 Jul 2026 00:00:00 GMT

Eight opinionated stacks, from a weekend Vercel-and-Supabase startup to causal agent observability with PyRapide. Hand your agent a coherent set of tools instead of letting it improvise one.

Template: Webhook Receiver

Mon, 27 Apr 2026 00:00:00 GMT

A webhook is another company's server calling yours: Stripe telling you a payment cleared, GitHub telling you someone pushed, Shopify telling you an order landed. Your side of the deal is one public URL, and that URL has three enemies. Strangers, because anyone who finds the URL can POST fake events to it, and "anyone can tell my server a payment cleared" is a sentence you should read twice. Duplicates, because every serious webhook provider retries on timeout or error, which means delivering the same event two or three times is normal operation, not a bug. And your own slow code, because if handling the event takes longer than the sender's timeout, it marks the delivery failed and retries, and now your slowness is manufacturing duplicates. The shape that survives all three is the same regardless of provider, and it is worth memorizing: verify the signature on the raw bytes, insert the event ID into a table with a unique constraint, return 200, and do the real work after. Verification keeps strangers out. The unique constraint is your dedupe: the database refuses the second insert, so a retried delivery becomes a no-op without any clever code. Returning 200 fast, before processing, keeps the sender's timeout from ever seeing your slow parts. Every piece of this spec is one of those three moves. The naive version, the one an agent writes if you just say "handle the Stripe webhook," does the work inline and returns 200 at the end. It passes every test you'll think to run, because your tests don't time out and don't retry. Then production delivers a duplicate on a slow night and a customer gets charged twice, or emailed twice, or shipped twice. This is the template other integration templates on this site point at when they say "dedupe before acting." Fill in your provider; the skeleton does not change.

Template: Slack Integration

Mon, 27 Apr 2026 00:00:00 GMT

Slack integrations come in two directions, and mixing them up wastes an afternoon. Outbound: your code posts messages into a channel, which needs an incoming webhook URL and nothing else. Inbound: someone types `/yourcommand` in Slack and your server has to answer, which needs a public endpoint, request verification, and respect for one brutal deadline. Most projects want outbound first. It is ten lines of code and it makes your system feel alive: deploy finished, order came in, backup failed. Start there even if you came for the slash command. The slash command is where the real engineering lives, and it lives in one number: three seconds. Slack sends your endpoint a request when someone runs the command, and if you have not responded in three seconds, the user sees a timeout error, no matter how well your code was doing. The pattern that survives is acknowledge-then-work: reply immediately with "on it," do the slow thing, then deliver the answer through the `response_url` Slack handed you, which stays valid for thirty minutes. Agents reliably write the naive version that does the work inline, and it even works in testing, because your test query was fast. Production queries are not. The other thing agents skip is verifying that requests actually come from Slack. Your slash-command endpoint is a public URL; anyone who finds it can POST to it. Slack signs every request, and checking that signature is the difference between an integration and an open door. The spec below treats verification as a hard requirement, and for the general theory of receiving webhooks safely (dedupe, retries, idempotency), see the webhook-receiver template; this one bakes in the Slack-specific parts.

Template: File Uploads to S3

Mon, 27 Apr 2026 00:00:00 GMT

There are two ways to get a user's file into cloud storage. Route it through your server, which means every 200MB video ties up your server's memory and bandwidth on the way past, and on serverless platforms slams into request-size limits around a few megabytes. Or have the browser upload straight to S3, with your server's only job being to sign a short-lived permission slip first. The second way is the right way, it is what the presigned URL exists for, and it is what this spec builds. The flow is three steps and worth having in your head before the agent writes anything. The browser asks your server "I want to upload a JPEG, 4MB." Your server decides yes or no, and if yes, generates a presigned URL: a link that permits exactly one PUT, to one key it chose, expiring in minutes. The browser PUTs the file to that URL, straight to S3, never touching your server. Then the browser tells your server "done," and the server verifies the object actually landed before recording it. Your AWS credentials never leave the server; the browser only ever holds the temporary slip. What agents get wrong here is not the happy path, which every SDK tutorial covers. It is the defaults around it: buckets left publicly readable, filenames taken from the user and used as keys (which is how `../../etc/passwd` and overwritten files happen), size limits enforced only in JavaScript where anyone with curl can ignore them, and no answer for the user who requests a URL and never finishes the upload. The spec below closes each of those, and the bucket stays private the entire time: downloads are presigned too.

Template: Postgres Schema Starter

Mon, 27 Apr 2026 00:00:00 GMT

Every table you will ever create has to answer the same three questions: how are rows identified, when did things happen to them, and what happens when someone deletes one. Most people answer these three questions differently on every table, on the fly, while thinking about something else. Six months later the users table has integer ids, the orders table has UUIDs, half the tables know when they were updated and half don't, and "deleted" means four different things in four places. None of those decisions was wrong. Making them inconsistently was. This file answers the three questions once, as SQL you can run today, with the reasoning in comments right where each decision sits. That placement is deliberate: your agent reads schema files, and conventions stated where they apply are conventions that survive the tenth table, long after the chat where you explained them has scrolled away. It is data-shape thinking (§5.1) in its most concrete form. The defaults are boring on purpose: UUID keys, timestamps on everything, soft deletes via a nullable timestamp. Boring is what you want load-bearing infrastructure to be. Where a default has a real cost, the comment says so, and the adaptation notes cover the honest cases for deviating. Rename the example table, keep the skeleton, and apply the conventions to every table that follows.

Template: Postgres + pgvector RAG Pipeline

Mon, 27 Apr 2026 00:00:00 GMT

Before you provision a dedicated vector database, look at what you already run. If there is a Postgres in your stack, pgvector turns it into a vector store: your chunks live in a table, joined to real metadata, backed up by the backups you already have, filtered by the SQL you already know. A purpose-built vector store earns its place at scales most projects never reach. Until then, a second database is a second thing that pages you. The part of RAG nobody puts in the demo: retrieval is where these systems die. The generation step gets the attention, but if retrieval hands the model the wrong chunks, the model composes a fluent, confident answer out of the wrong facts, and fluent-but-wrong is worse than no answer because people believe it. This spec spends its effort accordingly. Vector similarity alone misses exact terms: part numbers, function names, people. Keyword search alone misses phrasing it hasn't seen. The pipeline below runs both and fuses the results, because each one covers the other's blind spot, and the blind spots are where your users live. The section your agent will try to skip is the eval, which is precisely why it's in the spec with teeth. Twenty real questions with known-correct sources, run before and after every retrieval change. Without it, every tuning decision is vibes, and "it seems better" is how retrieval quality drifts downward one clever tweak at a time. With it, tuning is a measurement. Twenty questions is one honest afternoon.

Template: Document Ingestion Pipeline

Mon, 27 Apr 2026 00:00:00 GMT

Ingestion is the unglamorous half of every retrieval system, and it is where the real failures start. If a document got mangled on the way in, no amount of clever querying gets the truth back out. The naive version is a script: loop over files, chunk, embed, insert. It works exactly once. Run it again and every chunk exists twice, search returns duplicates, and you paid the embedding bill twice for the privilege. The property that separates a pipeline from a script is idempotency: run it on the same folder five times and the result is identical to running it once. You get there by making the pipeline check before it works. Every source file gets a content hash; unchanged hash means skip, changed hash means the old chunks die and new ones replace them, in one transaction, so no query ever sees half a document. This also gives you the thing scripts never have: a table you can query to ask "what is actually in my index, and when did it get there." The other discipline is treating ingestion as a state machine rather than a loop. Each document moves through discovered, parsed, chunked, embedded, indexed, or lands in failed with an error message attached. When file 412 of 500 is a corrupt PDF, it fails alone and visibly; the other 499 proceed, and the pipeline can resume from wherever it stopped without redoing finished work. A loop that dies at 412 and restarts from zero re-embeds 411 documents to get one file further, and at API prices that habit shows up on your invoice (§4.6).

Template: CSV Import/Export Spec

Mon, 27 Apr 2026 00:00:00 GMT

Every internal tool converges on the same feature request: "can I just upload a spreadsheet?" And every naive implementation of it converges on the same incident: someone uploads 2,000 rows, row 847 has a date typed as "next tuesday", and now either the whole import died with a stack trace nobody can read, or, worse, 846 rows imported and nobody knows which ones. The person doing the upload is not a developer. They have a spreadsheet and a deadline, and the tool's job is to tell them exactly what's wrong in language that names their rows, not your exceptions. The design that survives contact with real spreadsheets has three properties. Validate everything before writing anything: an import is all-checked-then-applied, never check-as-you-go. Default to dry run: the first pass produces a report ("1,994 rows OK, 6 problems, nothing imported yet"), and applying is a separate, deliberate step. And report errors per row, per column, in a file they can open in Excel, fix, and re-upload, because that is the actual workflow: upload, fix six cells, upload again. That loop happening twice is normal. That loop being pleasant is the feature. CSV itself will fight you more than the database will. Excel exports smuggle in a byte-order mark, Windows line endings, commas inside quoted fields, dates in whatever format the machine's region settings felt like, and at least one column renamed by a helpful human. The parsing rules below exist because each one is a support ticket I am saving you from filing. Hand the spec to your agent whole; the boring parts are the load-bearing parts.

Template: Vercel Deployment Spec

Mon, 27 Apr 2026 00:00:00 GMT

Vercel's pitch is that deployment is one button, and the pitch is honest. Connect the repo, push to main, the site is live. That is exactly why it needs a spec: the button works whether or not you have thought about what is behind it, and the failures it enables are quiet ones. The site deploys fine. It just happens to be talking to the wrong database. The thing to internalize is that Vercel gives you three environments: Production, Preview, and Development. Every branch you push gets its own live Preview URL, which is genuinely great, and which also means every pull request is a running copy of your app. If that copy holds your production Stripe key, then every experiment, every half-finished agent branch, every "let me just try something" can charge a real card. Scoping environment variables per environment is not an advanced feature. It is the whole job. Hand this spec to your agent to do the setup and wiring, but set the secret values in the Vercel dashboard yourself. An agent that never saw your production key cannot paste it somewhere it shouldn't. Fill in the brackets, then work the post-deploy checklist personally: the agent verifying its own deployment is the fox auditing the henhouse.

Template: Scheduled Jobs Spec

Mon, 27 Apr 2026 00:00:00 GMT

A cron job is code that runs when nobody is watching, which means it fails when nobody is watching. That is the entire discipline in one sentence. An interactive app that breaks gets a bug report within the hour. A nightly job that breaks gets discovered in six weeks, when someone asks why the digest emails stopped, and by then you're not fixing a bug, you're reconstructing six weeks of missed work. On Vercel, a cron job is just an HTTP route that Vercel promises to call on a schedule, and that shape has two sharp edges. First, the route is a public URL: anyone who finds it can trigger your job, so it authenticates or it doesn't ship. Second, schedulers deliver "at least once," not "exactly once." Retries, overlapping runs, and manual triggers all mean your job will eventually run twice for the same period, and it has to be idempotent: running it twice produces the same result as once. A job that sends invoices needs this property before it sends its first invoice, not after its first double-bill. The spec below covers the Vercel path, the contract every job handler must meet regardless of platform, and the honest line for when serverless cron stops fitting: jobs longer than your platform's timeout, or schedules tighter than a minute, belong on a worker. The dead-man's switch is not optional decoration. "The job stopped running" and "the job ran and failed" are different failures, and only the switch catches the first kind.

Template: GitHub Actions CI Workflow

Mon, 27 Apr 2026 00:00:00 GMT

CI is a machine that runs your checks every time code moves, without being asked and without getting bored. That last part is the point. You will run the tests before merging for about two weeks. Then you'll be busy one afternoon, and the agent will say the tests pass, and you'll take its word for it, and that is the merge that breaks production. The robot does not get busy. It runs everything, every push, forever, and it does not accept "it worked locally" as evidence. This matters double when an agent writes most of your code. Agents produce plausible code quickly, and plausible is exactly the quality that slips past a tired human reviewer. A CI run is a checkpoint the agent cannot charm its way through: the lint either passes or it doesn't, the build either compiles or it doesn't. Green checkmarks on the PR are the difference between "the agent says it's done" and "it's done." The template is a working workflow file plus a short spec around it. The spec matters because the file alone isn't the whole job: a CI that runs but doesn't block merging is a smoke alarm with the battery out. The branch protection step at the end is what gives it teeth.

Template: Docker Compose Local Stack

Mon, 27 Apr 2026 00:00:00 GMT

"Works on my machine" is not a defense, it is a confession. It means your app depends on things that live outside the repo: the Postgres you installed with Homebrew two years ago, the Redis that autostarts on login, the one environment variable you exported in a terminal that has since been closed. Your agent inherits none of that. Neither does your laptop after it dies, and laptops die. Docker Compose fixes this by writing the whole environment down. One file declares your app, its database, and its dependencies, with versions pinned. `docker compose up` builds that world from nothing; `docker compose down` removes it without residue. The database version in the file is the database version, period. When your agent needs to run the app to test its own work, it reads this file instead of guessing what is installed, and its guesses about your environment are the source of half its weirdest failures. The template below is a working compose file for the most common shape: one app, one Postgres, one Redis, wrapped in a short spec telling the agent how to adapt it and which commands do what. The annotations in the YAML are load-bearing. The healthcheck, in particular, is the difference between an app that waits for its database and an app that races it and loses at random, and intermittent startup crashes are miserable to debug precisely because they are intermittent.

Template: Backups and Restore Runbook

Mon, 27 Apr 2026 00:00:00 GMT

Nobody has ever needed a backup. People need restores. A backup is a file you hope contains your data; a restore is the proof. Plenty of businesses have discovered, on the worst day of their year, that they owned three years of nightly backups and zero working restores: the dump was empty, the credentials had rotated, the one person who knew the procedure had left. The backup job ran green every night. Green meant "a file was written," not "your data is safe," and nobody had ever checked which. That is why this template is a runbook and not a script. The script is the easy part, and your agent will write it in five minutes. The runbook is the part that makes it real: what gets backed up, on what schedule, kept how long, stored where, and, as a first-class scheduled step and not a someday, the drill where you restore a backup onto a scratch database and verify the data is actually in it. If the drill isn't on a calendar, it doesn't exist. You will not spontaneously test restores on a quiet Tuesday. Nobody does. Two numbers anchor everything, and you should pick them before any tooling: how much data you can afford to lose (if the answer is "a day," daily backups are fine; if it's "an hour," you need more than dumps), and how long you can afford to be down while restoring. Everything else in the runbook is machinery serving those two numbers. Fill it in with your agent, then put the drill dates on your actual calendar before you close the tab.

Template: Sentry Error Tracking

Mon, 27 Apr 2026 00:00:00 GMT

Right now, your deployed app's errors go nowhere. A user hits a crash, sees a blank screen, closes the tab, and the only record of it is their opinion of you. Error tracking is how production tells you what broke before users bother to, and Sentry is the standard tool for it. The install is genuinely five minutes. The five minutes is also where most people stop, and a stopped-at-install Sentry is nearly worthless. Here's why. Production JavaScript is minified, so without sourcemaps every stack trace reads like `t is not a function at a.js:1:48213`, which tells you a thing broke somewhere in your app, a fact you already had. Without releases, Sentry can't tell you which deploy introduced the error, which is usually the single most valuable clue, because "what did we just ship" is the first question anyway. And without alert rules, errors pile up in a dashboard nobody opens; you find out about the crash from a user email, which is the exact outcome the tool exists to prevent. So this spec treats sourcemaps, releases, and alerts as part of the install, not as advanced options, and it adds the two hygiene items that keep Sentry useful past week one: scrubbing user data you shouldn't be storing, and filtering the noise (browser extensions, bots, ad-blocker fallout) that otherwise trains you to ignore the feed. An alert channel you've learned to ignore is the same as no alert channel, with worse morale.

Template: PostHog Setup

Mon, 27 Apr 2026 00:00:00 GMT

Analytics is the one system where bugs don't throw errors. Wire PostHog wrong and everything looks fine: the dashboard fills with numbers, the charts go up and to the right, and six months later you make a real decision based on data that was double-counted, half-anonymous, or missing every purchase that happened while a tab was closed. Nothing crashed. You just steered with a bent compass. The wiring mistakes are specific and repeatable, which is good news, because it means a spec can prevent them. Single-page apps navigate without full page loads, so pageviews need to be captured on route change or you'll record one view per visit and wonder why your funnel starts at the front door and ends there too. `identify` ties events to a user; call it with your database's user id, not an email, because emails change and when one does, that user's history splits in half. And the events you actually bill decisions on, signups and payments, belong on the server, because ad blockers eat somewhere around a third of client-side events and they do not eat them evenly. One more habit this spec bakes in: every event that gets captured is written down first, in a small table your agent keeps in the repo. Untracked event sprawl is how you end up with `signup`, `sign_up`, and `user_signed_up` all meaning the same thing and no funnel that trusts any of them. The event taxonomy template goes deeper; this spec just refuses to let the sprawl start.

Template: Event Taxonomy

Mon, 27 Apr 2026 00:00:00 GMT

Six months from now you will open your analytics tool to answer one question: where do people drop off before paying? And you will find `signup`, `sign_up`, `Signup Completed`, and `user_registered`, all live, all slightly different, none documented. Which one goes in the funnel? Nobody remembers. The person who added the third one was you, and you don't remember either. The data was collected faithfully the entire time; it just can't be queried into meaning anymore. This happens because event names get invented at the call site, one at a time, in the heat of shipping the feature. Each individual name looked fine. Taxonomy is the boring fix: one naming convention, one tracking plan file in the repo, and one rule that no event ships without a row in the plan. It costs about an hour up front and roughly nothing per event after that. The alternative costs you every funnel you'll ever want to build. This matters double when agents write your code, because an agent asked to "add analytics to this feature" will cheerfully invent event names in whatever style the surrounding file suggests. Give it this plan and the naming rules become constraints it follows instead of decisions it improvises. The template below is the plan file itself: fill in the starter rows, commit it, and point every future analytics task at it.

Template: Transactional Email Set

Mon, 27 Apr 2026 00:00:00 GMT

Every product that has accounts needs exactly three emails before it needs any others: a welcome when someone signs up, a receipt when someone pays, and a reset when someone forgets their password. Ship these three and you can ignore email for months. Skip them and users assume the product is abandoned, accountants chase you for receipts, and locked-out customers simply leave. Transactional email is not marketing email, legally or socially. These messages are triggered by something the user did, they contain information the user needs, and that's the entire justification for sending them. The moment a "quick product update" sneaks into your receipt template you've converted a message people trust into one they filter, and you've done it in the one channel where trust was the whole point. Two of the three have teeth. Receipts must be idempotent: a payment webhook that retries, and they all retry, must not produce a second receipt, because a duplicate receipt reads as a duplicate charge and generates a support ticket every single time. And the reset email is a security surface: it must not confirm whether an account exists, and its token must be single-use, short-lived, and never logged. The spec below hands your agent all of that as requirements, not suggestions.

Template: Contact Form with Resend

Mon, 27 Apr 2026 00:00:00 GMT

The contact form is usually the first real backend a site needs. A `mailto:` link is not one: it hands your address to every scraper that reads your HTML, and on half the phones on earth it opens nothing at all. The grown-up version is small: a form, a serverless function, and an email API. Resend is the API here because the free tier covers any normal contact form many times over and the integration is one POST request. Spam is the part people get backwards. The instinct is a CAPTCHA, which taxes every legitimate visitor to inconvenience bots that increasingly solve them anyway. Start with the cheap tricks instead: a honeypot field that humans never see and bots dutifully fill, and a rate limit so one IP can't submit four hundred times a minute. That combination kills the overwhelming majority of form spam and costs your actual visitors nothing. Escalate only if reality demands it. The one rule you cannot bend: the Resend API key lives in an environment variable on the server. The moment it appears in browser-side code it belongs to the internet, and the internet will use your domain to send things you will have to apologize for. That's §6.4, and this template is where a lot of people meet it for the first time. Hand the spec below to your agent from inside your site's repo.

Template: Supabase Email Auth

Mon, 27 Apr 2026 00:00:00 GMT

Do not build your own auth. Not because you couldn't: because the failure modes are invisible until they're catastrophic, and password storage is a problem the industry already solved and keeps re-solving every time someone's homemade version leaks. Supabase gives you signup, login, email confirmation, and session management on top of Postgres, and your job shrinks to wiring it in without undoing its guarantees. That wiring is where beginners get bitten, in two specific places. First, the confirmation flow: a user signs up, Supabase sends a confirmation email, and the link in it has to land somewhere in your app that completes the handshake. Skip that route and every new user hits a dead end with a valid account they can't use. Second, where you check the session: a login check that lives only in client-side JavaScript is a curtain, not a lock. Anyone can call your API directly, no browser required. The session check has to happen on the server, on every protected route, every time. This spec hands your agent the full circuit: signup, confirm, login, logout, protected routes checked server-side, and a profiles table with row-level security so the database enforces who sees what even if a bug slips through the app layer. Defense at the data layer is not paranoia. It's the layer that holds when the other one doesn't.

Template: Role-Based Access Control

Mon, 27 Apr 2026 00:00:00 GMT

Hiding the admin button is not access control. The button is a suggestion; the API route it calls is the door, and if the door only checks "is logged in" rather than "is allowed", every member of your app is one copied fetch request away from being an admin. This is the single most common security hole in agent-built apps, because the happy path demos perfectly: the admin sees admin things, the viewer doesn't, and nobody in the demo thought to ask the database directly. So this spec enforces roles at the database layer with row-level security. The app checks roles too, for UX and for clean error messages, but the policy that actually holds is the one Postgres evaluates on every query. A bug in your route handler, a forgotten check in a new endpoint, an agent that helpfully adds a query somewhere: RLS catches all of it, because the database doesn't care how the query arrived. Two design decisions in here are load-bearing, so know why they exist. Roles live in their own table, not as a column on profiles, because profiles are user-editable and a user who can edit the row that stores their role will eventually promote themselves. And the role lookup happens through a `security definer` function, because an RLS policy that queries a table which itself has RLS recurses; the function is the standard Postgres escape hatch, and your agent will get this wrong without being told.

Template: Password Reset Flow

Mon, 27 Apr 2026 00:00:00 GMT

Password reset is the back door to every account in your app. An attacker who can't guess a password doesn't need to if the reset flow will hand them the account instead, and reset flows fail in quiet ways that demo perfectly. The form works, the email arrives, the password changes, everyone moves on. Meanwhile the token never expires, works twice, and the "no account with that email" error message is happily confirming to a stranger exactly which of your users exist. Four properties separate a real reset flow from a liability, and this spec treats every one as a hard requirement. Tokens expire, in minutes, because reset emails sit in inboxes for years and an inbox is only as private as its weakest moment. Tokens are single-use, because a link that works twice works for whoever sees it second. The request endpoint answers identically whether the email exists or not, because "we couldn't find that account" is a user-enumeration oracle: it lets anyone test your user list one address at a time. And a successful reset kills every existing session, because the entire reason people reset passwords is the fear that someone else is already inside; a reset that leaves the intruder's session alive is theater. If you're on Supabase or another managed auth provider, most of this is handled and your job is to not break it: the spec marks exactly which parts remain yours. If you're rolling the flow yourself, the token table and handler sketch are in here too. Either way, hand your agent the spec, then run the verification list personally. This is the one flow where "the agent says it works" is not good enough.

Template: Stripe Webhook Handler

Mon, 27 Apr 2026 00:00:00 GMT

Every Stripe integration is secretly a webhook integration. Checkout, subscriptions, refunds, disputes: the browser sees a redirect, but the facts arrive later, server to server, as events. If your handler is sloppy, every feature built on top of it inherits the sloppiness, and billing bugs are the expensive kind. Customers notice them, and they notice in the direction that costs you either money or trust. Three properties make a webhook handler trustworthy, and none of them are optional. It verifies signatures against the raw request body, because an unverified webhook endpoint is a public API that edits your billing table; anyone with curl can call it. It is idempotent, because Stripe delivers at-least-once and will happily send you the same event twice; a handler that isn't idempotent sends two receipts, grants two credits, or double-fulfills an order. And it treats the event as a doorbell, not a database: events can arrive out of order, so on anything that matters you fetch the current object from the Stripe API and write that, instead of trusting a payload that may already be stale. There is a fourth rule that isn't about the handler at all: UI state never substitutes for webhook truth. The success redirect is a hint. The customer's card can be declined on retry, the subscription can lapse, the dispute can land, all without a single click in your app. The webhook is where the database learns the truth, which means it is the only code allowed to write it. This spec builds the handler as shared infrastructure: verify once, dedupe once, then dispatch to small per-event functions. Hand it to your agent before you build the features that depend on it.

Template: Stripe Subscription Billing

Mon, 27 Apr 2026 00:00:00 GMT

Here is how most subscription integrations die. Someone wires up the Checkout button, sees the success page, and updates the database right there on the redirect. It works in the demo. Then month two arrives, a card gets declined, Stripe cancels the subscription, and the app never hears about it because nobody clicked anything. The customer keeps full access, forever, free. That is not a hypothetical: it is the default outcome of trusting the browser to tell you about money. The fix is a rule, and this spec enforces it: the webhook handler is the only code allowed to write billing state. Checkout starts the process, the customer portal lets people cancel and update cards without you building any of that UI, and the webhook is where the database learns what actually happened. Everything else just reads. The other thing this spec bakes in: Stripe's customer portal instead of hand-rolled cancel and upgrade screens. People burn weeks building subscription management UI that Stripe already hosts, keeps compliant, and updates when card networks change the rules. Your job is one redirect. Take the free win. Hand this to your agent with the placeholders filled in. It assumes auth already exists; if it doesn't, build that first, because a subscription without a user to attach it to is just a donation.

Template: Stripe One-Time Checkout

Mon, 27 Apr 2026 00:00:00 GMT

Selling one thing once is the easiest money problem you will ever have, which is exactly why people get it wrong: it looks too simple to need a spec. You make a Checkout Session, the customer pays, they land on your thank-you page, and you hand over the goods right there in the page code. Then someone's connection drops between paying and redirecting, and you have a paid customer staring at nothing, emailing you at 11pm. Or someone bookmarks the success URL and gets the goods for free every time they visit it. The thank-you page is decoration. Stripe tells you about the payment the reliable way, server to server, through a webhook, and that is where fulfillment happens: mark the order paid, send the download link, grant the access. The page the customer lands on just reads the order and displays its state. If the redirect never happens, they still get what they paid for. That is the entire trick, and it's the difference between a checkout that works in a demo and one that works on a bad hotel wifi. This spec is deliberately smaller than the subscription one. No customer portal, no recurring state machine, no plan table. One product, one payment, one webhook event that matters. Fill in the placeholders and hand it to your agent.

Template: Research Agent

Mon, 27 Apr 2026 00:00:00 GMT

A research agent without citation rules is a confident summary machine. It reads three pages, remembers a fourth that doesn't exist, and hands you a tidy report where the real findings and the invented ones are typeset identically. You can't tell which sentences to trust, so you can trust none of them. The fix is structural, not motivational. Telling an agent "don't hallucinate" does approximately nothing. Forcing every claim to carry a source URL, and forcing the synthesis step to draw only from notes gathered in phase one, does a lot: a claim with no note behind it has nowhere to hide. This template splits the work into gather, cross-check, and synthesize, with a paper trail at each step. Hand it to any agent with web access: Claude Code with web search, a deep research tool, whatever you run. The output is a draft report for you to read, not a finished truth. You still spot-check the citations. Two minutes of clicking links beats an afternoon of acting on a source that never existed.

Template: Monitoring Alert Agent

Mon, 27 Apr 2026 00:00:00 GMT

Checking whether a URL returns 200 is not agent work. It's a loop and an if-statement, it costs nothing, and it should run every minute forever. The agent earns its keep in the thirty seconds after the check fails: pulling recent logs, noticing the disk filled up an hour before the crash, and writing an alert that says "the site is down, here's probably why, here's the likely fix" instead of just "DOWN." That split is the workflow-versus-agent decision from §3.6 in miniature. Deterministic checking stays deterministic. The model only runs when there's something to diagnose, which also means you're not paying inference costs to confirm, sixty times an hour, that everything is fine. Two rules keep this from becoming its own incident. The agent suggests fixes; it never applies them. An agent that restarts services on its own diagnosis will eventually restart the wrong thing at the worst time, and you'll spend a weekend learning why. And alerts are deduplicated through a state file, because the fastest way to stop reading alerts is to receive forty identical ones. An ignored monitoring system is decoration.

Template: Invoice Chasing Agent

Mon, 27 Apr 2026 00:00:00 GMT

Nobody likes chasing invoices, so nobody does it. The reminder you meant to send on day 7 goes out on day 40, apologetic and mistimed, and the client learns that your invoices are optional. Meanwhile the businesses that get paid on time are not braver than you. They just have a system that sends the awkward email so no human has to feel awkward. This agent runs a three-rung ladder: a friendly nudge at 7 days, a firm note at 21, and a final notice at 45 that says what happens next. Tone is the whole game here. The day-7 email assumes the invoice slipped their mind, because it usually did. The day-45 email is still professional, because you may want this client again, and because an agent that threatens people on your behalf is a liability, not an employee. Two safety rails are non-negotiable. First, every message is a draft for your approval; a payment that crossed in the mail plus an auto-sent final notice equals a lost client. Second, a sent-log makes the run idempotent, so running the script twice on Tuesday never double-reminds anyone. The agent also never invents late fees, discounts, or legal threats. If it's not in your invoice terms, it doesn't go in the email.

Template: Document Processing Agent

Mon, 27 Apr 2026 00:00:00 GMT

A shoebox of invoices, a folder of scanned receipts, a decade of PDFs someone needs in a spreadsheet by Friday. This used to be a data-entry job. A multimodal model does it in minutes, and does it well, right up until it reads a smudged 7 as a 1 and your books are off by six hundred dollars with total confidence. The model does not know when it's wrong. That's the entire design problem. So the design has three parts. A schema, decided before you extract anything, because "pull out the important stuff" produces a different shape for every document and §5.1 already told you why that ruins everything downstream. A confidence score on every field, reported by the model itself. And a review queue: extractions below your threshold go to a human, and until you've audited the pipeline against documents you've checked by hand, the threshold is effectively "everything." Auto-accept is a privilege the pipeline earns, not a default it ships with. This one is tagged advanced because it calls the model API directly instead of hiding behind a framework, and because the failure mode is quiet. A broken website looks broken. A wrong number in a spreadsheet looks exactly like a right number.

Template: Customer Support Agent

Mon, 27 Apr 2026 00:00:00 GMT

The nightmare version of a support agent is the one that improvises policy. A customer asks about refunds, your docs say nothing, and the model helpfully invents a 90-day money-back guarantee in your brand voice. Now you're either honoring a policy written by a language model or telling a customer the robot lied to them. Both options are bad, and both were avoidable. The rule that prevents it is grounding: the agent may only state what it can quote from your docs folder. No doc, no answer. Anything it can't ground gets escalated to you with a note explaining what the customer needs and what's missing from the docs. That second part is quietly the best feature here: your escalation queue becomes a list of documentation you should have written. Every reply is a draft printed for your approval. The stub tools are stubs on purpose, same as the other agent templates on this site: wire them to your real inbox one at a time, verify each, and let the agent earn autopilot on the easy tickets before you even think about the hard ones.

Template: Code Review Agent

Mon, 27 Apr 2026 00:00:00 GMT

"Review this PR" is an underspecified request, and an agent handles it the way a bored intern would: three style nitpicks, a compliment about naming, and a missed SQL injection. The problem is not the model. The problem is that you didn't say what a finding is, where the bar sits, or what shape the output should take. This template fixes all three. It gives the agent a checklist ordered by what actually hurts (correctness, security, tests, then style), and it demands findings as structured records with a file, a line, evidence, severity, and confidence. Structured findings are the difference between a review you act on and a review you skim. One counterintuitive rule is baked in: the agent reports everything it finds, including low-severity and low-confidence items, and you filter afterward. Modern models follow "only report serious issues" faithfully, which sounds great until you realize they found the bug, judged it below your stated bar, and quietly dropped it. Coverage first, filtering second. And the agent files findings only. It never approves, never merges, never pushes a fix into your branch uninvited. That call is yours.

Template: Portfolio Site

Mon, 27 Apr 2026 00:00:00 GMT

A portfolio site has one job: a stranger with your link and ninety seconds decides whether to email you. Everything on the page either helps that decision or delays it. Most portfolios delay it, because they are organized around the owner's history instead of the visitor's question, which is always the same question: can this person do the thing I need done? The answer to that question is not a skills grid. It is three or four pieces of work, each shown as a small case study: what the problem was, what you did about it, what happened because of it. One project explained beats nine projects thumbnailed. If you're switching careers or returning to work and the honest answer is "I don't have client work yet," case-study your practice projects the same way. The problem-action-result structure is doing the persuading, not the client's logo. The technical decision baked into this spec is that your projects live as data, separate from the layout. When you finish something new, you add one entry to one file and the site updates. Portfolios die when adding a project means re-opening the code, so the spec makes adding a project the easiest operation on the site.

Template: Landing Page with Waitlist

Mon, 27 Apr 2026 00:00:00 GMT

The waitlist page is the smallest real project there is. One page, one form, one table of email addresses. It is also the fastest way to find out whether anyone wants the thing before you spend three months building it. If a hundred strangers hand you their email, build it. If nine people sign up and six of them are you testing the form, you just saved a quarter of a year. The trap is treating "small" as "doesn't need a spec." A vague prompt like "make me a landing page with email signup" gets you a page that stores emails in the browser, or in a public spreadsheet, or nowhere at all: the form animates nicely and the address evaporates. Emails are personal data. The moment you collect one, you own its storage, its privacy, and the awkward question of what happens when the same person signs up twice. This spec pins down the parts an agent will otherwise improvise: where the emails actually live, what happens on a duplicate, what the visitor sees after submitting, and what keeps a bot from filling your table with garbage overnight. The copy is yours to write. The plumbing is what you're handing over.

Template: Command-Line Tool

Mon, 27 Apr 2026 00:00:00 GMT

Command-line tools are where agents look best and behave worst. No UI to fuss over, so an agent will hand you something runnable in minutes. Then you pipe its output into another command and discover the "table" is decorated with box-drawing characters, errors print to stdout where they poison the pipe, and the exit code is 0 no matter what happened, so your script can't tell success from disaster. The fix is knowing that a CLI has a contract, and the contract is older than you are. Arguments and flags follow conventions. `--help` exists and tells the truth. Exit code 0 means success and nonzero means failure, because that single integer is how every shell script, cron job, and CI pipeline ever written decides what to do next. Human-readable output goes to stdout, diagnostics go to stderr, and a `--json` flag gives programs a stable shape to parse. None of this is hard. All of it gets skipped when the spec doesn't demand it. This template is the spec that demands it. Fill in what your tool actually does; the contract section rides along unchanged, and it is the part doing the work. A CLI that honors the contract composes with fifty years of existing tooling. One that doesn't is a program you can only operate by hand, which on a command line is a strange thing to have built.

Template: Chrome Extension

Mon, 27 Apr 2026 00:00:00 GMT

A browser extension is three small programs pretending to be one. The popup is a tiny web page that appears when you click the icon. The content script is code injected into someone else's website, where it can read and change the page. The background service worker is the coordinator that owns state and talks to APIs. They run in separate worlds and can only communicate by passing messages, and that message passing is where agent-built extensions go to die: the agent writes each piece correctly and wires them together wrong, or writes Manifest V2 patterns from its training data into your V3 project. The other thing to get right before any code exists is permissions. Every permission you request is a scary line in the install prompt and a bigger attack surface if your extension is ever compromised. "Read and change all your data on all websites" is what `` looks like to the person installing. If your extension works on one site, say that one site. This spec forces the permissions list to be written down and justified up front, because an agent left to guess will request everything, and it will work in testing, and you will only feel the cost at review time or install time. One hard rule baked in below: no secrets in the extension. Anything shipped in an extension can be unzipped and read by anyone who installs it. If your extension needs an API that requires a key, the key lives on a server you control and the extension talks to that server.

Template: Blog with MDX and RSS

Mon, 27 Apr 2026 00:00:00 GMT

The fastest way to not have a blog is to start by choosing a CMS. You will compare five of them, sign up for two, wire one halfway in, and write nothing. A blog needs a folder of files, a way to turn them into pages, and a feed so people can subscribe. That's the whole machine. Your posts as files in your own repo means version history for free, no vendor to outlive, and writing that happens in the same editor you already live in. MDX is markdown that can embed components. The honest pitch: you will write plain markdown ninety-five percent of the time, and the five percent where you want an interactive chart or a demo embedded mid-post, MDX makes that possible without a rewrite. You are buying the escape hatch, not the habit. The RSS feed is not optional, and it is the piece agents most reliably get wrong: absolute URLs where relative ones sneak in, valid dates, correct content types. The spec makes the feed a first-class requirement with its own checks, because a subtly broken feed fails silently. Nobody's reader updates, nobody tells you, and you conclude nobody reads the blog.

Template: Test Plan Spec

Mon, 27 Apr 2026 00:00:00 GMT

Ask an agent to "add tests" and you will get tests. Lots of them, green, fast, and aimed wherever the code was easiest to aim at. Coverage of the function that formats dates: extensive. Coverage of the checkout flow that takes money: one test, mocked so thoroughly it would pass if the payment provider ceased to exist. The agent did what you asked. You asked for tests when you meant protection, and those are different orders. A test plan is you deciding what needs protecting before anyone writes a test. The structure is deliberately small: three to five happy paths, three to five edge cases, one or two failure modes. Happy paths are the promises on the tin: the thing a user came to do, working start to finish. Edge cases are the borders: empty, maximum, duplicate, zero, the unicode name, the second click on a button that should only work once. Failure modes are the world misbehaving: the API that doesn't answer, the file that doesn't parse. You are not aiming for coverage of everything. You are aiming for a written answer to "if this breaks tonight, what did we lose?" The other half of the plan is defining "passing," and it is less obvious than it sounds. A test that asserts the function returns something is green whether the answer is right or garbage. Every case in the plan states its expected outcome concretely, so the agent has to assert against reality instead of against existence. And one rule carries most of the weight of the whole document: when fixing a bug, the test gets written first and must fail. A test you never saw fail has told you nothing about whether it can.

Template: Migration Plan Spec

Mon, 27 Apr 2026 00:00:00 GMT

Everything else you build with an agent has an undo button. Bad code: revert the commit. Bad deploy: roll back to the last one. A migration is the exception, because it touches the one thing that can't be regenerated: the data. Run an UPDATE with a missing WHERE clause on a live database and git cannot help you. This is the single place in this whole curriculum where I will tell you to be slow on purpose. The plan has one structural idea: never make a change that breaks the currently running code. That is the expand-and-contract pattern. Add the new column while the old one still works. Ship code that writes both and reads the old. Backfill. Flip reads to the new column. Only when nothing has touched the old column for a comfortable while do you contract: drop it. At every point in that sequence, the live version of the app and the live shape of the database are compatible, which means at every point you can stop, and stopping safely is the entire feature. Two disciplines make the plan real rather than ceremonial. Every step gets a verification: a command you run, and the output you expect, written down before you start, because mid-migration is the worst possible moment to decide what "looks right" means. And every step gets a rollback, written before you execute the step, because writing the rollback is how you find out whether the step is actually reversible. Some aren't. Dropping a column isn't. Those steps wait until the end, after everything else has been verified, when rolling back is something you no longer need. Hand this plan to your agent to help draft and to write the scripts. Do not hand it the production credentials and walk away. You run the irreversible parts, awake, with the backup verified first.

Template: Data Model Spec

Mon, 27 Apr 2026 00:00:00 GMT

The data model is the one part of a project you cannot cheaply redo. Rip out a frontend and your data survives. Swap frameworks and your data survives. Get the tables wrong, let six months of real records pile up inside the wrong shape, and you are now doing surgery on a patient who is awake. Which is why the data model is the worst possible place to let an agent improvise, and exactly where an unspecced agent will improvise most, because every app it has ever seen had a slightly different schema and it will happily average them. So you write the shape down before any code exists, and you write it twice. First in plain language: what things exist, what facts you store about each one, how they relate. This is the version you can actually check, because you know your own domain. Whether a customer can have two open invoices is not a database question. It is a question about your business, and you are the only one in the room who knows the answer. Then a SQL sketch, which is the same information made precise enough that nothing is left to interpretation: types, required-or-not, unique-or-not, what happens on delete. The sections people skip are the rules and the sensitive-fields list, and they are the ones with teeth. Rules are the invariants the schema alone can't express, and unstated rules get discovered as production bugs. The sensitive-fields list is your privacy obligations written where the agent will actually see them, before it helpfully logs email addresses to the console.

Template: Bug Report with Repro Steps

Mon, 27 Apr 2026 00:00:00 GMT

"It's broken" is not a bug report. It is a mood. An agent handed a mood will guess at what you meant, fix something adjacent to the problem, and report success, and you will not find out it fixed the wrong thing until the real bug bites again. A usable bug report has three properties. It is reproducible: numbered steps that take a stranger from a clean start to the wrong behavior, every time. It is specific: what you expected, what you got instead, quoted exactly, not paraphrased from memory. And it separates observation from theory: what happened goes in one section, what you suspect goes in another, clearly labeled, so the agent investigates your evidence instead of inheriting your assumptions. Write the repro steps as if the reader has never seen your project, because functionally, a fresh agent session hasn't. If you cannot reproduce it reliably, say so and describe the pattern; an intermittent bug honestly labeled is workable, an intermittent bug reported as consistent burns hours.

Template: Architecture Decision Record

Mon, 27 Apr 2026 00:00:00 GMT

Six months from now you will open your own project and ask, out loud, why the database is SQLite when everything else in your life is Postgres. There was a reason. It was probably a good reason. It is gone now, and the person who could have told you was you, on a Tuesday, in a hurry. An architecture decision record is the fix, and it is deliberately small: one markdown file per decision, a dozen lines, written the day you decide. Not documentation of the system. Documentation of the fork in the road: what you picked, what you didn't, and what would have to change for you to reverse it. The rejected options are the valuable part. "We chose X" is a fact you can read from the code. "We rejected Y because of Z" is knowledge that exists nowhere else, and it is exactly the knowledge that stops you from spending a weekend re-evaluating Y when Z is still true. ADRs matter double when you work with a coding agent. A fresh agent session knows nothing about last month's reasoning, so it will cheerfully suggest the thing you already rejected, argue for it well, and you will half-remember disagreeing but not why. A folder of ADRs turns that argument into a file lookup. Point your CLAUDE.md or AGENTS.md at the folder and the agent stops relitigating settled questions. Number them, never edit a decided one, and when a decision changes, write a new ADR that supersedes the old one. The history is the point.

Template: API Contract Spec

Mon, 27 Apr 2026 00:00:00 GMT

An API written without a contract is negotiated one endpoint at a time, in the moment, by whoever is typing. The agent picks a URL shape at 2pm and a different one at 4pm. One endpoint returns errors as strings, another as objects, and your frontend grows a small museum of error-handling styles to cope. None of this is the agent being bad at its job. It answered every question you left open, and it answered them inconsistently because you asked them separately. The contract closes the questions before the code exists. It says, once, how URLs are shaped, how errors look, how auth works, and how lists paginate, and then every endpoint inherits those answers. The endpoint entries themselves get short, because they only carry what is actually specific to them: the path, the shapes in and out, and the ways they fail. This is also the document that makes an agent genuinely fast. Hand it the contract and it can build the backend, the frontend client, and the tests against the same shapes, in any order, and the pieces meet in the middle. Skip it and you build the same API twice: once in code, and once in the debugging sessions where you find out what the code decided. Write the conventions section first. It is the highest-value ten minutes in the file.

Template: AGENTS.md

Mon, 27 Apr 2026 00:00:00 GMT

Same job as CLAUDE.md, different address. CLAUDE.md is the project-context file Claude Code reads at the start of every session; the CLAUDE.md template on this site covers it. AGENTS.md is the vendor-neutral version of the same idea, and enough tools have adopted the convention (Codex, Cursor, Copilot, and a growing list of others) that it is now the closest thing to a standard location for "here is what any agent needs to know about this repo." Whether you need it depends on who, and what, touches your repo. If you use Claude Code exclusively, CLAUDE.md alone is fine and this file is a maybe. The moment a second tool enters the picture, a collaborator on Cursor, a CI bot, you trying a different agent for an afternoon, the calculus flips, because context that lives only in a Claude-specific file is invisible to everything else, and an agent without context reverts to guessing. You already know how guessing goes. Do not maintain two full copies; two copies of the same facts diverge, and then your agents disagree about reality depending on which file they read. Put the real content in AGENTS.md and make CLAUDE.md a pointer: a single line saying "Read AGENTS.md," plus anything genuinely Claude-specific, like skill or subagent notes. One source of truth, every tool sees it, nothing drifts. The content rules are the same as for CLAUDE.md, so I'll compress: write facts an agent can act on, not vibes ("use pnpm, never npm" beats "we care about consistency"), keep it current or it becomes a well-formatted lie, and treat "What NOT to do" as the section that pays the rent.

Template: Inventory and Reorder Agent

Mon, 27 Apr 2026 00:00:00 GMT

Written for a restaurant, but the structure fits any business where inventory depletes against sales. The agent takes your sales, walks them through recipes to ingredient usage, checks the math against stock on hand, and drafts the reorder; the sales-to-recipe-to-inventory math is already in the file. It drafts, you send. Keep it that way until the numbers have been right for a month straight.

Template: Customer Scheduling Agent

Mon, 27 Apr 2026 00:00:00 GMT

For the roofer, the plumber, the cleaning service: any business where booking currently happens by phone tag. Customers book themselves; the agent confirms, reschedules, and reminds, and every message is a draft for your approval until you decide it has earned autopilot. The stub tools are stubs on purpose. Wire them to your real calendar and inbox one at a time, and verify each one before wiring the next.

Template: Gmail + Calendar Agent

Mon, 27 Apr 2026 00:00:00 GMT

This template builds a CrewAI crew that reads your Gmail, reads your Google Calendar, and creates calendar events for actionable emails.

Template: REST/GraphQL API Skeleton

Mon, 27 Apr 2026 00:00:00 GMT

A backend skeleton for people who already know which stack they want and why. It carries the decisions that hurt to change later: JWT auth, money stored in cents, soft deletes via deleted_at, consistent error shapes. Disagree with any of them if you like, but disagree now, before the agent generates forty endpoints on top of them.

Template: Internal Dashboard

Mon, 27 Apr 2026 00:00:00 GMT

A single-page app for the numbers your team checks every day, which currently live in a spreadsheet or in somebody's head. The spec covers the layout, the components, and the API calls behind them; your job is to name the actual metrics and exactly where they come from. Be precise about the data source. "Pull the sales numbers" is how dashboards end up confidently wrong.

Template: Small Business Website

Mon, 27 Apr 2026 00:00:00 GMT

Five pages, a contact form, a domain: the site a small business actually needs, specced completely enough for an agent to build it in an afternoon. Swap in your business name, your services, and your words, then hand the whole thing over. Spend your review time on how it looks on a phone, because that is where your customers are.

Template: CLAUDE.md

Mon, 27 Apr 2026 00:00:00 GMT

CLAUDE.md is the file your coding agent reads at the start of every session: what the project is, how it is laid out, which commands run things, and which conventions you refuse to relitigate. Without it, every session starts with the agent guessing at all four and you correcting it. Write it on day one, keep it current, and treat "What NOT to do" as the most valuable heading in the file.

Template: Feature Specification

Mon, 27 Apr 2026 00:00:00 GMT

A PRD describes the product; a feature spec describes one change to it, tightly enough that an agent can build it without interviewing you first. The discipline is in the edges: inputs, outputs, error states, and what is explicitly out of scope. If writing it feels slower than just asking the agent, count the round trips your last vague request cost you.

Template: Product Requirements Document

Mon, 27 Apr 2026 00:00:00 GMT

The PRD is the one-page answer to "what are we building and why," written before any code exists and read by every session after. Fill it in badly and your agent will happily build the wrong thing at full speed. Fill it in honestly, including the non-goals, and most of the clarifying questions disappear before they get asked. The AFD considerations section is not decorative. Fill it in or rethink the project, but do not delete the section.

§9.3 What "functional" Looks Like Now

Mon, 27 Apr 2026 00:00:00 GMT

v1 ended with "now you're functional." This is what functional means two years later, with the new tools.

§9.2 Contributing Templates Back

Mon, 27 Apr 2026 00:00:00 GMT

This curriculum has nine templates. You'll write the tenth, the hundredth, the thousandth. Send them back.

§9.1 The Community

Mon, 27 Apr 2026 00:00:00 GMT

You're not alone. The people doing this work are mostly happy to help the next person.

§8.9 Inventory And Reorder Agent (restaurant)

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.9.

§8.8 Customer Scheduling Agent (small Business)

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.8.

§8.7 Gmail + Calendar Agent (crewai)

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.7.

§8.6 Rest/graphql Api Project Skeleton

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.6.

§8.5 Internal Dashboard (svelte Or React)

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.5.

§8.4 Small Business Website (one-shot)

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.4.

§8.3 Claude.md Template (project Context For Coding Agents)

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.3.

§8.2 Feature Specification Template

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.2.

§8.1 Product Requirements Document (prd) Template

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 8.1.

§7.4 The Data Analyst Leveling Up (dashboards And Pipelines)

Mon, 27 Apr 2026 00:00:00 GMT

You finished v1. You're functional in Python and SQL. You want to ship faster. Here's the loadout.

§7.3 The Solo Consultant (research, Follow-up, Scheduling)

Mon, 27 Apr 2026 00:00:00 GMT

You sell your time. Your time is finite. The activities that make you money — meetings, calls, deliverables — get crowded out by activities that don't. Here's the loadout.

§7.2 The Restaurant Manager (operations And Inventory)

Mon, 27 Apr 2026 00:00:00 GMT

You manage a restaurant. Food costs 30%+ of revenue. Half your time is firefighting. Here's the loadout.

§7.1 The Roofer (small Home-services Business)

Mon, 27 Apr 2026 00:00:00 GMT

You install roofs. You're good at installing roofs. You're losing hours every day to phone tag, scheduling, and follow-up. Here's the loadout.

§6.6 The Deployment Cliff: Making It Run While You Sleep

Mon, 27 Apr 2026 00:00:00 GMT

Building an agent that works on your laptop is one thing. Having it work at 3 AM when you're asleep is a different thing. This is the deployment cliff.

§6.5 Data Privacy: When Local Models Are Non-negotiable

Mon, 27 Apr 2026 00:00:00 GMT

Some data should never leave your machine. Knowing which is which is a business skill, not a technical one.

§6.4 Secrets, Api Keys, And What Not To Put In A Prompt

Mon, 27 Apr 2026 00:00:00 GMT

This section is short because the rules are short. Read all of them.

§6.3 Testing Without Being A Tester

Mon, 27 Apr 2026 00:00:00 GMT

You don't need to learn pytest to ship working software. You need a basic verification habit.

§6.2 Git Discipline For Ai-generated Code

Mon, 27 Apr 2026 00:00:00 GMT

v1 covered git. This section is what changes when an agent is the one making most of the commits.

§6.1 Reading Code You Didn't Write

Mon, 27 Apr 2026 00:00:00 GMT

The single highest-leverage skill for vibe coders. Most of the difference between people who ship and people who don't is whether they can read their agent's output and tell when it's wrong.

§5.6 Api Design For Vibe Coders

Mon, 27 Apr 2026 00:00:00 GMT

You probably won't write the API. You will have to describe what it does. Here's how.

§5.5 User Roles And Permissions

Mon, 27 Apr 2026 00:00:00 GMT

Most apps have at least two kinds of users. Most apps fail to think this through up front. Don't be most apps.

§5.4 Design Preferences (radii, Shadows, Fonts, Spacing)

Mon, 27 Apr 2026 00:00:00 GMT

The aesthetic choices. Most people skip these and end up with the default "AI-generated SaaS" look. A few specifications get you out of that valley.

§5.3 Component Vocabulary (tabs, Buttons, Modals, Drawers)

Mon, 27 Apr 2026 00:00:00 GMT

Within the layout, the components. Here's the cheat sheet so you can name what you want.

§5.2 Describing Interfaces Accurately (top Menu, Side Menu, Panels)

Mon, 27 Apr 2026 00:00:00 GMT

You're going to ask an agent to build a UI. The agent has read every UI ever made. You have to tell it which one you want.

§5.1 Data Shape: The Prerequisite To Good Prompts

Mon, 27 Apr 2026 00:00:00 GMT

We touched on this in 2.5. Here's the longer treatment, because data shape is the bottleneck for most projects.

§4.6 Cost Literacy: Tokens, Context Windows, And The $200 Question

Mon, 27 Apr 2026 00:00:00 GMT

You can't make smart routing decisions if you don't know what you're paying for. Here's the cheat sheet.

§4.5 Self-hosting On Nvidia (spark, Orin, Full Gpus)

Mon, 27 Apr 2026 00:00:00 GMT

The NVIDIA path. More flexible, more setup, often cheaper for comparable capability.

§4.4 Self-hosting On Mac (mini, Studio, Pro)

Mon, 27 Apr 2026 00:00:00 GMT

Apple's the easiest on-ramp to self-hosting. Here's the lineup.

§4.3 Ram, Vram, And Unified Memory

Mon, 27 Apr 2026 00:00:00 GMT

The number that determines whether you can run a model is "how much memory do you have, and what kind." The kinds matter.

§4.2 How Models Actually Work (weights, Parameters, Active Parameters)

Mon, 27 Apr 2026 00:00:00 GMT

You don't need to understand the math. You need to understand the vocabulary so you can read a model's spec sheet and make a buying decision.

§4.1 Frontier Vs. Local: When Each Makes Sense

Mon, 27 Apr 2026 00:00:00 GMT

This is the most important budgeting decision you'll make. Not every problem deserves Claude Max.

§3.6 Crewai For Agents

Mon, 27 Apr 2026 00:00:00 GMT

The most useful new tool in this curriculum. Read this section twice.

§3.5 Fastapi Vs. Devii: When To Write An Api Vs. Generate One

Mon, 27 Apr 2026 00:00:00 GMT

Every application needs a way for the frontend to talk to the database. That layer is called an API. You can write one (FastAPI) or generate one (Devii). Here's how to choose.

§3.4 Mage (still The Move) For Data Pipelines

Mon, 27 Apr 2026 00:00:00 GMT

v1's recommendation holds. Mage is still the move for data pipelines. What's changed: now you don't have to write the Python yourself.

§3.3 Voice-to-text: Wispr Flow And The Dictation Workflow

Mon, 27 Apr 2026 00:00:00 GMT

You think faster than you type. Stop typing.

§3.2 Coding Agents: Claude Code, Openclaude, Others

Mon, 27 Apr 2026 00:00:00 GMT

The IDE is the room. The agent is the engineer. The agent landscape has gotten more interesting since v1; here's the current map.

§3.1 Ides And Editors: Vs Code, Cursor, Anti Gravity

Mon, 27 Apr 2026 00:00:00 GMT

You need somewhere to write code. Not all editors are equal anymore.

§2.6 The Claude Code Playbook

Mon, 27 Apr 2026 00:00:00 GMT

You have requirements (2.1), specs (2.2), structured prompts (2.3), context discipline (2.4), and data shape (2.5). What's missing is the loop you run them through. This section is the loop.

§2.5 Prompting Based On Data Shape

Mon, 27 Apr 2026 00:00:00 GMT

Effective prompts come from understanding your data. Most bad prompts come from people who don't actually know what's in their data.

§2.4 Context Engineering (the Missing Discipline)

Mon, 27 Apr 2026 00:00:00 GMT

The principle that explains why the playbook in 2.6 works the way it does. You can ship without reading this. You'll ship better if you don't.

§2.3 Structured Markdown: The Format Coding Agents Read Best

Mon, 27 Apr 2026 00:00:00 GMT

You wrote a spec. The agent needs to read it. The format matters more than you think.

§2.2 Specifications: What The Machine Actually Needs

Mon, 27 Apr 2026 00:00:00 GMT

Requirements are for humans. Specifications are for machines. The machine needs more.

§2.1 Requirements: What You Actually Want

Mon, 27 Apr 2026 00:00:00 GMT

Most software fails because nobody wrote down what it was supposed to do. This is true of $50 million enterprise projects and your weekend side project. Start here.

§1.4 When Not To Use Ai To Write Your Code

Mon, 27 Apr 2026 00:00:00 GMT

Counterintuitive section, but the most important one in Part 1. If you read nothing else, read this.

§1.3 The New Skills Stack: Requirements → Specs → Structured Prompts → Agents

Mon, 27 Apr 2026 00:00:00 GMT

There's a pipeline from "I have an idea" to "the software exists." Here are the four stages, in order, with the skill each one requires.

§1.2 What "vibe Coding" Actually Means (defined On Our Terms)

Mon, 27 Apr 2026 00:00:00 GMT

"Vibe coding" gets thrown around to mean ten different things. Here's what it means in this curriculum.

§1.1 Why The Old Foundation Matters More Now

Mon, 27 Apr 2026 00:00:00 GMT

The grift you're going to hear is: "AI will write code for you, you don't need to learn programming." The grift is wrong. Here's why.

§0.17 Projects And The Final Boss

Mon, 27 Apr 2026 00:00:00 GMT

NOW IT'S TIME TO MAKE SOME PROJECTS

§0.16 Day 100: Cloud, Cli, And Tools

Mon, 27 Apr 2026 00:00:00 GMT

SO YOU'RE ABOUT 100 DAYS IN, CALL IT 16 WEEKS. MAYBE LONGER. YOU HAVE THE BASICS DOWN. LET'S LEARN SOME TOOLS. Now you need to learn how to put all these skills into use with some tools. This is by no means a complete list, but it is a list of tools that I personally use, or tools that I know my peers use. More importantly, tools that you will actually use, and can use to turn data into things that employers like… you know… money and value related shit. Let's surf through the most common tools that will help you engineer problems into solutions.

§0.15 Day 60: Docker, Kubernetes, Git

Mon, 27 Apr 2026 00:00:00 GMT

YOU DID ALL THE HARVARD STUFF, SO MY GUESS IS YOU'RE AROUND 60 DAYS IN Now we move into Docker, Git, tools, and the things that turn code, theory and basics into functional skills. We call this DevOps, but it's essential.

§0.14 Day 30: The Wall And Cs50

Mon, 27 Apr 2026 00:00:00 GMT

AT 30-ISH DAYS, YOU'RE ABOUT TO HIT "THE WALL" IN LEARNING TO CODE This is a good time to go to Harvard. For free. Seriously. This is where we take a break and get into some theory. You've seen how Python and SQL can work, you have some understanding, and now it's time for the same exact Harvard course that people literally pay for at Harvard… but for free.

§0.13 Day 20: Add Sql

Mon, 27 Apr 2026 00:00:00 GMT

AROUND DAY 20, START ADDING IN SOME SQL The best way to do this is to tackle more than one course at a time. That's why you take multiple courses in college. I think about 20 days of Python is enough to make you "start thinking like a computer" and that's a good time to dive into SQL.

§0.12 Day 1: Python

Mon, 27 Apr 2026 00:00:00 GMT

AND NOW YOU BEGIN. THIS IS STILL DAY 1. PYTHON. LFG. This is where all the actual coding and learning to code starts. (Holy crap that was 25 intro slides. My God what have I done?) I'm still glad I did all that explaining because it all matters.

§0.11 Set Up Your Environment

Mon, 27 Apr 2026 00:00:00 GMT

HOW DO WE MAKE CODE HAPPEN? LET'S START DOWNLOADING STUFF. What kind of computer do you need, by the way? Literally fucking anything works.

§0.10 The Stack: Python, Sql, Docker, Git

Mon, 27 Apr 2026 00:00:00 GMT

DIVE INTO PYTHON, SQL, GIT AND DOCKER/KUBERNETES Here we go… (and now the intro to the stuff you're gonna learn starting out).

§0.9 How Code Thinks: Mvp, Mvc, And What A Computer Is

Mon, 27 Apr 2026 00:00:00 GMT

MVP — Most Valuable Player. After winning the 2013-14 MVP award, Kevin Durant said his mother was "da real MVP", which isn't what we're talking about here today.

§0.8 What This Covers (and Why Not A Bootcamp)

Mon, 27 Apr 2026 00:00:00 GMT

The core foundation of data engineering and analytics, in the next 180 days.

§0.7 Foundations: Start Here (or Skip It)

Mon, 27 Apr 2026 00:00:00 GMT

[COPY: 1-2 sentences framing sections 0.7-0.17 as Internet Menace Version 1.1 — the original curriculum, released July 8, 2024 — folded into this wiki as a day-ordered path, plus who should skip it (already finished v1 → jump to Part 1) — VOICE: Shane — LENGTH: 2-3 sentences]

§0.6 How To Use This Curriculum (core Path Vs. Deep-dives)

Mon, 27 Apr 2026 00:00:00 GMT

This is a wiki, not a textbook. You don't have to read it in order.

§0.5 What Changed Since Internet Menace V1

Mon, 27 Apr 2026 00:00:00 GMT

A lot. Not all of it for the better. Most of it for the better.

§0.4 Who This Is For

Mon, 27 Apr 2026 00:00:00 GMT

Internet Menace, Again is for three kinds of people: 1. People who finished Internet Menace v1 and want to know what's next. 2. People who own or run a small business and want to use AI to handle work that's eating their week. 3. People who are not engineers, never wanted to be engineers, but have an idea for software they want to exist.

§0.3 Sponsor

Mon, 27 Apr 2026 00:00:00 GMT

There's no sponsor.

§0.2 Acknowledgments

Mon, 27 Apr 2026 00:00:00 GMT

Wiki section 0.2.

§0.1 Welcome Back (or Welcome For The First Time)

Mon, 27 Apr 2026 00:00:00 GMT

Two years ago I wrote Internet Menace because I was tired of watching people get fleeced by $20,000 bootcamps that taught them less than a free YouTube playlist. About 2,000 people downloaded that curriculum. Some of you got jobs. Some of you got better jobs. A few of you sent me very nice emails. One of you sent me a meme so good I screenshotted it. Now it's 2026, and the ground has moved under all of us.

v1.0.0: Internet Menace, Again is live

Mon, 27 Apr 2026 00:00:00 GMT

The curriculum, the templates, the glossary, and the site go public. Internet Menace, again, the second pass.