In my recent posts, I’ve argued that Velocity is an Illusion and that to survive the AI age, we need to stop acting like factory workers and start acting like Architects.
But in my point of view “philosophy needs enactment, otherwise it’s just words”.
If I’m going to tell you to “build the pipeline, not just the product,” I need also tell you “how”, that’s why I presenting you my personal AI Assisted Software Development Pipeline.
The process you are about to see is not a “magic prompt” that writes your app in 5 seconds. It’s a rigorous workflow born from years of coding, designing and testing, reading technical papers, suffering through bad architectural decisions, leading test automation efforts, and experimenting with the friction between human intent and machine execution. (I apologize in advance: while this is built on the shoulders of giants from “Clean Code” to more modern Systems Thinking, I cannot cite every specific source that influenced this work).
Here is how I use AI not just to write code, but to think.
The Core Philosophy: Parameters > Prompts
Most people use AI like a slot machine: they pull the lever (prompt) and hope for a jackpot (working code). I use AI like a flight simulator. I define the physics, the boundaries, and the mission profile before I let the pilot take off.
You can find my complete “System Prompts” and process documents in my public repository here: Rod’s AI Code Assistant Software Development Process
This process is tool agnostic. Whether you use Cursor, GitHub Copilot, ChatGPT, Gemni, or Claude, the logic remains the same.
Phase 1: The Fight with The Rigorous Architect
Tool: Rod’s Reflective Architectural Sparring Partner (RRASP)
How to use it: Copy the text from the RRASP.md file and paste it into your AI’s “System Instructions” (if using ChatGPT/Claude) or simply paste it at the very start of a new chat session.
The Interaction: Before I write a single line of code, I argue. I don’t use AI to validate my ideas; I use it to stress-test them.
- You say: “I want to build a real-time chat app using Firebase.”
- Standard AI says: “Here is the code for a chat app!” (by its inherent Sycophantic nature).
- RRASP says: “Hold on. You mentioned ‘real-time’ but didn’t define the scale. Are you optimizing for low latency or message persistence? If you use Firebase, have you considered the read/write costs if this scales to 10k users? What is your strategy for offline sync?”
For the Junior/Non-Technical: This saves you from building the “wrong” thing perfectly. It forces you to answer questions you didn’t know you needed to ask.
For the Senior Architect: This is “Shift-Left” testing applied to requirements. It combats the “Sycophancy Bias” inherent in RLHF (Reinforcement Learning from Human Feedback) models. By forcing the model into Critique Mode, you transform it from a “Yes Man” into a devil’s advocate, allowing you to catch architectural flaws (e.g., race conditions, scalability bottlenecks) before a single commit is made.
Phase 2: The Treaty (The Documentation)
Tool: Rod’s Software Project Documentation Assistant
The Flow: Once you have finished your argument in Phase 1 and have a solid idea, you open a new chat. Paste the Documentation Assistant prompt. Then, copy the summary (or your own abstract) of the discussion from Phase 1 and feed it here.
The Output: We don’t “vibe code” here. We “Design Code.” This assistant ensures that when we finally do ask for code, the AI has a rigid sandbox to play in. It generates a structured design document containing:
- Context & Goals: The “Why.”
- User Stories: The “What.”
- Technical Constraints: The “How” (and the “What NOT to do”).
For the Junior/Non-Technical: Think of this as the blueprint. You wouldn’t ask a contractor to “build a house” without drawings. This tool creates the drawings for you so the AI knows exactly where the walls go, what materials to use for the proposed load and leave the proper space for the windows, doors and plumbing.
For the Senior Architect: This enforces Design by Contract. The generated artifact acts as a “Context Anchor” for the LLM. By explicitly defining boundaries (e.g., “Use PostgreSQL, not MongoDB” or “Max payload size is 2MB”), you drastically reduce hallucinations and “drift” during the implementation phase. It forces the separation of concerns between Design (human-led) and Implementation (AI-assisted).
Phase 3: The Implementation (The Jarvis)
The Execution: Only now (after the fight and the treaty) do I let the AI write code. Because I have a robust design document, I don’t need to micromanage the syntax of a loop. I can say:
“Implement the User Authentication flow defined in
Section 2.1of the Design Document. Adhere strictly to the error handling patterns inSection 4.”
But before even asking for the first line of code (or perhaps even the whole project’s tech-stack setup), I ask RRASP to:
“Layout an detailed implementation plan document, based on all the information you have of the project”
The Result: A well structured and ordered set of steps you (and your AI code assistant) can follow and keep track of the progress (even between coding sessions, or when you need to wait for when you run out of tokens XD )
I’ve also made some tweaks for some projects adding more “technical details” before coding, like:
“Create the Entity-Relationship Diagram for all the data that needs persisting storage”
“Create the required UML diagrams in mermaid for the feature 2.3”
“Document in a markdown file called considerationsForFeatureX.md any potential implementation risks for FeatureX”
The Result: The friction I introduced early on (by sparring with the grumpy AI Architect) makes the implementation phase frictionless. I can understand how my intent is going to be implemented into code and if the AI gets stuck, I don’t prompt-engineer a solution; I point back to the document: “You violated Constraint #3.”
For the Junior/Non-Technical: This makes you a Technical Project Manager. You define the task, the AI executes it, and you verify it against the plan you created in Phase 2.
For the Senior Architect: This is the ultimate form of Context Engineering. You are effectively reducing the probabilistic search space of the model. By constraining the context with a rigid spec, the AI’s output becomes far more deterministic and reliable. You stop debugging code and start debugging logic.
Final thoughts
A big mistake I see all the time with some beginners while implementing this process is to let the AI just “spit” the documents and move “right straight to coding” without ever opening the documentation (let alone “understand it”). The current state of AI (and certainly the process presented here) “begs” for a Human In The Loop.
Read the specs you asked for, inform yourself about the technical decisions made (specially if anything seems unfamiliar or odd), approve the tech stack, question the AI about things you care about (e.g. user experience, platform compatibility, scalability, performance, security, “deployability”, etc.).
This process helps you guide the AI towards you goal but it’s irresponsible (to say the least) to just let it loose!!!
Andrej Karpathy, himself stated that (and I’m paraphrasing here) “it’s difficult to keep up” with the AI, but you must be involved! Don’t be the guy that just sees the code “stream away”.
A Call to Open Source Your Mindset
This repository is my personal protocol. It’s very opinionated, and it’s specific to “my style”. I’m aware that there are other ways to approach this, like “gemini-cli + conductor“, Github Copilot or work your way out with claude code or even a project like “fabric“. I’ve used them and I think they are great, but I’m also aware of their limitations and nothing stops you (or me) to use them combined!!!
I’m sharing this work not because it’s perfect, but because I want you to see if it’s useful for you. Fork it, take these prompts, break them, adapt them to your specific domain, and build your own workflow. This way you can stop trying to be “faster than the AI” but be the one who tells it where to go.
Expand, enhance, and share your process. The future belongs to the Architects, not the typists.
