How I use AI for coding

A practical workflow for AI-assisted coding.

Most AI coding advice focuses on tools, prompts, or productivity claims. What I miss are concrete descriptions of how people actually organize the work around AI.

This post is my attempt to describe that. My approach is to build a process where context survives, decisions are explicit, and the human keeps reviewing the work in small pieces.

Take my process as one example. I currently feel comfortable with it, but I still do not think it is perfect. Given the current pace of progress across different tools, it is hard to create a solid and lasting system, because you need to keep updating it regularly.

The process is heavily shaped by the type of work and its scope. There will be different strategies depending on factors such as the impact or size of the feature.

Here I will speak in general terms about how to implement a medium-sized feature with a medium-high impact on a project. I will limit myself to one very specific part: implementation. I will leave aside product analysis and feature definition.

The process 🔗

1. Feature plans: Connecting requirements and implementation 🔗

Throughout the whole process, I use one core file for all the decisions and information about the feature. I call it a feature plan, and I usually store it in a feature-plans folder inside the repository, where I organize feature plans by domain together with the template they follow.

The feature plan is the main artifact in the process. It starts as a planning tool, then becomes the reference during implementation, and finally can work as long-term documentation once the feature is merged.

Motivation 🔗

A persistent file is needed to hold critical information about the current state, the feature context, the decisions made, and the plan to follow. Without this file, the decisions, accumulated knowledge, and feature context get lost as the conversation progresses.

In sessions with AI, the first and last messages carry more weight than the messages in the middle. We want to prevent that from deciding the importance of the requirements, so we rely on the feature plan.

As a conversation progresses, the context grows. Even if a model supports 1M tokens of context, we should try to reduce that scope to avoid drifting away from the goals. As I said, not every message in the conversation has the same weight.

A feature plan can also avoid the need for context compaction, because the feature plan already reflects the full context of the feature. The conversation context is then useful for implementing one specific part.

We all experience how conversations degrade when they reach their context limits. The feature plan makes it possible to keep conversations small and “fresh” for more atomic goals.

In one of his videos, Matt Pocock says that the “smart” limit of models is around 100k tokens, and that it is useful to treat that as a fixed limit for the context of a conversation.

Structure and content 🔗

This file exists to:

• Focus: keep the goal and requirements visible.
• Context: store the feature context and an index of the files involved.
• Source of truth: act as a shareable and evolving reference between sessions.
• Decisions: keep a record of the decisions made during implementation.
• Plan: maintain an implementation plan.

The exact template can change, but these are the sections I usually need:

• Goal
• Current State
• Requirements
• Use Cases
• Implementation Plan
  • Steps
• Decisions
• Open Questions
• Core Files
• Verification
• Manual test plan

A longer template can also include the branch for which the plan is valid, the ticket link, a description, and a done checklist. Those sections are useful, but the essential part is that the file captures what exists today, what we are building, why we are building it, what files are involved, what decisions have already been made, and how we will verify the result.

Creating it 🔗

Through a prompt, I define the goal and a natural-language description of the requirements. I ask the AI to create a plan that captures the context, files involved, and so on in the feature plan. I usually start from an issue, so when an MCP gives the AI access to that issue, the plan can be built around a more specific objective.

2. Grill me: Clearing up and clarifying goals and implementation 🔗

I use something similar to the grill-me skill from Matt Pocock. Basically, I start a session with the AI clarifying concepts so that any gaps are covered. I do this until the AI stops or I see that the questions are no longer relevant.

At this stage, I want the AI to ask about edge cases, permissions, existing domain concepts, rollback behavior, and how the change should be verified. The goal is not to generate code yet. The goal is to expose the assumptions that would otherwise appear later as bugs or awkward implementation choices.

Then, based on the new knowledge, I ask for an implementation plan.

Once the initial feature plan is created, I manually read and review it.

3. Step-implementation loop: The human stays in the loop 🔗

One of the most important things is keeping the human in the loop. This means you can’t delegate completely and stop understanding what the AI is doing. You need to verify every line of code.

We need to:

• Implement: let the AI work on one bounded step.
• AI review: start a separate review pass over that step.
• Human review: read the diff yourself and make sure you understand it.

If you ask the AI to implement the full plan at once, then you’ll spend a lot of time reading and reviewing the generated code. Instead, plans are implemented in steps. For instance, you can have a first step that creates some interfaces and types. Then you review them. Next, you can create the service that contains the logic, then you review it. Then the UI, and finally the wiring between all the components.

The important constraint is that each step must be small enough to review properly. If a step produces a diff that you can only skim, the process has already failed. The point of the loop is to keep the work inspectable.

The idea is to have an iterative process where code is reviewed at the end of each step. This helps detect deviations from the plan and prevents the implementation of bad practices.

4. Full review 🔗

Once all the steps are implemented, we do another full review (AI code review + manual review).

This final review has a different purpose from the step reviews. At this point, I look for inconsistencies across the whole implementation: missed requirements, weak tests, unnecessary abstractions, naming that no longer matches the final shape of the feature, or code that made sense in one step but feels wrong once everything is connected.

5. The long-term feature plan 🔗

I’m a fan of ADRs, and I see the feature plan as a kind of ADR for this new era. One final step before merging the PR is preparing the feature plan for long-term consumption, where we can save information about the feature and the decisions we made during its implementation.

This is something I’m still testing. On one hand, it serves as a place to understand how a feature was built. On the other hand, we do not want to touch it or maintain it, so it will become obsolete at some point.

Supporting the process with skills 🔗

For the different phases, you can use different skills to support the process. You can have one skill for creating the plan, another one for challenging the requirements, another one for implementation, another one for code review, and another one for preparing the handoff.

Skills should, and can, be called explicitly or implicitly during development. I will not go into detail, but the skill set is as important as the framework you are using. Otherwise, you will not find a replicable process for building and developing.

Handoffs between sessions 🔗

For each of the previous phases and steps, it is crucial to start a new session. For that, and following Matt, I also use a handoff skill. That skill collects the relevant information about the feature we are building, such as the path to the feature plan or the current state, and prepares a summary for the next task.

For instance, when implementing, we create a new session for the AI review after each step. We can create the instructions for the new session using this handoff skill, which is just a small skill that knows we are working with feature plans and needs to collect specific data.

How this relates to RPI 🔗

RPI (Research, Plan, Implement) is a fairly widespread framework, and it is very similar to how I approach my strategy. In RPI, there are two different phases for research and planning. In my case, I usually do both at the same time and generate a single artifact. I find it more natural and accessible. My idea is to keep a reduced version of the plan in the long term, and having a single file simplifies things.

The goal is not to make AI autonomous. The goal is to make the work inspectable, repeatable, and easier to reason about. I do not want AI to replace my judgment. I want it to operate inside a process where my judgment still matters.