Live data from Hacker News

Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML

acai.sh

91–100 of 316 posts

Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML

#91

What is it with people and procrastinating with the most useless shit you can imagine? First it was choice of editor: people were micro optimizing every aspect of their typing experience, editor wars where people would literally slaughter over suggesting another camp. Editor wars v2: IDEs arrived and second editor war began. Revenge of the note taking apps: Obsidian/Roam/Joplin/Apple Notes/Logseq. Just one plugin, ju…

Lmfao. Going to a site for computer geeks and complaining that they are computer geeks.

Also, a lot of folks don't write code anymore, and barely have the time to read the volume of code that AI produces. This may just be one of the most profound changes in an industry, and some folks are excited about it and want to get better at building with it.

I think the person who wrote this post made a good faith effort to share his learnings while promoting his tool.

Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML

#92

Author here, if you don't want to read all that, I'll post one excerpt that I think sums it up nicely: > My point is, the spec must live somewhere, even if you don’t write it down. The spec is what you want the software to be. It often exists only in your head or in conversations. You and your team and your business will always care what the spec says, and that’s never going to change. So you’re better off writing it…

> will always care what the spec says, and that’s never going to change Did I miss something or is everyone back in 1970s, working in waterfall processes now?

Sort of, but the downside of waterfall was you build the wrong thing and waste a shitload of time rewriting it.

When rewriting the entire codebase is very quick and cheap, why bother iterating on small components?

Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML

#97

Earlier quoted context omitted.

Should I apologize for being excited about something I built and use daily and for wanting people to try it, discuss it, critique it? Not sure by the tone of your message.

Read the room. What you "built" is neither exciting, nor something most people want to "try". Why? Because just like other AI boosters, you are still trying to somehow optimise the usage of natural language to make it work. But it will never "work" because the way the stochastic ML system is built, it has a failure built into the system.

Totally agree it's not exciting, even though I am personally excited by it, and I also agree it's not something most people want to try, even though some people do want to try it-- and I found a few of them right here on HN.

Disagree on the bit about it "never going to work" though.

Failure-prone stochastic ML systems produce testable, auditable code... just like failure-prone human brains can produce testable, auditable code. And in fact, in both cases, changes to our process can reduce the amount of failures that slip past testing and audit. Or can reap other rewards. Finding the a better process is what I'm interested in right now.

Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML

#98

Author here, if you don't want to read all that, I'll post one excerpt that I think sums it up nicely: > My point is, the spec must live somewhere, even if you don’t write it down. The spec is what you want the software to be. It often exists only in your head or in conversations. You and your team and your business will always care what the spec says, and that’s never going to change. So you’re better off writing it…

> will always care what the spec says, and that’s never going to change Did I miss something or is everyone back in 1970s, working in waterfall processes now?

waterfall is not the sole purveyor of written docs

distributed teams do well when proposals, decision, etc, are written down, and can be easily found and referenced

it doesn't mean docs are frozen in time and can't be patched like code

Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML

#99

Where is the part where the author overcomes ai psychosis? Reads like digging in deeper and deeper.

Fair, I could have made that point clearer. It's a couple things. First is that I finally stopped experimenting with TUIs, harnesses, models, subagents, roles, skills, mcp, md libraries etc. and have mostly settled on this approach, and got back to building other things with it. I'm sure that won't last forever though. Second is that I'm doing a lot less "seat of my pants prompting" and doing more engineering and ide…

I don’t understand how that relates to AI psychosis?

Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML

#100
post #93

Small advice - make one repo “main” and link to it from the website instead of an organisation. I wanted to star the project to track the progress but it feels a bit weird.. Which repo shall I track? Server? Cli? Sounds like a misc repos.

Ooh thought I did that, thanks.
Post reply on HN