Illustration of a developer at a computer with AI network nodes above his head and on the screen, symbolizing artificial intelligence architecture for developers.

Vibe Coding Is Just the Beginning: How to Think Software Architecture with AI

How to architect systems with AI: agents, patterns (RAG/ReAct), 12-Factor Agents, and trade-offs in latency, cost, and quality.

Author: Rian Tavares
min read: 10 min
AISoftware ArchitectureAI AgentsRAGReAct12-Factor Agents

Share this post:

AI for Devs: How to Architect Solutions in the Age of Artificial Intelligence

“Teaching is one of the best ways to learn.”

I joined a three-day AI for Developers bootcamp and came out with a flood of concepts, frameworks, and practical examples. To consolidate what I learned, I decided to turn my notes into an article — not just for myself, but for any dev who wants to understand how software architecture is changing with AI at the core.

From the Vibe Coding Hype to Architecture

We’ve lived through revolutions before: cloud, microservices, DevOps, CI/CD. What’s happening now goes beyond how we write code: it’s changing how we design systems.

The Vibe Coding phenomenon — letting AI write code from descriptions — is fun, but shallow. The real value lies not in “typing lines,” but in orchestrating intelligent systems, connecting models, infrastructure, and humans.

The Three Layers of AI Architecture

In the workshop, I learned to break this world down into three layers:

  • Application Development → where most of us live: building apps that leverage AI, designing prompts, preparing context, and evaluating results.

    💡 Example: a smart search bar that translates queries and returns structured results.

  • Model Development → the domain of ML engineers and researchers. They improve models: optimize inference, fine-tune for specific domains, or even create new architectures.

    💡 Example: adapting an LLM to answer medical questions.

  • Infrastructure → the invisible foundation that keeps everything running. This is where scale, security, and monitoring come in.

    💡 Example: keeping a chatbot running for thousands of users without leaking data.

These layers aren’t isolated — AI cuts across all of them and often serves as the translator between product, devs, and security.

My Demo Project: AI-Assisted Authentication API

To avoid staying in theory, I built a demo project. The idea was simple: a signup/login API with JWT, using Node.js, TypeScript, and Express. The challenge wasn’t the code itself — it was seeing how AI could help in the process.

  • Stack: Node.js + TS + Express, JWT (15 min), Zod, bcryptjs, in-memory DB.
  • Structure: ai/context, ai/plans, ai/prompts → directories to organize how I interacted with AI.
  • Current state: stubbed endpoints (501), empty tests, but with structured context docs, checklists, and prompts.

One of the most interesting experiments was generating a PRP (Product Requirement Prompt) for the login feature. The AI returned a doc with acceptance criteria, error cases, and even a security checklist. I didn’t implement everything, but just having that “contract” before coding changed how I looked at the task.

AI Agents: Way Beyond Chatbots

One clear takeaway from the workshop: agent ≠ chatbot. The chatbot is the interface. The agent is the component capable of reasoning, acting, and interacting — even with other agents. This movement, called Agentic AI, only makes sense with clear protocols and patterns.

Design Patterns Every Dev Should Know

Just like we rely on Factory or Adapter, new AI-specific patterns are emerging. Here’s how some of them play out:

  • RAG (Retrieval-Augmented Generation) → say you’re building an intelligent FAQ. A plain LLM would hallucinate answers. With RAG, the AI first fetches info from the right docs (knowledge base) before generating a response.
  • ReAct (Reason + Act) → the model alternates between reasoning and acting. Example: asked “what’s the weather tomorrow in Lisbon?”, the AI reasons about what’s needed and calls a weather API before answering.
  • Planner/Executor → useful in complex tasks, like data pipelines. One agent creates the plan (steps), another executes them. Separation of concerns makes debugging easier.
  • Critic/Reviewer → one agent writes code, another reviews with defined criteria (lint, security, performance). In my demo, this pattern not only flagged errors but suggested improvements in Express structure.

These patterns give us a common language for building scalable solutions.

12-Factor Agents and Engineering Discipline

Inspired by the classic 12-Factor App, the new 12-Factor Agents bring that mindset to agents. A few highlights that stuck with me:

  • Natural Language to Tool Calls → turn NL into actions. Example: input “create user” → structured call to /auth/signup.
  • Own Your Prompts → control prompt and context construction. If prompts get too big, quality drops.
  • Small, Focused Agents → each agent should have a clear task. In my demo, having an “auth agent” made more sense than one agent handling signup, login, and security at once.
  • Human Integration → know when to escalate. If the AI can’t decide a password policy, it should suggest options and ask for human input.

Instead of a giant script, we start thinking in observable pipelines.

Security and Guardrails

Another hot topic: risks. Jailbreaks, prompt injection, data leaks. The answer? Guardrails + continuous evaluation.

In my demo, for example, AI suggested logging login payloads for debugging. Fine in dev, but a huge risk in prod. A simple guardrail: never log raw passwords. These checks need to be baked into the flow.

And it’s not just about early testing; you need to monitor quality, latency, and cost constantly.

Reasoning Techniques

Three reasoning techniques that really clicked for me:

  • Chain of Thought (CoT) → AI writes step by step before answering. When I asked how to validate input with Zod, it first listed steps, then generated code.
  • Tree of Thought (ToT) → explore multiple paths before choosing. Great for design: testing different auth approaches and weighing pros/cons.
  • Skeleton of Thought (SoT) → predefined logical templates. I used SoT in a code review prompt: the AI followed the “Security / Performance / Readability” skeleton to structure its feedback.

Action Plans and PRPs

This might be the biggest learning. Action Plans work as maps: you define where human work stops and AI autonomy starts. Two strategies:

  • Global Plan: describe the whole system and let AI break it down.
  • Stage Plan: define only the current stage (e.g., auth), and let AI generate the local plan.

In my demo, the Global Plan was too generic. The Stage Plan was way more useful, spitting out steps like “create signup schema,” “implement POST /auth/signup,” “validate with Zod.”

PRPs (Product Requirement Prompts) are different: they’re like Jira tickets in prompt format. For the login feature, I wrote:

Context: Basic authentication system for Express API.
Task: Implement POST /auth/login that takes email/password.
Requirements: Validate with Zod, return 15-min JWT.
Acceptance criteria:
- Returns 401 if invalid credentials
- Returns {token} on success
- Token expires after 15 min

The AI then suggested starter code + a security checklist (e.g., don’t store raw passwords). I didn’t follow everything, but just having that contract upfront improved my flow.

The Future Is Architecting with AI

The vibe coding hype is just the surface. What really matters is learning to architect with AI at the core: from the three layers to Agentic AI, from design patterns to 12-Factor Agents, plus security, reasoning, and PRPs.

Writing code still matters. But the edge will belong to those who can structure intelligent systems.

👉 And about you, how are you integrating AI into your architecture today?