Build a Full-stack Multi-tech app using Agents, start Problem Engineering
Problem Engineering - Vicky Biswas

Build a Full-stack Multi-tech app using Agents, start Problem Engineering

If your workflow is “talk to AI until it works,” you are accelerating drift. PPP is how technical debt compounds silently - from hallucinated logic causing outages, to quiet security regressions, to 3 week refactors and broken migrations.

  1. Prompt: Ask for a feature, bug fix, or analysis
  2. Paste: Drop logs, errors, or screenshots/outputs/results into the AI chat.
  3. Pray: Hope it doesn't break the build or introduce security debt.

It feels productive and fast, but it is not scalable. The problem isn’t AI; the problem is the lack of structured intent.

Note: Since the article ended up being long, mixing vision and implementation, I split it into Manifesto and Walkthrough for easy navigation.

Manifesto

A Quick Background (for people new to Agentic AI - skip otherwise)

Google Cloud says agentic AI can set goals, plan, and execute tasks with minimal human intervention. To be able to do that it an Agent should have autonomy, do goal‑oriented planning, ability to reason/adapt, use tools/actions, and maintain a memory/state.

If a developer today has to use an Agent or better, manage an Agent team, swarm, whatever collective we wish to call it, he/she needs to to provide a clear, high-level SMART goal, along with available tools, success criteria, constraints, and optional role/persona framing—while avoiding step-by-step instructions to preserve autonomy. However, the high-level goals lead to ambiguity, hallucinations, drifts, security debts, or off-track execution, as they lack boundaries for probabilistic LLMs.

So what’s the alternative? We have to be a Problem Engineer and work in a "Goldilocks zone" of specificity that guides without prescribing steps. The balance favors outcome-focused specificity: Tell what success looks like (measurable goals, constraints, criteria) over how to do it (no steps), providing enough context to constrain ambiguity while leaving planning/execution autonomous.

Our thesis is to propose a three-part architecture that will be used in every step of this walkthrough:

  • High-level outcome: Define end-state clearly (e.g., "PRD with 50+ stories ready for dev") to drive planning without scripting subtasks.
  • Constraining details: Add tools, boundaries, role for focus (e.g., "align to event co. visibility rules")—prevents drift in probabilistic models.
  • Validation methods: Test iteratively with targeted metrics to confirm the right definition of done and loop till we get it right.

A reliable agentic delivery is possible if we move the coordination logic into specs. We replace handoffs with contracts, reduce ambiguity with constraint encoding, and we use loops to reduce drift. Teams that encode coordination will out-execute teams that don’t as the current state of agentic capabilities evolves.

What we are trying to achieve!

The goal is simple: Build a working full-stack app in 90 minutes using agents - not by randomly prompting - but by orchestrating contracts. This Is the First Operational Step. What you’re about to see is not a final enterprise-grade solution, but:

A demonstration
A mindset shift
A controlled experiment
A wake-up call        

This walkthrough proves something important: Intent can be structured, Contracts can replace coordination chaos, Agents can operate independently when bound properly, and Drift is optional. This is not about agents replacing developers. It’s about our existing teams replacing ambiguity by visualizing:

  1. Repeatable system based on the 3-part architecture above.
  2. Organizational implications where you can consider ways of making the end-to-end development cycle faster, not necessarily following this approach, but building on it.
  3. Change is possible in the velocity, cost, and governance of projects you execute every day.

Note: 90 minutes, assuming a senior dev with all tools subscribed others should aim at 2 to 3 hours, which can be done in disjoint parts if time is a constraint. For some, the first run might take longer. The second run, when you build something of your own, will feel dangerous.

Why CTOs Should Care

A CTO should not ask: Can AI code? Will it add tech debt?. They should ask: Are my teams structured to give AI deterministic boundaries?. That’s the shift. Is your team (primarily tech) structurally prepared for agentic development? You might want them to try this Walkthrough.

This is not about speed or savings using AI. The companies that win will not be those who “use AI.” AI without structure increases velocity at the top and entropy at the bottom. leading to a code review backlog explosion, a security regression, or other issues. If you need to navigate this for success, you need to structure AI usage and harness it to deliver:

  • Contract-first engineering
  • Reduced coordination overhead
  • Artifact-driven governance
  • Verifiable autonomy

Note: As a CTO, you might have many other questions, like how does this scale across 200 repos, how does this integrate with CI, who owns spec quality, what governance framework ensures spec correctness, what’s the failure containment model, and so on. In future articles i will aim at those as well.

Why Developers Should Care

This does not remove engineering. It increases the value of engineering. Because the best engineers will design better constraints, will build stronger contracts, will own orchestration, and will own the product end-to-end. That is harder than coding.

Business problems, Ideas need to be engineered, and once you engineer them, your Agents can help you deliver what you want. Your focus on and mastery of Problem Engineering will allow you to be the orchestrator for all the agents coming our way. Engineers who design constraints will outpace engineers who write isolated features.

Why should Everybody care

The Shift is from Code-first engineering, which is human coordination heavy, to a Contract-first engineering that would be machine coordination driven. Only teams that treat specification as a first-class artifact will scale.

The agentic era is here and being used by multiple teams already, and this changes organizational power dynamics as it alters who defines truth, owns architecture, how coordination happens, where review shifts, and even what “senior” means. Teams will merge and reshuffle, giving value to Spec authors, Boundary designers, and Constraint architects, Orchestration owners, and away from pure feature implementers, code-only contributors, etc. We are therefore recreating a new SDLC that shifts from code-first to contract-first.

If you disagree with this framing, don’t debate it. Run the experiment...        

Walkthrough

Now let’s operationalize this in a controlled time-bound experiment (post subscribe roughly 10 + 20 + 15 + 15 + 20 + 10 minutes as per my tests) to achieve from subscribed services to a running app with a UI test setup. Open the links one by one, register, and use the spec to generate the required output. There would be no ideal output we seek for now, but you should do your best to nudge the output towards the best you can imagine. Once you have a quality that is acceptable to you, move to the next step.

Our team of Agents...

Our team will contain the following members

Please note: I am not paid by any of them for promotion. Also, I have no reason to believe they are the best options. I could have added IAC, API/Performance Testing, etc., and I even realize that some of the specs I am sharing here could be better. However, all that would not matter if you can see what you can achieve without writing a lot of code, within an affordable budget (free for this demo), and in an unbelievably short time.

Generic Notes:

  • We use a few technical things in the specs, like Supabase RLS, 3NF, JWT, RBAC, DAG, etc., along with specific tool names like Alembic or Docker, which might not be well-known to some junior developers. We also expect knowledge of git (GitHub) for extracting the codebase and cloning on a PC. You have 2 options: 1. Just ignore them, let the agent handle, and focus on the running product. If you get stuck, ask here. 2. Do a basic search on these, and although that will take much more than 90 minutes, you will come out stronger.
  • You have limited tokens; use them wisely by limiting the scope to something small but tangible to begin with, eg. "Book Accounting Tool."
  • When you are an expert, reading some of the intermediate files might not be needed, but for now, it's good to read, understand, and tweak them, eg. SQL or OpenAPI.json
  • Always push your Agent to stick and deliver your spec (that's where you labored), eg. "Has the Spec I shared been completely done as asked. Please deeply evaluate and confirm line by line with proof."
  • It is a good idea to correct upstream (early in the pipeline), eg. PRD or OpenAPI.json
  • If you do not know how to fetch a Supabase anon key or push front/backend code to git ask in comments or just search it up. These are standard things that many people will love to help.
  • Ask the agent if the spec provided has been followed, delivered, and verified in its entirety or not.

Your Product Manager - https://chatprd.ai (Defining the Personas, User Stories, etc) - Ask to create a new document, paste the spec, and Chat in the chatprd chatbox till you are satisfied with the PRD document.

SPEC: https://gist.github.com/vickybiswas/882acf4c8eb7fa90c4a71d7503fb74c8         

Answer the clarifying question as you would wish. Feel free to ask for more modifications or make modifications in Edit mode. To confirm, I tried "Compress the doc as much as possible without losing anything in the spec, once done, confirm line by line if the spec has been properly followed or not". Once you are done and satisfied, download your prd.md file, go to View > Edit > Export > Download as md file.

Article content
Build your PRD
Article content
Build your PRD

UI Designer and Developer - https://v0.app (Visualize and build the UI) - Let's now ask for "Build a client only app based on given spec" and attached the spec below and the prd.md file you created from the step before. Here is what I got out of this step https://v0-event-task-management-app.vercel.app/

SPEC: https://gist.github.com/vickybiswas/c92f0da4e42935722befebbbbafdbf65        

Mostly, it would not ask you for input, but if it does, use your best guess. Sometimes the agent might run for more than 10 minutes and time out. In this case, a simple continue will suffice.

Article content


Your database designer - https://supabase.com (Schema Design). Ask to build the SQL based on the OpenAPI spec using the AI (icon right next to the profile dropdown). However, this one is going to be a bit problematic because there is no way to attach files to the chat, so you will have to add "--openapi.json [paste file here] --prd.md [paste file here]" in chat. Follow the same methods as earlier and talk to the AI Agent till you have what you need.

SPEC: https://gist.github.com/vickybiswas/50851fc2eb08cccf2970b728c2d8f0d3        

I hope they build the add file soon, but the job done is quite good. To validate after the spec was completed and all was done, I used this chat message - "1 =) Deeply analyze and check critically if any endpoint or parameter/schema is missing from the mapping JSON. 2=) Ensure the SQL is well-formed and executable (run it to prove). 3=) Ensure the mapping covers all fields on either side and confirm all the fields/parameters exist in the mapping."

Supabase sometimes can get chatty while getting errors and retrying to fix, navigate with your best guess. You will have to copy and paste from the chat, there is an easy hover option, as supabase doesnot generally give a file for download as of now. It might get slow or hang on some systems, so beware of that. In my case, waiting helped as it eventually gave me the desired data.

Your Backend Python Developer - https://emergent.sh (Backend and Logic). This will help you to build a FastAPI app, building the API layer for our web or future mobile app. The choice of Python FastAPI was because there is a host of Vibe coding tools allowing you to create frontend and backend bundled using Node, and we wanted to make it more Dev-oriented. They do a good job sometimes, but this is more of a demo for developers, and FastAPI can be replaced by Rocket or Gin with minimal effort.

SPEC: https://gist.github.com/vickybiswas/91a3739956fc53d42f31eed4340d5576        

You should take a few moments to see Emergent working on your spec. I loved it. Ensure you answer clarifying questions. The token runs out fast, but we can continue on whatever is generated and use the next steps to fix. Please remember we are sharing creds only because it's a throwaway demo, be careful with live permissions.

Article content

Your DevOps - https://cursor.com and https://antigravity.google (Docker, integration, etc). I would suggest you download and install them if not already done. As with others, the free plan is enough to try this out.

I am sure all of you already have git installed to pull code, which emergent and v0 can easily add to your GitHub (if you cannot locate the option to push to GitHub from v0 or emergent, do a quick search). To pull code, use the below.

# in a directory of your choice
git clone emergent_path .
rm -rf frontend
git clone v0_path frontend
md docs 
# copy all file prd.md, db.sql, openapi.json, mapping.json, etc here        

Once done, please open the folder path in Antigravity and fill in the information below for the next step.

SPEC: https://gist.github.com/vickybiswas/a95518ad99ac813ae1958652899e412f        

This is where you see your running app on http://localhost:3003, which should be able to run off your backend and DB. This can be exposed and shared with someone if you are excited, using Pinggy, just run this in the console to get a remotely sharable url "ssh -p 443 -R0:localhost:3003 qr@free.pinggy.io". Enter "yes" to continue connecting. Enter blank password if prompted.

Your Quality Assurance - https://testrigor.com (Functional UI testing). This one is not my favourite for 2 reasons. 1) I prefer the code to always be with the developer, with no dependencies and lock-in on a paid program. 2) This is slow and takes time. However, the reason I used it here is that it creates test cases based only on the URL and our specs and covers some use cases that even a seasoned tester might miss.

https://gist.github.com/vickybiswas/c91e0899f4ddd7c8700a86e3e0b67e9a        

Again, like in the Supabase Agent file cannot be attached, so you will have to paste the PRD file along with the spec you provide.

This will take a lot of time, and most test cases might fail because of the 60-minute limit on your link, or missing functionality, or other reasons. However, the idea is to show how it can understand your app and "think" of use cases based on the information we gave. Once it extracts test cases and you add them, the purpose of this walkthrough is done.

Article content

What This Is Not:

  • A replacement for architecture
  • A legacy migration solution
  • A 500-developer enterprise rollout plan

What this is:

  • A first operational discipline
  • A proof of structured agentic orchestration
  • A new baseline expectation

Watch the next steps.

This is just the first step towards the journey. By the end of it, you will understand that with proper Problem Engineering, we can give Agents a larger, well-defined spec when you sleep, and it can do all this and give you a running, tested, containerized app when you wake up. Is it 100% fool proof today? No, but with a great spec, enough tokens and loops, in controlled, bounded systems, we are close. Many developers have thoughts like, it won't be able to handle legacy code, will go bad when projects become larger, etc. Once you experience what this walkthrough does, you will also realize that the bottlenecks are shifting from implementation to specification. I will try to write more articles to help more with:

  • Scaling this beyond this initial walkthrough
  • Applying this to legacy systems
  • Managing multi-repo enterprise orchestration
  • Governance frameworks
  • Token budgeting and loop design
  • Agent memory models
  • Cost optimization
  • TDD driven agentic dev

The question is no longer, "Will AI replace developers?" The question is: "Will developers who understand Problem Engineering replace those who don’t?"

This walkthrough is not the end. It is just a wake-up call. Will look forward to your comments on how it helped.

PS: This one is dedicated to all the wonderful developers I have worked with in Techindo Systems, E365 India Pvt. Ltd., Ovonts, BandEdge Talent Agency, Trilogy Innovations, Trilogy, DevFactory, IgniteTech, Alpha School, GT School, Simpplr, Awfis Space Solutions Limited, Hungama, Hungama Digital Media Entertainment Pvt. Ltd., Hungama Digital Services, Penske Media Corporation, Mail.com Media Corporation, 123 Greetings, IntraSoft Technologies Limited, and other companies I missed. I would love for them to share with people they think can benefit from this walkthrough.


AI is no longer optional for anyone studying or working in tech or product. If you’re a past or present ABridge AB intern we encourage you to experiment with it now. How you engage with AI today will shape how you understand the software industry tomorrow. Here is a quick way to generate applications without a lot of tech knowledge - You should try it NOW.

What's been the biggest challenge others have faced when building similar full-stack apps? Would love to hear different perspectives on the development workflow.

This is interesting and while it is definitely helpful as a Proof of Concept, I would love to see the part where you iterated with these tools to get things right, and how did you put all of that together? For e.g. you generated the backend using Emergent and the frontend using Vercel and schema using Supabase. It is highly likely that that API contracts are different -- how did you marry things together? Would love to see an iteration just using Claude Code or Cursor, and building an incremental feature on an existing repo -- right form PRD to figma to final code. This is something that will resonate well with most orgs.

Thank you, Debabrata Biswas Dada said React/Python, nah, not something I care about. It made me change the Title. Agentic dev, and this article applies to all platforms alike. The current choice is just a demo. In one of my recent works, I could make an API from the same set of specs, not only using FastAPI but also Fastify.dev, Hono , NestJS, Gin, Fiber, Rocket, Actix-web, Kore, Drogon, Django, Axum, Echo, Oat++, and Facil.io Motivated by you I will add .NET/EF Core to this list as well.

Vicky Biswas sir , I tried and also I build some project using these structures as you know and by your help . Now I am confident to help others also about how to use this effective . I also now creating some other projects using this much effectively so that I have the good catch on the full execution of all these tools.

To view or add a comment, sign in

More articles by Vicky Biswas

Explore content categories