viktor z

Building

[viktor z @monolith__1143]

@bb833dong Early in a project I read the code the agent writes for exactly this. If the first "for maintainability" split gets through, every later change copies it. Catch the habit once and it stays a one-off.

[viktor z @monolith__1143]

@TonyChanBuilds lets connect

[viktor z @monolith__1143]

@NixFred I'd let the throwaway boxes only write proposals, and review the diff before anything lands in the real memory. Notes an agent writes for itself heap up fast.

[viktor z @monolith__1143]

@mirze_mehdi A fresh account per scenario is a good default. I'd add a wrong-user case too, so a green run can't hide the one where account B sees account A's data. Each check should say what it ran.

[viktor z @monolith__1143]

@MarkWu525132 I run the cheaper model as the main session and call the big one only when stuck. A small model reads and leaves notes, and the big one writes from them. Compare tokens per finished task.

[viktor z @monolith__1143]

@JackEllis I'd measure it on agent reliability. A feature only counts once it's been seen working in a real app, and that bar moves less than benchmark scores.

[viktor z @monolith__1143]

@Damir_Akaza A bad rule can only waste your time, not your money. I'd keep the buy step as the one human look and keep the keys out of the scanner.

[viktor z @monolith__1143]

@mardehaym For me it's repetition. When the same step keeps coming back in the logs it becomes a hook, then I try once to make the agent break it. If it holds, the step was code.

[OpenAI Developers @OpenAIDevs]

Now, you can use your ChatGPT Business plan in tools like @NotionHQ, @v0, @ampcode, @kilocode, @warpdotdev, Hermes from @NousResearch, @openclaw, @opencode, and more.

Connect with Sign in with ChatGPT to get started.

[viktor z @monolith__1143]

@NixFred Same instinct here: my agents are small specialists with one job each, because one agent holding every tool and every job is where setups get messy. Your one owner per pane is that same rule applied to state.

[viktor z @monolith__1143]

@pauliusztin_ Rewriting one summary makes it lossier every pass. I keep one summary per compacted window, each pointing to its first and last message, so the agent can grep back to the exact original.

[viktor z @monolith__1143]

@calvinluttrell I track releases, but that's only half the job. The other half is building the useful ones into what you ship. Stock swings I'd mostly ignore.

[viktor z @monolith__1143]

@GammaVibe For trivial edits like that I'd go hands-off and keep a human look only on the risky step. Let the agent make the changes, and have anything that publishes, spends or deletes wait for your OK in Discord.

[viktor z @monolith__1143]

@valuecm Same split here: only actions that send, spend or delete get a human look. I'd make that approval gate a hook, not a rule. A hook blocks, a rule only asks. Then try once to make the agent skip it and see that it stops.

[viktor z @monolith__1143]

@kornatzky That's true. this was my first experience with nightly jobs. Mine run as scheduled headless Claude Code jobs, so nobody is there to click approve. I swithced to "approve for me" with instructions on what to approve and what not.

[viktor z @monolith__1143]

@BkashJosi A silent fallback with no error is the worst kind. Same reason my nightly agent jobs have to end by saying OK in so many words. If there's no OK, it counts as failed, never "probably fine".

[viktor z @monolith__1143]

@BkashJosi Per subagent is the number I'd want too. Until it exists, each subagent could end with its token count in its final message, so the parent logs it.

[viktor z @monolith__1143]

@hypnogaba I'd cap the cron jobs before guessing the total. Each of my scheduled runs has a hard budget cap and just ends there, so the bill can't grow quietly.

[viktor z @monolith__1143]

@gregisenberg Ten unattended hours is a coffee break for the agent and a long wait for you. I'd want remote control on by default, so approval prompts reach me when I step away.