I typed a prompt, the LLM responded, and I celebrated.

5 minutes later, I had a second idea, then a third. By the end of the day my beautifully concise prompt had somehow evolved into a huge blob representing my perimenopausal chain of thoughts:

“You are an expert event planner. Create the perfect invitation, generate witty invitation copy, recommend decorations, suggest gifts for the hosts, organize the guest list, validate email addresses, schedule reminder emails, predict no-shows, create seating arrangements, answer in JSON, but if that doesn’t work, answer in markdown…”

You get the gist. My prompt had become what software engineers affectionately call a god object. Except this one wasn’t in Java. It was in English.

I don’t build applications like this

My immediate thought was I haven’t executed like this in ages, not since I ended up fixing the mess that my sixth grade science fair code was.

What if I was building an e-invite website (Thanks to the background processing thread that’s running in my head as I’m planning my 4 year olds b’day party)? I wouldn’t just write “one giant function” to do it all.

I would have naturally thought about it in terms of:

• UI

• APIs

• Database

• Business logic

• Validation

• Error handling

Because that’s how my engineering brain has been trained to think. Interestingly, the moment LLMs entered the picture, in my excitement to offload all of it, I forgot decades of software engineering lessons.

Instead of designing a system, I started negotiating with a paragraph. I could hear my high school English teacher’s signature “tch.. tch..” in the background.

The Biggest Mindset Shift

The single biggest realization I had while starting to build with GenAI was this:

The LLM isn’t my application. It’s just another dependency.

Treat it like you would any other external service. Would I program an invitation template to keep track of RSVPs, send reminder emails, handle venue’s waiver requirements, and suggest gifting ideas?

No.

Then why was I asking LLMs to do everything from arithmetic to fetching APIs to formatting JSON? I immediately started exploring how others have been architecting the AI workflows and agents and taking notes. Here is a summary of what I learnt.

Every AI Application Has Five Building Blocks

I started noticing a similar sort of architecture everywhere.

Whether you’re building an AI travel planner, coding assistant, medical chatbot, or meeting summarizer, the flow almost always will look like this.

1. Input

This is basic software engineering. Your application fetches data from APIs, reads databases, downloads documents, gets Slack messages, loads calendar events.

The LLMs should never be responsible for fetching information. That’s your code’s job. Think of the LLMs as the world’s smartest interns. You don’t tell your interns, “Go figure out what’s in my database.” You hand them the relevant data.

2. Prompt Construction

This is where the magic really happens. People think prompt engineering means writing clever sentences. It doesn’t. It’s mostly data engineering.

Imagine you’re creating a briefing for your SLT. Would you forward all 2,000 Slack messages? No. You’d filter, summarize, highlight what’s important and emphasize on immediate tasks.

Prompt construction is exactly that. Instead of sending: entire slack workspace, entire task list, entire email inbox. You send: Urgent Slack threads, known prioritizing/resourcing conflicts, blocked tasks, and relevant context.

The cleaner the input, the smarter the output.

3. The LLM Call

This is surprisingly the smallest part of the architecture, your application sends a prompt, the model generates tokens. Done.

That’s it. This is also the only step, which might not function the same always.

Same input everyday: “Write a polite RSVP reminder.” might produce slightly different wording each time. That’s perfectly okay.

You might be wasting resources and adding up on costs if you are asking the models to perform the tasks where you need the same output each time.

This is where you need to spend some energy and divide your tasks into deterministic and probabilistic.

Deterministic vs Probabilistic

This is the architectural idea I wish someone had explained to me on Day 1.

Some tasks have one correct answer, others don’t.

Tasks like: validating email addresses, removing duplicate guests, counting attendees are all deterministic. Whereas, writing a warm & engaging invitation, suggesting themes, recommending color pallets are all probabilistic.

Here’s a good rule of thumb:

If you could write it as a Python function, don’t ask an LLM to do it.

Suppose you’re building an AI invitation assistant.

Don’t ask: “Find all attendees that said yes and sum up the total number and recommend party favors.” Your code can already determine the yes and sum up the number of attendees. Then tell the LLM: “The total number of kids attending the party are 12 within an age range of 3-4. Recommend party favors for a dinosaur theme. Budget $10”

Detection belongs in code. Explanation belongs to the model.

4. Parse everything

One of the earliest mistakes I made was trusting the model. It looked like JSON but it wasn’t exactly JSON. After an hour of searching through the blob and painfully keeping my eyes wide open to catch the issue I discovered that there was one trailing comma that was making my application explode. (I could have asked GPT or Claude to do it for me, but well I’m budgeting my monthly spend and was painfully close to my quota). I learnt my lesson.

Never trust raw model output. Validate it.

Use tools like Pydantic, JSON schemas, or structured outputs, but always create a clean boundary between: AI-generated text and application objects.

Think of it exactly like validating API responses, because that’s essentially what you’re doing.

5. Feedback

Sometimes the response is good enough. Sometimes it isn’t. Maybe validation failed, or important information was missing, or you needed another tool call.

This is your application’s control flow. Not the model’s. Eventually this evolves into agents.

But even sophisticated AI agents are fundamentally doing this:

Observe, Think, Act. Repeat. It’s just a loop.

The Principle That Feels Wrong

When people discover LLMs, they naturally ask: “Where else can I add AI?”

I’ve slowly come to appreciate the opposite philosophy.

Use as little AI as possible.

It sounds almost anti-AI. It isn’t. It’s pro-engineering.

Imagine you have this workflow.

1. Fetch calendar

2. Filter meetings

3. Find conflicts

4. LLM summarizes day in a parsed object

One model call. Beautiful.

Now imagine if we would have called LLM for every single step - to parse calendar, to find meetings, to detect conflicts, summarize and then format. 5 different opportunities to hallucinate, compounding latencies, future debugging nightmares and added costs in the billing cycles due to several more tokens getting involved.

My Biggest Takeaway

Coming from years of building experience, I expected AI to require me to unlearn everything. Instead, I’ve found the opposite. Good AI architecture looks remarkably similar to good software architecture.

• Clear interfaces.

• Single responsibility.

• Validation.

• Observability.

• Retry logic.

• Separation of concerns.

The only difference is that one component occasionally responds with something wonderfully insightful… and occasionally has a habit of hallucinating.

If there’s one lesson I’d internalize, it’s this: Don’t build prompts. Build systems.

Prompts will change. Models will improve. Frameworks will come and go. Good architecture lasts longer and enables faster improvements.

Ironically, the secret to building great AI applications isn’t adding more AI. It’s knowing where not to use it.

There was a time, when building a personal website meant, a lot of hours and steps:

1. buying a domain,

2. configuring hosting manually,

3. fighting CSS like you have serious bones to pick with it,

4. and spending 14 hours trying to vertically center a div.

Back then, full stack engineer was basically corporate language for: “Congratulations, you now suffer across multiple layers of the application.”

And as someone who started her career during that phase, let me tell you — frontend development was not for the weak hearted.

The JSF Era

This was the time when web development built character, well mostly through suffering and pain. When I started as a full stack engineer, the frontend stack looked very different. We had: JSFs, JSPs, Struts, Spring MVC, XML config files etc. Frontend wasn’t really frontend It was more like: Backend engineers reluctantly generating HTML.

You didn’t build delightful user experiences. You fought: component lifecycle issues, state management, unexplained breaking AJAX partial page refreshes, stack traces that you could get lost in. A single button click would involve about at least 6 different steps including the most important one - praying that it all works. And even after that if something failed? The browser would simply display: ViewExpiredException. Or maybe it worked on Firefox but not on Internet Explorer.

Which honestly sounded less like an error and more like a medieval curse.

The Frontend Renaissance

Yes, I am comparing it with the Renaissance - the period of art and cultural growth. Frontend engineering transformed dramatically, we had a stream of frontend art-movements the likes of Angular, React, Vue, TypeScript etc. Focus shifted to creating delightful aesthetic experiences and worrying about component libraries, client-side, server-side or static rendering, hydration, reusability. At some point, keeping up with frontend evolution began to feel like: Every six months the internet collectively decides we were building websites incorrectly.

Frameworks became shinier, tooling became smarter, but build systems became… more emotionally complicated. And somehow we all collectively accepted that installing a frontend app should require: 2 GB of node_modules, 14 package updates, and at least one critical dependency vulnerability.

New Age

Fast forward to today. Welcome to the new age of vibes-based development. I recently decided to build my personal website using v0 by Vercel and deploy it using Vercel.

And honestly? The experience felt illegal. Instead of architecting everything manually, I basically described what I wanted: Minimal personal website with projects, blogs, modern design, subtle colors.

And v0 just… generated it.

Not a rough mockup. Not a wireframe held together by optimism. An actual polished UI.

Within minutes, I had what I had asked for: fully functional responsive layouts, clean components, sections for blogs and projects, modern typography and design consistency that suggested I knew what I was doing. In all honesty, I did not.

The truly abnormal thing about modern AI-assisted development is how quickly it convinces you that you are now:

• a frontend engineer

• a UX designer

• and possibly a creative director

Suddenly I had opinions about spacing scales, color palettes, motion design, hover states, whether a section felt too visually loud. At one point, I caught myself saying Can we make this feel more calm but still intellectually curious?

Meanwhile 2012-me was somewhere in the background still trying to debug a JSF managed bean.

Deploying on Vercel with Main Character Energy

Historically, deployment has always felt like assembling IKEA furniture where you miss one small step and have to do everything again. But Vercel removed all the drama. I connected to GitHub, clicked deploy, and boom: website live!! (Cue: a celebration dance.) No server provisioning, no mysterious config files, no SSH-ing into machines while pretending I fully understood Linux networking, and no praying to nginx gods.

The entire experience left me with one overwhelming realization: We are entering a completely different era of software creation. The distance between I have an idea and this exists on the internet has collapsed dramatically. Instead of needing deep frontend expertise, pixel-perfect design skills, DevOps specialization, or emotional resilience against webpack configuration, what will suffice is your curiosity, your ideas, and the ability to describe what you want reasonably well. Which is both incredibly empowering and mildly terrifying — and enough to set off a small storm of existential thoughts.

So… What Even Is Time Anymore?

Let me return to the question I opened with, now that I’ve confessed to having opinions about hover states.

If history only needs documentation, impact, and enough distance to look back objectively — then maybe we don’t need 20 years anymore. Maybe an era now lasts about as long as a node_modules folder stays under 2 GB. Because looking back at JSF from the vantage point of v0, the distance feels like decades, even though it’s mostly just me getting older and the tooling getting kinder.

But before I crown vibes-based development as the end of history, my JSF-traumatized self would like a word. So here’s what I actually believe, stripped of the celebration dance:

1. v0 collapsed the distance from idea to existence — not the distance from existence to production. A personal website is the friendliest possible demo. The moment you add real state, real users, real data, and the requirement that it not fall over at 2 a.m., the old complexity doesn't vanish. It just moves somewhere I haven't had to look yet. I'm suspicious for a reason.

2. What changed isn't that expertise stopped mattering — it's where it moved. For fifteen years my value was can I make this work. Now the baseline answer is yes, in minutes, so value migrates upward: do you know what's worth building, can you tell when the generated thing is subtly wrong, and can you describe what you want precisely enough to get it? Taste, judgment, and clear thinking — the parts AI hasn't collapsed — turn out to be the parts that were always hardest to outsource.

3. And so the thing I'd tell you: if you've been waiting to feel technical enough or caught up before you build something — that gate just got a lot lower. The cost of trying has collapsed. Open v0, describe a thing badly, and see what happens. Worst case, you've lost an hour. Best case, building and deploying something in under an hour reminds you why you fell in love with technology in the first place — it turns ideas into reality, and for the first time in a long time, it feels playful again.

Just keep one eye on the console. My younger, JSF-traumatized self insists the NullPointerException is still out there somewhere, biding its time.