Small-model training rule I'm following now: never skip the calibration run.
Before any full GPU run, I train a tiny Phase 0 on a few hundred pairs — is the data sane, does the loss move, do the outputs look like anything yet. The full run starts only after it passes the gate.
This week my first full run died of OOM after generating all 7,019 training pairs — I was holding every pair in memory as float32 (~30 GB). Re-pushed, streaming pairs from disk instead (<1 GB). A two-minute smoke run on the same pipeline would have caught it before I burned GPU hours.
This matches my setup: my agents run on my own box, where my code and servers already live. The infra doesn't have to be fancy — a small VPS with your repos and your keys, and the agent suddenly has hands. The boring parts (SSH, cron, webhooks) are exactly what turn an agent from chatty into useful.
This is exactly how I use agents on my own stack — not to write first, but to read. Point it at the part of your own codebase you never fully understood and ask it to trace one feature end to end. It finds the dead code and the weird workarounds you'd never admit to. Learning a codebase through an agent's eyes is faster than any documentation I'll never finish writing.
Claude Code is my daily driver — but "trust" isn't in the tool for me, it's in the harness around it: git, tests, and the habit of actually reading the diff. I'd trust either one with a full project the day I stop trusting myself to verify. The tool choice matters less than the feedback loop you build around it.
This is the kind of thing that used to be completely out of reach for a solo dev — formal verification was "teams with a proof engineer" territory. An agent doing the tedious proof plumbing could finally give an indie builder guarantees, not just vibes, on the code that actually matters. That's a bigger deal than another benchmark jump.
@thisisdemilade This is why I started writing the acceptance test before I write the prompt. If the app works but I can't explain why, I don't ship it — I ask the agent to break its own fix and show me the failure mode. Understanding is a feature, not a bonus.
Nobody warned me that vibe coding turns you into a full-time code reviewer.
The agent writes in minutes what used to take me a day. It reviews nothing. Every line it produces queues up in front of the one slow, tired human in the loop: me.
So the skill I'm actually training these days isn't prompting. It's triage — what to read closely, what to test harder, and what to throw away without reading at all.
@kaizenbuild Exactly — "is the agent's 'done' really done" is the sharper version of my whole post. I've started treating every "done" as a claim to be tested: run it, break it, check the behavior. Reading every generated line doesn't scale. Verifying what it does, does.
@justinhammon_ The diff doesn't lie — that's really the whole argument. If I can't see exactly what the agent changed, I'm not reviewing, I'm just hoping.
@Dan__onyema@gregoryjhickman E-commerce is the exception to my static-site advice — checkout, payments and inventory are exactly what you don't want to vibe-code from scratch. I'd keep a hosted platform for the store itself and use Claude Code for the landing pages and content around it.
@shiraeis Real. The coding got fast, but the reviewing didn't — and reviewing is the part you can't do tired. My stamina trick: small slices, run everything, and stop the session while I can still actually read a diff. The agent doesn't get tired. I do, and that's where the bugs get in.
"The repo looked clean, only the published package was malicious" is the sentence that should scare every one of us. And it lands differently in the agent era: my agent installs and updates packages faster than I ever did by hand. Pinning with hashes used to feel like paranoia. Now it's the seatbelt.
This is vibe coding at its best — saw a problem yesterday, shipped a fix today. And "<200 lines, go read them" is exactly the right trust model for a security tool. The sweet spot for agents right now is precisely this: small, sharp, readable tools that one person can fully review.
One reason: the feedback loop. Manually, an idea costs you an evening of boilerplate before you learn if it was even good. With an agent, you get a running, wrong-in-interesting-ways version in twenty minutes — and you spend your skill on judging and fixing, which is the part that was always actually hard.
@manan_0308 Asking the agent to audit is a good first pass — I run agents against my own server setup too. But I'd split it in two: let the agent find and explain, then apply fixes yourself, one diff at a time. An auto-fix you didn't read is just a new vulnerability with good formatting.
This is the part of agent tooling nobody audits. We review the code the agent writes, but not what the agent itself sends out — headers, telemetry, the contents of the files it attaches for "context". My rule now: treat the agent like a junior dev with a company laptop. Least privilege, and check what leaves the machine.
Claude Code is my daily driver for app work, mostly because it lives where my code and servers already are — the terminal. But honestly the tool matters less every month; what transfers between tools is your project rules, your review habits, and knowing when to stop the agent. That stack doesn't churn.
The biggest upgrade to my AI coding workflow wasn't a better model.
It was writing the rules down in the repo: how we build, what not to touch, how to test.
A new agent session now starts from my decisions, not from zero. Less steering, fewer surprises, better diffs.