AI workflow — turning AI coding into real team productivity

// Context

I was a senior frontend engineer on Doccle's React and Next.js apps. When our team started writing code with AI, I took the lead on how we use Claude Code, on my own initiative and alongside my feature work, from late 2025 to mid-2026. I wrote the guidelines and the skills, first for my own work, then shared them with the frontend team and showed how they work, and then the rest of the team picked up the approach: when a review asked for a fix, they had the AI update the rules too, so the same comment didn't come back. The workflow ties Claude Code's rules, skills and hooks to the tools the team already used: Jira, GitLab, VS Code, Prettier and ESLint.

Claude Code Crash CourseNew to Claude Code? My course shows how to let an AI agent add features, fix bugs, write tests and review code in your project

// Problem

At first everyone wrote long prompts by hand, repeated them, and checked every result line by line. Even so, much of the time went into fixing what the AI wrote, because the same kinds of mistakes came back in every merge request. When backend developers added frontend to their features with AI, review comments piled up further, and review became the bottleneck.

Around the code itself, the routine was manual too: branch names, commit messages, merge request descriptions, reviewers and labels, and small fixes after each review. AI was supposed to save the team time, and it was eating it.

// Objectives

We wanted AI to give the team time back instead of taking it. That meant AI-written code that looks like the team wrote it, whoever asked for it, so review stops being spent on the same fixes. It also meant the routine steps from a ticket to merged code done the same way every time, so developers spend their time on the feature itself.

// Research

To fix it, I first had to see why the AI got it wrong. The cause was the codebase, not the prompts: over three years many developers had worked on it, each with their own approach, so the AI had many styles to copy, and it copied whichever one it found first.

That meant a better prompt could only fix one result at a time. As long as the codebase held several ways of doing the same thing, the AI needed to be told which one is ours, every time and for everyone.

// Options

That left two ways to go:

The first treats the symptom; the second treats the cause.

// Design

I chose shared rules and skills, because they fix the cause: the AI gets one standard instead of copying whichever style it finds, and every developer gets the same result. I didn't build it all at once; each step answered the next problem as it came up, and together they now cover the whole path from a ticket to merged code.

// Guidelines with examples

The guidelines came first, starting with basic rules for unit tests and components. When review comments piled up, I extended them into detailed guidelines for components, hooks, forms and the design system, where each rule shows a correct and a wrong example, because the AI follows an example far more reliably than a description. After every change the AI makes, Prettier and ESLint run on their own, so formatting never reaches review. Since then, Claude Code writes all our unit tests for features.

// From ticket to merge request

Given a Jira link, an agent creates a branch named by our rules and a separate worktree, a second copy of the code, and opens it in a new VS Code window. Developers could already set this up by hand; the agent just makes it quicker and simpler, and each worktree can run its own copy of the app. On request, the agent commits with the right message and opens the merge request: it suggests the reviewers and labels the team usually picks, the developer chooses, and it writes a short description and returns the link.

// AI review of the most common issues

For a while, most merge requests landed on me, so I made review part of the workflow too. I built a review skill from 500+ real merge request discussions, so it knows the problems reviewers flag most often. It checks a merge request against those problems and the project's guidelines and drafts short comments, which are posted only after I approve them.

// Automatic fixes for review comments

The last step was the comments themselves. A babysit agent works only on merge requests a developer turns it on for with a label, and stops once the request is merged. Every three to five minutes it reads the comments left by developers or other agents. When a comment is clear and it agrees, it fixes the code, pushes and replies that it's done; it fixes a failing pipeline the same way. When a comment is a question or needs a decision, it tags the developer and explains why it can't decide alone.

// Results

AI now gives the team time back instead of taking it. The code is consistent, whoever wrote it with AI, and review comments dropped roughly two to three times, by my estimate. Comments about style or our guidelines have almost disappeared from merge requests, so reviewers focus on the critical issues. When backend developers add frontend to their features, their code follows the same rules. Most review comments are closed by the babysit agent without the developer, and the review load I took on became much lighter.

Claude Code Harness EngineeringWant the same for your team? My course shows how to make an AI agent check its own work

// Looking back

It was worth it. At first it was a few rules for my own work; now the team keeps the rules up to date as part of review, so every fixed comment makes the AI better for everyone. Better prompts per person would have left quality depending on who asked. The order is what I would change: next time I would write the detailed guidelines, with good and bad examples, at the start, instead of waiting until the review load grew.

// What people say