Tooling

Module 9: Ownership, security and new ways of working Closing section. Reflection and discussion. No hands-on needed. Leaves attendees with the right mindset to take this back to their team. Cognitive debt of using agents (TODO: write this up) Security is part of ownership — what agents get wrong, what you are responsible for Scope your environments properly — credentials, prod vs dev, worst-case thinking Team guardrails — what to put in place before rolling this out to a team (TODO: write this up) More upfront design — how agentic dev revives the value of thorough specs When not to use agents — learning through doing; knowing when to keep your hands on the keyboard Your own knowledge is the limiting factor — why deep expertise matters more now, not less Common questions — cost, context windows, efficiency, automation ceiling, are engineers obsolete testing again Security is part of ownership Agents are not security-aware by default. They will produce code that looks right and works, but may not be secure. I have seen agents happily suggest long-lived tokens for third-party authentication on public CI/CD pipelines. They will use overly broad IAM permissions, hardcode credentials, or accidentally include .env files in a commit. If you are not paying attention, these things get through. ...

Resources There Is an AI Code Review Bubble - Honest take on why most AI code review tools are fundamentally limited. Shallow diff-only reviews produce noise, not signal. (HN discussion, 351 points) How We Made Our AI Code Review Bot Stop Leaving Nitpicky Comments - Practical deep-dive into the #1 problem: LLMs leave too many low-value comments. Details what worked and what didn’t to reduce noise. (HN discussion, 257 points) Google Engineers Launch Sashiko for Agentic AI Code Review of the Linux Kernel - AI code review applied to one of the most demanding environments: high-stakes, low-level C code with strict quality standards. (HN discussion) Get an AI Code Review in 10 Seconds - DIY, no-nonsense approach to lightweight AI code reviews using existing tools. (HN discussion, 142 points) Benchmarking GPT-5 on 400 Real-World Code Reviews - Systematic benchmark of LLM performance on real pull requests, not synthetic examples. (HN discussion)

Resources Claude Code: Agent Teams - Official documentation on running multi-agent teams with Claude Code. Claude Code: Best practices for agentic coding - Includes guidance on running headless agents, parallelizing work, and using sub-agents. (HN discussion, 614 points) Don’t Build Multi-Agents - Cognition (Devin) argues against naive multi-agent architectures. Specialized sub-agents sharing context outperform fully independent agents passing messages. FleetCode: Open-source UI for running multiple coding agents - The HN discussion includes detailed practitioner experiences with parallel agent execution using git worktrees. (HN discussion, 103 points) Software Engineering Is Back - How coding agents changed an entire development workflow. The 594-comment HN thread is full of multi-agent patterns and real-world experiences. (HN discussion, 375 points)

Introduction At this point we have already seen how to use spec driven development to create a structured engineering workflow and using feedback loops te ensure the code is validated and meeting the necessary standards. We already have a very solid workflow we can go and use. Engineering is more often than not, not done on your own. You usually work in a team where everyone is trying to achieve the same goals. If everyone in the team is using agents differently, this can create inconsistencies on how the code is built. Perhaps one of the approaches from you junior members is not very thorough, and the output code comes out bloated, and in very large pull requests that are very difficult to review. There is a benefit in everyone using the same workflow and principles to ensuere the whole team is building under the same standards. ...

Introduction Once you get to the implementation phase, you can simply ask your agent to implement the task and end it there. The agent will produce the code based on the specifications. If that’s all you do, then you still have the job of going through the validation steps required to ensure the code is ready for production, such as running unit tests, locally testing functionality to check it works and all the other things a good engineer needs to do to ensure the code is ready for production. ...

Module 6: CLIs, MCPs and debugging Hands-on: attendees connect a CLI or MCP to their agent and use it in a spec or debug session. What is a CLI tool? — terminal access to external systems, examples What is an MCP? — structured tool access, how it differs from a CLI, JSON config example When to use them — three scenarios: spec validation, triggering external systems, debugging MCP setup walkthrough — install, configure, verify with one concrete example (TODO: pick example) Debugging with spec driven development — using CLIs and MCPs in the feedback loop CLI agents and IDEs — does the IDE still matter? Getting comfortable with terminal-first workflows When working with agents, your goal is to give them as much context as possible so they have enough information to complete their tasks successfully. Sometimes it is enough to look at the current repo. Other times it helps to have access to external systems to gather additional context that makes for stronger specs and more accurate implementations. ...

Module 3: Spec driven development First hands-on moment. Attendees write a spec for a real or dummy feature by the end of this module. Why spec-first? — what changes when you plan before implementing The planning phase overview — spec → plan → tasks as a pipeline, not a negotiation The spec.md file — purpose, required sections, what good looks like vs what bad looks like The annotation loop — how to use the agent to fill gaps and surface edge cases in the spec before implementation The plan.md file — breaking the spec into ordered steps The tasks.md file — granular tasks with validation criteria baked in TODO: talk about using spec+plan+tasks vs plan+tasks only. depends on use case. A spec is useful for newer repos or new tech and we want to detach the WHAT from the technical decisions (that should come last). Technical decisions too early can lead is to inefficient solutions (ie choose an architecture because it fits the tool, rother than designing a good architecture and choosing the right tools) ...

Introduction — what you will have set up by the end of this chapter IDE agents vs CLI agents — the two flavours, narrow scope to CLI for this chapter Understanding the workspace — mental model of what the agent can see, do, and access before you install anything Installing an agent — now the reader knows what they are installing and why Running your first prompt — first real interaction, what to expect What is agents.md / CLAUDE.md? — general repo configuration for agents Prompt engineering fundamentals — how to communicate effectively with the agent Custom agents — specialised agents for specific tasks, encoding tribal knowledge Skills — automated slash commands, how they differ from custom agents Putting it all together — final repo structure walkthrough Introduction IDE agents vs CLI agents Traditionally, software engineers use code editors to navigate and edit their code. These are often referred to as IDEs (Integrated Development Environments), and you could say the IDE is the main tool every software engineer uses to write code. Some common examples are VSCode, IntelliJ, or Eclipse. ...

Module 1: How we got here Sets the stage. No hands-on. By the end, attendees understand why this is happening now and what an agent actually is. Why this course? ROI framing — what changes for developers, teams, and organisations The copy-paste problem — where most developers are today What is an LLM? What is an agent? — very short, no-jargon explanation; just enough to understand the rest of the course LLMs vs agents: the key difference (tools, loops, autonomy) The evolution of development — from copy-paste to agentic; the inflection point we are at Agentic development vs Vibe coding Why this course? ROI framing — what changes for developers, teams, and organisations ...

In this post, guest writer Billy interviews Pablo on learning Dvorak. Pablo started to learn Dvorak in January 2025. This is an interview about his experience. First of all, can you explain what Dvorak is? Dvorak is a keyboard layout created in the 1930s, proposed as a more efficient alternative to Qwerty. Dvorak groups letters on the keyboard based on how often they are used (in the English language), so the most used ones are located in the “home row” and less used ones are located in locations that require further finger reach. ...

I currently have a basic setup in NeoVim: I use NvChad by default with treesitter to get pretty text highlighting, telescope to navigate files, conform for all my formatting needs and some python utilities such as pyright. This is enough to get me by. The thing that has been annoying me the most lately is the terminal workflow in NeoVim. To start with, the terminal does not save any history across sessions, which is incredibly annoying. ...