Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

acai.sh

Post reply on HN
Print view View original

111–120 of 316 posts

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

#111

Post by khalic »

dgellow wrote: post #99
brendanmc6 wrote: post #59

Earlier quoted context omitted.

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?

Some people seem to give very little thought to semantics and semiotics lately, to the point where people use words vaguely without even looking it up.

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

#112

Post by brendanmc6 »

dgellow wrote: post #99
brendanmc6 wrote: post #59

Earlier quoted context omitted.

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?

I guess I misappropriated the term then, woops. AI OCD? AI obsession? Whatever you call the behavior that I saw myself and others falling in to. Getting obnoxiously fixated on the tooling and the models to a counterproductive degree.

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

#113

Post by hypendev »

hansmayer wrote: post #74
brendanmc6 wrote: post #2

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?

We never left waterfall in the end. Working with and for dozens, collaborating with probably a hundred software companies in different scales, every single one said:

We do agile

Guess what? Every single one of them was doing waterfall.

Their agile included preplanning and pre-specifying the full spec and each task, before the project kicked off. We'd have meetings where we'd drill down into tasks, folks would write them down so detailed that there would be no other way than doing that. Agile would be claimed, but the start date, end date, end spec and number of developers was always concrete.

Sometimes, the end date was too late, so a panic would ensue. Most of the time, the date was too late because developers had "unknowns" which then had to be "drilled down and specced so they wouldnt be unknowns". Sometimes, nearly 50% of the workweek was spent on meetings.

A few times, a project was running late - so to make sure we are _really_ doing it agile, we'd have morning standups, evening standups, weekly plannings, retrospectives, and backlog refinement. It would waste the time, and the "unknowns" aka "tickets to refine" were again, as always, dependant upon the PM/PO/CEO's wishes, which wouldn't get crystallized until it was _really last minute_.

One customer wanted us to do a 2 year agile plan on building their product. We had gigantic calls with 20+ people in them, out of which at least half had some kind of "Agile SCRUM Level 3 Black belt Jirajitsu" certificates.

To them, Agile was just a thing you say before you plan things. Agile was just an excuse to deal with project being late by pinning it on Agile. Agile was just a cop out of "PM didn't know what to do here so he didnt write anything down". Agile was a "we are modern and cool" sticker for a company.

And unfortunately, to most of them, agile was just a thing you say for the job, as their minds worked in waterfall mode, their obligations worked in waterfall mode, companies worked in waterfall mode, and if they failed their obligation to the waterfall, their job would go down one.

So while we were doing the Agile ceremonies, prancing around with our Scrum master hats, using the right words to fit into the Agile™ worldview - we were doing waterfall all along.

And after 15 years, I'm not even sure - did agile really ever exist?

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

#114

Post by rrgok »

hansmayer wrote: post #75
energy123 wrote: post #30

Earlier quoted context omitted.

I do (1) the same but (2) differently. In my workflow, (2) are AI generated specs using human written (1) as the input. It's an intermediate stage between (1) and the codebase, allowing for a gradual token expansion from 30k to 250k to the final code which is 2-3M. The benefit I've found with this approach is it gives the AI a way to iterate on the details of whole system in one context window, whereas fitting the wh…

Let's cut through the noise - what did you build with this very elaborate process and how much ARR is it generating ?

Asking the real questions. I would also really like know how much value AIs are bringing in terms of ARR or MRR.

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

#115

Post by eterps »

mike_hearn wrote: post #107
nalpha wrote: post #29

Earlier quoted context omitted.

What's the difference between this and Jira. Your specs already live somewhere, it's where you defined them. That's why it's nice to put the Jira ticket number in your code / commit, so you can refer back to the spec when something breaks

A specification isn't a series of change requests! Using Jira as your source of truth is no different to just recording all your prompts. There's nothing you can easily review to spot contradictions or how things interact with one another. I've been doing "specmaxxing" for a few months now. Unlike the author I don't use Yaml, I use a mix of Markdown and Gherkin. If you haven't encountered Gherkin before, it's not new…

I agree, Cucumber works really well with LLMs.

> I use a mix of Markdown and Gherkin

Gherkin also has a Markdown based syntax that is not well known:

https://github.com/cucumber/gherkin/blob/main/MARKDOWN_WITH_...

I prefer that to the 'verbose' original syntax. MDG also renders nicely in code forges.

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

#116

Post by MaKey »

brendanmc6 wrote: post #112
dgellow wrote: post #99

Earlier quoted context omitted.

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

I guess I misappropriated the term then, woops. AI OCD? AI obsession? Whatever you call the behavior that I saw myself and others falling in to. Getting obnoxiously fixated on the tooling and the models to a counterproductive degree.

AI psychosis: (informal) A phenomenon wherein individuals reportedly develop or experience worsening psychosis, such as paranoia and delusions, in connection with their use of chatbots.

https://en.wiktionary.org/wiki/AI_psychosis

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

#117

Post by try-working »

beshrkayali wrote: post #51
brendanmc6 wrote: post #2

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…

I wrote something similar recently about how agent-generated code lacks the institutional memory that human-written code has. There's nobody to ask why a decision was made (1). “Specsmaxxing” is basically the right response to this. When you can't rely on authorial memory, you have to put the intent somewhere durable. Specs become the source of truth by default if we continue down the road of AI generated code. 1: ht…

the recursive-mode workflow has full traceability, including why decisions were made, what the original requirement was, what the previous state was, etc. https://recursive-mode.dev/introduction

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

#119

Post by MoreQARespect »

mike_hearn wrote: post #107
nalpha wrote: post #29

Earlier quoted context omitted.

What's the difference between this and Jira. Your specs already live somewhere, it's where you defined them. That's why it's nice to put the Jira ticket number in your code / commit, so you can refer back to the spec when something breaks

A specification isn't a series of change requests! Using Jira as your source of truth is no different to just recording all your prompts. There's nothing you can easily review to spot contradictions or how things interact with one another. I've been doing "specmaxxing" for a few months now. Unlike the author I don't use Yaml, I use a mix of Markdown and Gherkin. If you haven't encountered Gherkin before, it's not new…

The problem with gherkin is that it was a badly designed language.

The general idea of "readable specification language" was an inspired one but it failed on execution - it has gnarly syntax, no typing and bad abstractions.

This results in poor tests which are hard to maintain and diverge between being either too repetitive to be useful or too vague to be useful.

The ecosystem is big but it's built on crumbling foundations which is why when most people used it most of them got frustrated and gave up on it.

Annoyingly there's a certain amount of gaslighting around it too ("it didnt work for you coz you werent using it correctly") which is eleven different kinds of wrong.

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

#120

Post by bizzletk »

beshrkayali wrote: post #51
brendanmc6 wrote: post #2

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…

I wrote something similar recently about how agent-generated code lacks the institutional memory that human-written code has. There's nobody to ask why a decision was made (1). “Specsmaxxing” is basically the right response to this. When you can't rely on authorial memory, you have to put the intent somewhere durable. Specs become the source of truth by default if we continue down the road of AI generated code. 1: ht…

I've been attaching to my commit messages a Git Trailer [1] of the Session UUID from the Claude Code conversation that created that commit.

It allows Claude to look back into the session where a change was made and see the decisions made, tradeoffs discussed and other history not captured by code, tests.

[1] https://git-scm.com/docs/git-interpret-trailers

Post reply on HN