4,234 karma · joined July 29, 2011
http://friggeri.net
I’m making a baby book for my son Henri featuring famous Henri’s through history.
I’m also building a zigbee free/busy eink display that only needs to powered once a year or so
Smoking is terrible in that it really messes with your brain, you intellectually know all the reasons why you should quit but it’s so easy to put it off. “I can quit whenever, I just don’t want to”. Until you try and get that gnawing yearning feeling.
It took me a solid year to not feel that way all the time. And another two to not feel that when having a coffee/glass of wine/standing next to someone else smoking.
13 years later I’m completely over it, to the point where I can barely tolerate being in the vicinity of someone smoking. And yet I often have dreams where I light a cigarette.
If you’re thinking of quitting, there is no better way than today. It’s likely going to be hard, but it’s one of the best things you can do to yourself. You already know that of course, but hopefully this helps.
The overall approach I now have for medium sized task is roughly:
- Ask the agent to research a particular area of the codebase that is relevant to the task at hand, listing all relevant/important files, functions, and putting all of this in a "research.md" markdown file.
- Clear the context window
- Ask the agent to put together a project plan, informed by the previously generated markdown file. Store that project plan in a new "project.md" markdown file. Depending on complexity I'll generally do multiple revs of this.
- Clear the context window
- Ask the agent to create a step by step implementation plan, leveraging the previously generated research & project files, put that in a plan.md file.
- Clear the context window
- While there are unfinished steps in plan.md:
-- While the current step needs more work
--- Ask the agent to work on the current step
--- Clear the context window
--- Ask the agent to review the changes
--- Clear the context window
-- Ask the agent to update the plan with their changes and make a commit
-- Clear the context window
I also recommend to have specialized sub agents for each of those phases (research, architecture, planning, implementation, review). Less so in terms of telling the agent what to do, but as a way to add guardrails and structure to the way they synthesize/serialize back to markdown.
Arguably there might be more curious tinkerers nowadays, but they might represent a smaller slice of the pie.
This being said, Sweden is a fun one: I was in Copenhagen for a few weeks and I thought it’d be fun to take the train to Malmo, do my long run, and then take the train back. All that to say, I’ve spent 3h30 in Sweden, 3h05 of which I was running.
Shanghai was an overnight layover.
The actually awful runs I’ve had are more of the "type 2 fun" kind (running in the desert, grueling trail runs), or the occasional hungover run before I quit drinking.
Thankfully the ablation took care of them and I haven’t had an episode in a few years.
The only thing I ever really cared about was keeping the streak going, everything else has come second. I dropped out of a trail running trip after a fall because I felt that even though I could continue, putting too much mileage on my knee would jeopardize the streak.
I loved loved running in Japan, such a wonderful country
After about two years the streak became part of my identity, which might sound a little unhealthy. It’s easier to just head out and jog a mile or two than to let the number go back to zero.
This being said, it’s made for interesting conversations with medical professionals – I needed a cardiac ablation a couple of years ago and my electrocardiologist came to an “agreement” (as in she didn’t forcefully dissuade me from doing it) that I could jog a slow slow slow mile late in the evening the day after the procedure, as long as I kept my heart rate down and I made sure I was being mindful of my puncture sites.
I've been using Cursor extensively these past few months, for anything ranging from scaffolding to complex UIs. The trick, I've found, is to treat the AI like I would work with a junior engineer, giving in concrete detailed tasks to accomplish, breaking the problem down myself into manageable chunks. Here are two examples of little word games I've made, each of them took all in all a couple of days to ideate, design and build.
https://7x7.game You're given a grid and you need to make as many words as possible, you can only use the letters in the bottom row. There's complex state management, undo, persistent stats, light/dark modes, animations. About 80-90% of the code was generated and then manually tweaked/refactored.
https://vwls.game Given 4 consonants, you have to generate as many words as possible. This is heavily inspired by Spelling Bee, but with a slightly different game mechanic. One of the challenges was that not all "valid" words are fun, there are a lot of obscure/technical/obsolete words in the dictionary, I used Claude's batch API to filter down the dictionary to words that are commonly known. I then used cursor to generate the code for the UI, with some manual refactoring.
In both cases, having the AI generate the code enabled me to focus on designing the games, both visually and from an interaction perspective. I also chose to manually code some parts myself, because these were fun.
At the end of the day, tools are tools, you can use them however you like, you just need to figure out how they fit in your workflow.
Using AI enabled me to spend more time thinking about game mechanics.
I recently went from an idea for a casual word game (aka wordle) to a fully polished product in about 2h, which would have taking me 4 or 5 times that if I hadn’t used Cursor. I estimate that 90% of the time was spent thinking about the product, directing the AI, and testing and about 10% of the time actually coding.