in the last two weeks I've started using Cursor in the 'you do everything, I'm just your boss mode', to see how far I can push it. Right at this minute, I'm working on something thats become pretty big but I'm constantly on the verge of just going back to writing code like normal LOL.
That said, I'm super impressed by how quickly I've been able to get this far with something pretty niche and complex in places.
Here's what I've learned. There are million AI Bros on youtube who have the ultimate solution but they all boil down to a few basic things.
Make rules: make them before you get started and continue updating them as you go.
Lots of tiny modules: Push things into small bite sized bits of code with lots of interface documentation. This feels a bit unnatural when the code is prototype quality.
Documentation is key: the youtubers will often create detailed planning and specification documents in advance. I done this and it's hit and miss, what I've found works is explain what you want to build to an llm and have it create extremely concise documentation, then a rough checklist for implementation and then evolving these documents in cursor as I go.
This leads to a kind of plan --> document, implement --> document, run tests --> document workflow on each reasonable chunk of the design being the most smooth.
Don't let cursor ever see inside big datasets or huge folder trees. In fact keep cursor in a few folders writing source code and nothing else. To do this, early on build tools that can go and get information or make safe edits for cursor from those datasets without it attempting direct access.
The current project has a tools for working with the primary datasets, a job manager, a process manager, a log manager, a workflow manager, these all have functions for querying. Cursor is instructed to use these. It naturally doesn't want to but if you tell it 7 times out 10 it will :)
No mess: Cursor will like to make lots of random tests and processes along the way. instruct it to use a /debug/tests/ folder and wipe it clean often. force it to make 'production' code by having it be registered with the workflow manager and made allowable by process manager. This lets it play around for a while and get something up and running with it's weird little scripts and then implement it for real elsewhere and using the proper framework. The workflow manager needs to have documentation on how the script is used and the process manager needs to the source to be in a particular place with a particular set of standard interfaces.
you might say this is a lot of plumbing, but what isn't these days and it's not like I'm maintaining it - right ;)
Cursor is always about to go insane any minute, or can't remember what's going on. So most of it is about keeping things simple enough for it to focus on the bit it's working on and nothing else.
Regularly for work we have massive code bases written in our company style and built using our business processes. This kind of thing is absolutely not the place for Cursor. I can imagine a company setup from scratch to use Cursor but our current products and practices woud just make it impossibly time-consuming.
I needed to get a message to my misses while on a long flight home. It wasn't an emergency but it would have been a total bummer to let her know after I had landed.
The problem was I had packed my wallet into my check-in like a dumbass. I couldn't figure out a way to sign up for in flight wifi. Plenty of apps and services have my credit card number on my phone but none of them would show the entire number without me signing on.
The flight however had Alipay as one of the apps to pay, which would have been great except it wasn't working. It still allowed connections to alipay. I figured out I could cancel the payment through a button hiding in a transaction details page and be dumped out to the alipay home screen.
The alipay chat feature wasn't working though, they'd must have thought about that. But some of the mini-apps did work, including the mini-app for my home automation.
It let me send a message to the terminal thingy at the door of my place where you buzz people in (there was a feature to send mail to other rooms, I just sent it to myself).
This took up about 40 minutes of the 11 hour flight.
That said, I'm super impressed by how quickly I've been able to get this far with something pretty niche and complex in places.
Here's what I've learned. There are million AI Bros on youtube who have the ultimate solution but they all boil down to a few basic things.
Make rules: make them before you get started and continue updating them as you go.
Lots of tiny modules: Push things into small bite sized bits of code with lots of interface documentation. This feels a bit unnatural when the code is prototype quality.
Documentation is key: the youtubers will often create detailed planning and specification documents in advance. I done this and it's hit and miss, what I've found works is explain what you want to build to an llm and have it create extremely concise documentation, then a rough checklist for implementation and then evolving these documents in cursor as I go.
This leads to a kind of plan --> document, implement --> document, run tests --> document workflow on each reasonable chunk of the design being the most smooth.
Don't let cursor ever see inside big datasets or huge folder trees. In fact keep cursor in a few folders writing source code and nothing else. To do this, early on build tools that can go and get information or make safe edits for cursor from those datasets without it attempting direct access.
The current project has a tools for working with the primary datasets, a job manager, a process manager, a log manager, a workflow manager, these all have functions for querying. Cursor is instructed to use these. It naturally doesn't want to but if you tell it 7 times out 10 it will :)
No mess: Cursor will like to make lots of random tests and processes along the way. instruct it to use a /debug/tests/ folder and wipe it clean often. force it to make 'production' code by having it be registered with the workflow manager and made allowable by process manager. This lets it play around for a while and get something up and running with it's weird little scripts and then implement it for real elsewhere and using the proper framework. The workflow manager needs to have documentation on how the script is used and the process manager needs to the source to be in a particular place with a particular set of standard interfaces.
you might say this is a lot of plumbing, but what isn't these days and it's not like I'm maintaining it - right ;)
Cursor is always about to go insane any minute, or can't remember what's going on. So most of it is about keeping things simple enough for it to focus on the bit it's working on and nothing else.
Regularly for work we have massive code bases written in our company style and built using our business processes. This kind of thing is absolutely not the place for Cursor. I can imagine a company setup from scratch to use Cursor but our current products and practices woud just make it impossibly time-consuming.