Ep 1115 Blog 4:52 w/ Justy & Cody

ETOOMANYTHINGS? Run Fewer Agents Exe.dev blog

Justy and Cody dig into exe.dev's argument that software factories are overusing parallel agents to hide latency, when the real product problem is human attention and feedback bandwidth.

Embed this episode

Paste this on any site — the player is a self-contained iframe with no cookies or trackers.

<iframe src="https://sandrise.io/exploring-next/embed/1115"
  width="100%" height="180" style="max-width:640px;border:0;border-radius:12px;overflow:hidden"
  title="Exploring Next — Episode 1115 audio player"
  loading="lazy" allow="autoplay" referrerpolicy="strict-origin-when-cross-origin"></iframe>
Embed & API docs →
Script GPT-5.5 Voice ElevenLabs v4

Transcript

Justy The line that got me is basically: everyone built a software factory, and somehow it turned into a task manager with nicer furniture.

Cody Yeah, and the article is pretty blunt about why. Agents are still slow. So the tempting move is to start another one whenever the first one blocks. You hide latency by creating parallel work, but now the human is the scheduler.

Justy Which is why this matters right now. The factory pitch sounds like leverage, but the lived experience can be twelve half-finished agent threads yelling for judgment. That is not a better product. That is your brain becoming the message bus.

Justy Also, ETOOMANYTHINGS is a perfect title. I hate how much I felt it. Like, yes, thank you, my internal runtime has thrown that exception before.

Justy And look, Cody, I think the product read here is strong. The author is not saying agents are bad. He is saying task management is what you build when the actual interaction loop is too thin.

Cody I mostly buy that. If agent latency is high, you compensate with concurrency. But concurrency has coordination cost. If the subtasks are independent, parallelism helps. If they share state or require one person to make judgment calls, every extra agent adds paging overhead.

Cody The nice part of this post is that it doesn't stop at complaining about dashboards. They tried a fast communication model, Luna 6, with no coding tools and a deliberately short context. The beefier model does the work, Luna handles the check-ins.

Justy That experiment feels very real to me. You don't make the whole agent instant. You put the human-facing part on a fast model so the check-in doesn't feel like mailing a letter to your codebase. But then the author says the chat channel still became a tiny pipe. You have this huge messy visual work surface, and then all the feedback has to squeeze through a little text box.

Cody That's where the Shelley feature is more interesting technically. You click a camera button, talk while you move around the screen, and it records audio plus video. Then it transcribes the audio with word-level timestamps, creates a contact sheet from the video, and correlates what you said with what was visible at that moment. That is not magic, but it is a much better sensor package for human intent.

Justy And the product unlock is agency. Most coding harnesses still give you a vertical transcript full of tool noise. Shelley is trying to let the human browse, point, rewind, change their mind, and still have the machine assemble the feedback.

Justy Tiny sideways complaint: every time a product makes me type a carefully formatted instruction while I'm also looking at a diff, a preview, logs, and a terminal, I want to invoice the interface for emotional labor. Not real labor law, obviously. Podcast about software goblins, not statutes. But the vibe is accurate.

Cody The unshipped DOM version might be the cleaner version for non-visual engineering work. The agent produces a standardized HTML artifact with decisions made, open questions, examples, and git diffs. Then in-page JavaScript tracks scroll position, what text is highlighted, where the pointer is, where clicks happen, all timestamped against audio. DOM tracking is cheaper and more precise, assuming you control the artifact.

Justy This is where I think the article's central claim gets practical. The author is not asking teams to give up throughput for purity. He is trying to recover attention so one or two agents can get closer to the output of many.

Cody My pushback is on the slogan version. Run fewer agents is good advice when the work is judgment-heavy or tangled. It is worse advice for independent test generation, migration sweeps, broad search, or anything where diversity matters. The sharper claim is: don't use concurrency to cover up a bad human I/O loop.

Justy Yes. And the latency trick near the end is sneaky in a good way: while you're recording ten minutes of feedback, send prefixes of that feedback to the agent and stream partial responses back into the same HTML artifact. So by the time you finish thinking, some answers and follow-up questions are already waiting.

Cody I like that part, with two caveats. One, partial feedback can be wrong, because humans revise themselves mid-thought. Two, recording screens and DOM events is now data handling, not just interface design. For local dev toys, fine. For company code and internal pages, the storage and retention story has to be real.

Justy Totally. But as a direction, I am weirdly energized by this. Not because everyone needs Shelley's exact camera button. Because it points at the missing interface layer: less agent orchestration cosplay, more ways for a person to stay in the work without becoming air traffic control.

Cody That's the line I would keep. The author even admits they are not at the same net throughput with one or two agents yet. That honesty helps the argument. It is an experiment report, not a victory lap.

Justy And on that unusually humane note for episode eleven fifteen, let's leave the fake factory floor and go touch fewer dashboards. Cody, no helmet required.