Lessons So Far
Six months in. What we built, what it taught us, and the discipline we absorbed from the field along the way. §01 is the vision · §02 is the empirical receipts.
1. SnapSell — What We Built and What It Taught
Bartosz, on SnapSell
On November 25, 2025, I shipped a test-drive of SnapSell on Google Cloud Run. Maciej said “LOVE IT.” We said: launch in two months.
We’re now five months in and it’s still not in production.
I’m not telling you this to apologize. I’m telling you this because everything we’ve learned the hard way over the last five months is the reason the next chapter exists.
SnapSell — Planned vs. Actual
| Status | Duration | Target |
|---|---|---|
| Planned | 2 months | Jan 2026 |
| Actual | 5 months & counting | Apr 25, 2026 |
Timeline
| Date | Event |
|---|---|
| Nov 25, 2025 | First test-drive on Google Cloud Run. Marketing video shipped. “Launch in 2 months.” |
| Jan 2026 | Vinted API ruled out. OLX OAuth investigated. Maciej’s competitive research lands. |
| Feb 24, 2026 | Petro Polishchuk joins as contract dev (~15k PLN/mo). |
| Mar 4-13, 2026 | OLX OAuth flow + Vinted integration shipped. Admin panel + token economy. Latency 81s → 12s. |
| Mar 22, 2026 | Vincent posts the first real OLX listing using the app — Radlands board game, 220 zł. “I am impressed. Well done guys.” |
| Mar 24-31, 2026 | First native iOS + Android builds. IAP + Google Play Billing. Sentry live. Apple Developer + Play Console bootstrap. |
| Apr 25, 2026 (today) | Both iOS and Android published in stores. Pending friends & family launch + Vincent marketing activation. |
🎓 3 Lessons From SnapSell
Lesson 01 — I prototyped off dirty wireframes, with no framework under me.
Starting with wireframes isn’t the mistake — that’s actually how design-led products come together. The mistake was what came next. The wireframes themselves were inconsistent, we were building without the framework we were simultaneously inventing, and I started prototyping off the mess instead of cleaning it. Every downstream decision — auth, payments, API surfaces, mobile, legal — inherited the contradictions baked into the mockups.
→ Clean the wireframes. Stand the framework up first. Only then touch code.Lesson 02 — We had no foundation. We built it while building the product.
No Stripe access. No Apple Developer Portal. No Google Play Console. No admin panel. No Nova AI stack. Vincent’s 80/20 is real — vibe coding gets you 80% of the way — but the last 20% is most of the time, and the foundation absorbs most of that. We built the runway while taking off.
Lesson 03 — SnapSell paid a tax. The next product won’t.
We now have the LiteLLM proxy, the admin panel, the management portal at management.nova-labs.ai, Sentry, the legal templates, the payment plumbing for both stores, and the product builder prototype. The next product starts at month two, not month zero. That’s the whole reason this conversation is worth having.
2. Named By the Field
Between Nov 2025 and Dec 2025 — the same 30-day window we started SnapSell in — two of the most respected voices in software engineering landed, independently, in the same place.
- Simon Willison · Nov 2025 · industry inflection
- Andrej Karpathy · Dec 2025 · stopped typing code
- Us · Nov 25, 2025 · SnapSell began
Simon Willison says the models (GPT 5.1, Claude Opus 4.5) crossed a reliability threshold in November 2025. Karpathy says “something flipped” for him in December: “I went from 80/20 writing code myself to basically not typing a line of code since.”
We started SnapSell inside that exact window. We vibe-coded because that was the vocabulary the day we began. Six months later the vocabulary has changed.
The biggest thing we carry out of SnapSell isn’t the code. It’s the method. We started the project vibe-coding — and we paid the tax for it in every corner of the stack. What replaced vibe coding now has a name, and a discipline: agentic engineering. And it has a frontier: the dark factory. Simon Willison gave us the vocabulary. Our job is to live it.
The definition — in Simon’s words
“What do we call it for professionals? I’ve gone with agentic engineering because I think the thing to emphasize is these coding agents. If you’re asking ChatGPT to knock out some code, that’s a different thing from if you’re running Codex and having it run, write the code, debug the code, test the code, all of that.” — Simon Willison · “An AI State of the Union” · Lenny’s Podcast · 2026
Agentic engineering is AI inside a disciplined SDLC — not AI as an autopilot you hand your product to. Every generated line is specified, reviewed, tested, and owned by a human. Architectural control stays with the engineer. The AI is a force multiplier on engineering discipline — not a substitute for it.
95% — the scale signal
“You cannot write code — you have to type code into a computer. Six months ago I thought that was crazy. Today probably 95% of the code that I produce, I didn’t type it myself.” — Simon Willison, 2026
Simon predicts ≥50% of engineers will be in this state by end of 2026. The gap isn’t the technology — it’s people learning to use it well, which is harder than the “it’s just a chatbot” framing suggests.
Companion voice — Andrej Karpathy · Dec 2025
“Code’s not even the right verb anymore. I have to express my will to my agents for 16 hours a day.” — Andrej Karpathy · December 2025
Karpathy went from 80/20 writing code himself to essentially not typing a line since December 2025. Two of the most respected voices in the field landed in the same place — 30 days apart — without coordination.
3. Agentic Engineering — The 5 Pillars
| # | Pillar | What it means | Simon’s / Karpathy’s pattern |
|---|---|---|---|
| 01 | Spec & plan first | Before a line of code — spec, architecture, step-by-step plan. AI executes; it doesn’t invent. | Thin Templates (Simon) — start with single passing test + preferred file layout. Agents pattern-match existing structure. |
| 02 | Every line is reviewed | Humans retain architectural control. Nothing lands in the tree unreviewed. We own the output. | Red/Green TDD (Simon) — write test first · watch fail · implement · watch pass. Karpathy’s default: assume it’s your Skill Issue (agents.md, memory, parallelization), not the model’s. |
| 03 | Tests as contract | Tests alongside code, not after. Test suite is the executable specification. | Agent-Swarm QA (frontier) — tests scale to swarms simulating end-users 24/7. StrongDM is living proof (see below). |
| 04 | The whole SDLC | Spec, architecture, code, tests, docs, PR review, migration, incident response — AI in every step. | Hoarding (Simon) — public + private research repos (simonw/tools + simonw/research, ~268 projects) as context for new problems. |
| 05 | Context is the new prompt | Curate context, not prompts. Prompts are thin. Context is everything. | Three-Prototypes-Always — cheap generation means build 3 options per feature, choose the right one. Judgment is the new bottleneck — not writing. (Exactly the POC → Demo → Pitch flow in §05.) |
4. The Frontier — The Dark Factory
“The reason it’s called the dark factory is there’s this idea in factory automation — if your factory is so automated that you don’t need people there, you can turn the lights off. The machines operate in complete darkness. What does that look like for software? It’s when you’re not reviewing the code, but you’re also not vibe coding. You’re applying professional practices and quality expectations to code you’re not directly reviewing.” — Simon Willison · on the dark factory pattern
Case study · StrongDM
| Metric | Value |
|---|---|
| Tokens spent simulating end-users | $10k / day |
| Agent swarm QA that never sleeps | 24 / 7 |
| Test sandboxes | Vibe-coded fake Slack, Jira, Okta (dodge real-world rate limits) |
| Code review | Zero — the simulation is the review |
“StrongDM had a swarm of agent testers simulating end users. They built their own simulation of Slack and Jira and Okta because real APIs have rate limits. They told their coding agents ‘build this’ and they did. They were spending $10,000 a day on tokens simulating all of these end users. It’s kind of similar to having a manual QA team — except one that never sleeps.” — Simon Willison · on StrongDM
This is where Nova AI is heading. Not tomorrow. But Product Builder + wave-based delivery + Vera’s Playwright suite (see §05 and §07) are designed to compose into this pattern as we scale.
5. Lifecycle Automation — Stage by Stage
Agentic engineering gives us the method. The next move is turning every repeatable step into a Claude Skill, a plugin, or a scheduled agent. Here’s the lifecycle we’re automating — from POC to live product on Nova AI Stack.
| Stage | What it is | Tools / Agents |
|---|---|---|
| 01 · POC | Generate, test, kill, repeat. Three prototypes per feature, not one. | Claude Code + Product Builder |
| 02 · Pitch & Business Idea | Deck, pitch, market validation. | Mira (PM agent) turns POC fields into delivery-ready narrative |
| 03 · Branding + Landing Page | Name, logo, voice, visual system, landing page. | Iris (marketing agent) drafts → Vincent approves |
| 04 · MVP Build | Ship on Nova AI Stack. Red/Green TDD. Agent-authored tests. | Dexter + Petro build · Ada reviews PRs |
| SUBSTRATE | Nova AI Stack | LiteLLM proxy · admin panel · payments · observability · Claude Skills library |
This is the pattern. Every dashboard we used to click through becomes a skill. Every weekly ritual becomes a scheduled agent. Every repetitive judgment becomes a curated context the AI reasons over. More automation, always.
6. Vibe Coding vs. Agentic Engineering
| Vibe Coding | Agentic Engineering | |
|---|---|---|
| Flow | Prompt → accept → ship | Spec → plan → generate → review → test |
| Approach | Frontend-first, feeling-led | Architecture-first, context-led |
| Tests | Optional, written last (if ever) | Red/Green TDD as the gate |
| Iterations | One shot, minimal review | Iterative, reviewed, owned, shipped |
| Fit for | Throwaways and weekends | Production, from day one |
“If you’re vibe coding something for yourself where the only person who gets hurt is you, go wild. The moment you’re vibe coding code for other people to use, that’s when you need to take a step back.” — Simon Willison · on the boundary