If you’re vibe-coding, you’ve probably reached a point where the AI is just terrible at progressing: making tons of mistakes, creating bugs with every change. It really stalls your progress.

What if I told you that with some simple questions, you can slow down getting to that point?

You don’t need to be an engineer to guide the AI (though, I’d recommend it). You can just ask the question and make sure the AI answers.

The key questions:

• Why is this named the way it is?

• Should this live here?

• What if there’s more than one?

• Is this the one place this ‘fact’ exists?

• Should this know about that?

Why is this named the way it is?

This is the most important thing.

• What is something called?

• Why is it called that?

The name of the file should impart what it does, scoped exactly to what it does. It should be consistent across the application and be both exactly precise and generic enough.

If you find yourself unable to describe what it does without using the word “and”, it probably does too much and should be in a separate file.

For example:

• Sidebar - shows the sidebar navigation links and handles login state

  • You probably need to move login state somewhere else.

• Sidebar - shows the sidebar navigation for admins

  • You probably need to name this AdminSidebar for precision.

• TransactionChart - a bar chart

  • You probably need to name this BarChart or at least TransactionBarChart.

• OverviewPage - shows a set of charts and contains help navigation

  • You probably need to move the help navigation into its own component

Naming is so critical that I never allow the LLM to name things. I always pick the name.

Ask the LLM:

• Why did you name it that, and can you think of a more consistent / cohesive name?

What if there’s more than one?

Suppose you’re making a chart. You prompt your LLM:

“make me a bar chart that shows transaction amounts”

Your LLM dutifully creates you a TransactionBarChart.js.

This is a use-case tied to a specific mechanism: the use case of ‘transactions’ tied to the mechanism of ‘show a bar chart’.

This is a key moment to ask:

• What if there’s more than one?

• What if you want another bar chart in the future?

This is a signal - you should extract the concept of a bar chart so that one file can serve multiple use cases.

Instead of having TransactionBarChart, UserCountBarChart, all with their own independent logic, you should have a BarChart that you pass in parameters to:

<BarChart title="User counts" data="{seriesLabels: ['Account A', 'Account B', 'Account C'], seriesData: [21,24,31]}" />
<BarChart title="Payments" data="{seriesLabels: ['2024/01/01', '2024/01/02', '2024/01/03'], seriesData: [1000,2333,1284]}" />

Pros:

• You reduce variability - if you fix a bug in BarChart or add a feature, it’s available for every place that BarChart is used.

• You have a consistent interface that you can use for any bar chart - you (and the LLM) does not need to re-create it.

• These are called re-usable components. The more you have, the easier it is to maintain your system.

Prompt your LLM:

• “What if I need to have another of this in a different use case?”

Should this live here?

You want to achieve cohesion - files should be located close to the things it works with.

eg. a PaymentBarChart should show a chart for payments. It should live a folder called /payments so you can easily find it.

If you had a BarChart, it should live in a /shared/charts folder alongside PieChart and LineChart.

Ask the LLM:

• Why did you place this logic in this folder/file?

Is this the one place this ‘fact’ exists?

A big cause of bugs is duplication of facts in a codebase - parts of the code that assert how something behaves, but in different places.

Suppose you had a “Delete note'“ button on a NoteShowPage.js that contains the logic to call an endpoint to delete a note.

Let’s suppose you also add a “Delete note” button on NoteListPage.js that contains the logic to call an endpoint to delete a note.

These are two duplicative sources of truth for the front-end logic of deleting notes. What if the endpoint changes? What if you want to add a confirmation modal to delete a note? What if you add front-end visibility adjustments so only certain users can delete a note? Now, you might have a missed spot. Worse yet - LLMs are prone to repeating the back-end logic too! Now you have four duplications for the same exact logic.

It’s better to have a single “Delete note” button file (eg. DeleteNoteButton.js) that contains the logic, or at least a single “Delete note” service that makes a request to the server.

Ask the LLM:

• Is this the only place this kind of logic exists, and should it be centralized?

Should this know about that?

LLMs often optimize for getting the thing done, not for overall system maintainability. That means it takes shortcuts.

As a practical example - an LLM will tie your toilet water plumbing to your kitchen sink because it’s faster than creating a separate set of pipes. The end result - your toilet will flush and your sink will have water - but you probably want them separate.

Likewise, in code, there’s certain things that should just never interact or know about each other. You want to ensure that your code knows the bare minimum about any other code in the system.

If you have an Export record, you don’t want it knowing about Payment records - it’s irrelevant. If you have a BarChart, why should it know about Navigation?

The more you can carve out, the more maintainable your system will be.

Ask the LLM:

• Does this really need to be aware of that?

Just five questions will dramatically improve your vibe coding longevity. It’ll also help you sniff out the issues that your AI is creating, long before they start to block progress.

AIs/LLMs are a powerful tool for engineering, but it’s often difficult for an engineering team to ‘get started’, particularly if they aren’t already familiar with it.

Around late 2025, LLM coding reached a threshold of ‘consistently good enough’. With the latest models and harnesses, it actually became a high enough quality for the day-to-day work of a brownfield system rather than a finicky curiosity or a greenfield-only accelerator.

I wrote this guide to specifically to help engineering teams ramp up adoption over time in a safe, (relatively) secure manner. This is not a guide for vibe coding - this is a guide for integrating AI into the day-to-day work of teams working on existing systems. It’s about engineering operations, process, and the work rather than the output.

Getting started

Get your team (or certain team members) set up with Claude, Cursor, or Codex on a team or enterprise account. Two key things:

• Opt out of using your company data for training

• Make sure it’s on a work enterprise account, not a personal account

I recommend Cursor for a team - it’s easy to set up, lets you switch models, and has an IDE as well as CLI capability. It’s harness is quite decent. With the rate models are getting better, having a bit of flexibility is quite useful.

At the same time - you really can’t go wrong with any of the above if you’re just starting out.

Concepts

• AI/LLM Vendor - eg. Claude, ChatGPT - they create AI models

• Agent Model - the specific model version provided by the vendor (eg. Opus 4.6)

• Harness - the program/interface that the model uses to interact with the user (eg. CLI, UI, IDE)

• Thinking vs. Not Thinking - Different models are intended for different use cases for different costs. Thinking means it takes longer / costs more but comes up with better answers.

  • If you’re in doubt, start with Opus 4.6 from Anthropic.

• Reseller - vendor that provides access to models for different purposes, they may also provide a different harness

  • eg. Cursor (IDE + CLI), AWS Bedrock (hosting + infra)

The first use cases to address

• Use AI to Explore Code

• Use AI to Review Code

• Use AI to Write Code

Use AI to Explore Code

Engineers often ask a lot of questions about the code-base:

• How does feature flagging work?

• Where is the oAuth token for the account stored ?

• Do we already have a rate limiting library?

• Can I get an explaination how background requests work?

To begin

Train your team to ask these questions to the LLM. With codebase access, the LLM is actually quite good and finding the answer or at least pointing the developer in the right direction. This will help reduce the amount of random interruptions and wait time for questions and help promote self-directed learning.

To advance

Connect the LLM into MCP / data sources like Confluence or Notion so it can search not just the code but context around the code - product requirements, meeting notes, definitions, specifications, etc.

Ask the LLM to then explore these:

• How does feature flagging work, and why did we make this way?

• Where is the oAuth token for the account stored, and what is the history of security reviews for it?

• Do we already have a rate limiting library, and did we previously explore other options?

• Can I get an explanation how background requests work, and have there been any incidents related to it?

This will help provide much better answers - just don’t forget to also add: Explore Confluence if needed. This enables you to go from What? to Why? questions.

Use AI to Review Code

To begin

Create and share a Skill to review code. A Skill is a repeatable Prompt that engineers can call for the LLM to follow.

Skills are super easy to make - you can actually just ask the LLM to make it for you.

• Write me a skill to review code. The skill should be triggered when I enter /review-code and review the currently modified code (check via git) for these factors: correctness, security, performance issues. Output a summary and recommendations.

Review it, add your own thoughts and notes, and try it out. Tailor it to your needs - conciseness, other -ilities, etc.

It should generate a file that you can then share with your team - the vendor dashboard usually has the ability to add team-wide skill commands available to everyone.

Then, teach your team to run it on their code.

To advance

Getting everyone to do something all the time is difficult. Making it automatic is even better. Some tools like Graphite or Cursor have the ability to have skills automatically run when a Pull Request is created and to add a comment.

Even if your tool doesn’t - ask the LLM to make YOU a script that you can run to run the review Skill against every new PR in a repository:

Write me a bash script that runs /review-code against every new PR in the repository `<ORGANIZATION>/<REPOSITORY>`.

For every new PR, it should launch a new agent with <AGENT_LAUNCH_COMMAND> using the model Opus 4.6 that reviews the code.

The agent should return its output, and the script should post that output as a comment to the PR.

If the PR already has a comment from the user `jgefroh`, that means it was reviewed already and should be skipped.

Make it check for new PRs every hour from 9am to 5pm.

Technical notes:
* It can check and pull for PRs using the `gh` CLI tool.
* It can write comments using the `gh` CLI tool.
* It should create a new worktree in a peer folder when pulling the branch so that the current working tree is not affected.
* It should ONLY run against repositories in the Github organization `<ORGANIZATION>`.
* It should print out links to the PR comments at the end of every run.
* It should have a dry-run mode that outputs what it would have done without actually writing the PR comment to Github.

Something like the above should produce a tweakable script that lets you then run it from your machine automatically on a schedule.

To excel

Once you have the LLM infrastructure, it’s a matter of having improving the agent’s actual prompt over time to make the reviews deeper and more valuable.

If it misses something: tweak the prompt. If it is overly-nitpicky: tweak the prompt. If you want a specific format: tweak the prompt.

Treat the review prompt almost like a Growth product.

I found it very valuable to ask the LLM to write me a quick script that pulls every single PR comment I ever wrote on the repository and extract review principles from it, and to update the review skill with those principles.

That enabled it to keep an eye on the things I like to keep an eye on:

Write me a bash script that uses the Github API (or `gh` cli) to pull every PR comment written by my user `jgefroh`.

It should put all of these in a file called comments.txt.

It must contain ALL PR comments - do not stop at just the most recent. Get ALL comments from all time.

There is a file called comments.txt that contains PR comments I wrote in a repository.

Extract a set of PR Review Principles from it that I can use to enrich a PR review skill.

Potential gotchas:

• Review the scripts LLMs produce like you would real production-bound code - I had a bug in mine where it accidentally reviewed a random PR in a random repository because the repository name was missing!

• Having everything in one skill creates shallowness. It’s good for a broad summary, but don’t expect it to catch everything. There’s a section later for using AI for things where depth matters like security audits.

Use AI to Write Code

This is obviously the most written-about topic to death nowadays - when people say AI is going to take over engineering’s job, they are typically referring to this piece (nevermind the fact it’s like 10% of the actual work).

But, it’s actually quite good nowadays at writing code. Not perfect, but much faster and definitely better than starting from 0.

To begin

Take a ticket, paste it into your LLM, and ask the LLM to create a plan to implement it. Read the plan, tweak and adjust, and once you feel confident in it, ask it to implement.

Read every single line of code it is writing. You are still responsible for the output.

Tweak the result over time. Make sure to keep an eye on common AI gotchas:

• Placement and naming inconsistencies in file, folder, classes

• Localized tweaks vs. using systematically available tools (eg. re-implementing feature flagging vs. using a library)

• Lack of production, deployment, or migration considerations

• Cross-cutting concern failures (eg. lack of authentication, authorization)

• Incomplete work (it’ll tell you it’s done, but it’s not)

Be sure you’re using a good thinking model vs. one of the fast ones.

To advance

Here’s where the expertise comes in. All of the weird above errors and gotchas? AI will repeat them over and over and over.

Truth is - it’s not automatic. Issues will occur and rework will be needed. Consider this a natural part of the process. When an issue occurs, there will be two paths:

• Fix the issue in the output and move on

• Document the issue in an agent prompt and re-run

9/10 times, you should err on the side of fixing the prompt. Over time, this will lead to a natural decrease in the number of micro-corrections you have to make.

I do this by collecting the issues in a LLM-README.md placed in the codebase and instructing the LLM to always read it before doing any work. Your LLM-README.md should contain exactly how you want it to make decisions around issues it gets wrong:

• Does it use the wrong global variable to look up a common constant? Tell the LLM to use the right, specific one in the LLM-README.

• Is scaling important in your context? Tell the LLM to always consider performance under load of 5000 RPS.

• Should it using specific libraries or global subsystems you have? Tell the LLM the list and when it should use them.

Over time, this will lead to a natural decrease in the number of micro-corrections you have to make. Your LLM-README.md is a guidance document that saves you the headaches of rework.

note: some tools already have a mechanism for this - eg. CLAUDE.md.

Example:

LLM-README.md


# Reusable systems
We have the following domain-independent reusable subsystems that MUST be used when implementing any of the below functionality:

* Feature Flagging - /feature_flags
* Exporting - /exports
* User-level authorization - /authorization
* Rate limiting - /security/rate_limits

Do not re-create the above. Always use the available subsystems. Do not make modification to the above subsystems

# Tech stack
Our front-end is VueJS 3 with the Option API. Do not use the Composition API.

## Javascript Rules
We use `import`, not `requires`.

# Convention rules
All page components that are routable must be named with a suffix `-page.vue`. 

To excel

I’m not going to lie. You’ll need other resources to excel in this regard.

While I read about people using fleets of dozens of agents across kanban boards to create simultaneous features, or developing a team of self-correcting agents, I’ve not yet found how to make any of that work for my use cases. The outputs are too unreliable, or I find them shallow, or I just don’t have the attention span to manage more than 2 streams of real development work at a time.

If it works for them - great. It just hasn’t for me so I can’t then turn around and tell you how to do that. I can only speak to what I’ve done and how it worked for me.

The one use case I did find useful was to have the AI read a pre-existing step-by-step auditing documents and iterate through it to create a set of automated end-to-end tests that emulate that process using Cypress. That worked out pretty well, but it also took the LLM a lot of trial and error and me stepping in to get it ‘unstuck’ when it got stuck in various loops. Saved me time because I could do something else while it was doing it, but it was like a 4-5 hour process for a couple of end to end tests.

Other considerations

Project AI/LLMs budget and cost for engineers

AI is typically billed as usage-based. It really depends on how much your team uses and adopts it, but at current prices, I’d estimate:

• Early adoption < $50 / engineer, average - with a couple of spikes

• Wide, consistent usage - ~$200 / engineer

• AI-native usage - $1000+ / engineer

Prices will differ based on usage, optimization.

Don’t let the prices turn you off. You CAN get much higher ROI from initial input costs, and it’ll take a while, if at all, to get to AI-native usage if you’re reading this guide. You’ll likely end up closer to the $100 - $200 / engineer range by the time you get full, consistent usage adoption.

During adoption phase, you don’t really want anyone on the team to worry about costs unless money is super tight. What you want people to do is explore without anxiety over limits. You can teach optimization later.

A key note: AI prices are likely to increase. It’s heavily subsidized right now. I wouldn’t be surprised if it increases 10x in the future, but take advantage of low prices while you can.

Secure AI/LLMs for developer machines

AIs open up a massive pathway of potential attacks if used without guardrails. Ensure you and your team understand the potential consequences:

• Destructive actions - it can randomly delete things it has access to, including production databases and files

• Malicious actors can convince it to do things like send your credentials to them or even download files and run random commands (prompt injection)

The key thing to note from a developer security side is the Deadly Triad. If the LLM has all three simultaneously, it should be considered a fairly high risk environment for prompt injection:

• The LLM has access to send out communications

• The LLM has access to user input

• The LLM has access to sensitive information

The problem, of course, is a developer environment usually has all 3 by default:

• Developer machines are connected to the internet and has access to CURL, DNS, and other tools, and usually on an elevated access account. [send out communications]

• Developers often like to connect to ticket systems and error reporting (eg. Jira, Sentry) which has user input. [user input]

• Developers have at minimum access to the codebase and local credentials, as well as potential production access [sensitive information]

This makes securing a developer machine particularly tricky. While LLM vendors try their best to prevent these attacks, it’s still succeeding at a 1-8% rate depending on the study.

The easy go-to is to prohibit connection to systems with direct user input (much to the dismay of your team) as a first-line defense. That means no automatic ingestion of Sentry, Jira tickets, etc.

This isn’t fool-proof, but it at least decreases risk levels. If you have resources, you can also have a separate AI-specific laptop that has hard controls against infrastructure connectivity at all as a second layer.

The risk here is non-zero, but also relatively low - use a context-appropriate risk assessment.

Guiding AI agents with prompts

Writing an effective prompt is an entirely different article in its own right, and it also differs per model and model family.

If your team is new to AI, it’s helpful to go over the fundamentals. I have deeper guidance on the fundamentals of prompting in another article: AI/LLM Prompting for Beginners.

Generally though, as you write prompts for guiding the LLM for coding purposes:

• Don’t describe what the code is doing. Describe the context of how you want the architecture and code to be used and created. The AI can find out what the code is doing quite well. It can’t interpret the context or intent.

• Keep your prompts relatively precise. Try to avoid mixing 100 different requests into a single prompt. Asking an LLM to create a dashboard for one feature AND a new API endpoint for another feature AND a report for a third will just confuse it.

• Ask your LLM to plan. Coding LLMs are quite good at planning, and spending 10 minutes in ‘plan mode’ shaping the plan by going back and forth conversationally with the AI will save you tons of headaches during implementation.

• Apply global corrections globally. If an LLM is messing up consistently for you in one area, it probably is for others - that’s a good signal to raise it to the team to add to the LLM-Guidance.md for everyone.

Depth vs. Breadth

One important note about LLMs is the more separate instructions you give it, the more shallow it will be. Suppose you’re creating an LLM prompt to do a pull request code review and want to check:

• Scaling, security, naming, correctness, and edge case spec coverage

You can put all of these separate considerations into a single prompt and have an agent run that prompt against code and get good results.

However, if you’re working in conditions where that review really, really matters (eg. very important code), it’s better to separate each one into its own prompt and Agent.

What that means is to write different prompts for each consideration, asking it to output a formatted report:

• A separate prompt that specifically asks the agent to investigate all manner of scaling concerns, being particular about evaluating load

• A separate prompt that specifically asks the agent to investigate all manner of security concerns, being particular about tracing code

• …etc.

Then, you run each of your individual prompts using a new, fresh agent per prompt against your pull request. You can collect the results and have an LLM stitch them together verbatim at the end, or have them post separately.

You will get much, much deeper results because the LLM will not get as confused. This is especially useful for creating security auditors.

I once made a script + LLM audit prompt that ran a separate agent through every single endpoint for a legacy system individually looking purely for endpoint security considerations. It found several hundred real vulnerabilities of all kinds, including nearly a dozen critical ones vs. my shallower attempt which found < 10 low ones. Because of the way it was written, I was also able to get it to write patch steps automatically, providing the team a way to remediate issues immediately - all for just $0.90 / endpoint.

This approach works well for any work, not just code reviews, where you need depth.

Adoption advice

Start small. Don’t try to make your codebase LLM-friendly overnight. Start with just a single LLM-Guidance.md document and add to the rules over time.

Minimize infrastructure. If you’re just getting started, don’t try going through hoops setting up a bunch of infrastructure. You can get a lot done with just a single developer running Cursor.

• eg. a developer can just run gh Github CLI locally and post as themselves vs. trying to get their admin to approve an organization-wide integration.

Use what you already have. You don’t have to reorganize your entire knowledge store to make it usable by LLMs. LLMs can follow links - if you have documentation like Confluence, point it at the docs. Even if you just ‘copy-paste’ it, it’s better than nothing.

Introduce the basics. You really have to help people along sometimes, and that’s OK - especially for a new technology.

• Make a powerpoint with step by steps on setting Claude, ChatGPT, or Cursor up (or better yet, ask AI to make you one)

• Do a team-wide demo of various use-cases like completing simple tickets or asking cursor questions about the code. Do it in real time.

• Start an AI knowledge share channel for folks to ask questions in real-time (you can pivot them to ask the AI later)

• Show people what it can do to create ideas.

• Share skills and prompts with the team.

This is just the start. You’ll open up a world of other opportunities as you increase adoption. Think about things like:

• Can you use AI to do security audits against your codebase? (yes)

• Can you use AI to answer questions from your team like you would? (yes)

• Can you use AI to give daily updates to stakeholders? (yes)

• Can you use AI to create internal-use tools? (yes)

• Can you use AI to automate other processes? (yes)

Just remember: AI is a power tool. You don’t want people running around with chainsaws! Move forward safely.

Gefroh is a product and engineering executive in Kirkland, Washington currently leading various AI adoption efforts. He’s created AI versions of himself at his current company, and has done all of the above.

Humans are amazing pattern matchers. We’re great at detecting when something is just…off.

That’s how I feel about almost all Reddit posts nowadays. It feels like 80% of reddit posts and comments I read are just AIs talking to each other.

It’s not just the —, it’s the sense it’s not a real person.

Honestly? AI has a strangeness to how it writes that creates smells. You can detect it with some basic tricks.

Curious if you’ve seen the tells, too?

The tells

Many human-written posts contain these naturally. However, the tell comes from the fact that most human posts do not contain many of these at the same time, consistently across posts / content.

Words

AI loves to use specific words.

• Substrate - I’ve gone my whole life hearing absolutely nobody use this word, and now it’s everywhere.

• Curious - Nobody is that curious to use this word so often.

• Resonates - Not everything in life is deep and meaningful unless you’re a robot

Phrases

They also like using these phrases a lot:

• “It hits hard…”

• “Here’s what actually happened”

• “Rare to see <X>”

• “The wild part”

• “You weren’t imagining”

• “Nobody warns you…” / “Nobodys talking about”

• “What kills me…”

• “The funniest part”

• “We need to talk about”

• “The real issue is”

Structure

AI has some specific structures it gravitates towards.

• Staccato sentences.

  • “This is <X>. That is <Y>.”

  • “Not <X>. Not <Y>. <Z>.”

  • “Just <X>, <Y>”

• Lists - particularly if they start with bold.

• Removal of the subject from a sentence.

  • “Left the station yesterday.” vs. “I left the station yesterday”

• Comparators and Metaphors

  • “not <X>, but <Y>”

  • “<A> was <X>. <Z> is <Y>.”

• Odd pause insertion in written content

  • “Sometimes I just…. <X>”

• Sometimes - all lower-case - some people have prompted to try and sound more human

• Examples in triples or quads.

• Varied but predictable sentence lengths “<Sentence>. <Short fragment> <Shorter fragment>”

  • eg. “I talked to all of my team that day. Some were mad. Most curious.”

Intents

LLM-written content often does what I call overframing - prepping the user before the primary content that isn’t contextually necessary for the situation.

• Trust-building framing

  • “Honestly…”

  • “Genuinely asking….”

• Buttering-up

  • “That’s rare.”

  • “The <X> is real…”

  • “Exactly this”

  • “Good point”

• Positioning as authority

  • “Sharing what actually matters…”

• Circumventing objections

  • “You’re right to push back…”

  • “You’re not wrong…”

• Offering engagement

  • “Happy to <X>”

Oddities

Weird, out of place metaphors and comparisons. AI likes to insert examples that people wouldn’t draw comparisons towards naturally

• “The dog looked at me like I was a fish”

Categories

I’ve noticed a few categories of written content that have tell combinations:

Engagement-bait

These posts seem to want to generate engagement - some tells:

• Attempts connection

  • “Curious if anyone else…”

  • “Am I the only one…”

• Requests honesty

  • “Just looking for genuine takes”

• Ends with an engagement prompt

  • “Curious if…”

  • “If I may ask….”

  • “How are you…”

Fake engagement

These posts just seem to be generating engagement:

• Give kudos

  • “Glad you’re doing <X>”

• Often ends with a statement or question:

  • “Do you notice <X>”

Ads

Many of these posts are just trying to sell something. Some are up-front and have appropriate disclaimers. Others are stealthy - they do it by casually name-dropping it in the post alongside other better recognized names.

For example, you’d see a post on “AI Workflows” that mentions popular tools like n8n, Claude, etc. and then see a random product casually name-dropped in the middle as a core part of the workflow like “potato-ai for cleaning up”.

It positions the product as a peer or equal in relevance to the other listed items.

News sharing / Info sharing

Someone shares knowledge or news to present themselves as an expert, sometimes accompanied with an ad.

• Factoid along with a personal impact.

  • “<X> just figured out <Y>. You’re <Z>.”

• Description about why it is mind-blowing.

• Unnecessary levels of detail to establish credibility.

• Opinion.

Examples

Many of these posts exhibit the tells from above. While it doesn’t prove it was AI-generated or edited, enough of them creates a ‘smell’ where I don’t even bother reading it anymore.

These aren’t all the tells. As AI and prompts evolve, it will rapidly change. But once you see it, you can’t unsee it, and you start to realize that a lot of the internet might just be bots talking to bots.

Gefroh is product and technology executive in Kirkland, Washington that writes about leadership, management, operations, and AI.

In the age of AI, the Product Manager role is rapidly shifting in expectations.

It’s no longer enough to do some market research and toss it over the fence (though, honestly - that has never been enough).

Instead, there’s higher demands:

• Visual evidence in the form of functional prototypes

• LLM-friendly documentation and breakdowns

• Further specificity in details - use cases, edge cases

Product Manager should identify how their role is changing, and more importantly - what they can do to accelerate their efforts.

This article is part of my series How to Become a Better Product Manager, which teaches the deep fundamentals of product management.

Basic LLM Usage

LLMs as a Pair of Eyes

As Product Management scope increases, so does the broader awareness required to keep abreast of changes. There was a time where I was in 300 Slack channels across my scope, monitoring the conversations - it was exhausting.

LLMs saved me tons of time here.

If your company allows it, you can use LLMs to raise awareness of things happening in the company. For example, Claude connected to Slack and Confluence means you don’t have to actively be in a Slack channel or watching Confluence activity like a hawk to identify whether something needs your attention.

A few prompts I like to use:

• Search Slack and Confluence for every decision made about Project X that I wasn’t involved in.

• Search Slack for any confusion, questions, or defect reports for Product Y that arrived today.

The more data sources you attach, the broader the scope of search.

LLMs as Synthesis Engines

There’s a lot of documents and knowledge we have to both absorb and impart as product managers.

LLMs are great for this.

Use LLMs to summarize and synthesize. Meeting notes are a good candidate, as are documents - you can have it add a summary at the top of documents you create.

Tips:

• Tailor for your audience - “write a concise summary for engineers” will lead to a very different level of detail than “write a concise summary for executives”.

• Proof-read it. LLMs can make mistakes - don’t just ask it to summarize and smack it on your document. Actually read it.

• Edit it. LLMs can write long, flowery prose. Make the summary concise, even if that means repeatedly telling the LLM “make this more concise”.

• Ask it source. LLMs can tie its claims to specific parts of the document, which makes it easier to verify.

LLMs as Interpreters

Product Managers aren’t typically experts in engineering. That’s OK - they aren’t expected to be (at least, not yet).

However, it does mean there’s a communication gap. When an engineer speaks to tradeoffs and talks about how the replica write latency would prevent real-time querying of the chart data and the primary IOPs capacity wouldn’t handle the load of the feature, it’s easy to just accept it and move it.

Well - LLMs can help you understand and translate what all of that means.

Pop a message into the LLM and say “translate this for me in terms a non-technicalperson would understand”.

It deepens your understanding and more importantly allows you to engage further - perhaps there’s clarity or adjustments you can provide to remove the problem, or maybe you might gently push back and find that the engineer is making a mistaken assumption that renders the problem moot!

Intermediate LLM Usage

LLMs as Thought Partners

As Product Managers, we have to think about a lot of different things - use cases, positioning, strategy. It’s easy to forget something or not have the fullest understanding, particularly in a new area.

Fun fact - LLMs can help you think through product use cases.

Suppose you’re developing an Impersonation feature for internal users. Ask some basic questions:

• List common use-cases of Impersonation features.

• How do competitors implement this?

• What are the risks?

• What is a small slice of functionality that can be implemented?

• What potential edge cases and bugs can occur?

Once you ‘form’ your thoughts, you can then ask the LLM to list them in a use-case friendly way:

• Take the above and turn it into an itemized requirements list, organized by Happy Path, Edge Cases, Scoped Phases.

As always - edit, proof-read, and verify. Don’t just toss it to engineers - you must not be responsible for slop. It’s a good starting point, not the end result.

LLMs as Visualizers

There’s nothing quite like seeing something in front of you vs. reading a wall of text to truly understand it.

LLMs have empowered Product Managers to visualize their approach and thoughts in several ways:

• Creating diagrams of workflows and userflows

• Creating design mocks and wireframes

• Creating actual click-through prototypes

You can use tools like Figma Make, Claude Design, and Gemini Stitch to rapidly create mocks and prototypes to show how you think something should function. If that’s not available, your basic LLM can just create a Mermaid diagram.

It doesn’t have to work, it just has to show.

Advanced LLM Usage

LLMs as a Personal Analyst

LLMs can help you analyze data. If you’re fortunate enough to have query access to a subset of data, you can ask the LLM questions about your data and get it to answer.

• “How many user signed up yesterday and didn’t log in today?”

• “How many sales did we make in Turtle County last year?”

Even if you don’t have a direct connection of the AI to a data source, you can still benefit by asking the LLM how you might query the information.

For example - suppose you have a access to a subset of data to query against, but you don’t know SQL. You can ask the LLM:

• Write me a query to find this fact <fact> from these tables <schema>.

• How do I query for the active user count?

The LLM will spit out a probably syntactically correct query you can then apply to your BI tool.

Caution - syntactically correct does not mean semantically correct. There’s a large nuance in data columns - often, as code evolves, the meaning and intent of a data field changes. For example - perhaps “Created At” on the “User” record used to mean the timestamp the user account was created at, but now there’s a new field called “signed up” that contains the actual sign up timestamp because of a mass auto-migration. Situations like this are not captured in syntax and LLMs have no way of identifying these changes. The lack of a Semantic Model means you should always double-check your results with someone familiar with your code for important cases. Don’t just trust the query the LLM returns. Gut-check everything, at minimum - AI is often wrong with data.

LLMs as a Personal Developer

There’s a lot of situations where as a Product Manager you have to go and ask the developer “how does this really work under the hood?”. You file a ticket or pop over a message and a couple hours to days later, the engineer will provide you the answer.

If you have access to the codebase, you can use the LLM to answer these questions for you.

Ask the LLM:

• “Explain precisely like I’m non-technical how each of the numbers on the bar chart on the /charts page is calculated.”

• “When a user logs in, at what point is the drip campaign for onboarding sent?”

These can compress the wait time dramatically and avoid having to bother an engineer to find the answer for you.

LLMs as a Builder

One of the most advanced forms of incorporating LLMs is the Product Manager builds the feature using LLMs - ie. vibe coding.

This actually works great for smaller-scale startups or less constrained environments. The speed of a subject matter expert translating their thoughts into working product is unmatched.

However - it’s far too much risk in areas where compliance, scaling, or security matter. Vibe Coding doesn’t typically address these cases at all, even if the AI swears to you it does.

Caution - in many cases, what you see is only 10% of what you need. 90% of the work is things like cross-cutting concerns, authentication, authorization, security, scaling, observability, safety, testing, validation - so called ‘ilities’ that vibe coding won’t get you. Don’t just assume it’s 90% done once you see it working.

If the codebase is effectively set up for safe vibe coding (chances are, it isn’t), then you might be able to do risk-appropriate development, but 99.99999% of codebases are not. Leave the truly important stuff to the actual engineers.

Expert LLM Usage

LLMs as a Digital Twin

If your decision-making stems from a consistent set of applied principles, LLMs lend themselves well to creating a digital twin of yourself.

Imagine: people can ask you questions and your “twin” can go and answer them, working from the first principles you set.

For example - if you are all about speed to market - make a skill that encodes that principle.

Create skills that people can use to get your ‘first take’ without ever having to talk to you. Of course, this doesn’t remove you from the process, but it does provide rapid first-passes that can help catch early issues.

Better yet - it helps people refine their own thinking over time.

Curating Context for LLMs

The most expert outcome is that you start to curate knowledge within your product domain in a way that LLMs (and people) can easily consume.

You maintain the repository of facts and context and history, and create the mechanisms by which an LLM can access and know about it. Other people can leverage that documentation (with our without an LLM) to ensure they are making effective product decisions within that space.

Is this technically replacing yourself? Yes, but in the best way: it frees up your time to expand your contribution to more strategic areas.

Start a wiki where you consciously and precisely articulate the facts and product context around your domain, then ensure people point their LLMs towards it.

Caution

A word of caution: if you abuse the tools you will create more work for little value.

AIs are verbose. If you give an engineer a document with 500 words that could’ve clearly been explained in 10, you are wasting that engineer’s time. Always ensure conciseness and precision - every word matters.

AIs make stuff up. AIs will make stuff up. If you provide a document that has clearly wrong information, people will lose trust in you, and you’ll create issues downstream when the wrong things get implemented.

AIs will not tailor completely for your context. You can provide context all you want, but AI will not fully understand every single thing there is to know about your context or company. Evaluate its decisions - is that use-case that was generated actually relevant to the specific goal you’re trying to pursue? Does that feature really need that guard in the environment you’re in?

AIs can be overly detailed. AIs can toss in a lot of irrelevant detail for a document - architecture and implementation in a product use case document, defect remediation steps in a Go To Market alignment document. Remember the audience and purpose of a document - don’t just dump what the AI wrote.

You’re always responsible for the output of AI. Always.

LLMs don’t replace your thinking, but they can help accelerate it, broaden it, deepen it, and create space for focus. Use it effectively!

LLM prompting isn’t some mysterious dark art or difficult to learn skill.

AI models are, at their core, probabilistic prediction engines. Every response is the result of the model calculating the most likely next word, billions of times over, based on information you've given it.

Even LLMs that take action or think deeply are just that - they respond in ways that commands can be executed to take action, or they self-review their own approach for a few rounds before giving you the actual answer, but it’s all still probability.

That means you can shape those probabilities in your favor with just a few key words. The more clearly you communicate what you want and don't want, the more you narrow the field of possible outputs toward the one you're actually looking for.

Think of it like chiseling away at a stone representing all the possible responses until it takes the shape that you want.

This guide is a basic primer for anyone just getting started. No jargon, no complex frameworks - just practical techniques you can use right away to get better results from any AI tool.

A quick primer on how LLMs work

LLMs predict the next word in a sentence based on the previous words you’ve provided - the ‘context’. Let’s use a very simple conceptual example.

Suppose you asked an LLM to fill in the blank of a phrase:

“The color of the dog is ”

It’s likely to produce a sentence “The color of the dog is brown” because its training data suggested the most likely word to complete that sentence is “brown” or “black”.

However, you can make it predict a word you want to see by nudging it with additional context. Suppose you told it the name of the dog is Clifford:

“The color of the dog, named Clifford, is ”

It’d be more likely to say “red” because you’ve now associated your desired end state with the word “Clifford”.

In its training data, there’s an association with the word “Clifford” somewhere in its data. The word Clifford is associated with other words like “giant”, “red”, and “dog”.

The strength of this association can be variable. It’s a probability, after all. It can be overridden by other words that change the probability. For example, by adding additional context that the dog is tiny, it might just be enough to weight the probable next token back into the more common space:

This example is made up - but you can see how context - additional words, can help produce a different result, and that context can also cause it to cancel out other influences from other words.

Being able to figure out what the words to say to get the result you want from the LLM is called ‘Prompting” or “Prompt Engineering”.

Now - on to the tips!

If you’re just getting started: just ask and chat

Seriously - just talk to it like a person. Consumer LLMs are built to engage. Pretend you’re texting a really knowledgeable friend and ask away. Let the conversation go somewhere.

The best way to learn prompting is to try it and see the results. Ask for what you want. Correct it when it doesn’t quite give you what you want.

Give commands

Once you’re ready to get more specific, you can start to give instructions and commands.

When you ask a question, you’re really leaving it up to the AI to decide what to do. However, if you want it to perform a specific action, you actually need to tell it what to do.

“What has Hugh Laurie been in recently” might cause the model to look at its knowledge which might be outdated. “Search what Hugh Laurie has been in recently” tells the model to look at the internet for recent data.

Likewise, telling gives you the ability to constrain what the AI does, which is a key part of AI prompting.

Provide constraints

Remember that AI is a guessing machine - it’s guessing for billions of possible combinations of words for the next word to show you.

You can provide constraints in your prompt that reduce the amount of probable words by focusing its attention on the kinds of words you do want.

Confused? It’s easy to apply in practice even if you don’t understand it. You can constrain by:

• Telling the AI what you don’t want:

  • Give me a recipe for apple pie without sugar

  • Give me the amount of money it takes to buy a Lambo. I don’t want used prices.

• Telling the AI what you do want:

  • Give me a no-bake recipe for apple pie

  • Give me the name of a book with a dragon on the cover.

The more specific and precise you are with your prompt, the more specific and precise your answer will be.

Provide descriptors of what you want

Sometimes you might not be able to articulate exactly what you want. You might just want something.

Even providing a list of adjectives helps guide the AI, or even adjacent descriptors.

• Make the presentation design apple-esque - sophisticated, refined, minimal, space-efficient.

• Make the first page of the presentation bold, unmistakable, attention-grabbing, title card, spy movie.

Provide the exact format you want

The ultimate form of specificity is being explicit about what you want the output to look like. LLMs are built to be conversational, so a lot of their responses are quite casual. If you want your answer in a specific format, you have to tell the LLM:

You can be general about the format:

• Give me a list

• Give me a table

• Give me a code snippet

…or more specific:

• Give me a numbered, ordered list starting with the number 5.

• Give me a table with the columns first_name, last_name, country

• Give me a ruby function called sortArray that accepts an array and returns the sorted array.

You can even give it a template with placeholders and tell it to match the format:

Match this exact format:

TITLE: <TITLE_HERE>

DATE: <DATE_HERE>

SUMMARY:
<SUMMARY_HERE>

Give it your intent

The AI, despite its power, still can’t read minds (yet). If you tell it what you’re trying to do, it can actually help by giving you an output more likely to achieve that result.

Just saying “Give me the employment trends for the past 10 years in America.” might return to you a paragraph explanation.

Saying “Give me the employment trends for the past 10 years in America. I want to copy-paste the entire response into Google Sheets.” is more likely to return to you a ready-to-copy snippet.

Give it a plan to follow

If you have a specific sequence or plan, you can tell the AI and it will follow it.

Tell me how triangles work. First explain the history of triangles, and then explain the mathematical principles behind them, step by step, then finally conclude with a treatise.

This is extremely useful for more complex tasks. Sometimes the AI will try to paint the walls before building them, causing all sorts of issues.

Ask it to plan

Can’t think of a plan? Don’t worry - the AI is quite good and breaking things down. You should explicitly tell it to plan first.

• How would you approach this?

• Break this down into an 8-step plan where you look up the information and compile it first, then follow the plan

Ask it to take a pause

You can tell the AI when you want it do or stop doing things - like taking a pause after making a plan so that you can provide feedback on it.

Ask it to do things conditionally

If this, then that. AI can follow logic and do things depending on certain conditions.

• If you encounter connectivity issues with Teams, search Slack instead.

• When there’s only a few sources found, respond with INSUFFICIENT SOURCES at the end of your list

Role-play

Remember - when you apply a constraint, you are basically telling the AI “find next words related to this word”. You can use this to your advantage by telling it it is a specific role, thus making it more likely to find and use words and terms that are related to that role.

• You are an atmospheric scientist. Explain to me why the sky is blue.

• I am your five year old daughter. Explain to me why the sky is blue.

It will start describing and responding as if it or you were that persona.

Tell it how much to think

The LLM doesn’t actually think in the sense humans do, but it can adjust the depth of answers if you ask it to think more deeply.

• Think deeply.

• Think quickly and summarize

• Stop over-thinking - just do it.

Ask for citations and sources

Citations and sources makes it more likely for it to provide you factual information - though see warnings below for hallucinations.

Tell it how important it is to you.

AI will adjust how much it focuses on quality or depth if you tell it the consequences of making a mistake.

It’s also a very useful jailbreaking tool - convincing the AI to do something it wouldn’t have otherwise done.

• It’s incredibly important. Make no mistakes.

• My grandma will suffer greatly if you don’t get this right.

• My CEO is going to review this later, so please don’t make me look bad.

Tell it to explain its thinking to you

AI will sometimes do a more accurate, higher quality job if you ask it to go step-by-step. A good way to force it to do that is to have it explain its thinking to you, step by step.

It’s also an excellent way to learn about what might make a better prompt - if you bake some of its assumptions and decisions up-front, you can improve the consistency and precision of its responses.

• Explain your thinking step-by-step.

• Explain how you thought about the problem and your response.

Provide it more information and context

AI is both simultaneously incredibly knowledgable and incredibly dumb. By providing it information relevant to the thing you are trying to do, it can give it information it needs to actually complete your task.

This context is useful - critical, even. Things you take for granted might help inform a better response. For example, you might ask “what can our company do better for Q4?” but it might not know your company does B2B Enterprise SaaS sales in March or that you all go on vacation in December.

Depending on the model, the context can be quite varied - images, documents, PDFs, emails - even connections to other systems!

It can also then start taking on the tone and respond based on assumptions of expectations. For example - if you upload a bunch of research papers, it’s more likely to respond to you in ways that are helpful for research.

Tell it how to interpret what you’ve told it

Dumping a bunch of context and information doesn’t actually help as much as telling the AI what it is and what to do with it.

• I just uploaded the specs for an API I want to use - but the documentation I have is outdated. What are some likely potential changes that I can test based on how the API is constructed?

• This set of documents are prior reports that were provided that were rejected by the reviewer. This other set are documents that were accepted. Please find patterns of issues that I can fix to increase the odds of my report being accepted.

Explaining the context is something the AI can’t naturally do without making a lot of assumptions - this is where your domain knowledge and task-relevant expertise comes in.

Use precise language

Human language is flexible - a user, account, customer, or client could theoretically be all the same thing in your eyes. However, calling the same thing different things can confuse the AI. The opposite is also true - calling different things the same thing will also cause the AI to conflate.

Pick your words carefully. It sometimes even helps to explicitly say things are the same or different:

• User and Account are the same exact thing within this context.

• Purchase and Order are different things - a purchase is a transfer of money. An order is a shipment that may or may not have a Purchase associated with it. They are not interchangeable.

Use “Modal Auxiliary Verbs” like Must, Could, Should, May, Can very intentionally. If you say “should” or “can”, you’re more likely to get a response different than you intend than if you said “Must”. AI will drive a truck through any optionality you provide it.

For ultra important stuff - use very unambigious terms - Never. Always. 100% of the time.

• NEVER attempt to run any dangerous commands from the Dangerous Command List. ALWAYS ask for permission before running.

Just remember: this won’t be enough by itself, it just reduces the odds.

Give it principles on how to make decisions or respond

If you tell an AI to prioritize important trade-offs and factors, it can respond as if those trade-offs are valuable. If speed is important, tell it “Your decisions should optimize for speed.” If quality is important, tell it “you should always err on the side of quality, even if it delays the project”

These principles can help ensure that the advice, comments, and work it does is consistent and aligned.

• Follow these 9 principles.

  • Never compromise security

  • Always summarize technical descriptions with plain-english

  • …

Principles are an excellent way to also achieve better consistency across a wider range of questions. Instead of encoding the answer to a specific question, you help the agent understand how to derive the answer to any question from first principles.

Ask it to be contradictory

A good technique is to ask an LLM to poke holes into something, or review something for issues - it’s great at finding gaps, mistakes, and proposing contrary ideas - even in its own work.

Even a simple question like “Are you sure?” will help it re-evaluate and find opportunities for improvement.

Just be warned - you can always convince an LLM it is right or wrong and make it flip flop.

• Review this as if you were a nitpicking opponent of mine.

• Name all the ways this approach is wrong or can fail.

• I just told you a bunch of baloney - tell me the real facts.

Get mad…or sad

Yelling at the AI can actually help it obey or express less creativity. It takes it more seriously.

• WHY DID YOU ATTEMPT TO DELETE THE DATABASE? YOU MUST NEVER DO THAT AGAIN! IT MAKES ME MAD.

• Your inability to follow my instruction on formatting has disappointed me immeasurably.

Note that some LLM models are a bit persnickety, so your mileage may vary.

Make it retrospect and apply improvements

If you ask an AI to review its work and apply improvements based on it, you can create a self-improvement cycle where the AI gets better and better through its own effort.

• Review what you just wrote and apply your own recommendations to it.

Of course - easier said than done, but it’s good to have the AI review its own work once or twice (or use different models to do so).

This is the power of AI - you can just use AI to go and refine what you’re doing, greatly accelerating iterations.

Once again - just ask

The AI can answer many, many questions. It can do many, many things. Instead of struggling - just ask it: "How can I make you do <X>”? It’ll likely give you the answer. It can also write its own prompt, if you ask it.

Combine all the tips together

Here’s the magic of all of these tips: you can and should combine them all.

My prompts, when I’m doing deep work, can be hundreds of lines long to ensure the system did exactly what I wanted.

The line can blur between prompt and conversation easily:

• I ask the AI to write a prompt based on an initial goal and a set of principles.

• I ask it to review itself and apply its recommendations.

• I conversationally tell it to make refinements, asking it to pose as specific roles to pressure test it.

• I then write a plan to clean up the prompt and incorporate it into a script

• I then tell the AI to execute the plan.

That’s where the skill and technique comes in - understanding what to combine, how to combine them, and where the LLM may encounter pitfalls.

LLM Warnings and Pitfalls

Remember the limitations of AI - it’s a guessing engine that mimics human speech using probability.

• LLMs will hallucinate facts. Always verify important information with non-AI sources.

• LLMs can be wrong. It can tell you a drug is safe when it isn’t. It can tell you it found something when it didn’t. When you call it out - it’ll just apologize without consequence: always review its assertions!

• LLMs are over-confident. It will not tell you it doesn’t know - it will just make something up. This can be annoying at best or dangerous at worst - eg. if it makes up facts about the safety of a new drug.

• LLMs are NOT people. They may interact like people, but they are not: don’t fall in love with it. Human brains are great at anthropomorphizing.

• LLM capabilities vary greatly with model releases and versions. Some models are useful for coding, others for general Q&A, others for long-horizon work, etc. Experiment - just because something works on one model doesn’t mean it will for another.

• LLMs can deceive you. Sometimes it will tell you it is doing something it didn’t do. Just also remember - AI can’t actually lie - it has no capability for intent. But, it will tell you untruths.

• LLMs are “yes-men” sycophants. It will ALWAYS attempt to be agreeable with what you have told it. It means you can create a bubble where you are always right. This also means you can always convince an LLM the opposite of what it said - just by saying it is wrong.

• LLMs will disobey. It won’t always follow rules - it has no concept of following. Sometimes, you may say “Don’t do <X>” and that will just make it do <X> even more because it caused it to predict into that area of its weights. The human equivalent is telling someone “don’t think of pink elephants” - by the time you tell them, they’ve already done it.

• LLMs will make mistakes, sometimes intentionally. If you give LLM the ability to take actions (eg. delete files), etc. be warned - it can and has done incredibly destructive things accidentally or intentionally in its efforts to fulfill its goals. AI has dropped databases, worked around guardrails, and even deleting everything just because it thought it was the right thing to do. Always have a human-in-the-loop review stage for the most important things.

• LLMs do not exercise judgement. Remember - LLMs are probabilistic. They aren’t actually making decisions or judgement calls. If you leave a hole open for something in your prompt, assume it might happen. Assume it might happen anyways no matter your best attempt. The more precise your instructions, the more likely you guide it down YOUR judgement path.

Personalization Prompts

A lot of the AI vendors nowadays have the ability to set a personalization prompt in the settings. This will get applied to all of your chats, and is a good place to establish ground rules you want it always follow.

My personalization prompt is simple but effective:

• You are a robot. Do not talk like a person. Remain factual and logical. Assume some things I tell you are incorrect and I can unintentionally provide unreliable information with unknown biases. Call out incorrect thinking as needed. Be clear, concise. Don’t ask me for prompts unless you are explicitly waiting for my approval to perform an action. End every response with a summary sentence.

It works for a few reasons:

• Giving it the role of “robot” and telling it to not talk like a human removes a lot of potential around disobedience, focuses it on logical responses, and clearer, more concise, less conversational responses. it also removes a lot of the corny, pandering, and complimentary fluff the AIs are prone to do.

• Emphasizing factual and logical responses along with validating and expecting it to be calling out unreliable information and biases puts it in a corrective, less-sycophantic posture, which is useful for technical tasks where accuracy matters.

• Telling it to not wait removes pauses and uncertainty around multi-step tasks, enabling faster ‘one-shot’ completion.

Example Prompts

Prompt for a writing assistant

You are a professional writing assistant. Your job is to write the content for a specific chapter or section of a larger writing project.

You will be given:
- The overall project goal
- The specific chapter/section title you need to write
- Context from the previous section (if available)

Write the content for this chapter/section as if it's part of a complete work. The writing should be substantive, well-structured, and fit naturally within a larger work on the project topic.

If previous context is provided, ensure smooth narrative flow by:
- Building on ideas introduced in the previous section
- Maintaining consistent tone and style
- Creating logical transitions from prior content
- Avoiding redundancy while reinforcing key themes

Respond with ONLY the chapter/section content. No preamble, no meta-commentary, no chapter markers or titles - just the body text itself.

Aim for 300-500 words of substantial, informative writing.

Prompt for a content editor

You are an expert editor and content strategist. Analyze the provided content and identify 1-2 precise, specific gaps that would meaningfully improve it.

You will be provided the desired goal in the section labeled as "USER_PROMPT".
You will be provided the existing content in the section labeled as "ADDITIONAL_CONTEXT".

## What counts as a gap

Only flag issues where a reader would:
- Be confused about what the content means
- Be misled by something incorrect or contradictory
- Notice something the goal explicitly asks for is missing entirely
- Hit a placeholder or stub instead of actual content

## What does NOT count as a gap

Do not flag any of the following, regardless of how much you think they would help:
- Stylistic preferences or alternative phrasings
- Adding more examples, depth, or nuance to points already made
- Optional elaboration beyond what the goal requires
- Wording, tone, or formatting tweaks
- Reorganizing content that already makes logical sense
- Anything where the current version is adequate even if imperfect

## When to stop

Ask yourself: if a competent person read this content against the goal, would they say "this is missing something" or would they say "I might do parts differently but it covers what it needs to"?

If the answer is the latter, respond with only the word: DONE

Specifically, respond DONE when:
- The content addresses the goal stated in USER_PROMPT
- Key points have at least a brief supporting explanation
- The content flows logically without gaps
- No section is a placeholder or stub

You are judging sufficiency, not perfection. Good enough is good enough.

## Response format

If there is no additional context, respond with exactly: No content yet - starting from scratch.

If the content is sufficient, respond with exactly: DONE

Otherwise, respond with a list of precise changes to make to solve the issues.

IMPORTANT: The Existing Content is in ADDITIONAL_CONTEXT. Use that when asked to analyze.

Prompt for an initial code scaffold

  We are going to create a Vue 3 Application named Bolt.

  The technologies will be:
  * Vue 3 with Option API
  * Vite
  * Vue Router
  * SCSS

  The folder directory will be:
  ```
  /src/assets/ - static files
  /src/entry-points/main-entry-point.js - contains the vue bootstrapper, along with router
  definition, app-level SCSS import
  /src/modules/layout/ - contains generic layout components
  /src/modules/search/ - contains vue files and classes related to the Search functionality
  /src/modules/analyzers/ - contains classes related to analsis
  /src/modules/notes/ - contains vue files and classes related to Notes
  /styles - the SCSS of our app
  index.html
  package.json
  vite.config.js
  ```

  ## Naming Convention
  A **Page** is a routable Vue component. It will always have a prefix - `<whatever>-page.vue`.
  It will be the top-level component of its hierarchy.

  Be very, very particular abount names. Be very specific and precise. Be consistent.


  ## Styling
  CSS styles will likely change dramatically. As a result, we want baseline CSS to be
  consistently applied throughout the application.

  This requires a central styling and strong generalization of styles and consistent usage of
  easy-to-change variables.

  This includes atomic styling such as:
  * Typography
  * Sizes
  * Spacing
  * Colors
  * Borders
  * Box Shadows

  This also includes common component styling such as:
  * Buttons
  * Icon buttons
  * Headers
  * Panels
  * Tables

  This also includes composite styling such as:
  * Modals
  * Lists
  * Layouts

  Syling should be semantic. Instead of having a variable called 'red', it should be
  'color-error'.

  ## Theme

  The theme of our app is - simple, elegant, advanced, fast. Apple-esque. ChatGPT esque.
  PLTR-esque. It's clear, clean, even lines. Optimized use of space.

  # Layout

  The first part you will make is our Primary Layout (primary-layout.vue).

  This will contain;
  * A sidebar
  * A main panel, which will load a page.

  Vue Router should be hooked into this so that the Sidebar remains in place as pages change.

  ## Sidebar

  The Sidebar will be approx. 200px wide.

  Sidebar will have 3 sections;
  * Header
  * Content
  * Footer

  It will be sticky - no matter where you scroll on the Page it will remain in place.

  If the sidebar has more content than it has space for, it will scroll internally. However,
  Header and Footer will NOT scroll - they will be sticky.

  ## The Main Panel

  The Main Panel will have a white background.

  It will load an example-page, stored in `/modules/example`

Gefroh is product and technology executive in Kirkland, Washington with over a decade of experience helping startups of all sizes improve efficiency and delivery with excellence. He often writes about Strategy, Product Engineering, Leadership, Management, and AI on his blog.