How to automate your dev workflow with AICODESIT's Pipeline Builder (2026)

What the Pipeline Builder is (and what it is not)

The regular AI Chat panel in AICODESIT is conversational — you type a prompt, the AI responds, you type again. That works well for exploratory work. But some tasks are not exploratory. They are the same ten steps every time: read the codebase, generate a draft, check it against a spec, apply corrections, write the files. Repeating that sequence manually, message by message, is slow and error-prone.

The Pipeline Builder solves this. It is a visual, graph-based editor where you wire together AI agents, data sources, logic nodes, and tool grants into a workflow that runs automatically from start to finish. You run it once by clicking a button, or you call it from your own code via the API. Either way, every step fires in sequence, outputs flow from node to node via variables, and the result lands in your project files — without you supervising each step.

The Pipeline Builder is not a general-purpose workflow tool like Zapier or n8n. It is specifically designed around AI agents that read and write to a codebase, call databases, fetch external URLs, run sandboxed commands, and generate files. Every feature is built for that use case.

The building blocks — every node type explained

A pipeline is a directed graph of nodes connected by edges. Each node has a type that determines what it does when it fires. Here is every type available.

Node type	What it does
Agent	Sends a system prompt + user prompt to an AI model. Can write files, run commands, query databases, generate images — depending on what a connected Tools node grants.
Transform	Same as Agent, but semantically marks this step as a data transformation — useful for reshaping the output of a previous step.
Tools	Grants capabilities to the preceding Agent. Connect an Agent → Tools edge to unlock: file writing, shell commands, web search, database reads/writes, image generation, video generation, edge function deployment, and browser screenshots.
Input	Feeds the user's message into the pipeline as {{user_message}}. Can also override with a fixed prompt so the pipeline always starts with the same instruction regardless of what the user typed.
System Prompt	Overrides an Agent's system prompt via an edge. Useful for dynamically building a system prompt in one step and injecting it into the next agent.
Fetch	Makes an HTTP request (GET, POST, etc.) to any URL. The response becomes the step's output, available as a variable to downstream agents.
Read File	Reads one or more files from the project directory. The contents are injected as a variable for the next agent to reason about.

Nodes are connected by edges. A normal edge means "run this node next". A back-edge (an edge pointing to an earlier node) creates a loop. A Tools-return edge (from Tools back to the Agent that owns it) tells the pipeline to keep feeding tool results back into the agent until it is done, then continue.

Variables: how steps pass data to each other

Every step that produces output stores it in a variable that downstream steps can reference. The variable name follows the pattern {{step_N_output}}, where N is the step number in the execution order. If Step 1 produces a database schema and Step 2 needs it, the Step 2 prompt can include {{step_1_output}} and it will be substituted automatically before the AI sees it.

Beyond step outputs, the pipeline injects a set of global variables into every step:

Variable	What it contains
{{user_message}}	The message the user typed when triggering the pipeline run.
{{file_tree}}	A flat list of every file in the project — updated fresh at each step.
{{project_url}}	The live preview URL of the project.
{{db_schema}}	The current database schema (table names, columns, types). Available when the project has a connected database.
{{conversation_history}}	The full AI chat history for this project, so agents can reason about what has already been built.
{{system_prompt}}	The project's global system prompt — the same one the regular AI Chat panel uses.
{{DB_URL}} / {{DB_API_KEY}}	Database REST endpoint and API key — substituted server-side, never exposed in client code.

Variables make pipelines composable. You can chain ten agents, and each one receives exactly the context it needs — nothing more, nothing less — because you control which variables appear in each step's prompt.

Loops, branches, and self-loops

Linear pipelines are useful. But many real workflows are not linear — they need to retry, fan out, or iterate until a condition is met. The Pipeline Builder handles all of these.

Self-loops: repeat a step until it is satisfied

Any Agent node can be set to self-loop up to N times. On each iteration, the step runs again with fresh context — it can see the output of its previous iteration via {{step_N_output}}. You set a break condition: a string that, if it appears in the output, stops the loop early. A common pattern is an Agent that reviews its own work and outputs DONE when satisfied, or keeps revising until it is.

Example: a code quality agent self-loops up to 5 times. Each iteration reads the current file, checks for issues, and either outputs a corrected file plus DONE, or outputs a corrected file and continues. The pipeline stops as soon as DONE appears.

Back-edges: loop back to an earlier step

Draw an edge from a downstream node back to an earlier node and you get a loop. The edge carries a max iterations setting (default: 3) and an optional break condition. When the target node has been visited that many times, or the output matches the break condition, the pipeline exits the loop and either stops or follows the next outgoing edge.

Parallel branches: fan out and collect

A Branch node splits execution into multiple parallel paths. All branches run simultaneously — each branch is its own mini-pipeline with its own sequence of steps. When they all finish, the results merge and flow to the next node.

There are two join modes. Wait all collects every branch's output, concatenates them, and passes the full result downstream. First wins races the branches and takes the output of whichever finishes first — useful when you want the fastest result from several competing approaches.

Sub-agents: parallel AI work inside a single step

Sub-agents are one of the most powerful features in the Pipeline Builder, and one of the least obvious. They let a single Agent node spawn multiple AI calls in parallel — mid-stream, without any extra nodes in the graph.

Here is how they work: when an Agent's output contains a <sub_agent> tag, the pipeline detects it and immediately fires a separate AI call with the prompt and capabilities defined inside the tag. Multiple sub-agent tags in a single response run in parallel. Their outputs are collected and injected back into the main agent's context before it continues.

A practical example: an architecture Agent analyses a spec and decides it needs to research three things simultaneously — the best database schema for the use case, the right authentication approach, and the available third-party APIs. It outputs three <sub_agent> tags, each with a specific research prompt. All three fire at the same time. When they are all done, the main Agent receives their outputs and writes the implementation plan.

Sub-agents can have their own model, their own capabilities, and their own tool grants — configured independently from the parent agent. This lets you use a fast, cheap model for sub-agents doing simple lookups while keeping the expensive model for the orchestration layer.

4 real pipelines you can build today

Here are four concrete pipeline designs that demonstrate how these features combine in practice. Each can be built inside AICODESIT's Pipeline Builder in under ten minutes.

1. Automated code review pipeline

What it does: Reviews every file changed in a session, flags issues, and applies fixes — then outputs a summary.

Structure:

1. Input node — passes the user's message (e.g. "review everything I changed today")
2. Read File node — reads the file tree to identify recently modified files
3. Agent: Reviewer — reads each file using {{file_tree}} and the Read File output, identifies bugs, style violations, and security issues. Self-loops up to 3 times, breaking when output contains ALL CLEAR.
4. Agent: Fixer — receives {{step_3_output}} (the review), reads the flagged files, and applies corrections using the file-writing capability.
5. Agent: Summariser — reads both the review and the fix outputs and writes a short Markdown summary saved to REVIEW.md.

Key settings: Grant the Reviewer agent read capability (via Tools node). Grant the Fixer agent file-write and command capability so it can apply edits and run a lint check.

2. Content generation pipeline

What it does: Takes a topic from the user, researches it via web search, writes a draft, then runs an SEO check — all in one click.

Structure:

1. Input — captures the topic from the user message
2. Agent: Researcher — receives {{user_message}} and uses web search (via Tools) to gather current data, stats, and examples. Outputs a structured research brief.
3. Parallel Branch — splits into two simultaneous paths: one agent writes the full article draft, another writes the meta title, description, and keyword list. Both receive {{step_2_output}}.
4. Agent: Editor — waits for both branches (wait_all join), receives the draft and the SEO metadata, merges them, and writes the final file to content/[topic].md.

Key settings: Use Claude Fable 5 or Opus 4.8 for the Researcher and Editor (complex reasoning). Use Claude Haiku for the SEO metadata branch (a straightforward structured task).

3. Database seeding pipeline

What it does: Reads the current database schema and generates realistic seed data for every table — without hallucinating column names or types.

Structure:

1. Input — user specifies how many rows per table (e.g. "seed 20 rows per table")
2. Agent: Schema Reader — uses {{db_schema}} to understand every table. Outputs a structured plan of what seed data to generate, respecting foreign key relationships.
3. Agent: Seeder — receives the plan via {{step_2_output}} and uses database curl commands ({{DB_URL}} + {{DB_API_KEY}}) to INSERT rows into each table in the correct dependency order. Self-loops up to 5 times until all tables are seeded.

Key settings: Grant the Seeder agent database-write capability. Use the break condition seeding complete on the self-loop. This pipeline is particularly powerful because {{db_schema}} is resolved fresh at each step, so the Seeder always has the current table state.

4. Screenshot-to-redesign pipeline

What it does: Takes a URL, screenshots it, critiques the design, and rewrites the frontend to match a target aesthetic — entirely automatically.

Structure:

1. Input — user provides the URL and describes the target aesthetic (e.g. "modern SaaS, dark mode, Inter font")
2. Agent: Screenshotter — uses the browser-screenshot capability to capture the URL. Outputs the screenshot reference.
3. Agent: Design Critic — receives the screenshot and the target aesthetic via {{user_message}}. Analyses the current design and outputs a specific list of changes needed.
4. Agent: Implementer — receives {{step_3_output}} (the change list), reads the relevant frontend files using {{file_tree}}, and rewrites them. Has file-write capability enabled.

Key settings: Use a vision-capable model (Claude Fable 5 or Opus 4.8) for the Design Critic step. Pin the relevant component files into the Implementer's context using the Context Files setting so it always sees the current code.

Tips for building reliable pipelines

Start with two nodes, not ten

The most common mistake is building a ten-step pipeline on the first attempt. Start with the two most critical steps, run them, verify the output is what you expect, then add the next node. A pipeline you can debug is worth ten pipelines you cannot.

Use the Preload setting to give agents exact context

Every Agent node has a Preload section where you can specify files to read, strings to grep for, or URLs to fetch before the agent runs. Use this instead of asking the agent to read files itself — it is faster, deterministic, and does not consume tool-call loops.

Pin context files for agents that touch code

For any agent that writes or edits files, use the Context Files setting to pin the specific files it will touch. This ensures the agent always sees the current file content rather than working from a stale memory of what was there in step 1.

Use cheap models for structured steps

Not every step needs Claude Fable 5. Steps that format output, route a decision, or extract structured data from a clean input work fine with Claude Haiku — at a fraction of the cost. Reserve Fable 5 or Opus 4.8 for steps that require genuine reasoning: architecture design, complex code generation, or multi-file coherence checks.

Set break conditions on every loop

A loop without a break condition will always run to its maximum iteration count. That wastes credits and time. Choose a specific, unambiguous break string — something the AI will output naturally when it is actually done, like COMPLETE or NO ISSUES FOUND — and set it as the break condition on the edge or self-loop.

Use the log panel to debug step by step

When a pipeline runs in the Pipeline Editor, the log panel shows each step firing in real time, including tool calls, file writes, database operations, and cost per step. If something goes wrong, the log tells you exactly which step failed and why. Read it before adding more nodes — the fix is almost always in the prompt of the failing step, not the graph structure.

Conclusion

The Pipeline Builder is the part of AICODESIT that converts one-off AI work into a repeatable process. Once you have built a pipeline for a task you do regularly — code review, content generation, database seeding, design iteration — you run it with a single click and get a consistent, high-quality result without supervising every step.

The key primitives — variables, loops, parallel branches, sub-agents, and tool grants — are composable. A pipeline that looks complex is almost always just a few of these simple pieces connected together. Start with two nodes, verify the data flows correctly between them, and build up from there.

The four pipelines in this post are a starting point. Every project has its own repetitive multi-step work. The Pipeline Builder is how you stop doing that work manually.

Open the Pipeline Builder in AICODESIT →

---

Related: How the Pipeline Editor works — node types and the visual interface · Claude Fable 5 on AICODESIT — the best model for complex pipeline steps