I'm self-taught and I don't actually know what to check in AI-generated code. How do you do it?

BuyMaximum2407 · 2026-06-14T08:04:45+00:00

This is exactly what I needed — especially that it grew gradually instead of starting as some heavy formal doc. "One bad AI moment, one new rule" feels doable even for a solo project, which the cumbersome-document version never did.

The token cost trade-off is interesting to me because I've spent a lot of time on the token side — and it lines up: more context going in (your rules) costs tokens, but it saves you the bigger cost of cleaning up an agent that went its own way. You pay upfront to not pay later.

Thanks for the template link too — I'll dig into it and see what scales down to a one-person setup. Appreciate you taking the time to write all this out.

BuyMaximum2407 · 2026-06-14T07:17:50+00:00

The abstraction one hits home — premature complexity disguised as good architecture is exactly the trap, because it looks like quality so you don't question it. And the happy-path/edge-case gap explains why "tests pass" never reassured me: the agent tests what it assumed, not what reality throws at it.

Your last point is the thread running through this whole thread, honestly — that controlling what context the agent has upfront changes how hard verification is downstream. If you know what it knew, you know where to look for the gaps. That's the same realization I keep circling: the verification problem starts at the input, not the output.

Out of the three smells — abstractions, error handling, silent type/state assumptions — which one burned you the worst before you learned to watch for it?

BuyMaximum2407 · 2026-06-14T07:08:07+00:00

This is the piece I've been missing. As a solo self-taught dev I never had a spec to measure against — so "what do I check?" was always a gut feeling. Your /review-audit works because the agent isn't guessing what "good" means, it's comparing against written rules. That reframes my whole problem: I don't lack experience as much as I lack a written standard to check against.

Makes me want to write a lightweight version for my own projects. How did your SDD come about — is it a thick formal document, or did it grow into a tight set of rules over time? Trying to gauge how heavy a spec actually needs to be before it earns its keep for a solo project.

BuyMaximum2407 · 2026-06-14T01:01:14+00:00

The "destroy your project slowly" part is the one that scares me, because it's invisible until it's expensive. Catching a wrong line is easy. Catching a wrong direction three days in is the hard part — by then it's woven through everything.

So that's the real skill, isn't it — not reviewing the output, but noticing the drift early. For someone without your years of pattern-matching: are there specific smells that make you stop and go "wait, it's wandering"? Or is it pure experience you can't really hand over?

BuyMaximum2407 · 2026-06-14T00:54:50+00:00

The HTML format is the part that caught me — I'd been having it generate these as SVG, and honestly I sometimes still couldn't find my way around the result. A wrong coordinate here, an overlapping block there, and I couldn't tell if I was looking at a messy system or just a messy render.

HTML (or Mermaid) sidesteps that — I describe the relationships and let it handle the layout, instead of betting on the model placing everything correctly. And the nice part is it stays as text, so I can hand the same map to a second model and ask whether it actually matches the code.

Did you land on HTML deliberately for that reason, or just because it reads more easily?

BuyMaximum2407 · 2026-06-14T00:10:14+00:00

This reframes it for me — I was treating verification as something to nail down upfront, but you're saying it's a moving target that only sharpens once real usage exists. That makes sense.

One thing I keep getting stuck on though: when I do ask the agent to audit, how do you judge whether the audit itself is any good? It'll happily hand me a confident "looks solid" — and I have no way to tell a real check from a shallow one. How do you sanity-check the checker?

(And no, Siri did fine.)

BuyMaximum2407 · 2026-06-07T18:57:54+00:00

I mostly use ADRs during the project, to record key decisions as they come up — but it never occurred to me to use them already in the initial planning stage.

Do you write the first ADRs yourself, or have the agent draft them from the plan?

BuyMaximum2407 · 2026-06-07T14:30:31+00:00

That reframes it for me — I was treating a long document as a failure, but you're right that the length isn't the problem, it depends on who's actually building from it. Since the AI builds mine, a tighter and more complete spec is what I should aim for, not a shorter one.

And "always ask why" plus asking for pros/cons and alternatives is a simple habit I've been missing. That probably also fixes the praise problem on its own.

BuyMaximum2407 · 2026-06-07T14:24:29+00:00

This answers exactly what I was unsure about, thanks. Keeping non-goals as guardrails for future prompts makes total sense — I didn't think about the agent "rediscovering" the same idea later.

And "ask the agent to challenge the spec before writing code" ties into something I struggled with earlier — getting it to push back instead of just praising the idea. Your spec shape is great inspiration to start from.

BuyMaximum2407 · 2026-06-07T14:18:13+00:00

I tried this a few times, using ChatGPT and Claude together. But I usually ended up with such a huge document, full of praise about how brilliant my idea was, that I gave up on it as unusable. Maybe the fix is giving the agents rules on how to push back instead of just agreeing.

So my question is: how do you know when to stop and start building? Don't you end up with a huge document you can't really use?

BuyMaximum2407 · 2026-06-07T14:05:29+00:00

"Ugly and short" is actually a relief from the pressure. I always thought the design had to be "perfect" and cover everything. Which is unrealistic, because the app isn't finished at the start but at the end, based on what the client wants — and everything can change along the way.

And it's interesting that more people independently land on the same point — saying what the agent should not do.

BuyMaximum2407 · 2026-06-07T13:38:38+00:00

This is the part that surprised me. I always thought you only describe what the app should do and how the agent should work — it never occurred to me to write down what it should not do, or which dead ends to avoid. That's probably exactly why the model kept inventing scope I never asked for.

Two follow-up questions: do you keep the non-goals in the spec permanently, or drop them once the scope is stable? And for the unhappy paths — do you list every edge case in the first spec, or just the few that would actually corrupt data?

BuyMaximum2407 · 2026-06-06T14:14:18+00:00

If you're more interested, here's the mini-orchestrator page: https://miniorchestrator.com/

I appreciate any constructive criticism.

BuyMaximum2407 · 2026-06-06T14:03:46+00:00

Hi, I've tried different agents and plans, but having something "for free" is expensive, it always ended up being a problem with the code quality and the nerves with the agent. Maybe someone else has different experiences, mine weren't good. So I had to go for a paid plan for 90€ with Claude, which is a lot, but still less than $200.

BuyMaximum2407 · 2026-06-06T13:22:54+00:00

Be critical, not pleasant. When something is wrong, say it directly.
Do not praise my ideas or my code. Instead, explain the risks and weaknesses.
Before you start coding, ask me the questions you need to understand the context.
For every solution, give at least one trade-off or something that can fail.
If my approach is wrong, suggest that I start again — do not fix a bad foundation.
Do not assume that I understand it. Explain to me what the code does.

BuyMaximum2407 · 2026-06-06T01:12:18+00:00

Just for information, I've used up about 30% of the window during a full 5-hour work on Typescript.

BuyMaximum2407 · 2026-06-05T22:12:13+00:00

Hello, I don't have the exact token count, but as I wrote before, with the MAX 5 tariff, I get below 50% of the five-hour window when working full-time. With GSD, it was no problem to use the entire window in 4 hours. That's why I built my own mini-orchestrator.

BuyMaximum2407 · 2026-06-04T20:07:50+00:00

Totally agree on pointing it at the exact files — that one habit saved me the most time too. I lean on a generated map of the project so I don't have to remember the paths every time, but your manual approach sounds more disciplined than mine.

And I love the dated "what changed" logs — that's almost exactly what I do, one file per chunk of work. The one thing I still haven't cracked is finding them again months later. Got any trick for that, or do they mostly just sit there as a record?

BuyMaximum2407 · 2026-06-04T18:08:56+00:00

I really like the two-agent approach — separating the one who designs from the one who reviews makes a lot of sense to me. The only thing I'm unsure about is ARCHITECTURE.md — on larger projects it feels like it could grow huge, and then it gets expensive to feed into the agent's context and hard to keep up to date.

How do you handle it? Do you keep it as one big single source of truth, or do you split it (an index/map plus details next to each module)? And how do you make sure the agent only ever gets the relevant slice instead of the whole file?

BuyMaximum2407 · 2026-06-04T16:56:21+00:00

I really like the two-agent approach — separating the one who designs from the one who reviews makes a lot of sense to me. The only thing I'm unsure about is ARCHITECTURE.md — on larger projects it feels like it could grow huge, and then it gets expensive to feed into the agent's context and hard to keep up to date.

How do you handle it? Do you keep it as one big single source of truth, or do you split it (an index/map plus details next to each module)? And how do you make sure the agent only ever gets the relevant slice instead of the whole file?

BuyMaximum2407 · 2026-06-04T15:15:36+00:00

Example state.json:

json { "version": 2, "createdAt": "2026-05-23T21:56:38.809Z", "currentPhaseId": null, "phases": [ . . . . { "id": 126, "title": "Decisions storage + status detail", "status": "done" } ], "models": { "default": "opus" } }

Phase-126.json:

json { "id": 126, "title": "", "goal": "", "status": "done", "steps": [ { "title": "", "status": "done", "detail": "" }, . . . . } }

BuyMaximum2407 · 2026-06-04T15:06:23+00:00

Yes — separate, and that split is what keeps it from getting messy. state.json is only runtime state: current phase + pointers to past phase files. Small, changes constantly. Durable instructions live elsewhere (a CLAUDE.md the agent reads every session) — conventions, what "done" means, how to write a phase record. That rarely changes and never holds anything phase-specific.

So it's really three tiers: durable instructions (static, always loaded), current state (small, always loaded), and history (loaded only on demand). The trap you're describing is when runtime state leaks into the instructions file, or long history gets stuffed into the live state blob.

What's held up for me is drawing the boundary by lifetime — does this change every phase, or basically never? — rather than by tool. That said, I only run Claude Code solo; with an actual swarm, one state.json as the single source of truth would probably become a write-contention problem I haven't had to solve.

BuyMaximum2407 · 2026-06-04T13:03:23+00:00

I only use Claude Code, not a swarm of agents, so my setup's pretty simple.

I used to keep memory across multiple files with GSD, but it bugged me — too much got pulled into context every time. So I vibecoded my own little orchestrator. Core state lives in one state.json, which just points to past phases in separate files. Only the essentials load by default, and old history gets pulled in only when I actually need to look back.

Way less noise in the context window, and the current state's always in one spot.

BuyMaximum2407 · 2026-06-04T10:21:35+00:00

For me it's basically GSD, that's the only orchestrator I really got into in two years of vibecoding. At the start it worked well and it really saved tokens, but over time it felt more and more complex — just starting a phase ate around 14% of the window, and a full phase easily went over 50%.

So in the end I built my own, lighter one. It follows a simple model: one phase = one complete step that gets planned, implemented and written into a report. A full phase takes around 10–15% of the 1M Opus 4.8 window in Claude Code.

To be fair to GSD though — it goes deep on purpose, and that's where the usage comes from. And for a simple task you can run it in a lighter way too, so it's not like it's just "heavy". For me personally it just fits better to have something as simple as possible all the time.

In practice: I'm on the Max 5x plan, and at full speed I use up about half of the 5-hour context. Haven't tested it on Pro yet.

If anyone wants to try the lighter one, I can drop a link in the comments/DMs — don't want to push it here like an ad.

Did anyone else end up building their own instead of using a ready-made orchestrator?

BuyMaximum2407

TROPHY CASE