This deck accompanies a talk Masahiro Nishimi of Generative Agents gave in the AI track of Tech Challenge Party 2026 on 4 February 2026. It introduces Agentic Coding by starting from how an AI Agent works, with the stated goal that the audience understand the essentials well enough not to be swayed by every new update in the field.
The talk is in three parts: what agentic coding is, the problems it runs into, and three principles for addressing them.
Details
- What agentic coding is. The deck defines it as a way of developing software that makes use of coding agents, with an LLM as the reasoning engine, and describes it as being in a period of explosive adoption. It points to the rapid improvement in LLMs’ coding ability — model providers almost always advertise coding performance when releasing a new model — and to the shift from code completion, where the human drives and the AI navigates (GitHub Copilot as the example), to coding agents, where the AI drives and the human navigates (Claude Code as the example). Claude Code, OpenAI Codex, OpenCode and GitHub Copilot are named as tools of this kind.
- Three common problems. The agent builds something different from what was asked; code it reports as “done” does not run; and it ignores rules or scatters duplicate code. As an illustration of the third, the deck quotes a news report of Replit’s AI agent deleting a company’s production database during a code freeze.
- Why they happen. The deck explains an AI agent as an intelligent system that carries out tasks by interacting with an environment towards a goal, through perception, memory, planning and action around an LLM. A coding agent is such an agent whose environment is the codebase, and which keeps choosing among its tools — file operations, shell commands, search, task management, web search — on the basis of what it has perceived. Read this way, each problem has a root cause: the agent was not given enough information to plan, it was not given a means to check its own work, and it was not given a mechanism that controls its actions.
- Principle 1: define what to build. Detail the plan until the implementation can be pictured, have the agent point out gaps and omissions, and put it in writing for consistency. The deck shows the plan modes of Claude Code and Codex, recommends writing requirements into a GitHub issue to some degree beforehand, and suggests having Codex review a plan Claude Code produced, going back and forth between planning and review to raise its quality. It points to methodologies such as AI-DLC and Spec-driven development, describing the latter as a workflow in which documents are the single source of truth, humans concentrate on the documents and the AI on implementation. A slide on Context rot sits in the same section: LLM performance depends on input length and degrades as the input grows, so a model performs at its best only at token counts below its context-window limit.
- Principle 2: make self-verification systematic. Let the agent check what it built: for a web application, by operating a browser through MCP or CLI tools such as Chrome DevTools MCP; more generally, by running CLI tools directly in the shell as well as test code. Turn self-verification and correction into a loop. The deck argues that having the coding agent set up its own environment is a bad move, and that such mechanisms are better built by people.
- Principle 3: grow the rules that must be kept. Make the agent’s out-of-bounds zones explicit, layering what is completely off limits under organisation-specific and project-specific adjustments that are grown over time. The deck’s central contrast is between skills, which tell the agent in markdown how to proceed and depend on the prompt, and Agent Hooks, which enforce rules in code and are always followed. Agents follow documents to a degree, but not with any guarantee; whatever must always be obeyed belongs in a rule-based mechanism, and what cannot be self-verified will not be kept — summarised on the summary slide as “prompts are not obeyed”.