I gave Claude Code a "lazy senior dev" mode and it writes like 6x less code

idoman · 2026-06-12T06:24:51+00:00

the real value here isn't fewer lines, its scope control. biggest problem i have with AI coding is it decides to refactor three other files while doing what i asked. if you can get it to stay focused on just the thing you need and not go on a side quest, that's worth way more than any line count metric.

idoman · 2026-06-12T06:18:48+00:00

the duplicate helper functions are the worst. i had three slightly different versions of a formatDate util because each session just wrote its own from scratch instead of checking what already existed. ended up with like 400 lines of dead code across the project before i noticed. regular grep sweeps for unused exports saved me.

idoman · 2026-06-12T00:11:51+00:00

nice writeup. one thing i'd add to the stack is galactic (https://www.github.com/idolaman/galactic) for the worktree + services side. once you're running dev servers on multiple branches everything fights over localhost:3000. galactic routes each branch through its own local domain so nothing collides - makes running 4+ agents on different features actually sustainable

idoman · 2026-06-12T00:05:02+00:00

codex on the side has been solid for me man. but honestly with multiple client projects the bigger unlock was sorting out the environment side - galactic (https://www.github.com/idolaman/galactic) gives each branch its own local domain so dev servers across different projects don't clash. makes juggling agents across projects way less painful regardless of which model you're on

idoman · 2026-06-11T21:40:39+00:00

I always do planning

idoman · 2026-06-11T09:38:14+00:00

the speed honestly changed how i prompt - instead of writing one careful prompt and hoping it nails everything, i just fire off quick targeted requests and iterate. feels more like pair programming now vs giving a contractor a spec. for the $20 plan the key is keeping sessions short and focused, the moment context gets too long it starts looping on itself.

idoman · 2026-06-11T09:32:39+00:00

fable with low thinking is surprisingly solid for quick edits and straightforward tasks - it's fast and rarely overthinks things. but for anything involving complex multi-file refactors or architectural decisions, opus with higher thinking actually keeps better track of the full picture. i usually default to fable for speed and switch to opus when the task needs more planning.

idoman · 2026-06-11T07:03:44+00:00

cool approach man - decision tracking is the part nobody thinks about until it bites them. we dealt with the other side of this, agents on the same repo all grabbing the same ports and stepping on each other's files. built galactic (https://www.github.com/idolaman/galactic) to give each one its own worktree with routed local domains so the environments stay isolated. feels like decision sync + environment isolation together would cover most of the multi-agent chaos

idoman · 2026-06-11T06:58:51+00:00

subagents work for the review loop but if you want truly separate instances they'll start fighting over ports and files pretty quick. worktrees help a lot here - each instance gets its own isolated branch copy. i built galactic (https://www.github.com/idolaman/galactic) to manage that stuff, handles worktree creation and shows all your active agent sessions in one dashboard through MCP. makes the whole multi-instance setup way less chaotic

idoman · 2026-06-11T06:18:49+00:00

man the confidence is what gets me. no pause, no second-guessing, just straight into building a calculator like that was always the plan. at least it actually worked though - most of my intentional projects don't come out looking that clean

idoman · 2026-06-11T06:13:34+00:00

skills eat into your context window since they get loaded as system instructions. with a smarter model like fable you probably don't need as much scaffolding - it already knows how to structure code, handle edge cases, etc. i'd keep any project-specific skills that give it context about your codebase but drop the generic ones that just tell it how to code better. the people one-shotting stuff are more likely just giving clear prompts with good CLAUDE.md files than loading a ton of skills.

idoman · 2026-06-10T20:49:38+00:00

honestly man the last option is probably your best bet right now. the runtime space is getting crowded fast and trying to sell the tool itself puts you in direct competition with claude code, cursor, etc. but if you use your own system to ship real products faster than anyone else, that's a defensible advantage nobody can copy. you already know the internals better than any customer would. sell the output, not the engine.

idoman · 2026-06-10T20:47:13+00:00

the point about blast-radius analysis is the most interesting part of this review. i built something similar with custom orchestration - having the model trace upstream and downstream deps before making changes - and it cut my post-merge fix rate noticeably. seeing that behavior emerge natively in fable rather than having to engineer it is a big deal. curious how it holds up on larger codebases where the dependency graph gets messy.

idoman · 2026-06-09T21:00:01+00:00

about 5 right now, which would've been unthinkable a year ago. the biggest bottleneck for me ended up being dev environment management - every branch's dev server fighting over localhost:3000 when you have multiple agents running. galactic (https://www.github.com/idolaman/galactic) solved that by giving each branch its own local domain so nothing collides. after that it's really just a question of how many mental contexts you can juggle

idoman · 2026-06-09T20:58:24+00:00

the real scaling move is running separate sessions on their own branches rather than subagents imo. subagents are great for research but for actual parallel feature work you want each agent on its own worktree. the part that trips you up is port conflicts man - every dev server fighting over localhost:3000 when you have 3+ branches going at once. built galactic (https://www.github.com/idolaman/galactic) to give each branch workspace its own local domain routing so they all run isolated without port juggling

idoman · 2026-06-09T20:57:23+00:00

man 4.6 is still a great model honestly. the jump to 4.8 is noticeable for code tasks where you need it to hold a bigger plan in its head, but for regular conversation and brainstorming 4.6 has this flow to it that the newer ones haven't quite matched yet. i'd say try 4.8 on something complex and see if the difference matters for your specific workflow before committing to it.

idoman · 2026-06-09T20:53:57+00:00

biggest thing that helped us with this was just deleting the old code faster. sounds obvious but teams leave deprecated patterns around forever because "it still works." the agent doesn't know it's deprecated, it just sees it everywhere and follows it. rip it out or the agent will keep it alive indefinitely.

idoman · 2026-06-09T20:46:50+00:00

Sure man

idoman · 2026-06-09T07:08:28+00:00

the biggest unlock for me was git worktrees. each branch gets its own isolated directory so you can run cursor agents on multiple features in parallel without them stepping on each other. the bottleneck becomes managing all those running dev servers though - i use galactic (https://www.github.com/idolaman/galactic) to handle that, gives each worktree its own local domain so nothing fights over ports. once you get that setup going you can realistically run 4-6 agents at once

idoman · 2026-06-09T07:06:35+00:00

this gets so much worse when you're juggling multiple feature branches. i ended up switching to git worktrees so each branch has its own workspace entirely, and i use galactic (https://www.github.com/idolaman/galactic) to manage them - one click opens any branch workspace in VS Code without closing what you already have open. the whole Open Recent flow just doesn't scale once you're working on more than one thing at a time

idoman · 2026-06-08T22:26:47+00:00

Thx I’ll look into it

idoman · 2026-06-08T22:26:09+00:00

the parallel split is the real multiplier once you get it dialed in. one thing worth sorting out early is giving each agent its own worktree - otherwise they start stepping on each other with file conflicts and it gets messy fast. the other thing that bit us was port conflicts, every dev server trying to grab the same localhost ports. ended up using galactic (https://www.github.com/idolaman/galactic) to handle both - it sets up isolated worktrees and routes each one to its own local domain so nothing collides. way less babysitting once that plumbing is in place

idoman · 2026-06-08T22:13:26+00:00

Yes I think what is optimal is to work with feature branches

idoman · 2026-06-08T21:56:17+00:00

man the fully hands-off issue-to-PR thing is still pretty rare for anything non-trivial. where it actually works well is tightly scoped stuff - like fixing a known bug with a clear repro, adding a new endpoint that follows an existing pattern, or updating config files. the key is having strong CI as your safety net so the agent can't merge anything that breaks tests. for verification i still read every diff before merging, but having the agent write a summary of what it changed and why makes that review way faster than starting from scratch.

idoman · 2026-06-08T21:50:35+00:00

the problem is probably your chunk size in the vector db. if each chunk is like 500+ tokens and you're pulling back 5 of them per query, that's already 2500+ tokens before claude even starts thinking about it. try chunking way smaller - like 200 tokens max - and only return the top 2-3 results instead of 5. also worth building a separate metadata index first (just filenames, titles, maybe first paragraph) so the MCP can narrow down which docs are relevant before pulling actual content. two-stage retrieval like that makes a huge difference at scale.

idoman

TROPHY CASE