Dexter Horthy says newer models diagnose bugs better, but still struggle to design maintainable abstractions and codebases.
2
Computer use lets Demetrios Brinkmann automate browser tasks such as checking in for flights, retrieving boarding passes, and booking government appointments.
3
HumanLayer is building infrastructure for software factories, including agent synchronization, approvals, streaming, artifacts, and team review.
Summary
Dexter Horthy and Demetrios Brinkmann discuss what happens when engineers let coding agents produce software they do not understand. Horthy argues that newer models can diagnose problems and use computers well, but still create messy abstractions that become difficult to maintain. They describe practical computer-use workflows for email, flights, government appointments, daily briefings, and browser-based research. Horthy also explains how he used Opus 4.8 and Palmier MCP to turn raw footage into a rough demo while he was away. The conversation then moves to the future of websites, MCPs, APIs, browser agents, and richer interfaces than chat. Horthy says each principal engineer is building a personal software factory, but much of the work becomes plumbing for synchronization, approvals, streaming, and agent communication. HumanLayer aims to provide reusable building blocks for that infrastructure, in the same way GitHub Actions removed much of the work involved in building a CI system.
Better coding models still produce code that becomes hard to maintain
Dexter Horthy says GPT-6 improved at areas where earlier models were weak, including Blender, game creation, and computer use. It still did not become better at building maintainable software. Models can diagnose bugs, he says, but their fixes still lead to poor abstractions and spaghetti code. The old joke was that engineers could ignore messy code because GPT-7 would repair it later. Horthy's experience is that GPT-6 has not made that safe. The problem appears months later, when a system has users and nobody on the team remembers why the code works.
Computer use makes browser-based automation useful for ordinary tasks
Demetrios Brinkmann describes using computer use for recurring tasks across multiple email accounts and Slack workspaces. A scheduled task watches for flight emails, fills out the airline's form, and retrieves the boarding pass. It also booked a government appointment for renewing his license, then placed the appointment details and required documents in his calendar. The advantage is that the agent can act through an already signed-in browser when no useful API or connector exists. Brinkmann says the ability to fill out forms is especially valuable because it avoids waiting for every service to expose an API.
Good MCP tools should match the way an agent was trained to use tools
Horthy says most MCP servers are poor because their designers do not understand how agents select and call tools. He compares a useful MCP to an axe that fits the human hand, then reframes the idea around an agent's mind. His approach is to inspect the tools exposed by the flagship harness for a model and mirror them. Claude Code tools should look like Claude Code tools, while Codex works better with its patch-style edit tool than with Claude Code's old-string and new-string interface. This takes advantage of months of reinforcement learning and large amounts of compute spent teaching models particular tool patterns.
An agent can turn raw footage into a workable draft while its owner is away
Horthy gives Opus 4.8 two hours of raw footage, an outline, and an ElevenLabs key. He asks it to create contact sheets, inspect clips, build a storyboard with screenshots and narration, and keep iterating while he goes for a run. The result is rough and not ready to ship, but it is good enough to reveal useful material and provide a starting point. He also gives the workflow speech-to-text access so the system can use what he says while recording. He describes this as an asynchronous workflow: provide the material, let the agent work, review the draft, and then make targeted changes.
Browser agents may delay the need for better software interfaces
Brinkmann and Horthy discuss whether browser agents are temporary tools until services expose APIs and MCP servers. A browser agent can already use websites built for humans, including government services that may not adopt MCP soon. That reduces the immediate pressure to rebuild those services. They also question the business model of websites funded by advertising or upselling when an agent ignores page design and negotiates directly with the user. Horthy expects some products to become an MCP over a system of record or an interface to a real-world service, while browser use remains useful wherever headless access does not exist.
The speakers argue that a wall of text is a poor way for an agent to communicate complex work. They want editable cards, comments, document blocks, database views, and interfaces that fit the task. Horthy gives video editing as an example: he wants to comment directly on a timeline timestamp and have the agent act on that comment. HumanLayer's broader idea is to let people review and approve work through purpose-built interfaces, whether the task is data labeling, classification, or sending an email. For Horthy, context includes how information is presented to a particular person, because the right interface can reduce the effort needed to make a decision.
A software factory includes plumbing that individual teams should not have to rebuild
Horthy says principal engineers across companies are building personal software factories, while CTOs want background agents and similar systems. The hard part is often the infrastructure around the agent: streaming messages, showing its work, handling approvals, syncing local and cloud state, sharing diffs, and making artifacts available to a team. HumanLayer has spent substantial effort on a sync engine using ElectricSQL and durable streams. Horthy compares this work with GitHub Actions. Teams define their runtime and tests, while GitHub handles scheduling, logs, webhooks, and execution wiring. He wants similar building blocks for the parts of an agent system that teams need but do not want to maintain themselves.
"We got better at like diagnosing bugs, but the fixes to those bugs end up still being quite uh"Dexter Horthy04:24
Who should watch
You are letting coding agents produce software and worry that the team will not understand it a few months later.
You are building browser or computer-use workflows and need a practical view of where MCPs, APIs, and browser automation fit.
You are building an internal agent platform and want to separate product-specific work from synchronization, approvals, streaming, and execution plumbing.
