In this Beyond Coding interview, lead architect Carlos Kelkboom makes a simple but demanding case: faster code generation is useful only while engineers still understand the system they are changing. He describes the files and types he writes before an agent starts, the read-only conversational agent that coordinates his work, and the point at which he discards a functioning result because he cannot explain it. This is his engineering practice, not a universal recipe for every team.
Carlos owns the architecture up front, gives implementation agents bounded work, and reviews the result as software he will maintain. His most memorable rule is to throw away generated code he does not understand, even when it runs. He prefers large, well-specified implementation passes in his own workflow, but that preference depends on a clear scaffold and strong verification, not blind acceptance.
Watch the Interview
Credit: Carlos Kelkboom's interview on Beyond Coding is the source of the workflow and opinions summarized here. Follow the chapter links to hear each point in context. The benchmark and Git documentation below are independent references, not endorsements of his entire approach.
Put the Architecture on the Page First
At 11:54, Carlos says he manually creates directories and files, then adds comments, type or class names, function signatures, and examples. Depending on the project, that takes roughly 20 minutes to an hour. In his compiler example, he lays out the lexer, language specification, and path from syntax tree to intermediate representation before delegating implementation. The goal is to encode choices about boundaries and data flow while they are still cheap to change.
He reports that unguided agents can produce working features while adding duplication, weak cohesion, or oversized objects that make the next change harder. His advice is not to write the entire program manually; it is to decide which interfaces and constraints are too consequential to leave implicit. When the domain is unfamiliar, he looks at existing projects and asks for critique rather than treating an agent's first structure as authoritative.
The research he mentions has a narrower conclusion. In the revised SlopCodeBench paper, agents repeatedly extend their own solutions across 36 problems and 196 checkpoints. The authors report rising structural erosion in 77% of evaluated trajectories. That supports concern about this benchmark's iterative tasks; it does not prove every coding agent fails on every real maintenance job or that one-shot builds are always better.
Keep the Conversation Separate From the Write
At 58:18, Carlos explains why his main agent does not edit files or change his machine: he wants room to ask questions and sharpen the task before a tool eagerly begins coding. That coordinator gathers context and delegates to sub-agents when he believes the assignment is clear. His stated confidence threshold and background model are details of his setup, not a standard safety guarantee.
He also uses parallel Git worktrees to try alternate implementations without having agents overwrite the same checkout. Git's documentation confirms that a repository can have multiple working trees. That isolation makes comparison possible; it does not decide which candidate is maintainable. A human still has to inspect the diffs, tests, and integration costs before merging.
Carlos favors a large one-shot task once he has settled the architecture and request. That is a personal response to the iterative failures he has seen, not a reason to turn off incremental verification. A team can keep the same principle of clear boundaries before execution while shipping in smaller reviewed steps.
Give the Agent a Trail, Not a Dump
His context harness starts with brief pointers to relevant information, then follows paths, links, or commit hashes into deeper material. He says he often lets an agent inspect a commit or diff before the full file, using the change history to explain why the current code looks the way it does. The underlying graph is distributed Markdown plus indexed and keyword search, not necessarily a graph database. Hear that design at 53:33.
A modest version for a small team could be a short architecture index with each module's owner, purpose, public interfaces, invariants, and links to tests or design decisions. That is an adaptation of Carlos's idea, not a claim that his own project uses those exact fields. The test is whether an engineer or agent can find the right context without pasting the entire repository into a prompt.
Maintainability Is a Human and Team Decision
At 1:03:07, Carlos says he discards code he cannot understand. Tests passing is necessary but insufficient when a team must debug, extend, and review the change later. Near the end, he discusses deterministic checks and mutation testing as ways to challenge generated code rather than relying on a pleasant-looking diff alone. Use those tools where they fit the language and risk; they are aids to review, not a substitute for it.
The interview also raises a team problem: when engineers work privately with agents, how do newer developers learn to reason about architecture and review? Carlos worries about losing shared language and mentorship. His proposal to reduce or eliminate dynamic heap allocation is similarly a design opinion, especially relevant to the constrained or deterministic systems he imagines, not an established requirement for ordinary application code. The practical lesson is to make resource and failure behavior explicit where the domain needs it.
Try this on one authorized change: write the module boundary and acceptance test first; let an agent implement only within that scope; inspect the diff, run the tests, and ask a teammate to explain the result. If neither of you can explain a surprising piece of code, simplify or reject it before it becomes the next person's maintenance burden.
Jump to the Video
| Time | Segment |
|---|---|
| 00:00 | Why Carlos rejects working code |
| 00:53 | Pull requests and teamwork |
| 03:50 | The unfinished-project trap |
| 06:06 | The solo AI developer bubble |
| 11:54 | Scaffold before agents |
| 15:54 | Learn languages with agents |
| 21:14 | Heap and deterministic systems |
| 28:32 | Shared engineering language |
| 31:31 | Vibe coding vs engineering |
| 40:12 | Parallel agents in worktrees |
| 41:45 | How deep to scaffold |
| 45:09 | Junior engineers and learning |
| 53:33 | Graph of project context |
| 58:18 | Why the main agent does not write |
| 1:03:07 | Reject code you cannot explain |
| 1:06:25 | Review and mutation testing |
Business Idea: An Agent-Change Review Pilot
A small engineering team may already have coding agents but no repeatable way to define boundaries, compare candidate changes, and catch maintenance costs. This prompt turns Carlos's method into a one-week, human-reviewed service test, not a promise to automate software architecture.
Test an agent-change review service
Start with one repository and one measurable change.
Sources and Caveats
Interview: Carlos Kelkboom on Beyond Coding. Independent references: the May 2026 revision of SlopCodeBench and Git's worktree manual. Carlos's observations about one-shot work, team habits, and heap allocation are attributed opinions. The paper's tasks and metrics do not validate every part of his workflow. Always assess generated code against your own codebase, tests, security requirements, and human review capacity.