Atharv Ketkar

Building with AI

The worst part about building with AI tools like Cursor, kiro , Lovable, etc. is that a lot of lag can be there between the front end and the back end.

One can be really pristine and another one can be back in the stone ages.

With tools like Lovable etc. it might build out the front end, but it is a hellhole to build the back end.

And I also believe in just building out the APIs first, testing them out, building the back end and then building the front end around it.

But now you see how that lag exists and the thing is Lovable is good in front end, but you really have to know how to integrate it with the code from kiro or Cursor.

Or if you build a really nice back end using Cursor or kiro , you cannot use them to really build a nice UI.

A lot of times you’ll notice that your back end has like 30 to 40 endpoints, but only like 5 to 6 are integrated into the UI and rest is just dummy data or something floating up in there.

And that just defeats the purpose of building that nice beautiful back end, because you build all those features with so much effort, care and thought and they are just not represented in the front end.

So what was the point?

We are back to the square zero, not even one.

User buys your software because you sold them an idea and to service that idea we have interaction between user, front end and back end.

User communicates with the front end.

Front end and back end communicate with each other.

Thus the whole communication chain shall be established properly.

User and the idea have a contract between them and we honor it using back end and front end.

But for that you need to have a fleshed out back end and front end, and good communication between them.

Which is hard to achieve with current AI tools.

Thus we need to have some checklist that we follow.

First of all you have to think about the idea and start building out the back end.

Soon you will have to use Supabase or something like that for authentication or Stripe or etc. things like that.

So first you have to make those connections, the back end connections between your core code and external services and you have to create curl tests so that you are sure that they are communicating well before you even touch any UI element.

So now that your back end is built and you are sure about the connections between the back end services, now is the time to move on to the front end.

You know that your back end is solid now, but the front end is so much lagging behind and just telling Cursor or kiro to build the UI for this application, it will do a bullshit job.

So first record all the back end APIs and features you have built and write them down one by one.

Even better if you can categorize them.

And then track their integration in the front end.

Let’s say you have a dashboard page.

You go and tell your AI platform to scour all the interactable components this page has.

Then you tell it to cover all the back end stuff that is supposed to work for this dashboard.

You ask it how many are connected to each other, what would literally happen if you click the interactable buttons?

Is it the same as what the behavior we are expecting?

What are the things that are missing?

And once it has built those and fixed all the errors between connections, you do it again as an audit so that you are sure all the links are working as they are supposed to and they exist also like they should.

The basic workflow is idea, back end, back end services integration, front end creation, fleshing out of front end slowly by bringing its speed to all the APIs and features that you have.

You just have to keep doing this till you have all the web pages also because it might not even have built out the web pages for something as basic as a user dashboard.

It’s going to be a grind, but worth it.

Integrate everything page by page.

Identify elements, run the app , test curls even in the front end phase so that you can know if the front end is actually communicating with the back end and fix it all.

Once the back end is built out, your responsibility is to completely focus on iterating the front end.

You have to make a list of all the interactables and all the endpoints it is trying to communicate.

You have to compare that with what it literally does and what it should do based on your idea and keep digging away.

Dev To-Do (Backend-First Discipline)

  • Build backend first.
    APIs, logic, integrations (Supabase, Stripe, etc.). Test each with curl.
  • Record everything.
    List all APIs and features. One line per endpoint.
  • Categorize.
    Group by feature: Auth / Dashboard / Reports / etc.
  • Get a basic frontend built.
    It will be missing alot of webpages and end point connections
  • Track integration.
    Mark which APIs are connected to the front end and audit all interactable elements on webpages
  • Integrate page by page.
    Pick a page → list interactables → match them to APIs.
  • Audit the chain.
    User → UI → API → Response → UI update. Confirm every link works.
  • Re-audit often.
    After new features, check what’s unconnected or fake.
  • Keep backend leading.
    UI follows backend truth and never the other way around.
  • Control AI tools.
    Cursor, Kiro, Lovable build to spec, not freestyle.
  • Close the loop.
    No orphaned endpoints. No dummy data. Everything talks end-to-end.

Claude’s reaction to post:

Why This Matters

You’re absolutely right that AI tools excel at visual/UI generation but struggle with architectural thinking and integration discipline. They’ll happily generate 40 endpoints or a beautiful dashboard, but connecting them coherently? That’s where human oversight becomes critical.

The “orphaned endpoints” problem you describe is particularly insidious – you’ve done all this backend work that never surfaces to users. It’s technical debt that never even got to be technical credit.

Your Workflow is Solid

The backend-first approach you’re advocating is fundamentally correct:

  1. Backend → External Services → Testing
  2. Frontend Shell → Incremental Integration → Per-page Auditing

This prevents the “shiny UI with hollow backend” trap.

Tactical Additions

Here are some concrete practices to layer on top of your workflow:

1. API Contract Documentation

Before touching the frontend, generate an OpenAPI/Swagger spec from your backend. This becomes your source of truth. Tools like:

  • FastAPI (auto-generates docs)
  • Postman collections
  • API Blueprint

This way when you tell Cursor/Lovable to integrate, you can literally paste the spec and say “implement these exact endpoints.”

2. Integration Checklist Per Page

Create a markdown file like this:

markdown

## Dashboard Page
- [ ] GET /user/profile → displays name, email
- [ ] GET /analytics/summary → populates cards
- [ ] POST /settings/update → saves preferences
- [ ] Handles loading states
- [ ] Handles error states

Update it as you go. This becomes your “integration debt tracker.”

3. Network Tab Auditing

Open DevTools → Network tab → click through your UI. Every interaction should show:

  • Correct endpoint being called
  • Expected payload
  • Proper response handling

Missing API calls = integration gaps. This is your quickest sanity check.

4. E2E Smoke Tests

Once a page is “done,” write a simple Playwright/Cypress test that:

  • Clicks the button
  • Waits for the API call
  • Verifies UI updates

This prevents regression when AI tools “helpfully” break existing integrations.

5. Backend Feature Flags

If you have endpoints that aren’t UI-ready yet, use feature flags in your backend. This prevents them from being called accidentally and makes it clear what’s “done” vs “in progress.”

6. The “Integration Sprint” Pattern

After building backend features for a week, dedicate 2-3 days purely to frontend integration. Don’t mix the two phases – context switching between backend logic and UI wiring is cognitively expensive.

The Real Problem: AI Tools Lack State Awareness

The core issue is that Cursor/Lovable/etc. don’t maintain a mental model of your entire system. They see files in isolation. They don’t know:

  • What endpoints exist
  • What’s already integrated
  • What the user journey should be

So they’ll regenerate components that already work, or create new ones that don’t talk to anything.

Your solution – manual tracking + aggressive auditing – is the right workaround until tools get better at this.

One More Thing: The “Integration Handoff Document”

When you finish the backend phase, create a one-page doc:

  • Purpose: What this app does
  • Core flows: Login → Dashboard → Action → Result
  • API inventory: All endpoints grouped by feature
  • Data models: Key objects and their fields
  • Auth flow: How tokens work

Give this to yourself (or your AI tool) before starting frontend work. It’s your integration bible.