Ai

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 ...

Coding agents work best when they have a good feedback loop they can use to verify their changes. Without a good local environment and feedback loop, agentic development quickly becomes a waste of time. My first experience with software development was javascript, building websites using frameworks like React. I loved my development setup back then. I would always have a local server, automatically refreshing on every change. If anything broke, I would instantly find out and fix the issue right away. I would also have my unit tests running constantly catching bugs in near real time. ...

After ignoring the whole “agent” hype for a while, I started to get that inevitable feeling of being left behind. That changed when I came across this blog post explaining the basic flow of an agent. It made me want to try it for myself and see what it actually makes an agent. This post is my walkthrough of that process: step by step, showing how to turn an LLM into an agent. The code here is mainly illustrative, meant to highlight the concepts rather than provide a fully working solution. ...

This is my story of how I went from non-tech into becoming a Machine Learning Engineer. I must have told this story multiple times in many different forms, but this will be the first time it goes into writing. Enjoy. I have a bachelor’s degree in Commerce. I found the last few years of school so exhausting that the thought of doing an engineering degree put me off. Four + years of no life? Oft, no thanks. I also thought I wasn’t smart enough to do engineering anyway so instead I chose Commerce - which “coincidentally” was the same degree my brother was doing. ...