A Pragmatic AI Workflow for Software Engineers

AI models are powerful but unreliable co-authors. Treating them as a single tool leads to inconsistent results and subtle errors. A better approach is a structured workflow that uses specialised tools for distinct phases of development: planning, validation, and execution. This guide outlines a production-ready process that leverages AI's speed without sacrificing engineering rigour.

Phase 1: High-Level Planning with a Frontier Model

The first step is to translate a product requirement into a technical plan. For this, I use a powerful, large-context model like Google Gemini 2.5. Its strengths in agentic reasoning and its ability to process large amounts of information make it ideal for architectural tasks.

My process:

  1. Provide Context: I give the model the full feature request, relevant existing code, and any key constraints (e.g., "this must be a serverless function," "use this library").
  2. Request a Plan: I ask for a detailed implementation plan, including suggested data models, API endpoints, and a file-by-file breakdown of changes.
  3. Debate and Refine: I challenge the initial plan, asking about edge cases, alternative libraries, or potential performance bottlenecks. This iterative dialogue produces a much stronger starting point.

The goal is to use the AI as a high-level architect to map out the solution before any code is written.

Phase 2: Cross-Validation with a Different Model

No single model is infallible. To reduce the risk of hallucination or suboptimal design, I take the plan from Phase 1 and present it to a different model, such as GPT-5 Thinking or Claude Sonnet 4.

I ask it to critique the plan: "What are the weaknesses of this approach? What could go wrong? Suggest an alternative design."

This cross-validation step is crucial. It is especially useful for catching subtle flaws, such as references to non-existent libraries, and often uncovers a simpler implementation path or identifies dependencies that the first model missed. This is the AI equivalent of a design review.

Phase 3: Execution with Specialised Tools

With a validated plan, I move to implementation, using a set of specialised, task-specific AI tools.

  • Cursor for Code Implementation: For the inner loop of writing and refactoring code, Cursor is my primary tool. Its tight integration with the editor means I can apply AI assistance—from generating functions to refactoring blocks—without breaking my flow.
  • Vercel v0 for UI Scaffolding: To quickly generate React components, I use v0. It excels at turning high-level descriptions ("a settings page with a toggle for dark mode") into clean, production-ready JSX with Tailwind CSS.
  • Perplexity for Grounded Research: When the plan requires new knowledge (e.g., "how to use a specific feature of a new library"), I use Perplexity. Its focus on providing cited, up-to-date answers is more reliable for technical research than a general-purpose chat model.
  • Injecting Up-to-Date Library Documentation: A model's knowledge of a library is only as current as its last training run. To get accurate answers about a specific library's API, I use the /llms.txt pattern. Many modern libraries, like the Vercel AI SDK, now publish an endpoint (e.g., https://ai-sdk.dev/llms.txt) that provides their entire documentation as a single text file. I feed this to the model as context before asking implementation questions. This prevents it from hallucinating deprecated functions or incorrect usage patterns. The main trade-off is context window size: this file can be large, so the technique is best used with large-context models. (This site uses the same approach to provide its own content to models — you can see it at /llms.txt.)
  • AI-Powered Code Review and Documentation: Once the code is ready for review, I use AI to automate the first pass. This can be integrated directly into a CI/CD pipeline. When a pull request is opened, a GitHub Action triggers a script that sends the diff to a model like Claude Opus 4.1, along with the project's coding rules. The model's review—checking for bugs, style violations, or unclear logic—is then automatically posted as a comment on the PR. This catches simple errors and lets human reviewers focus on the architecture. The same process can generate docstrings and comments for the new code.

The Foundation: A Detailed System Prompt

This entire workflow is underpinned by one principle: define the rules before you ask for work. Instead of a simple one-line instruction, I provide AI models with a detailed "system prompt" or a rules document that acts as a project constitution. It is the single most effective way to improve the quality and consistency of AI-generated output.

My rules document typically includes:

  • The Full Stack: Be explicit. "This project uses Next.js (App Router), TypeScript, Tailwind CSS, and PNPM on Node 22." This prevents the model from suggesting incompatible technologies or outdated patterns.

  • Directory Structure and Naming Conventions: Define the source of truth for code organisation. "All page components are in app/. Use kebab-case for files, PascalCase for React components, and camelCase for functions and variables."

  • Architectural Patterns: Enforce non-negotiable design decisions. "All data fetching must occur in Server Components. State should be managed with simple props or React context; do not introduce a global state manager."

  • Coding Style and Philosophy: Go beyond a linter config. "Style components using Tailwind utility classes directly in the JSX; do not create separate CSS files. All functions must be typed, and any use of any must be justified with a comment."

  • Language and Tone: Set clear rules for prose, both in documentation and UI copy. "All user-facing text must use UK English. Avoid em-dashes (—); use a spaced hyphen (-) or a colon instead. Remove filler phrases like 'it's important to note' or 'in today's world'. Prefer the active voice."

  • Process and Workflow: Define how the model should interact with your development process. "All git commits must follow the Conventional Commits specification (e.g., feat: ..., fix: ...). All new business logic must be accompanied by unit tests written with Vitest."

Providing these constraints up front dramatically increases the quality of the AI's output, turning it from a creative but erratic partner into a reliable executor that understands your project's specific needs.