Hacker Newsnew | past | comments | ask | show | jobs | submit | Ashbt's commentslogin

Amazing

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.


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.


> 2. Collaborate with o1 to create a PRD

what is a PRD?


"Product Requirements Document," I think.

A high-level specification of what the thing should do and why.


I've done a similar thing using calendar events in the future.

It's easy.

Just open up your calendar app to a date like 5 years from now and type away.

This derisks the possibility that the "future you service" goes under, taking your cherished letters with it.


I just use text files, with the dates stored in them. I make sure my folder is always backed up.

I have a few that go back to 1999. It's always a trip to go back and reread them.


I like how this approach trusts your future self to look back at these files, while the other methods implicitly distrust the future self motivation to look back at your present self.

Can we deeply trust the concept of our future self as being equivalent and worthwhile of replacing our present? Do we treat that future self almost like a child of our own?


I absolutely trust my future self to go back and look at the files.

I do not think I would have started this practice without knowing this about myself.

I do wish I made more of an effort to leave these notes. I have in my archive chat logs from various messaging services and there is contextual headspace which clearly has changed over the years without me really knowing it. For example: I had a conversation back in 2006 where it sounded like I thought very positively of Apple as a company. I have no recollection of thinking positively of Apple back then, and certainly not since.


There's no guarantee that the calendar event will exist 50 years in the future as well.

Gmail might not exist or be replaced, text files might suffer corruption, cloud hosting could go off line or the database could die or a physical letter can be lost or destroyed.

Really need to use a multitude of options to ensure delivery in the future.


> This derisks the possibility that the "future you service" goes under, taking your cherished letters with it.

I’d say it replaces it with a different set of risks (new phone, cloud service goes under, you start using a new account, etc). It’s a hard problem to solve over long time periods.



Made a bunch a while ago using Jukebox and cleaned it up a bit using some izotope plugins: https://m.soundcloud.com/R05c0

It's really just a matter of time before they figure out how to make the music a bit more "cohesive."

Right now it's kinda like a stream of consciousness, vs. being verse, chorus, verse, chorus.

My prediction: in under 5 years, most of us will have a favorite AI band.


I like it! Would probably call it 'Customer Success as a Service' (CSaaS) myself


This is brilliant


I don't know if docker would be the right service for my use case, but considering the user experience on this thread I thought I'd ask...

I'm looking to deploy a python based analytics service which runs for about 12 hours per job, uploads the results to a separate server then shuts down. At any given time there could be up to 100 jobs running concurrently.

Is this 'dockable' ?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: