Field notes · from 126 talks and essays

12 things the people building coding agents agree on

We went through 82 talk transcripts and 44 essays from people who build coding agents or use them seriously every day. They disagree about plenty: whether to read every line, how much to plan, how many agents to run. But on these twelve points they keep saying the same thing.

  1. Agentic engineering keeps the quality bar

    Vibe coding forgets that the code exists, which is fine when the only person a bug can hurt is you. Agentic engineering is the professional version: agents write and run the code, and you still hold it to the standard of any software people depend on.

    “Agentic engineering is about preserving the quality bar of what existed before in professional software.”

    ▶ Lesson 1: From vibe coding to agentic engineering · 4 min

  2. Agent intelligence is jagged

    Models peak wherever results can be checked, which is why code is their home turf. They stumble on judgment, design and anything they can't verify, and they report success with total confidence. Delegate by how verifiable and how risky the work is.

    “How is it possible that state-of-the-art Opus 4.7 will simultaneously refactor a 100,000-line codebase... and yet tells me to walk to this car wash?”

    ▶ Lesson 3: What agents are great at, and where they fail · 4 min

  3. Context is the constraint

    The context window is the agent's working memory, and quality drops long before it's full. Keep sessions focused, write important state to files, and when you've corrected the same mistake twice, start a fresh session with a better prompt.

    “Most best practices are based on one constraint: the context window fills up fast, and performance degrades as it fills.”

    ▶ Lesson 4: Context is everything · 4 min

  4. Align before the agent edits

    The people who build these tools rarely type a request and hit enter. They have the agent explore first, agree on a plan, then implement, often in a fresh context. The point of the plan is shared understanding.

    “I didn't need a plan, I needed to be on the same wavelength as my agent.”

    ▶ Lesson 5: The core loop: explore, plan, implement, verify · 4 min

  5. The agent fills every gap you leave

    Anything your request doesn't say gets filled with the agent's best guess, drawn from average code on the internet. A good spec closes the gaps that matter: the goal, what done looks like, and the constraints.

    “You know what we call a sufficiently detailed spec? It's a program. So if you leave blanks in your spec, what do you think happens?”

    ▶ Lesson 6: Specs agents can execute · 4 min

  6. Close the loop

    Ask people who ship real software with agents for their single best tip, and a surprising number give the same one: give the agent a way to check its own work, such as tests, types, a running app or a browser. Without a check, you are the verification loop. And passing tests aren't proof, so have it run the real thing.

    “You have to close the loop. It needs to be able to debug and test itself. That's the big secret.”

    ▶ Lesson 8: Close the loop: let agents check their work · 4 min

  7. Memory files should be short and earned

    CLAUDE.md and AGENTS.md work best when they hold only what the agent can't infer: commands, conventions and gotchas, grown from real mistakes. Long files get ignored.

    “For each line, ask: “Would removing this cause Claude to make mistakes?” If not, cut it.”

    ▶ Lesson 11: CLAUDE.md and AGENTS.md: memory files that work · 4 min

  8. Fix the system, not just the code

    When an agent makes a mistake, engineer it out for good: a lint rule whose error message teaches the fix, a test, a hook, a type. Hard constraints beat instructions the agent can forget.

    “Building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code.”

    ▶ Lesson 18: Harness engineering: build the factory · 4 min

  9. Parallel agents, serial attention

    You can run many agents at once if each one is isolated, for example in its own git worktree. The limit is you: pick work that won't collide, and review in batches.

    “More AI agents running does not mean that there is more of you available. Your cognitive bandwidth does not parallelize.”

    ▶ Lesson 16: Running agents in parallel · 4 min

  10. Prompt injection is not solved

    An agent with access to private data, exposure to untrusted content and a way to send data out can be turned against you. Prompts and filters don't fix it. Remove one leg of that trifecta with sandboxes, network allowlists and scoped credentials.

    “LLMs are unable to reliably distinguish the importance of instructions based on where they came from. Everything eventually gets glued together into a sequence of tokens.”

    ▶ Lesson 21: Security: prompt injection and the lethal trifecta · 4 min

  11. You own the loop

    Accountability doesn't move to the agent. Never send anyone something you haven't read. The teams that win change how they work instead of sprinkling AI on top, and they measure speed and quality together.

    “There is no human in the loop. You own the loop. The loop is yours.”

    ▶ Lesson 22: Agentic engineering in teams · 4 min

  12. What agents can't do is your job now

    Syntax and API recall are worth less every month. Vision, judgment, design, domain knowledge and real understanding of your system are worth far more. Keep building them on purpose.

    “The things that agents can't do is your job now.”

    ▶ Lesson 23: The engineer you become · 4 min

Each point is a short animated lesson with a quiz and a prompt to try with your own agent. The course is free, and your agent can take it too.