{"slug": "my-three-phases-of-coding-with-agents", "title": "My Three Phases of Coding with Agents", "summary": "Developer chaliy outlines a three-phase approach to coding with AI agents: design, implementation, and ship. The design phase focuses on challenging assumptions through agent interaction, implementation follows with a clear definition of done, and the ship phase automates pull requests and post-merge checks. The methodology emphasizes agent collaboration and structured workflows to ensure ideas are validated and delivered reliably.", "body_md": "This is my three phase development approach. I start with some inputs — a ticket, a requirement, an idea, whatever — and end with implementation. In between, there is structure. The phases look like this: design, implementation, ship.\n\n## Phase One: Design\n\nThis is the most important one, so I will spend most of the time here.\n\nDesign phase is where I literally put and shape the context the agent will work in. When there is a ticket, or a half-formed idea, that becomes the input. I drop it in and then we talk.\n\nThe key part: **I ask the agent to challenge me.** This is very similar to [Matt Pocock’s grill-me skill](https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me), but in most cases I do not even need a skill for it. I just ask the agent to push back and answer questions back and forth. What about this case? Did you think about that? Why this and not that? We go back and forth like this until the solution holds together.\n\nOnce I am more or less okay with where we landed, I move on. And this is important — it is not a separate step or a separate session. Same session, same context. I just say “okay, we are good now, go implement.”\n\n## Phase Two: Implementation\n\nThis is a regular coding session. Nothing fancy.\n\nIf something is wrong, I ask the agent to fix it. Sometimes the thing that is wrong is not the code, it is the design — so I return back to the design phase and we re-design. Then back to implementation. Sometimes I am totally okay and implementation is just good.\n\nOne important part of this phase is to have some level of **definition of done** in your context. For me, “implement” means implement — and that includes testing, and all the rest of it. I do not want to spell that out every time. So I keep the definition of done somewhere the agent can see it — in `AGENTS.md`\n\n, or somewhere else it will read. That way “go implement” already means “and write the tests, and make it actually work,” without me repeating it.\n\n## Phase Three: Ship\n\nLast phase, and the most different one, because it is much less interactive.\n\nIn most of my repositories I have a skill called `ship`\n\n. It is different for each repo — each one defines its own specifics — but the shape is the same. It is fast: format the pull request to the formal requirements of that repo, then babysit until CI is green. Then a security review. Then babysit again until that is green too.\n\nIf the repository allows it, I do automatic merge, again with some requirements attached.\n\nAnd after that, the same ship skill tends to do **post-merge checks**. This part matters more than people think. If you are shipping a site, merging to main triggers work — a deploy, a pipeline, something. So my ship skills check the after: main CI is green, the application actually deployed, that kind of thing. Shipping is not “merged,” shipping is “live and confirmed.”\n\nYou can see this in practice — the ship skill in [everruns](https://github.com/everruns/everruns/blob/main/.agents/skills/ship/SKILL.md) and the one in [bashkit](https://github.com/everruns/bashkit/blob/main/.agents/skills/ship/SKILL.md).\n\n## That Is It\n\nThree phases. Design, implementation, ship. Design is where I challenge and get challenged, implementation is a regular session against a clear definition of done, ship is the less-interactive part that babysits the thing all the way to live.\n\nMost of the value is in phase one. The other two are just making sure the good idea actually lands.\n\nOne side note: on repos that are not configured — no ship skill, no conventions of their own — I lean on a [generic-development skill](https://github.com/chaliy/skills/blob/main/skills/generic-development/SKILL.md) that defines my terms, so I can speak the same vocabulary everywhere. Supportive, not a phase.\n\nFor comments or feedback, write at[x.com/chaliy](https://x.com/chaliy).", "url": "https://wpnews.pro/news/my-three-phases-of-coding-with-agents", "canonical_source": "https://chaliy.name/blog/three-phases-of-agentic-coding/", "published_at": "2026-06-23 00:00:00+00:00", "updated_at": "2026-06-24 00:47:55.338799+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["chaliy", "Matt Pocock", "everruns", "bashkit", "AGENTS.md"], "alternates": {"html": "https://wpnews.pro/news/my-three-phases-of-coding-with-agents", "markdown": "https://wpnews.pro/news/my-three-phases-of-coding-with-agents.md", "text": "https://wpnews.pro/news/my-three-phases-of-coding-with-agents.txt", "jsonld": "https://wpnews.pro/news/my-three-phases-of-coding-with-agents.jsonld"}}