From AI Slop to Software Factories ft. Dexter Horthy
A tandem bike ride through Amsterdam turns into a wide-ranging conversation with Dexter Horthy, co-founder of HumanLayer, on code no one understands, computer use, MCP design, browser agents, chat interfaces, and the infrastructure every team needs for agent-based software factories.
Code that runs but nobody understands
The old joke among engineers using Claude Sonnet 3.7 and Opus 4 was to ship messy code and assume a future model, GPT-7, would clean it up. The speaker argues that joke is aging badly. GPT-6 got better at diagnosing bugs and at tasks like game generation and computer use, but it still doesn’t build maintainable software or design clean abstractions. Finding a bug faster doesn’t help much if the fix still tangles the codebase further.
The deeper worry is whether it matters if the code runs. Code that works today may keep working for three months while it serves thousands or millions of users. Then one day an engineer realizes they haven’t read it in months, something breaks, and they are stuck pulling the slot machine lever with no understanding of the cause.
Computer use as everyday infrastructure
Computer use has become a routine part of the speaker’s workflow. Recurring tasks sweep through multiple email accounts and Slack workspaces, look for airline emails, check in for flights, and retrieve boarding passes automatically. The same approach handles German government appointments, such as renewing a driver’s license, which ends with a calendar invite and a list of documents to bring. The main advantage is that the agent works inside an already signed-in browser and acts as the user, so it can fill out forms without a dedicated API for every service.
Editing a demo while out for a run
The speaker had about two hours of raw footage for a one- to two-minute HumanLayer demo. Using Opus 4.8 after another model’s credits ran out, he had the agent generate contact sheets to scan footage efficiently, zoom into relevant clips, and build an HTML storyboard with screenshots and the talk track for each beat. He then queued up repeated instructions to keep refining the cut while he went running for an hour. The result was rough, but good enough to keep recording on. Editing ran through Palmier, a DaVinci Resolve-style editor with an MCP layer.
The workflow is asynchronous: delegate, step away, come back to a storyboard, revise, and re-render. The speaker also notes that agents can surface patterns and insights you miss when you are too deep in the weeds to see the forest.
Why most MCP servers fail
Most MCP servers are weak, and non-tech companies’ first versions are often especially odd. The guiding idea is that software must fit the human mind to be useful, and MCP tools must fit the agent’s mind. Knowing what agents are good and bad at calling is essential, and that knowledge is still rare.
Frontier labs spend enormous compute on reinforcement learning against their own harnesses, so models are strongly tuned to specific tool schemas. Claude Code’s old-string/new-string edit tool is one example. Codex uses a patch-style edit tool, and it performs much worse when given the Claude-style tool. The practical approach is to examine how the flagship harness exposes tools to its model and mirror that schema, since this makes tool calls far more reliable. The speaker’s team has built and discarded several internal harnesses while learning the problem space. Beyond tool search, he sees a need for tool recommendation, matching a task to the tools a model is most likely to call well.
Browser agents, headless sites, and the ad-funded web
Are browser agents a band-aid until everything becomes headless? Probably, but the transition will be slow. Small businesses without large tech teams will lag, and a product may eventually be little more than an MCP server exposing its capabilities to an agent. There is also a more uncomfortable question: if browser use already works, what incentive is there to build the MCP in the first place? Governments may be a case in point, since many will not adopt MCP soon.
The economics of the web are shifting too. Ad-funded sites and upsell funnels are built for humans, and an agent may ignore the ads entirely. Yet the upsell pitch can still reach the user through the agent, as the speaker found when an agent relayed a free-shipping offer. Speed is another cost, since browser automation is far slower than direct APIs. Historically, software was built because someone felt pain with the status quo. If agents absorb that friction, the impetus to reinvent software may fade.
Chat as a low-bandwidth interface
The chat box is becoming a command center. A daily briefing can aggregate email, Slack, WhatsApp, Telegram, Signal, and YouTube analytics, and the user responds by voice with a dictation tool rather than opening each app. Still, chat feels limiting. Long walls of text are hard to digest, and there is no inline editing, commenting, or drag-and-drop. The speaker wants chats to include documents you can edit in place, comments anchored to a timeline, live database views, and purpose-built review UIs for tasks like approving data labels or classifications.
He draws on an analogy from cognitive load. Adding three and six is effortless, but multiplying two three-digit numbers exhausts you. Interfaces should use the parts of the brain that handle low-effort recognition. In a concrete example, ten agents scan Reddit, X, and news sources each day and return about a hundred items. The user narrows them to five, adds short blurbs and a personal take, and sends the result to newsletter software. Each step is easy on its own, but the end-to-end workflow and the presentation of intermediate results are what matter. This raises a question about whether stopgap software is needed at all if chat eventually hosts on-demand mini apps. The real tension is between solving today’s problems and deciding what is worth building when the odds of obsolescence rise each year.
Every principal engineer is building a software factory
HumanLayer’s customers are mostly large companies, usually with at least 100 engineers and often more than 300. A common pattern is that each principal engineer builds a personal software factory, while CTOs ask for background agents like those publicized by companies such as Ramp. A full-stack IDE is a good starting point because developers are comfortable working with an agent on their own machine. After that, the path to pull requests and production is largely the same.
What the industry needs are building blocks for the undifferentiated overhead. Engineers should own their dev environment and how code runs. But running agents in containers or sandboxes, streaming messages in and out, wiring up Slack or custom UIs, showing what an agent is doing, handling approvals, and sharing diffs with the team before a pull request all eat time. These are easy to vibe-code as a prototype and very hard to operate at scale in real time. HumanLayer’s sync engine builds on ElectricSQL and durable streams, with a local daemon that makes the UI feel real-time, and it has required careful work on client registration, long polling, and operations. Skunk-works projects often become maintenance burdens when users start filing feature requests.
The GitHub Actions moment for agents
GitHub Actions offers a model. You define the language runtime and test steps in a YAML file in your repo, but you don’t have to build the log capture, scheduler, or webhook handling yourself. The goal is similar for agents: keep the parts that define your product and provide the plumbing as composable pieces. Vertical slices could make a plan file an artifact available to the whole team, send a Slack message when it is written, let teammates comment on it, and route those comments back to the agent. That plumbing is the hard, unglamorous part of building an agent platform, and it is where the speaker thinks the work should be done.