AI-Powered Automated Web Development System

We propose a modular AI system where a central orchestrator LLM decomposes a complex web
development task, and then spawns specialized agents (LLM instances) to implement each component. The
orchestrator uses LLM reasoning (chain-of-thought, planning, and role-playing) to break down the prompt
into sub-goals: choosing the tech stack (frontend, backend, database, etc.), then decomposing each feature
into functions or modules. Each function is assigned to a dedicated LLM “coder” agent that is given the
function signature, desired behavior, and I/O examples. The coder agent generates code, executes unit
tests, and returns results. A separate “validator” agent or code review process evaluates the output. Once
each component passes validation, the orchestrator integrates them into the final application. This multi-
agent, pipeline-based design parallels modern microservices architectures and leverages recent
frameworks (LangChain, LangGraph, AutoGen, CrewAI) to manage LLM workflows 1 2 .

Figure: Modular LLM-based development pipeline. A central orchestrator (green) decomposes the task (blue
arrows) and dispatches sub-tasks to specialized agents (other boxes). Agents use tools (e.g. code execution, search,
VCS) and report back results. Source: adapted from AWS multi-agent example 3 4 .

Architecture Design
The system follows an agentic AI pattern: a central coordinator (orchestrator) LLM and multiple worker
agents. The orchestrator reads the user’s high-level prompt (e.g. “build a shopping site with product search
and user login”) and formulates a plan. It first selects a suitable technology stack (React/Node/PostgreSQL,
etc.) by reasoning over project requirements. It then breaks the work into features (e.g. “Shopping Cart
service”, “User auth module”, “Search API”). This mirrors the practice of functional decomposition and
microservices: each feature becomes a service or module with its own data and behavior 5 1 .

1
Next, for each feature the orchestrator defines finer-grained functional units (functions, classes, or API
endpoints) and spawns an LLM agent to implement it. Each agent is an isolated LLM instance (a new chat
session or API call) with a focused prompt specifying the function’s name, description, expected inputs/
outputs, and examples. The agent uses code-generation models (GPT-4/Anthropic Claude, Codex, etc.) to
write the code. After generation, the agent runs its own unit tests (provided or auto-generated) and reports
success or failure. Optionally an evaluator agent checks style and security. Once validated, the code is
returned to the orchestrator. Finally, the orchestrator composes these components: connecting APIs, wiring
frontend calls, and performing integration tests.

This modular design has proven benefits. Task decomposition is a recognized design pattern for GenAI
systems – it improves correctness, scalability, and testability 6 7 . By limiting each agent to a specific
function, the system reduces hallucinations and concentrates expertise, akin to how modular LLMs improve
performance 8 6 . Agents communicate via shared data structures or a “scratchpad” memory,
coordinating like a dev team. For example, Amazon’s multi-agent orchestration uses a Planner, Writer, and
Editor agents in a CrewAI pipeline 9 4 , and research shows splitting a coding task among
“programmer”, “test-designer”, and “test-executor” agents greatly improves final code quality 10 4 . In
summary, the architecture is a pipeline of LLM agents organized by function, managed by a central AI
orchestrator 1 11 .

Task Decomposition and Planning

A core challenge is breaking down the prompt into subtasks. We leverage LLM prompting techniques
(chain-of-thought, tree-of-thought, etc.) and even specialized “Planner” agents. The orchestrator LLM first
performs high-level planning: it generates a list of features or modules needed and assigns roles (e.g.
“Researcher”, “Coder”, “DB Specialist”) 1 . It can also iteratively refine this list via self-reflection (as in
AutoGPT or BabyAGI) 12 . In practice, this uses prompt engineering: for example, the orchestrator might be
prompted with “Think step by step: what components are needed for this web app?” or “Act as a software
architect and list the classes and services required.” Techniques like Chain-of-Thought (CoT) prompting are
employed to get the model to reason sequentially 13 .

Once the high-level plan is set, each item is further decomposed. For instance, the “Shopping Cart” service
might be split into functions like addToCart(userId, itemId) , removeFromCart(...) ,
getCartContents(...) . This two-phase approach (outline then detail) aligns with the Task
Decomposition design pattern 14 . Research and industry case studies confirm this yields better results: e.g.
generate class signatures first, then fill in methods, or outline paragraphs before writing text 14 15 . This
divide-and-conquer strategy also simplifies testing: each sub-task can be validated independently, making
errors easier to diagnose 16 .

Agents can be structured by role or workflow. For example, one agent might specialize in database
schema design (outputting SQL), another in API endpoint logic, and another in frontend component code.
They operate in a defined pipeline or a graph (as supported by LangGraph 2 ) with conditionals and loops.
In a parallel pattern, multiple coder agents could work on different features simultaneously. Coordination
(e.g. updating a shared “memory” or messaging) ensures consistency. This is akin to CrewAI’s “Planner–
Writer–Editor” pipeline, where agents pass intermediate results to each other 11 .

Best practices from literature include: explicit planning prompts, multi-agent role assignments, and
iterative refinement. Lilian Weng notes agents should plan subgoals then self-reflect on their work 17 . The

2
AWS blog on agentic workflows highlights breaking a task into ordered steps or assigning specialized roles
(planner, executor, evaluator) 18 . Our system follows these: e.g., a Planner agent might confirm the tech
stack and architecture, Coder agents implement modules, and an Evaluator agent checks each piece. This
dynamic, task-driven decomposition – not rigid domain-driven design – is key for AI agents 19 .

Spawning and Managing LLM Agents

Each function or subtask is handled by a fresh LLM instance (via API). In practice, this means creating a new
chat/completion request with a prompt tailored to that unit. The orchestrator can spawn these agents
dynamically and in parallel. For example, using Python’s asyncio or a task queue (Celery, AWS Step
Functions) to issue multiple LLM API calls concurrently for independent subtasks. Frameworks like
LangChain or CrewAI facilitate this: you define agent classes and workflows, and the framework handles
invoking each model call with the appropriate system and user prompts 20 21 .

Managing many LLM instances requires careful orchestration. One approach is to treat each agent as a
lightweight object with its own conversation state and tools. LangChain’s Agents or LLMChain abstractions
can be used, or Microsoft’s AutoGen (which supports spawning “bots” that talk to each other) 22 . CrewAI,
for instance, lets you programmatically create agents with roles and assign them to tasks in a “Crew” 21 .
Resource management (rate limits, API keys) is handled by the orchestrator: it keeps track of active calls and
can queue or prioritize as needed.

In summary, dynamic instance management is achieved by using existing multi-agent frameworks or

custom orchestration code. At runtime, the orchestrator issues API calls to OpenAI or Anthropic for each
needed function. Each call is an isolated context (“new LLM”), ensuring no leakage between different
components. The orchestrator collects each agent’s result before proceeding. This model is akin to
launching microservices on-demand: each agent is a stateless function call to an LLM, returning code or
output once done.

Code Verification and Testing

Ensuring the generated code is correct, secure, and high-quality is crucial. Our system incorporates
automated testing and review at multiple stages. Each coder agent not only writes code but also runs
unit tests. These tests may be provided by the orchestrator (based on specs) or generated on-the-fly. For
example, the orchestrator might prompt the agent, “After writing the function, run these example test cases
and report success or error.” If a test fails, the agent can iteratively refine its code. This loop – generate, test,
correct – is supported by recent work: AgentCoder uses a “test-executor” agent to run tests and feed back
results to the programmer agent 10 , yielding much higher pass rates than single-shot generation.
Similarly, deepsense.ai’s Multi-Step Agent pipeline raised code correctness from ~54% to ~82% by
integrating testing and iterative review 23 .

Beyond tests, we use static analysis and linters. After generation, code is automatically checked with tools
like ESLint (for JavaScript) or PyLint (for Python) to catch syntax/style issues. Type-checkers (TypeScript,
MyPy) can also validate interfaces. Security scanning tools (e.g. Snyk, Bandit) flag vulnerabilities. Some
systems even use LLMs to audit LLM output: an “Evaluator” agent can prompt the model to critique or
proofread the code. Frameworks like Patronus can run LLM-based evaluation prompts to judge output
quality.

3
Additional tests can be generated by specialized tools. For instance, IBM’s ASTER system uses static analysis
to craft LLM prompts that produce runnable, human-like unit tests 24 . We adopt a similar hybrid approach:
static analysis extracts function signatures and context, then the orchestrator prompts an LLM to generate
additional test cases. The test executor then validates the code. This two-tier verification (LLM-based unit
tests + conventional tests) greatly boosts reliability.

Finally, a CI/CD pipeline automates these checks. Each code module is versioned in Git; upon generation, we
run linting, unit/integration tests, and regression tests via CI tools (GitHub Actions, Jenkins). If any test fails
or coverage drops, the orchestrator is alerted to revise the relevant code. This aligns with best practices for
AI-driven development: extensive automated testing is essential to catch subtle LLM errors 25 . In sum,
combining iterative LLM self-correction (generate-and-test loops) with traditional software QA (tests, linters,
static analysis) ensures the system’s outputs are robust and maintainable 6 4 .

Secure Integration and Orchestration

Integrating generated functions into a coherent, secure system requires caution. Isolation is key when
executing LLM-written code. We never run untrusted code on the host OS directly. Instead, each code
execution (for tests or demos) happens in a sandboxed environment. This may be a container (Docker) or a
managed sandbox service. Hugging Face’s smolagents , for example, wraps Python execution in a custom
interpreter that blocks unsafe imports and limits operations 26 . Similarly, we can use Docker sandboxes to
run code: AWS, Hugging Face, and open-source tools like LLM Sandbox support spinning up ephemeral
containers (or E2B sandboxes) for secure execution 27 28 . These containers have no access to the host
filesystem or secrets and are torn down after use. This prevents malicious code from harming the system.

On the orchestration side, we ensure credential safety and network security. The orchestrator keeps API
keys and database credentials encrypted; agents only receive the minimal context needed. For database or
web calls, the agent can invoke secure APIs rather than embedding sensitive strings in the prompt. We also
apply standard code security: sanitizing any user inputs, validating third-party library versions, and using
read-only DB roles.

To integrate modules, the orchestrator creates glue code (e.g. import statements, routing). It verifies
compatibility (e.g. matching function signatures) before final build. End-to-end integration tests (calling the
full app’s APIs or UI) are then run in a staging environment. Any failing component triggers a feedback loop
to revise that part. Overall, the system treats generated code as first-class software components, subjecting
them to the same secure development lifecycle as handwritten code.

Tools, Frameworks, and Libraries

Current technologies make this system feasible. Agent orchestration frameworks simplify
implementation:

• LangChain (2023+) provides primitives for LLM “chains” and agents with tool integrations 20 . It
supports both sequential and dynamic tool use, and has a memory feature to maintain context.
• LangGraph (2023) extends LangChain with graph-based workflows: you can define agents as nodes
and specify branching/loops 2 . This is ideal for complex pipelines (e.g. conditional logic based on
previous results).

4
 • AutoGen (Microsoft, late 2023) emphasizes multi-agent dialogue and delegation, allowing agents to
call each other and humans easily 22 . It even supports human-in-the-loop checkpoints.
• CrewAI (2024) is an open-source Python framework for multi-agent teams. It lets you declare agents
with roles and assemble them into a “crew” pipeline 21 . CrewAI handles task assignment and data
flow between agents.
• smolagents (Hugging Face, 2024) provides a lightweight agent architecture focused on code tasks.
It includes tools for secure code execution and telemetry. We use it (for example) to implement our
iterative code agents with sandboxing 26 .

For LLM APIs, we rely on current models (GPT-4 Turbo, Claude 3, etc.) via their REST endpoints. We use
appropriate libraries (OpenAI Python SDK, Anthropic SDK) under each agent. For container orchestration,
we leverage Docker or AWS ECS/EKS to run sandboxed code. Continuous integration is managed by tools
like GitHub Actions.

Examples of related projects confirm feasibility. ServiceNow built a Workflow Generation app using Task
Decomposition and RAG patterns, showing these can meet production constraints 15 14 . The open-source
AgentCoder achieves state-of-the-art code generation by exactly this modular approach of programmer/
tester agents 10 29 . Other demos include Aider (GPT-based pair programmer) and OpenHands
(autonomous code pipeline) 4 . In short, many research teams and companies have validated that
decomposing software tasks into LLM agent workflows yields higher correctness and maintainability.

Practical Implementation Guidance

To build this system: 1. Choose the orchestrator model: Start with a strong conversational LLM (e.g. GPT-4)
as the central planner. Develop a prompt template that instructs it to output a task breakdown and tech
stack recommendation from a high-level requirement.
2. Define agent roles: For each layer of decomposition, define an agent (or function) prompt. For instance,
a “Signature Generator” that lists function names, a “Code Writer” for bodies, and an “Tester” agent. Encode
these prompts in your code. 3. Implement the pipeline: Use a framework (e.g. LangChain/Agents or a
custom manager) to automate the flow: send the high-level prompt to the planner, parse its output into
tasks, then loop over tasks and invoke the coder agents.
4. Manage state: Maintain a context object or database to track each component’s code and status. Use
vector DB or knowledge base if using RAG to provide documentation or API info to agents.
5. Run code securely: Set up a sandbox (Docker container or specialized executor) to run and test each
code snippet. Pass test cases to the sandboxed environment and capture results. 6. Validation and
feedback: After code is written and tested, have an evaluator step. This could be an LLM prompt like
“Review this code for bugs and style issues” or static tools. If problems are found, feed them back to the
relevant agent (prompting it to fix issues).
7. Integration: Assemble all validated modules into a project scaffold. Have the orchestrator LLM generate
any connecting code (e.g. importing modules, setting up routes). Run full-system tests (integration/UI tests).
8. Iterate and refine: Use human or automated review of the final output. Adjust prompts or
decomposition strategy based on shortcomings.

Throughout, apply DevOps best practices: version-control all generated code, use CI pipelines to run tests,
and apply linting. Adopt security measures like API whitelisting and least privilege for any generated scripts.

5
By combining these strategies and tools, an end-to-end AI system can plausibly automate much of web
development with today’s LLMs. While oversight is still needed, recent advances (modular agents, iterative
test-based refinement, multi-agent orchestration) make it increasingly viable 14 23 .

1 5 18 19 Microservices vs. Agentic AI (Part 1): Decomposing Applications vs. Orchestrating Tasks
https://newsletter.simpleaws.dev/p/microservices-vs-agentic-ai-part-1

2 20 Agent Orchestration: When to Use LangChain, LangGraph, AutoGen — or Build an Agentic RAG
22

System | by Akanksha Sinha | Apr, 2025 | Medium

https://medium.com/@akankshasinha247/agent-orchestration-when-to-use-langchain-langgraph-autogen-or-build-an-agentic-
rag-system-cc298f785ea4

3 9 11 Design multi-agent orchestration with reasoning using Amazon Bedrock and open source
frameworks | AWS Machine Learning Blog
https://aws.amazon.com/blogs/machine-learning/design-multi-agent-orchestration-with-reasoning-using-amazon-bedrock-and-
open-source-frameworks/

4 23 Self-correcting Code Generation Using Multi-Step Agent - deepsense.ai

https://deepsense.ai/resource/self-correcting-code-generation-using-multi-step-agent/

6 7 14 15 16 Generating a Low-code Complete Workflow via Task Decomposition and RAG

https://arxiv.org/html/2412.00239v1

8 (PDF) Factored Cognition Models: Enhancing LLM Performance through Modular Decomposition
https://www.researchgate.net/publication/
381274554_Factored_Cognition_Models_Enhancing_LLM_Performance_through_Modular_Decomposition

10 29 AgentCoder: Multiagent-Code Generation with Iterative Testing and Optimisation

https://arxiv.org/html/2312.13010v2

12 Introduction to LLM Agents | NVIDIA Technical Blog

https://developer.nvidia.com/blog/introduction-to-llm-agents/

13 17 LLM Powered Autonomous Agents | Lil'Log

https://lilianweng.github.io/posts/2023-06-23-agent/

21 Building a multi agent system using CrewAI | by Vishnu Sivan | The Pythoneers | Medium
https://medium.com/pythoneers/building-a-multi-agent-system-using-crewai-a7305450253e

24 ASTER: Natural and multi-language unit test generation with LLMs - IBM Research
https://research.ibm.com/blog/aster-llm-unit-testing

25 CI/CD Pipeline for Large Language Models (LLMs) and GenAI | by Sanjay Kumar PhD | Medium
https://skphd.medium.com/ci-cd-pipeline-for-large-language-models-llms-7a78799e9d5f

26 27 28 Secure code execution

https://huggingface.co/docs/smolagents/en/tutorials/secure_code_execution