Welcome to the Skiplevel newsletter. Every issue I share tips, knowledge, and insights for non-technical PMs to become technical leaders in the age of AI.

Keep an eye on your inbox and forward to a fellow PM who needs it!

Let’s take a behind-the-scenes tour of what's really happening inside ChatGPT, RAG chatbots, and ‘vibe coding’ tools like Lovable. After, you’ll understand how it all ties together.

"I came back to work after a year off and it feels like a new world. AI has become a must and I'm feeling lost."

A PM shared this with me recently, and I thought… yeah, that pretty much sums it up. From new PMs to senior VPs, AI feels like a flood, and no one is teaching you how to swim.

So today, we're tackling AI confusion at the root.

By the end of this issue, you’ll have a mental model that will immediately make the AI conversation stop feeling overwhelming. I'll also show you how it plays out across the 3 areas of PM work where AI is opening up new possibilities.

Let’s get into it.

A huge thank you to the Product Managers and leaders who filled out the form expressing interest in our technical readiness sprint. I read all the answers personally. Based on what you shared, we need a little bit more time over here at Skiplevel to build the AI-focused material you are waiting for. So I can tailor this material and future newsletters to you, please take 2 minutes to let me know what’s holding you back. I’ll read your answers and build with you in mind.

For the first time in software history, we have something that thinks (or at least behaves like it does). Traditional software follows rules a developer wrote: "if a user does x, then do y." AI is different because it can reason, generate, and respond to things it's never seen before by being really, really good at pattern matching.

The thing doing this thinking is called an LLM (large language model). 'AI' is a broader field that includes other things like recommendation systems and computer vision, but when most PMs say 'AI' at work, we're really talking about LLMs.

(LLM is actually just one slice of a bigger hierarchy: AI, ML, deep learning, LLMs. I broke that down here if you’re curious.)

But an LLM on its own can't do much. Like a brain outside of a body, it is powerless without the systems and infrastructure it is plugged into. 

This is why much of the discussion around AI that shows up in your day-to-day isn't about the AI itself. It's about the traditional software architecture built around it that actually makes it powerful.

Take Claude for example. Did you know Claude doesn't have memory of any of your conversations? Neither does ChatGPT, or Gemini, or any AI chatbot.

Memory for your chats is actually held in a separate database integrated with the Claude backend application (host). Each time you send a message in a chat, the backend pulls the entire chat history from the database and feeds it into the LLM as part of your latest prompt, word for word, every time. That's how the LLM “knows” what you talked about earlier.

The LLM is like an amnesiac genius. Every time you want a response from it, you give it a sticky note. The longer the conversation, the longer the sticky note.

Without the traditional software infrastructure holding the archive of your conversation, Claude the LLM doesn’t have the context or knowledge to provide a useful answer..

So here's the mental model for the kind of AI showing up in PM work right now:

In other words, when we talk about "AI" in your day-to-day work, we're really talking about an LLM plugged into traditional software architecture. The LLM is the new part. Everything else (the backend, the database, the frontend, the APIs) is the traditional software architecture you may already understand.

AI assistants aren’t some new universe of technology. They are really just traditional software with a powerful new component plugged in. And with that powerful new component, come new tools, language and concepts like MCP, evals, prompt engineering, etc. that support it.

Let that sink in for a second.

Once you really grasp this idea, you can see beyond the AI discourse and you can ask: what's wired up to the LLM in this situation?

And that question is the key to making sense of every place you're encountering AI in your work right now because you're encountering the same equation (LLM + Traditional software architecture) used to solve problems in three different use cases. 

Everyone with a pulse and internet connection seems to be using AI. For PMs in particular, the use cases can be folded into three broad categories: 

Even for PMs deeply embedded into the world of tech, these still feel a little bit like magic. When you understand the traditional software interactions involved, you’ll be able to better use these tools, and reason through their limitations and advantages. Let’s walk through them. 

Use case: Synthesizing customer interview transcripts.

You drop 20 customer interview transcripts into Claude and ask for the top themes. After a few back-and-forth edits, you have a structured synthesis. What would've taken a full day takes 20 minutes.

You send your prompt including the interview transcripts into Claude’s frontend. The frontend makes an API request to the backend application, which stores everything in the database. Then, the backend feeds it all to the LLM as a single prompt. The LLM sends back a response to the backend, which returns it as an API response to the frontend.

Use case: An AI-powered customer support chatbot that answers questions using your company's documentation.

A customer types into your support chat: "How do I export my data to CSV?" The AI chatbot responds with a step-by-step answer that references your specific product including exact menu names, button labels, and a link to the right help doc. The response is accurate and pulled directly from your company's documentation. That's RAG (Retrieval-Augmented Generation).

The customer's message is sent from your product's frontend (the chat widget) to the backend application via an API request. The backend takes the question and searches a vector database that holds your company's documentation. It pulls the most relevant chunks of docs, then bundles the customer's question and those doc chunks into a single prompt and sends it to the LLM. The LLM generates an answer, the backend returns it as an API response to the frontend, and the customer sees the reply. This process is often referred to as Retrieval Augmented Generation (RAG).

Note: Whether your engineering team built this from scratch, used a framework like LangChain, or integrated a vendor like Intercom Fin, the underlying architecture is the same. What changes is how much your team owns versus “rents” but the pattern (LLM + retrieval from your docs) is identical.

Use Case: Building an AI Prototype of a new onboarding flow with Lovable.

You've written the PRD for a new onboarding flow. To make it crystal clear for engineering, you open Lovable and type: "Build me a 3-step onboarding flow with email capture, role selection, and a welcome dashboard." Lovable creates a draft of a working prototype in your browser. You ask it to add a progress bar and make the role selection a dropdown. Within minutes, you have a real, clickable demo to show your team.

You type this prompt into Lovable's frontend: "add a progress bar to the onboarding flow." The frontend makes an API call to Lovable's backend, which sends the prompt to the LLM along with a list of available tools (code functions that live inside Lovable's backend).

The LLM decides it needs to look at your existing onboarding code and sends an API response telling the backend to run the read_file tool. The backend reads the files and sends the code back to the LLM. It figures out where the new progress bar code should go, writes the new code and sends it back to the backend, telling it to run the edit_file tool with that code. The backend takes the code and runs the edit_file tool to write it into the right files. (That's why you see code appear in real time. The backend is writing to your files on the LLM's behalf.) 

Next, the LLM tells the backend to run the run_command tool to restart the dev server so the new code is live. Finally, it tells the backend to run the take_screenshot tool to check the preview and confirm the progress bar actually rendered.

If something looks off, the LLM sees that in the screenshot, decides on a fix, and goes through the same process again.

Most PMs are treating AI like it's entirely new, when really, it's just expanding what's possible inside the PM work that already exists, both technically (existing software with a new component) and professionally (existing PM work with new possibilities).

The LLM is the same in each of these 3 areas. What changes is the traditional architecture around it, and the new processes that come with each. For example:

But once you can see the architecture in any given AI conversation, you can ask the right questions, spot the real trade-offs, and stop mixing up what AI can and can't do in each context. You'll stop being lost in "AI" as a category and start having a real mental map of it.

And once you have a map… well, then you'll start feeling a little less lost.

If you want a foundation in the technical concepts that show up across all three architectures (APIs, databases, system design, and more), my free email mini-course is a solid place to start: skiplevel.co/mini-course.