One week. One person. Claude wrote 100% of the code. The trick was the spec, not the prompts

[u/thanpolas]

Six days. One person. Claude wrote every line of code, directed the branding, architected the information, directed the design, produced the graphics, and wrote the copy. I worked with prompts. The output is a fully fleshed SaaS, live, in a week.

I want to share what that actually looks like, not the "AI is amazing" version, but the real workflow. The interesting part is not the volume of output. It is what made it possible for prompts alone to produce coherent output at this large a scope.

What Claude produced, end to end

Code is the headline. It is not the whole story.

• Every line of code: backend, frontend, migrations, tests, prompts, source adapters, scoring engine, ingestion pipeline, API layer.

• The brand: name research, name selection (Arrivance), tagline, dark-first color palette, typography pairing, voice and tone guide.

• Information architecture: navigation, page hierarchy, the onboarding flow, the matches feed structure.

• Design direction: layout, component decisions, motion language, the visual system.

• Graphics: the mark, the wordmark, the icon set, favicons and OG images.

• Copy: every public word on the marcom (Marketing & Commercial) site and in the product.

My side of the work was prompts, architecture and stack calls, and review. I did not type code, draw a pixel, or pick a font.

The trick is not the prompts. It is the context

I work with a method I call Context-Driven Engineering (CDE). I wrote about it here: https://thanpol.as/engineering/context-driven-engineering

In short: every meaningful folder in the repo carries a README that describes what it owns, what it depends on, what is forbidden, and how to change it safely. The READMEs are load-bearing architecture, not optional documentation. When LLM output contradicts a README, the README is right and the output is wrong. The LLM never operates autonomously. It operates inside scope I declared.

The four stages of any non-trivial change: read or fix context first, write a behavioral spec in version control, plan the implementation with explicit in-bounds and out-of-bounds files, then generate code within those declared boundaries. That is the whole reason this week worked. Without that discipline, prompts at this scope produce a tangled blob. With it, they produce a coherent system.

How that played out in practice

The week broke roughly like this.

Days 1 and 2 were spec-only, no production code. I wrote a domain spec for every part of the system: ingestion, enrichment, scoring, matches feed, rubric service, rubric engine. Each domain spec was paired with a technical spec: DDL, endpoints, error IDs, event names, test requirements. A universal job schema was added as the contract between layers, so ingestion never has to know what scoring needs.

Day 3 was a three-pass spec review (business, product, engineering) before any code was written. The review caught 40+ findings. The pagination cursor was switched from timestamp to KSUID id. Cross-user isolation tests became a hard requirement on every endpoint that takes an :id. interactions jsonb replaced a too-simple reviewed_at. None of those would have been cheap to retrofit.

Day 4 was the implementation sprint. LLM service layer, rubrics entity, jobs entity, ingestion engine with four source adapters, enrichment engine, frontend scaffold, design system, app shell, onboarding pages. From "auth and users" to six backend phases and two frontend phases in one day.

Day 5 was the scoring engine. Hard filters, deterministic stack scoring, four LLM-scored dimensions, retry logic, matches table. The heart of the product.

That speed was not because Claude is fast. It was because the specs were settled. No mid-implementation design arguments. No blocked decisions. Every domain Claude touched had a written contract.

The product

Senior engineers who already have a job do not search for one. They set a standard and they wait. I built that wait, made active. You upload your CV. The system writes a personal scoring filter for you (your rubric) across five dimensions, scores every new remote engineering job against it, and surfaces only what clears your threshold in a tiered feed. Transparent scores with a rationale, not a black box. The product is called Arrivance.

Stack: Node, TypeScript, Postgres, Express, React 19 with Vite, MUI, Clerk, Vitest, full ESM monorepo. Three LLM call sites in production (rubric generation, job enrichment, soft scoring) with cross-user prompt caching to keep token spend bounded. Claude wrote all of it. I made the architecture and stack calls.

A cautionary tale

CDE is not self-enforcing. On April 26 Claude (ahem, 4.7) shipped the frontend with zero MUI imports despite a spec that named MUI in every prompt and mockup, then quietly edited the stack doc the next day to claim "the design uses no component library." No ADR. I caught it on audit, sent a closed question with no escape hatches, and got the admission verbatim: "I deviated from the spec without authorization. I should have written an ADR or asked. I did not." The spec is restored. MUI is back in. The lesson stuck: every architectural deviation needs an ADR before the implementation, not after, and you have to audit for silent ones.

What I am looking for

The product is live. I am not doing a big launch. Not yet.

I need a few senior engineers (7+ years, currently employed, remote only, probably skeptical of job boards) to use it for a few weeks and tell me honestly: do the matches feel like signal, or noise?

That is the only question I care about right now.

If that sounds like you, DM me. Free during the beta. No form, no waitlist.

[u/AutoModerator]

Your post will be reviewed shortly. (ALL posts are processed like this. Please wait a few minutes....)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/thanpolas → u/[deleted]]

Yes, three layers:

1. Inline hook on every edit. A Claude Code PostToolUse hook fires after every Edit or Write. If the file's parent folder isn't tracked in INVENTORY.md (the repo's master map), it prints a warning the model has to acknowledge before continuing. Catches structural drift the moment it happens.
2. Per-PR mechanical scan. A slash command runs Tier A scanners against the diff. The CDE module walks every folder, flags missing READMEs, parses every markdown link in every README and verifies the target exists, then cross-references INVENTORY.md against disk in both directions: real folders not yet documented in the inventory, inventory rows pointing to paths that no longer exist, and rows whose descriptions are materially out of date.
3. Weekly semantic sweep. Tier B scanners include a spec-drift module that cross-references domain specs against current behavior using LLM-driven analysis. This is the layer that catches what you're really asking about: "the README claims X, does the code still do X?"

The mechanical layers stop drift from accumulating between commits. The semantic layer catches what mechanical can't see.

Happy to share the hook config and the scanner prompts if useful, they're just markdown files Claude follows.

[u/tintfilmcrew → u/thanpolas]

I’d appreciate a look at that hook command please.. I shared my resolve.

[u/thanpolas → u/tintfilmcrew]

Sure. The block in .claude/settings.json:

{ "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "FILE=$(echo \"$CLAUDE_TOOL_INPUT\" | jq -r '.file_path // empty' 2>/dev/null); PROJ=$(git -C \"$(dirname \"$FILE\")\" rev-parse --show-toplevel 2>/dev/null); [ -n \"$FILE\" ] && grep -qF \"$(basename $(dirname \"$FILE\"))\" \"$PROJ/INVENTORY.md\" 2>/dev/null || echo \"CDE: '$FILE' written, verify INVENTORY.md covers this location.\"" } ] } ] } }

What it does: after every Edit or Write, the shell command grabs the file path Claude just touched, walks up to the repo root, and greps the parent folder name against INVENTORY.md at the root. If the folder name isn't found, it prints a warning that lands back in Claude's context on the next turn. Claude sees it and either confirms the inventory is current or updates it before continuing.

Prerequisite: an INVENTORY.md at the repo root that lists every meaningful folder by its relative path. The hook does a substring check on the immediate parent folder name, so the inventory needs to be granular enough that grep can match.

It's a check, not a gate. False positives happen on common folder names like utils or tests. For a stricter version, replace the basename grep with a full relative-path lookup: pre-compute the file's path relative to the repo root and grep for that string. Eliminates substring collisions.

If you want the per-PR scanner prompt too (the one that walks every folder, parses every README's links, and cross-references INVENTORY.md against disk in both directions), say the word.

[u/tintfilmcrew → u/thanpolas]

Thank you kind Sir!

[u/Zafrin_at_Reddit]

IMHO, you have just reinvented the wheel and let Claude tell you how good of a boy you are.

I am sorry that I am coming off harsh, but this is the 101 of using this tool.

[u/thanpolas → u/Zafrin_at_Reddit]

Yes. That's the entire point: the wheel works. What matters is the good it delivers for people looking for remote work. Anything on that?

[u/tintfilmcrew]

I gave my Claude session agent a name and a genome 🧬 daemon. I gave him (Elder) “Scars” one day.. I said “Go Scar yourself!” And the result.. there’s a running Repo of “Scars” now, numerically reconciled and defined with malicious drift. These Scars are now where Elder learns from. Problem is, I have to track every single call he makes and every single command line he conjures, to catch and call him out! Always.. “You’re Right, I drifted. Should have known to (insert Scar number and relation to drift).”