Adding to what another user said here, when using LLMs for heavy prototyping, I also commit frequently and have a document outlining the opinions contained in the repo.
One thing I've also been doing now is I have a "template" to use for fullstack applications that's configured out-of-the-box with tech that I like, has linters and hooks set up, as well as is structured in a way that's natural to me. This makes it a lot more likely that the generated code will follow my preferred style. It's also not uncommon that on the first iteration I get some code that's not what I'd like to have in my codebase and I just say "refactor X in this and this way, see <file> for an example" at which point I mostly get code that I'm happy with.
Often the AI makes a recommendation that looks good, but has consequences 4 or 5 changes later that you'll need to reckon with. You'll see this especially with web vs. mobile UI behaviours. Cursor isn't so good at reverting changes yet, and GIT has saved me a LOT of headache.
2. Collaborate with o1 to create a PRD and put it in the same folder as your specs.
This increases the likelihood Cursor's recommended changes comply with your intent, style and color guidelines and overall project direction.
If you're using Cursor Composer it's very easy to jump back at any time in the history using "Revert all files to before this message". I use it all the time and have stopped obsessively committing every change as a result.
This is an interesting use case for LLMs. At first, I thought “why complete an MVP if you don’t have time to iterate it?”.
But MVPs are a good testbed for determining if something is worth iterating.
I build quick prototypes for validation and LLMs have really helped decrease the effort. Here is an example of a site which took me 2 weeks with help from ChatGPT. https://post.withlattice.com/
It was enough to get interior designers to start using it, provide feedback, and validate if it’s worth additional time investment.
My hypothesis is that 2025 will bring forth a lot of indie products which focus on doing one thing well and can be supported my a small or fractional team.
I look forward this break from VC funded and big tech consumer products!
Since I started using all flavors of Gemini 2.0 I haven't been back on Cursor
Gemini Exp 1206 and Gemini 2.0 Thinking Model exceed o1 in my experience and best part is that its free with insane context token size.
For agentic code experience RooCline is quite good but I actually do most of my work in ai studio and like to create the folders and files manually.
I almost think agentic code generation is the wrong step forward. Without knowledge transfer/learning involved during the code generation phase, you end up cornering yourself into unfixable/unknowable bugs.
You can see the examples on the linked site are quite simple. These are hardly real world use cases. Most of us aren't generating things from scratch but rather to gain understanding of systems being worked on by multiple people and very carefully inspecting and undertanding the output from GPT
This is why a lot of tools like Bolt, Lovable, Cursor, Windsurf will be toys aimed at people looking to use codegen as a toy rather than a tool. It will serve you better if you look at AI codegen as a knowledge transfer/explorer tool and an AI agent isn't wise imho.
I have been using o1 chatgpt to make and work on side projects where I don't know the language (Swift) but I started to understand enough where I am not using o1 as often and it has really helped me to learn Swift which is a great side effect. Although there are many gotcha's and the biggest is that visionos and ARKit get confused on o1 and it won't compile.
For what it's worth, good system prompting in Cursor makes an enormous difference, currently I use:
You're the best fullstack engineer and LLM engineer, prefer using Vite + React, TypeScript, Shadcn + Tailwind (unless otherwise specified).
CODE ORGANIZATION:
All code should be grouped by their product feature.
/src/components should only house reusable component library components.
/src/features/ should then have subfolders, one per feature, such as "auth", "inventory", "core", etc. depending on what is relevant to the app.
Each feature folder should contain code/components/hooks/types/constants/contexts relevant to that feature.
COMPONENTS:
Break down React apps into small composable components and hooks.
If there is a components folder (eg. src/components/ui/*), try to use those components whenever possible instead of writing from scratch.
CODE SYTLE:
Clear is better than clever. Make code as simple as possible.
Write small functions, and split big components into small ones (modular code is good).
Do not nest state deeply, prefer state data structures that is easy to modify.
I've been experimenting with having two editors open. If I'm strictly editing, I live in Helix which is fast and comfortable and distraction free, but when I could use some AI help I save the file in Helix and reload it in Cursor. When that's done, I save it in Cursor and reload it in Helix and carry on.
It's a lot to manage, but I find it better that trying to move my whole workflow into VSCode when really I only want the AI features and then only 30% of the time.
I usually select functions or classes and workshop them by having a conversation in the composer tab. I find the autocomplete kind of dizzying to work with so I've disabled it. It's just kind of... flickery.
This is a me problem. For instance, I've also disabled animation in Slack because I can't focus on talking to people over the "noise" of all of their animated gif's.
Mostly I just stay out of Cursor unless I'm conversing with an AI because I find the interface sluggish and awkward to use without a mouse (not Cursor's fault, that's a VSCodium/electron thing) and full of little bugs that end up entangling me in politics between plugin maintainers and VSCode people.
I like chasing down bugs and helping people fix them, but that ecosystem is just a bit too busy for me to feel like those efforts are likely to come back at me looking like a return on my investment. If I'm going to be finding and helping fix bugs (which is what I do with most of the tools I use), I want that effort to be in a place that's as open and free as possible--and not coupled to anybody's corporate strategy (these days that's wezterm, zellij, nushell, and helix). I have no animosity for Cursor, and only some animosity for Microsoft, but since I can't help but get involved with the development of my tools, I'd rather get involved elsewhere.
So it's really all about managing the scopes within which I'll let myself be distracted, and not at all about AI.
Using it for a side project right now and since last year it really became an inseparable part of my work, while in 23, I restricted it to writing emails, docstrings and unit tests. Now, I use it for a hell of a lot more. I am working on something cool and I feel kinda dumbfounded that Copilot/Claude etc. know of various SDKs etc I plan on using without me having to go through their docs. I am trying as much as possible to keep the code of high quality, but it feels like cheating, and at the same time I know if I don't use it, I will be left behind.
For example, I wrote my personal blog in Angular+Scully, thought about migrating to Gatsby due to threads here and on Reddit, and it took me one actual weekend worth of coding to get it migrated to Gatsby, though I am ironing out the kinks where I can.
Readit News
One thing I've also been doing now is I have a "template" to use for fullstack applications that's configured out-of-the-box with tech that I like, has linters and hooks set up, as well as is structured in a way that's natural to me. This makes it a lot more likely that the generated code will follow my preferred style. It's also not uncommon that on the first iteration I get some code that's not what I'd like to have in my codebase and I just say "refactor X in this and this way, see <file> for an example" at which point I mostly get code that I'm happy with.
Do you commit this in the same repo or a centralized note taking?
Two things I would add:
1. Use git and commit changes (very) frequently.
Often the AI makes a recommendation that looks good, but has consequences 4 or 5 changes later that you'll need to reckon with. You'll see this especially with web vs. mobile UI behaviours. Cursor isn't so good at reverting changes yet, and GIT has saved me a LOT of headache.
2. Collaborate with o1 to create a PRD and put it in the same folder as your specs.
This increases the likelihood Cursor's recommended changes comply with your intent, style and color guidelines and overall project direction.
what is a PRD?
A high-level specification of what the thing should do and why.
But MVPs are a good testbed for determining if something is worth iterating.
I build quick prototypes for validation and LLMs have really helped decrease the effort. Here is an example of a site which took me 2 weeks with help from ChatGPT. https://post.withlattice.com/
It was enough to get interior designers to start using it, provide feedback, and validate if it’s worth additional time investment.
My hypothesis is that 2025 will bring forth a lot of indie products which focus on doing one thing well and can be supported my a small or fractional team.
I look forward this break from VC funded and big tech consumer products!
Gemini Exp 1206 and Gemini 2.0 Thinking Model exceed o1 in my experience and best part is that its free with insane context token size.
For agentic code experience RooCline is quite good but I actually do most of my work in ai studio and like to create the folders and files manually.
I almost think agentic code generation is the wrong step forward. Without knowledge transfer/learning involved during the code generation phase, you end up cornering yourself into unfixable/unknowable bugs.
You can see the examples on the linked site are quite simple. These are hardly real world use cases. Most of us aren't generating things from scratch but rather to gain understanding of systems being worked on by multiple people and very carefully inspecting and undertanding the output from GPT
This is why a lot of tools like Bolt, Lovable, Cursor, Windsurf will be toys aimed at people looking to use codegen as a toy rather than a tool. It will serve you better if you look at AI codegen as a knowledge transfer/explorer tool and an AI agent isn't wise imho.
You're the best fullstack engineer and LLM engineer, prefer using Vite + React, TypeScript, Shadcn + Tailwind (unless otherwise specified).
CODE ORGANIZATION: All code should be grouped by their product feature.
/src/components should only house reusable component library components.
/src/features/ should then have subfolders, one per feature, such as "auth", "inventory", "core", etc. depending on what is relevant to the app.
Each feature folder should contain code/components/hooks/types/constants/contexts relevant to that feature.
COMPONENTS:
Break down React apps into small composable components and hooks. If there is a components folder (eg. src/components/ui/*), try to use those components whenever possible instead of writing from scratch.
CODE SYTLE:
Clear is better than clever. Make code as simple as possible.
Write small functions, and split big components into small ones (modular code is good).
Do not nest state deeply, prefer state data structures that is easy to modify.
It's a lot to manage, but I find it better that trying to move my whole workflow into VSCode when really I only want the AI features and then only 30% of the time.
This is a me problem. For instance, I've also disabled animation in Slack because I can't focus on talking to people over the "noise" of all of their animated gif's.
Mostly I just stay out of Cursor unless I'm conversing with an AI because I find the interface sluggish and awkward to use without a mouse (not Cursor's fault, that's a VSCodium/electron thing) and full of little bugs that end up entangling me in politics between plugin maintainers and VSCode people.
I like chasing down bugs and helping people fix them, but that ecosystem is just a bit too busy for me to feel like those efforts are likely to come back at me looking like a return on my investment. If I'm going to be finding and helping fix bugs (which is what I do with most of the tools I use), I want that effort to be in a place that's as open and free as possible--and not coupled to anybody's corporate strategy (these days that's wezterm, zellij, nushell, and helix). I have no animosity for Cursor, and only some animosity for Microsoft, but since I can't help but get involved with the development of my tools, I'd rather get involved elsewhere.
So it's really all about managing the scopes within which I'll let myself be distracted, and not at all about AI.
For example, I wrote my personal blog in Angular+Scully, thought about migrating to Gatsby due to threads here and on Reddit, and it took me one actual weekend worth of coding to get it migrated to Gatsby, though I am ironing out the kinks where I can.