What Does Sustainable Work With Coding Agents Look Like?

Scott always rolls his own templates — trivial in the agent era — unless the platform (he names PocketBase) builds them in; his pain point is cost, since he hates paying for occasional transactional email, and he currently sends through Resend's API while eyeing Postmark (free at 100 emails a month) and Amazon SES's pay-per-email for low-volume side projects. Wes's stack is React's render-to-string with inlined CSS for reusable templates, sent over plain SMTP through any provider like SendGrid, precisely so no single company owns his pipeline. Both converge on the portability rule: always send through standard APIs or SMTP, because deliverability is fragile — if 2% of mail suddenly lands in spam, that is real lost revenue, which is why Resend is such a big company — and a standards-based sender can swap providers the moment it happens.

Scott's mechanism list: harness hooks like Claude Code's can deterministically intercept a dangerous call — detect an rm attempt, block it, and tell the agent what to do instead — plus deny lists, linters, and tests; he wrote frame-rate tests that spin up an agent browser after each implemented feature and fail under about 55 fps. For routing he uses deterministic automations: when he asked an agent why his Jellyfin was down and it spun up an unrequested replacement container, he wired a status-check automation so the agent now gets state plus instructions instead of improvising. Rules in agents.md ('don't write fallbacks for absolutely everything') curb feature bloat, isolation and containers bound the blast radius (their producer CJ's recommendation), and Wes adds the human habit: he watches the output and spams escape the moment the agent wanders. Scott's caveat answers the interview question: there are still times the agent does what it wants, so if it derails constantly, that is on you — you are yoloing the prompts too much and need to stay closer.

Scott has not found a steering pattern he loves. He dislikes by-the-way features — that queued turn often takes too long — and his rule is that stepping in is usually urgent, so he defaults to stopping the run regardless. The one exception he names is Claude Code, which he lets pick up mid-run because it handles the injection particularly well; even then he does not mind hitting stop, since the agent usually is not doing damage and the next turn, twenty or thirty seconds away, is a fine place to add context or change course. Wes closes unsatisfied but decisive: none of them are great, and Codex's queue-next-turn behavior is his favorite so far.

Scott warns that some engineers carry an ideological anger toward AI tooling and will not be moved, and that many resisters have not registered how much better the models have become; the 'look at this crazy one-prompt thing' demo actively hurts. What works instead: lunch-and-learn sessions showing real workflows — how it improves your development flow and your code — rather than stunts; relating to the person, since this is a people problem about the wall they have built. Wes adds that leadership must visibly share how they themselves use the tool, ideally in a company Slack channel like Sentry's, where top engineers trade questions, criticism, and tips; he loves that channel. Scott's last suggestion is internal screen recordings of an actual debugging process — the bug, the steps, the benefit at the other end — even if that format does poorly publicly.

Scott says everyone is hunting the golden-goose UI right now. Codex has merged into ChatGPT as one app, and the two big general-purpose agents he names — Grokbot and Facebook's Muse — are chat applications with few knobs, aimed at daily tasks rather than coding. His read: plain Telegram back-and-forth is probably not it, because you need somewhat more control over the UI — but not so much that it overwhelms, which is why Grokbot and Muse lean chat-heavy. Wes testifies from the custom end: his own purpose-built setup is great when it works but 'breaks all the gosh darn time' and earns a weekly 'the AI is not working again' message from his wife; third-party options like the Hermes desktop app are really good, though. Scott's position lands in between: he still runs his custom one, and it is kind of annoying.

Scott answers from his own struggle: AI coding is like playing a game with Game Genie — the cheats are fun for five minutes, and then the challenge is gone, and coding's deep digging is exactly the part you lose when the workflow becomes 'agent, fix this'. He also acknowledges AI coding is more exhausting for other reasons — broken flow and what their listener mental-health survey surfaced. What restored his drive was moving up a layer: finding the joy in strategy, deep UI refinement, and larger structures and architectures — and in improving his own process, harness, and skills, so that the code becomes a result of an improved process rather than something improved by his hands directly. Wes's whole reply: 'I agree. Well put.'

Scott grants that harnesses are genuinely hard — caching, model routing, efficiency — which is why harness experts exist. But he has never considered rolling his own despite his build-it-yourself instincts: custom tooling around a harness makes sense, building the harness itself does not. His verdict on B Murf's either/or: the answer is in the middle — the company went left, the listener went right, and sadly the truth is between the monolithic harness and human-orchestrated micro-agents. Wes's addendum undercuts the shelf life of any answer: much of what they learned in the last eight months already does not matter — he now doubts they still need the Context7 MCP for docs because search got so good — and Scott seconds it with his 3D-printable rendering story (a library that collapsed a year ago now works), adding that installed skills often just add token churn, so audit which pieces actually help.