Iron oxide is not what regular floppy disks use. That's probably what the issue was.
Readit Newspolishdude20 commented on I made a floppy disk from scratch kottke.org/25/08/i-made-a... · Posted by u/bookofjoe
Good exercise also contributes to good sleep. I sleep like a log after a good bike ride or an evening out swing dancing, but if all I did was sit at my desk all day then it’s a lot more likely I’ll be tossing and turning or doom scrolling into the wee hours.
Just had a very tiring long run yesterday. Spent the night still scrolling haha.
I gave it explicit ordering, instructions on what tools to _not_ use, and before/after examples from the codebase. A full page of instructions.
After iterating on that for a while, I did a bunch manually (90) and then gave the LLM a list of pull requests as examples, and asked _it_ to write the prompt. It still failed.
Finally, I broke the problem up and started to ask it to generate tools to perform each step. It started to make progress - each execution gave me a new checkpoint so it wouldn't make new mistakes.
Yep, I think you did everything that's reasonable. I'm surprised myself only because I've been able to have Cursor do similar things for my codebase with no issues. Granted it's a react codebase following fairly standard practices.
It takes way more time to explain, and then re-explain, and then re-re-re-explain to the LLM what I want the code to do. No, it isn't because I don't understand LLMs, it's because LLMs don't understand, period. Trying to coax a fancy word predictor to output the correct code can be extremely frustrating especially when I know how to write the code.
Usually if you have to re re re explain, it means you didn't leave those details in the first prompt. So writing out the code yourself, you'd still get into this trap because you discover as you write. Just like you discover the details as the LLM writes.
> The moment you see it go off the rails, just throw it out. That problem is too hard for Claude, it’s for you now.
Or, any of:
- the problem was too big in scope and needed a stepped plan to refer to and execute step by step
- your instructions weren't clear enough
- the context you provided was missing something crucial it couldn't find agentically, or build knowledge of (in which case, document that part of the codebase first)
- your rules/AGENTS.md/CLAUDE.md needs some additions or tweaking
- you may need a more powerful model to plan implementation first
Just throwing away and moving on is often the wrong choice and you'll get better at using these tools slower. If you're still within the "time it would have taken me to do it myself" window, think about what caused it to go off the rails or fail spectacularly and try giving it another go (not following up, throw away current results and chat and try again with the above in mind)
I totally agree. I've recently been using Cursor to help create a new react project with a lot of functionality. I realized I need to have it do more smaller steps that I get to have lots of input on rather than say "this is the big picture now go forth".
almost every job ive ever had has been to build stuff. frequently programming is used to build stuff. programming is not my job, building stuff is. it’s perfectly normal (and a sign of a more mature engineer, imho) to prefer building stuff to the annoying stuff that gets in the way of building stuff, especially since many languages are obnoxious to work with.
I agree. I'm hired to build stuff and make it work. I get satisfaction from building stuff people want and use. If I can use an LLM to help me focus more on what the user wants in all for it.
I feel good because real humans are using what I've built and they like it.
I've just spent the better part of two weeks trying to convince a LLM to automate some programming for me.
We use feature flags. However, cleaning them up is something rarely done. It typically takes me ~3minutes to clean one up.
To clean up the flag:
1) delete the test where the flag is off
2) delete all the code setting the flag to on
3) anything getting the value of the flag is set to true
4) resolve all "true" expressions, cleaning up if's and now constant parameters.
5) prep a pull request and send it for review
This is all fully supported by the indexing and refactoring tooling in my IDE.
However, when I prompted the LLM with those steps (and examples), it failed. Over and over again. It would delete tests where the value was true, forget to resolve the expressions, and try to run grep/find across a ginormous codebase.
If this was an intern, I would only have to correct them once. I would correct the LLM, and then it would make a different mistake. It wouldn't follow the instructions, and it would use tools I told it to not use.
It took 5-10 minutes to make the change, and then would require me to spend a couple of minutes fixing things. It was at the point of not saving me any time.
I've got a TONNE of low-hanging fruit that I can't give to an intern, but could easily sick a tool as capable as an intern on. This was not that.
Which LLM? How are you prompting it?
I've been using Cursor for the last few months and notice that for tasks like this, it helps to give examples of the code you're looking for, tell it more or less how the feature flags are implemented and also have it spit out a list of files it would modify first.
polishdude20 commented on You Should Add Debug Views to Your DB chrispenner.ca/posts/view... · Posted by u/ezekg
I do the "same thing", but using PostgreSQL `EXPLAIN ANALYZE`. EXPLAIN ANALYZE has information about the number of rows returned, which means I know exactly which node in the query plan failed to return expected values.
Not for function though unless you specify it as a debug flag inside the function?
polishdude20 commented on Vibe coding creates a bus factor of zero mindflash.org/coding/ai/a... · Posted by u/AntwaneB
I like the spirit of these, but there are waaaay more. Like you only mentioned the ones for professional and skilled coders who have another option. What about all the sub-examples for people all the way from "technically unskilled" to "baby-step coders". There's a bunch of things they can now just do and get in front of ppl without us.
Going from "thing in my head that I need to pay someone $100/h to try" to "thing a user can literally use in 3 minutes that will make that hypothetical-but-nonexistent $100/h person cry"... like there is way more texture of roles in that territory than your punchy comment gives credit. No one cares is it's maintainable if they now know what's possible, and that matters 1000x more than future maintenance concerns. People spend years working up to this step that someone can now simply jank out* in 3 minutes.
* to jank out. verb. 1. to crank out via vibe-coding, in the sense of productive output.
*"to vibe out"
[0] - https://hjelp.yr.no/hc/en-us/articles/9260735234076-Lightnin...