# Lead Architect Reveals His Rules for Coding Agents

[Watch on tuber](https://tuber.guzus.xyz/video/mkN4uRZYPfs/summary) · [YouTube](https://youtu.be/mkN4uRZYPfs)

**Score: 64/100 · skim**

Carlos Kelkboom, an engineer who has built several compilers, says agents work best when a human does the engineering first. He scaffolds the folders, files, signatures and boundaries by hand, makes the agent understand the goal before any code is written, and then lets it build a large feature in one go. He throws the result away if he doesn't recognize it. He also warns that collaboration, learning and code review are being lost as developers retreat into private "agent bubbles."

- **0:53-3:50** — **Collaboration is eroding.** Asked what has changed most in engineering, Carlos says people now work alone with their agents instead of with their teams. Pull requests and review comments matter less, and some people even predict pull requests will disappear. He avoids social media and bases this view on articles, white papers and conversations with companies. In his view, solo builders produce fast demos but rarely finish the last hard stretch. His example is quickly built games: the hard part is listening to users and getting the game design right, and that requires talking to the world, not just your agent. That is why he thinks product thinking now matters more.

- **3:50-5:45** — **Starting projects is easy; finishing is not.** The host admits he spends his weekly credits at night building games and game-building harnesses that he never hardens into products. Carlos says unfinished projects were always normal: he has started five compilers and finished only one. What matters is deciding why you're starting. If it's for fun or learning, you've already succeeded. If it's meant to become a company, you have to finish.

- **5:45-11:45** — **The cost of the agent bubble.** Carlos wants more meetups, groups that review each other's products, and openness about ideas. He notes that ideas are cheap overall but feel personal, so people fear sharing them. His model is the World of Warcraft beta community, where a basic question gets 4-5 helpful replies. The host has heard people say "ask your agent before asking me" and thinks imposter syndrome is getting worse. Carlos points out that agents tend to tell you what you want to hear; running several models adversarially helps somewhat. The bigger loss is time to reflect: he cites John Cleese's "open mode" of creativity, which needs quiet that a constant stream of information prevents. Without that time, you don't internalize anything. People who learned the fundamentals before agents arrived will have an edge over those who only use agents. Learning to use agent tools also counts as learning.

- **12:00-14:50** — **Scaffolding is his core technique.** Before involving an agent, he spends 20-60 minutes creating the directory structure, files, comments, class names and function signatures. For a compiler, that means the lexer, part of the language spec, folders for how the abstract syntax tree flows into the intermediate representation, and many example programs in the new language. His reasoning: agents brute-force a local solution but forget how it fits into the whole application. That leads to duplicated code, poor cohesion and "God objects" (classes that try to do everything). When he built without scaffolding for months, he hit walls and no longer recognized his own code base. In one case the agent silently stopped using his deploy script and created several new scripts nobody understood. He calls being explicit and intentional the skill that turns a 10x agentic engineer into a 100x one.

- **14:50-21:05** — **Developing scaffolding taste in an unfamiliar area.** His suggested process:
  - Download good open-source projects in the area.
  - Have the agent extract their good patterns.
  - Use a "teach me" or "grill me" style skill so the agent explains why those projects work and where they are weak (a day or two of work).
  - Go outside with a coffee and let it sink in.
  - Build small proofs of concept and ask the agent to critique your scaffold.
  - Only then ask it to build.

  The point is to resist the early dopamine hit of instant results. His cautionary example: after a month of building a compiler in a language he didn't know well, he asked the agent to review the list feature and learned it had been implemented five times. To learn a new language, ask the agent to explain it in terms of one you already know (for example "I know C#, what do I need to write idiomatic Go?"). Then sketch rough code and let the agent tear it apart. The sketch doesn't need to be correct.

- **21:05-27:50** — **His view of a future programming language.** Carlos argues that languages need fundamental change:
  - **No heap:** no pointers, no dynamic memory allocation.
  - **Bounded loops** and fully deterministic behavior.
  - **Records laid out in memory at startup**, so data is reached by a start index plus fixed field offsets. He says this would be "blazingly fast."
  - **Three layers:** humans write natural language plus light structure, such as component keywords with markdown descriptions. A visual, audio or video layer then explains the intent back so you can challenge it. The bottom layer runs on the machine with old assumptions stripped away.

  His reasons are predictability and performance. Robots and satellites have fixed memory and can't afford out-of-memory or null-pointer errors. He also wants CPUs to work more like GPUs, which allocate a block of memory and run functions on it without heap complexity. On Rust: agents write it reasonably well but more slowly than other languages, and Rust code is hard to change later. He sees the borrow checker as a tool for managing the heap, so without a heap it wouldn't be needed.

- **27:50-31:30** — **One runtime, many personal languages, and the shared-vocabulary problem.** He expects the runtime and generated code to converge into one, while the upper layers become plug-and-play. People might even define their own language by talking to their agent. The host asks how teams would then share terminology (for example, what "component" or "agent" means). Carlos's answer is to start with something extremely simple that everyone agrees on, like "a customer has an ID." Treat the agreement as something that evolves, not a fixed point. He thinks agile was "captured" and lost its original spirit, and that fast agent-driven iteration could bring it back.

- **31:30-41:30** — **"Vibe coding" toward an outcome vs. engineering.** Some people never look at their code. The host gives an example: he built a game-generating harness so his non-technical younger brother and partner could make games, and he never looked at the code. Carlos says that's fine when the goal is simply making people happy. He asks what would have changed if someone with 25 years of game experience had helped. He adds that agents are good at writing code but not at engineering an application: they patch over old concepts instead of ripping them out, and eventually hit a ceiling. He suggests the host redo the project with a scaffold (folders, markdown files, dependency direction, maybe a 2D platformer using the raylib library) and expects an equally good result faster. They agree on a rule of thumb: for throwaway experiments, aim straight for the outcome; for anything you'll invest in long term, build the foundation first. Code is cheap, so throw it away more often. One pattern he likes: run three agents on three branches or git worktrees, then have a fourth agent compare them and merge only the good parts.

- **41:30-45:00** — **How deep he scaffolds.** He goes further than he would recommend to others. He creates Rust crates or C# projects with names, adds markdown files describing each project's boundaries, draws quick diagrams, and writes core files and signatures. Example: he defines exactly what a token contains (its span in the source, the file, and the line range). Otherwise the agent just creates an enum of token types plus a position, which is harder to reason about later. He is reluctant to open-source his current agent-built language yet, because people's first impression of a very early project tends to stick.

- **45:00-53:25** — **Democratization, juniors, and three AI trends.** Carlos wants a community where engineers with spare tokens build software for real needs, such as speeding up the slow process of getting a wheelchair. He stresses that engineers must teach new builders about security, because AI won't run a security check or penetration test unless asked. He is worried that we're training juniors to use tools rather than understand the work: full pull-request cycles are disappearing and computer science enrollment is falling. If tokens become too expensive or AI disappears, "everything will fall down." He sees three things happening:
  1. Genuine breakthroughs such as AlphaFold, medicine, materials science, robotics and self-driving cars. He calls this "true AI" and "magic."
  2. LLMs, which are very useful for programming but wasteful and energy-hungry, and look like a hype bubble.
  3. A shift in power toward tech companies that raises privacy and security concerns. AI is sold as an equalizer, but he doesn't see it equalizing.

  His cure for fear of missing out is learning fundamentals. When early GPT models came out, he built his own neural networks from a book and learned firsthand that scale matters.

- **53:25-1:00:20** — **His harness: context built like a social network.** The host frames scaffolding as "forward pressure" in loop engineering and asks about "back pressure." Carlos rebuilds his tools with every new model, but the design stays the same. Information nodes get one-line metadata plus a pointer (a commit hash, folder path or URL), are ranked by relevance, confirmed by a human when needed, and explored progressively deeper. Agents read the commit diff before the full code, which he says "warms up" the context. The graph is stored as markdown files, with vector search and keyword search over the front matter; he deliberately avoids a graph database so it stays distributed. His main agent runs in an "open mode": it never edits files or changes his machine and only talks with him, either teaching him or learning from him. What it learns goes back into the graph, and it spawns subagents to do the actual work. He made this rule after asking an agent about John Cleese's creativity talk inside a game-engine project, and it offered to implement the talk in the code.

- **1:00:20-1:06:25** — **Large one-shot tasks, a confidence gate, and throwing work away.** A local Gemma model scores the main agent's confidence. Only when it is more than 90% sure it understands him may it spawn subagents, which can then run for 12 hours. He makes tasks as large as possible because agents are good at one-shot builds and bad at incremental changes. The host backs this up with SlopCodeBench (mentioned in his episode with Dex Horthy), where models reportedly scored about 15% on evolving code bases. Carlos does review the output: after an hour or two he pauses and checks the worktree. If the code doesn't contain what he expected, he discards it without digging further, because that means the agent drifted from the scaffold and it would cause problems later. He then starts a fresh context, discusses with the agent what went wrong (usually conflicting ideas), and retries. The second or occasionally third attempt usually works. Whenever possible he turns non-deterministic behavior into something deterministic, either a script or a firmer scaffold.

- **1:06:25-1:15:20** — **Code review, testing, and the senior-engineer analogy.** Pull requests now often just say "looks good to me." Carlos wants real debates, down to an argument over a missing semicolon. If the volume of code is the excuse for skipping review, ask agents to write less code and keep features small. He doesn't fully reconcile this with his own preference for large one-shot builds. He wants testing to go beyond unit tests, which he says give a too-favorable picture:
  - mutation testing (which he says has fried some of his CPU's pins)
  - static analysis that measures what percentage of the original scaffold is still standing
  - a breakdown of how each commit moved the solution forward, which he thinks could be visualized

  His analogy: leaving agents unsupervised is like leaving a team of juniors alone. You get code, sometimes great code, but not an application. So he does what a senior engineer or architect would: clarify the product spec (his conversation graph), scaffold the code, decide the architecture, and set deployment boundaries (AWS vs. local; S3, Postgres or SQLite, and if SQLite, where the physical file lives). The episode ends with a proposal for an in-person community session to compare approaches such as scaffolding vs. no scaffolding, and to fight isolation by learning together. The last minute is goodbyes.

**Practical takeaways**
- Before prompting, scaffold the folders, boundary docs in markdown, core types and signatures. This keeps the agent from duplicating code or drifting architecturally.
- Separate thinking from doing. Use a main agent that can't touch files to clarify the plan, and only hand work to subagents once it is very confident it understands you.
- Give agents large, well-specified one-shot tasks. Check the worktree early and discard any output you don't recognize rather than patching it.
- Code is cheap: run several branches in parallel, have an agent merge the best parts, and turn recurring failures into scripts or a firmer scaffold.
- Protect your learning and your connections with people: study open-source patterns with the agent as a tutor, take quiet time to absorb, and keep real code reviews and meetups going.

## Audience signal

- No high-signal audience themes available.