Map

My AI-Assisted Workflow

Wiki summaryai-codingworkflowsoftware-engineering โ†ณ show in map Markdown
title
My AI-Assisted Workflow
type
summary
summary
Barbero's seven-step workflow where planning happens before code and AI stress-tests thinking rather than replacing it
tags
ai-coding, workflow, software-engineering
created
2026-04-15
updated
2026-04-15

Matteo Barbero describes a structured AI-assisted development workflow built around one principle: the real work happens before any code is written. AI accelerates production; humans own the review.

The problem

Standard AI-assisted coding feels fast but produces code nobody fully understands. Edge cases get missed, architecture makes sense in the moment but breaks on the next feature. You build faster and understand less.

The tension: how to get AI speed without losing clarity and maintainability?

The answer: thinking before implementation

AI is good at implementation. It's bad at figuring out what you actually want, catching implicit assumptions, and telling you when your mental model is wrong. That remains your job.

The workflow forces thinking to happen before code exists, then uses AI to stress-test that thinking rather than skip it.

The seven steps

1. Free-form plan โ€” Write in plain language about the problem, constraints, uncertainties. No structure required. This is private thinking, not a deliverable. Quality here determines quality everywhere downstream.

2. PRD via write-a-prd โ€” An AI skill explores the codebase, then interviews you relentlessly. "How does this behave when the user isn't authenticated?" "What happens if this operation partially fails?" Being forced to answer specific questions reveals where you were hand-waving. Output: structured PRD with problem statement, user stories, implementation decisions, out-of-scope items.

3. Issues via prd-to-issues โ€” PRD becomes vertical slice issues (tracer bullets through all layers, not horizontal architectural slices). Each issue is classified:

  • AFK โ€” AI can implement and merge without human interaction
  • HITL โ€” requires human decision during implementation

Issues contain end-to-end behavior description, verification steps, Given/When/Then acceptance criteria, blockers, and references back to user stories.

4. Tasks via issues-to-tasks โ€” Each issue becomes ordered tasks sized for single AI sessions. The constraint is deliberate: if a task can't finish in one session, it's too large. Tasks specify files to touch, patterns to follow, what "done" looks like. Intent, not implementation.

5. Implementation handoff โ€” Each task description is a self-contained prompt. Open fresh session, paste task + parent issue. Fresh context per task is intentional: long sessions drift as the model makes decisions based on accumulated context rather than task requirements. For HITL tasks, stop, make the decision, document it in the task file, continue.

6. Code review via code-review โ€” Six-pass structured review: logic errors, operation ordering, bad practices, security, magic values, pattern consistency. Operation ordering deserves attention โ€” AI tends to produce code that does the right things in the wrong sequence (notify before commit, log after action, mutate before validate).

7. Final audit via final-audit โ€” Cross-cutting analysis after the feature is complete. Not individual bugs (caught per-PR) but systemic issues: module inconsistencies, patterns replicated incorrectly, security assumptions that break across the full surface area.

Design principles

Every step has the same structure: AI produces, human reviews with full context, then it gets created. The workflow ensures you always have something to check against: PRD for issues, issue for tasks, acceptance criteria for code.

The approach trades setup time for understanding. It only pays off if you believe thinking time before coding is cheaper than debugging time after.

What this isn't

Not fast to start โ€” PRD and planning take real time. Not a replacement for judgment โ€” AI will suggest reasonable things that are wrong for your specific situation. The review gates exist because AI's output needs validation against team conventions, user behavior, and hidden codebase complexity.

Connection to other approaches

This is the disciplined opposite of pure vibe coding. It shares DNA with Maganti's disciplined rewrite โ€” both treat AI as implementation accelerator, not thinking replacement. The AFK/HITL classification maps directly to human-in-the-loop patterns. The fresh-context-per-task principle reflects good context-engineering โ€” preventing accumulated assumptions from polluting decisions.

Skills available at github.com/maiobarbero/my-ai-workflow, adapted from Mark Pocock's framework.

Sub-pages