The short version of the last two weeks of February was that the devil is in the details. First, I found some edge cases in the AI App builder that do not work. Then, I found a pattern that helps AI tools deliver better results. Finally, I crafted a workflow between AI tools and local Cursor coding.
Again, the devil is in the details.
TL;DR: I have come up with five AI rules of engagement! Read at your peril. :)
1. Fail Fast & Stop Early
Last week, I found that persistence and trying to manipulate AI processes to build an app are bad ideas. Several times this week, I scaffolded out an application. The AI tools would either miss a request or builder or change something I had not requested.
It took me a few efforts to realize that when the AI misses the mark on a prompt more than once, I have to stop and maybe restart from the beginning. Confusion in the applications or content is a problem. AI tools like Bolt.new and Loveable.dev use the entire code base for a project as the content.
This significant context for each prompt cycle means the AI pushes the entire code base into the LLM process. If a prompt is confusing or matches a context I do not want, then the result is confusion.
The AI tooling appears to value any delivery or change over the correct change. Like an overeager junior developer, it wants to prove its value. Retrying to force a better prompt to solve the request was only 20% effective.
I have two approaches: commit to github on each stable feature and restart when the prompts get confused, or restart completely if the existing value is not on track.
Trying harder with more and more detailed prompts seldom works.
AI Rule #1:
Don’t muscle the AI Agent.
2. Work from General to Specific
Work from general to detailed. When getting started, asking too many questions about the initial prompts is tempting. I have tried using a separate session to build a good master prompt. While this would make sense if the AI were human, it does not work with AI.
So, I have had more success starting with small prompts and moving slowly to more details as the App takes shape. Jumping directly into the application’s value proposition means that the base files and structure must be handled in one ‘single prompt shot’.
While this can work, it's hit and miss. So here is the way I start
Define the App: “Simple React App with Typescript”
Define the Routes: “Add in three routes…”
Define the Header and Footer: “Setup a responsive header with…”
Define the Route Protections: “Make one route public and all the reset protected…”
Define the Auth Provider: “Added in a Login Route using Firebase Credentials (.env)…”
Define the Store: “Install React Redux to handle state…”
Define the API: “Setup the CRUD for the API URL / accounts… in its own Redux Store called XXXX…”
Define more API…
Define Form or UI settings last…
It can feel strange to stage the prompts, but this means that the application context is built up in steps. Each prompt needs UI and code confirmation, which can then help direct the outcome of the next prompt.
AI Rule #2:
Resist the urge to use ‘One Shot Prompts’
3. Know Your Terms & Packages
This week, I learned a painful lesson: Letting the AI Builder select the NPM package is risky. It can select an outdated version or a set of packages that do not work well together. I have learned that event version numbers can be helpful.
A good example of this is Algolia’s NPM package. The newest version has some patterns not used in other projects. The AI can encounter an error-fix cycle that never ends, and each fix attempt can generate more incorrect context.
Before the AI coder could return to normal, I had to stop, manually clear the code, and re-prompt with a specific NPM version.
AI Rule #3:
Use specific NPM Packages. Package names are mini context triggers that help keep things on track.
Mix & Match Your Tooling
After a month of constant trial and error, I have started to understand which AI agent solves specific problems best. When I started moving a given project between agents, the outcomes, both in speed and code quality, jumped.
So now I start with Bolt.net for gross framing, then move back and forth into Loveable for some stuff or Cursor.
The value of Cursor is that I can define the context with more granular controls. I don't need the AI to change other things when I want to work with a given route. Cursor has some nice features that let me define the specific context for the prompt using a @ prefix.
Here is an example:
“Apply the same styling from the @UserComponent.tsx to the new @StoreListPage.tsx for page size, header and layout of form element. The curent page has only one element per row.”In my early attempts, I would name the features and assume or hope the AI would find the correct file or block of code by name or use cse. No, bueno.
Thankfully, Cursor supports prompts at the folder, package, and file levels. It even lets me define the line number to limit where a specific prompt will try to change the code. It took me two weeks of effort before I returned to a high-throughput process.
AI Rule #4:
No one AI Agent can do it all! Expect to use different tools for different application stages.
Next Step of Process Changes
I plan to try out tools like Helicone, which promises the ability to test AI-generated code. I have high hopes for this. However, while this work might generate more confidence in project delivery, I am not sure it will speed up the code generation process.
I had an epic fail with Replit on Saturday. My first real effort with an AI APp builder forced me to take a break and abandon an application that I had thought would be demo-ready by next week.
I also plan to roll in image-to-code processes to test if an image can provide a better prompt than a text prompt.
Next, I plan to experiment with forcing the AI to preprocess the prompt and estimate the file or component-level contexts beforehand. This might help me better direct the work and keep my prompts light.
Lastly, I am starting to work with the
.cursor/Rulesfolder that the IDE offers. It seems like a lot of overhead to have to define the rules for an application, but I think I might cut as much as 30% of my re-prompting and token consumption if I slow down and build some template rule sets.