Build a codebase agents can extend safely

Trust comes from the environment

High output is an outcome, not a setup instruction

Lauren describes shipping thousands of pull requests after investing in her environment. Copying the output target without the checks and conventions misses the work that made her workflow possible. The preparation matters because each new change depends on the same tools and conventions. Without a way to run and inspect the product, faster code generation can increase the amount of work waiting for a person to verify.

Organize the work before adding agents

Her kitchen analogy is about prepared tools, clear responsibilities, and consistent standards. More agents in an unprepared repository can multiply confusion rather than useful output.

Give agents runtime access

Remove the human relay between agent and app

If a person has to click every button and paste every error back, the agent cannot complete its own feedback loop. Give it controls and debugging tools so it can observe the result itself. The agent needs both an action it can perform and a result it can observe. For a UI change, that means opening the page, using the affected control, and checking the visible response. Compiling the code cannot replace that sequence.

Measure what the app actually does

Performance traces, heap snapshots, and user journeys answer different questions than a typecheck. A feature map helps the agent choose the relevant journeys and understand related behavior.

Preserve engineering judgment

Turn repeated workflows into shared skills

Debugging, feature development, and prototyping need different processes. Lauren describes pstack as a collection of workflows derived from her own engineering practice. A shared skill records the steps of a working method so another agent can repeat them. The value comes from preserving useful decisions, tools, and checks, rather than giving every kind of task the same generic instruction.

Combine process with observable evidence

A skill can ask for careful work, but real measurements and runtime checks show whether the work met the requirement. The two pieces reinforce each other.

Prefer constraints to repeated reminders

Existing code teaches the next agent

Agents extend patterns they read. A workaround can spread until it looks like the normal way to implement a feature. Clean examples are part of the instruction system. This makes existing examples part of the repository's design. When the nearest example uses a weak pattern, a new agent may repeat it consistently. Correcting that example and its underlying structure can prevent more mistakes than another reminder.

Fix the structure before adding more prose

Lauren orders interventions by how strongly they constrain mistakes. Change the architecture or data structure first when possible, then use static checks, then rules and skills. A human-only style guide is the weakest enforcement.

Make the easy implementation the intended one

Dune, the internal framework discussed in the talk, reduces the choices an agent must make. Clear conventions help contributors who have little project context, including non-engineers.

Stop bad patterns from spreading

Comments can preserve a workaround

Lauren says agents sometimes use a comment to justify avoiding the underlying problem. Her team banned comments in Dune in response. This is a reported local policy, not a general rule that all comments are harmful. The concern is a comment that makes a known defect seem intentional and therefore worth copying. The broader lesson is to examine the reason for a workaround and decide whether the design can remove the need for it.

Assign someone to maintain code quality

The gardener role watches for recurring mistakes and removes their causes. A lint can prevent new occurrences while the team cleans up existing ones.

Keep one standard path for common work

Multiple competing ways to do the same thing leave agents guessing. The talk favors deleting debt and enforcing a conventional implementation that new changes can copy.

Enforce module and process boundaries

Keep related feature code together

Dune places a feature in a predictable directory and gives its entry points specific roles. This makes it easier to find the code and reduces the temptation to append to a huge shared file. The feature directory acts as a starting point for a contributor with limited context. It should make both the implementation and the supported way to call it discoverable, so adding a feature does not require guessing among unrelated modules.

Keep slow work out of the renderer

An import can accidentally move expensive work into the Electron renderer. Dune checks dependency boundaries to prevent that class of mistake. Smooth rendering requires short tasks, roughly within a frame interval of 16.7 milliseconds at 60 Hz or 8.3 at 120 Hz.

Connect outside signals to verified work

Separate finding work from doing it

The outer loop collects context from feedback, alerts, and services. The inner loop implements and verifies a change. Connecting them reduces the need for a person to relay each report. A feedback report identifies something that needs attention; it is not yet a verified fix. The implementation still needs a clear task, enough context to reproduce the problem, and proof that the changed behavior addresses it.

Reuse the same checks across entry points

A task started by an alert should use the same repository conventions and verification tools as one started in a chat. Shared infrastructure lets improvements benefit the whole team.