FullStack-Agent: Enhancing Agentic Full-Stack Web Coding via Development-Oriented Testing and Repository Back-Translation

🍞 Top Bread (Hook): Imagine you ask a friend to build a lemonade stand website. It looks beautiful: buttons, pictures, animations. You click “Submit Order,” see a friendly ‘Success!’ message… but no lemons get counted and no orders are stored. It’s all looks, no lemonade.

🥬 Filling (The Actual Concept — Agentic Coding) • What it is: Agentic coding means an AI doesn’t just write code once; it plans, decides, runs tools, tests, and fixes bugs like a real developer. • How it works:

1. Read your instruction (what you want built).
2. Make a plan for parts to build.
3. Write some code.
4. Run the code and tools.
5. See errors and fix them.
6. Repeat until it works. • Why it matters: Without this, the AI often makes a single pretty page and stops, leaving out the hard parts (like servers and databases) that make real websites actually function. 🍞 Bottom Bread (Anchor): When you ask for “a recipe app that saves favorites,” agentic coding builds both the page you see and the server that truly saves your picks.

The World Before: LLM-powered coding agents could spin up nice-looking pages fast. Many products and papers showed clickable components, forms that “submitted,” and charts that “updated.” But under the hood, lots of these demos used mock data or no data at all. Benchmarks mostly judged by watching screens: if it looked right, it passed. This rewarded paint over plumbing.

The Problem: Real full-stack apps are hard. You need a frontend (what users see), a backend (APIs that do the work), and a database (where data lives). The tricky parts include:

• Managing data flow end-to-end (form → API → database → API → page reload),
• Handling huge codebases with complex folders and ever-changing dependencies,
• Locating obscure, messy bugs quickly.

🍞 Top Bread (Hook): You know how a restaurant works: the waiter takes orders, the kitchen cooks, and the pantry stores ingredients. 🥬 Filling (The Actual Concept — Database Interaction) • What it is: Database interaction is how apps store and fetch information (like orders) so it’s not lost. • How it works:

1. Frontend sends a request (e.g., save new order) to the backend.
2. Backend talks to the database to insert or read rows.
3. Backend returns results, which the frontend shows. • Why it matters: Without real database calls, the site can pretend to work, but nothing is actually saved. 🍞 Bottom Bread (Anchor): When you add a book to your wishlist, the database keeps it there so it still shows up next time you visit.

Failed Attempts: Previous systems often:

• Generated only HTML/CSS (no server, no DB),
• Stuffed all code into one huge context instead of navigating files smartly,
• Used GUI agents that clicked around blindly, missing backend mistakes,
• “Passed” tests that never checked if the database was touched.

The Gap: The field needed:

• A developer-like process (planning, coding, targeted debugging),
• A way to train models on real, working codebases (not just toy prompts),
• A benchmark that demands real backend and database activity—not just pretty screens.

🍞 Top Bread (Hook): Picture two halves of a zipper: they only work when they interlock. 🥬 Filling (The Actual Concept — Frontend and Backend Integration) • What it is: Making the visible page and the hidden server work together seamlessly. • How it works:

1. Frontend reads the plan for what data it needs.
2. It calls backend APIs for that data.
3. Backend talks to the database and returns real results.
4. Frontend shows the live data and sends updates back. • Why it matters: Without this, pages show fake results or nothing at all. 🍞 Bottom Bread (Anchor): A signup page that truly creates an account in the database and then logs you in.

Real Stakes (Why You Should Care):

• If a charity site says “Donation received!” but never records it, people lose trust.
• If a store shows inventory that isn’t in the database, customers get angry.
• If student grades appear updated on screen but never save, schools suffer. We need websites that are not just beautiful, but truthful—driven by real data and verified by strong tests. This paper’s system (FullStack-Agent) aims to deliver exactly that: real plumbing, not just paint.

The “Aha!” Moment in One Sentence: Treat the AI like a real dev team that plans, codes, debugs with the right tools, learns from real repos, and is graded by tests that only pass when the database truly changes.

Three Analogies for the Same Idea:

1. Cooking Show: Don’t just plate pretty food; the meal must be fully cooked through. Use thermometers (debug tools), recipes (plans), taste tests (benchmark), and learn by recreating famous dishes (back-translation from real repos).
2. Sports Team: Assign roles—coach (planner), offense (frontend), defense (backend), and review plays on video (debug logs). Practice drills on real game tapes (repos). Score only counts when the ball crosses the goal line (DB writes).
3. House Building: Architect (plan), interior designer (frontend), electrician/plumber (backend), inspectors (benchmark). Learn by studying existing houses and rebuilding them (back-translation) and trying variations (augmentation).

🍞 Top Bread (Hook): You know how a group project works better when each person has a clear job? 🥬 Filling (The Actual Concept — Multi-Agent System) • What it is: A team of cooperating AIs, each with a role (planner, frontend coder, backend coder), sharing information to build faster and better. • How it works:

1. Planner turns your idea into precise designs (what pages, what APIs, what data types).
2. Backend agent implements APIs and connects the database.
3. Frontend agent builds pages that call those APIs.
4. They use tools to run, test, and fix issues. • Why it matters: One giant agent gets overwhelmed; a team mirrors real software development and reduces mistakes. 🍞 Bottom Bread (Anchor): When you ask for a “task manager with tags,” the planner defines endpoints, the backend builds them, and the frontend consumes them—like teammates passing the ball.

Before vs After:

• Before: Systems often faked success on the screen without real data changes. Benchmarks couldn’t reliably catch that.
• After: The AI builds full-stack apps with real data flow. Tests check not just the UI, but also whether APIs work and the database was actually touched.

Why It Works (Intuition, No Equations):

• Structure reduces confusion: A planner’s typed JSON blueprint tells everyone exactly what to build.
• Tools target the hard parts: A GUI-agent that watches error logs and a Postman-like API tester zero in on real bugs fast.
• Learning from the real world: Turning existing repos into step-by-step building lessons (back-translation) teaches practical patterns and edge cases.
• Honest grading: Tests only count when database logs show the right operations, so “fake-it” frontends don’t skate by.

Building Blocks (The Key Pieces):

• FullStack-Dev: A multi-agent development line with specialized debugging tools.
• FullStack-Learn: A self-improvement loop that studies existing repos by back-translation and creates more data through augmentation.
• FullStack-Bench: A three-part exam (frontend, backend, database) that validates true functionality.

🍞 Top Bread (Hook): Imagine reading a great novel and then rewriting it, chapter by chapter, to learn how the author built it. 🥬 Filling (The Actual Concept — Back-Translation) • What it is: Convert a finished repository into a step-by-step “how to build it from scratch” trajectory for training. • How it works:

1. An agent reads the repo to summarize features and quality.
2. Another agent rebuilds it inside a clean template, following high-level plans.
3. A rule-based cleaner removes any direct copying traces and replays tool outputs. • Why it matters: This turns real, working codebases into clear lessons the AI can learn from, at scale. 🍞 Bottom Bread (Anchor): It’s like watching a chef deconstruct a cake to teach you the exact steps to bake it yourself.

🍞 Top Bread (Hook): Think of practicing a song in different keys to get better faster. 🥬 Filling (The Actual Concept — Iteration & Self-Improvement via FullStack-Learn) • What it is: The model improves itself in rounds by generating training data from real and augmented repos, then retraining. • How it works:

1. Round 1: Back-translate real repos; train.
2. Augment repos (simplify, extend, parallel apps); back-translate more; combine with round 1.
3. Final training produces a stronger developer model. • Why it matters: No need for a bigger teacher model—just smart data generation from real projects. 🍞 Bottom Bread (Anchor): Like practicing from real songs, then remixing them to learn more patterns, and performing again better each time.

🍞 Top Bread (Hook): You know how exams can be easy or hard depending on what they ask? 🥬 Filling (The Actual Concept — FullStack-Bench) • What it is: A test suite that checks frontend actions, backend APIs, and database contents together. • How it works:

1. GUI-agent runs UI tasks; results only count if database logs show correct operations.
2. Backend judge discovers endpoints and calls them; checks responses and DB logs.
3. Database judge inspects tables/rows to verify requirements. • Why it matters: If you don’t touch the database when you should, you don’t pass—even if the UI looked good. 🍞 Bottom Bread (Anchor): A contact form only passes when the test sees both the ‘message sent’ on screen and an INSERT in the messages table.

At a high level: Instruction → Planning Agent (frontend/backend designs) → Backend Coding Agent (APIs + DB) → Frontend Coding Agent (UI + API calls) → Debugging loops (frontendtest, backendtest) → FullStack-Bench evaluation.

Step-by-Step Details

1. Planning Agent 🍞 Hook: Imagine a blueprint before building a house so the plumber and painter don’t bump into each other. 🥬 The Concept: The Planning Agent produces a precise, typed JSON plan for backend (entities, API endpoints, schemas) and frontend (pages, components, data flows).

• How it works: a. Reads your instruction. b. Lists pages, sections, and data needs (frontendPlan). c. Lists entities, API routes, request/response shapes (backendPlan). d. Uses granular types (e.g., array<string>, object<{id:number}>).
• Why it matters: If the plan is fuzzy, the frontend and backend won’t match; data won’t flow. 🍞 Anchor: For “a navy-themed recipe app,” it defines /api/recipes, request/response fields, and pages like /, /add, /recipe/{id}.

1. Backend Coding Agent

• Implements the backend using tools: readfile, writefile, searchfilecontent, glob, runshellcommand.
• Uses Backend Debugging Tool (backendtest): starts the server, sends a method+URL+payload, and returns the response plus logs. 🍞 Hook: Think of a chef’s taste-test spoon—quick, direct feedback. 🥬 The Concept: Backend Debugging Tool is a one-step API tester.
• How it works: a. Start backend. b. Make a request (e.g., POST /api/todos with JSON). c. Return response and console logs.
• Why it matters: Without it, testing needs many manual shell steps and is error-prone. 🍞 Anchor: Testing POST /api/signup shows 201 Created and a DB INSERT; if not, fix and retest.

1. Frontend Coding Agent

• Builds pages and components that call backend APIs; no mock data allowed when dynamic data is required.
• Uses Frontend Debugging Tool (frontendtest): launches the app and drives a GUI-agent with a natural-language instruction. 🍞 Hook: Like a game tester playing through levels while watching the console for hidden errors. 🥬 The Concept: Frontend Debugging Tool is a smart UI test that watches both the screen and the error logs.
• How it works: a. Start dev server(s). b. A GUI-agent clicks/inputs as instructed. c. Tool monitors browser console and terminal; on error, asks the GUI-agent which action caused it and reports details back. d. Dynamically generates atomic test cases for current progress.
• Why it matters: Without error-aware tests, the agent may chase symptoms instead of causes, wasting time. 🍞 Anchor: If clicking “Add to Cart” throws an exception in the console, the tool flags that step so the agent can fix that component.

1. Dynamic Code Navigation 🍞 Hook: It’s like using a live map to explore a big city instead of carrying one giant paper map. 🥬 The Concept: Dynamic code navigation means using tools (glob, searchfilecontent, readfile) to locate and edit only what’s needed.

• How it works: a. Search file names and content by patterns. b. Read only relevant files or ranges. c. Edit the right spots with writefile/replace.
• Why it matters: Without it, agents stuff everything into context, get lost, and make mistakes. 🍞 Anchor: To change how /api/orders validates data, the agent searches for ‘orders controller’ and edits only that file.

1. FullStack-Learn: Repository Back-Translation 🍞 Hook: Rebuilding a finished LEGO model step-by-step teaches you the true assembly order. 🥬 The Concept: Convert existing repos into build-from-scratch trajectories.

• How it works: a. Information Gathering Agent summarizes repo purpose, quality, plus backend/frontend plans and a plausible user instruction. b. Trajectory Back-Translation Agent reproduces the repo into a clean template, guided by the plans. c. A rule-based transformer cleans references to the original repo and replays tool calls for consistent outputs.
• Why it matters: It creates high-quality, logically ordered training data grounded in real-world projects. 🍞 Anchor: A Next.js + NestJS blog is read, then faithfully re-implemented into a fresh template with the same features.

1. FullStack-Learn: Repository Augmentation 🍞 Hook: Practice scales by playing the same tune in a new key. 🥬 The Concept: Scale data by modifying repos in meaningful ways.

• How it works: a. Augmentation Planning Agent proposes five plans: 1 simplify, 1 extend, 3 parallel apps. b. Augmentation Implementing Agent applies each plan, runs debugging tools, and self-verifies changes; only successful samples are kept.
• Why it matters: You get 5× more diverse, validated training trajectories without writing everything from scratch. 🍞 Anchor: Turn an event app into a recipe catalog while keeping the same folder structure and routing style.

1. Iterative Self-Improvement Training 🍞 Hook: Practice, analyze, practice more—but smarter. 🥬 The Concept: Train in two rounds to get better using your own generated data.

• How it works: a. Round 1: Back-translate real GitHub repos (about 2K trajectories), train. b. Round 2: Augment repos (about 8K more trajectories), back-translate, merge with round 1 (10K total), train again.
• Why it matters: The model learns from accurate, multi-step, end-to-end examples and becomes a stronger full-stack coder without a larger teacher model. 🍞 Anchor: After round 2, the 30B model’s frontend/backend/database scores jump by 9.7/9.5/2.8 points.

1. FullStack-Bench (Evaluation) 🍞 Hook: A triathlon tests swimming, biking, and running—not just one. 🥬 The Concept: A benchmark that tests frontend, backend, and database separately and together.

• How it works: a. Frontend: GUI-agent interacts with pages; results count only if DB logs match expected operations. b. Backend: Judge discovers APIs, then sends requests; checks responses and DB logs. c. Database: Judge inspects schema and sample rows to verify requirements.
• Why it matters: UI-only scoring can be fooled; DB-validated scoring can’t. 🍞 Anchor: A “create task” test is only YES if the UI shows success AND a tasks INSERT appears in logs.

Secret Sauce (What’s Clever)

• Typed planning that locks down data shapes end-to-end.
• Two specialized debugging tools that watch logs and streamline API testing.
• Back-translation + augmentation that turn real repos into high-quality training lessons.
• Evaluation that refuses to pass “fake-it” frontends by checking database evidence.

The Test: The authors propose FullStack-Bench, which reuses 101 website instructions and adds 647 frontend, 604 backend, and 389 database test cases. Frontend checks are driven by a GUI-agent and only count when database logs confirm proper operations. Backend tests discover and call APIs, judging YES/NO. Database tests check table schemas and first rows to confirm data requirements.

The Competition: Baselines include WebGen-Agent, TDDev, OpenHands, Bolt.diy, and Qwen-Code. Because many baselines default to frontend-only code, the authors explicitly prompt them to include backends and database usage when needed. Models used include Qwen3-Coder-30B-A3B-Instruct and Qwen3-Coder-480B-A35B-Instruct.

The Scoreboard (with context):

• FullStack-Dev + 480B model achieved 64.7% (frontend), 77.8% (backend), and 77.9% (database). That’s like getting an A in backend and database and a solid B in frontend on a tough exam that checks the plumbing. It outperforms the previous state-of-the-art, WebGen-Agent (56.0%, 39.6%, 62.0%), by +8.7%, +38.2%, and +15.9% respectively. Appearance scores are also highest.
• FullStack-Dev + 30B model leads among 30B peers: 37.2% (frontend), 38.7% (backend), and 50.9% (database).
• Self-improvement (FullStack-Learn) on 30B: After round 1 (2K back-translated crawled repos), then round 2 (add 8K augmented repos), the final model improves over the original 30B by +9.7% frontend, +9.5% backend, +2.8% database, and a higher appearance score—without using a bigger teacher model.

Surprising Findings:

• Backend accuracy can exceed frontend accuracy in the authors’ system. Many baselines still skew frontend-heavy, sometimes using mock data. FullStack-Dev’s debug tools and planning likely make backend work more systematic, pushing those scores up.
• Removing the Backend Debugging Tool increases the average iterations needed by the backend agent (from ~74.9 to ~115.5), highlighting how much it speeds up development.
• Data quality matters: training on back-translated trajectories from real repos yields big gains; training on directly-generated trajectories from generic instructions barely helps.

Ablations:

• Remove multi-agent mechanism: all metrics drop—coordination matters.
• Remove Backend Debugging Tool: backend scores drop more (as expected); remove Frontend Debugging Tool: frontend scores drop more.
• Remove both debugging tools: large decreases in both frontend and backend.
• Data generation method: back-translation vs. directly-generated 2K shows that real-repo-based data substantially outperforms synthetic instruction-only data.
• Reliability: Human alignment checks on 200 samples per test type show >90% agreement (frontend ~90.5%, backend ~94.0%, database ~97.5%), suggesting the benchmark’s judging is trustworthy.

Extra Notes:

• Templates: Main runs use Next.js (frontend) and NestJS (backend) for stability. Adding Vue.js and Django (allowing the system to pick) slightly boosts scores, showing adaptability.
• Compute: For 30B self-improvement, they trained 2 epochs per round at lr=2e-5, batch size 32 on 32 H800 GPUs; trajectories were decontaminated against the benchmark via 5-gram Jaccard and sentence-embedding filters.
• Inference constraints: context length up to 131,072 and up to 400 tool calls.

Takeaway: The combination of a clear plan, specialized debugging tools, learning from real repos at scale, and DB-validated evaluation gives this system a sizable, reliable edge—especially on the backend and database parts that most earlier systems neglected.

Limitations (Be Specific):

• Framework Bias: Most data and experiments center on popular templates (e.g., Next.js, NestJS), even though expansions to Vue.js/Django work. Niche stacks might need extra prompts/tools.
• Data Dependency: Back-translation quality depends on having solid, crawlable repositories. Low-quality or license-restricted code could limit usable training data.
• Debugging Coverage: The tools are strong, but deeply subtle bugs (race conditions, complex auth flows, third-party API quirks) may still escape.
• Compute Cost: Generating, filtering, and training on 10K multi-step trajectories with 131k context and many tool calls is resource-intensive.
• UI Judgment Complexity: Even with DB checks, some nuanced frontend expectations (pixel-perfect design, animation timing) can be hard to score automatically.

Required Resources:

• Powerful LLMs (e.g., 30B–480B) with long context windows.
• Reliable sandboxes that can run full-stack dev servers and databases (PostgreSQL in this study).
• Substantial GPU time for iterative self-improvement and sufficient storage for many trajectories and logs.

When NOT to Use:

• Ultra-tight latency settings where tool calls and server spins are too slow (e.g., on-device coding assistants with few resources).
• Strictly static sites that don’t need a backend/database (though the system can choose to skip backend, simpler tools may suffice).
• Highly regulated codebases where training data cannot be derived from repos and trace cleaning/back-translation are not allowed.

Open Questions:

• How well does this generalize to microservices, serverless architectures, or real-time websockets at scale?
• Can reinforcement learning or execution-aware losses further amplify gains when paired with back-translation?
• How to extend database validation to cover complex transactional integrity, migrations, and multi-tenant setups?
• What is the best way to model long-lived development cycles (refactors, version bumps, dependency churn) over months?
• Can smaller, cheaper models get similar gains with more clever data selection or tool designs?

3-Sentence Summary: FullStack-Agent is a complete system for making real full-stack websites using an AI team that plans, codes, and debugs with purpose-built tools. It teaches itself from real repositories via back-translation and augmentation and is graded by a benchmark that only passes work when the database truly changes. This shifts web generation from pretty demos to production-like functionality.

Main Achievement: Proving that a planner+coders architecture, paired with specialized debugging, repository back-translation, and DB-validated evaluation, delivers large, reliable gains—especially on the historically weak backend/database parts—without needing a larger teacher model.

Future Directions: Broaden to more stacks (e.g., microservices/serverless), deepen database testing (transactions, migrations, policies), add longer-horizon maintenance skills (package updates, refactors), and explore RL or execution-aware learning on top of back-translation.

Why Remember This: It demonstrates a path from “looks right” to “works right” by aligning planning, training data, tools, and tests with how real software gets built and verified—raising the bar for trustworthy AI-generated software.