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

201–210 of 316 posts

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

#201

Post by dotneter »

brendanmc6 wrote: post #163
dotneter wrote: post #124

I didn’t quite understand why YAML is better than Markdown for such specifications. If the specification is written in such a strict format as YAML, I would expect it to be executable, something like this https://blog.fooqux.com/blog/executable-specification/ But as far as I understood, for acai that is not the case.

Here is how I got from Markdown to YAML in a few easy steps: 1. Start with unmaintainable prompt. Add auth to the admin route. It must only be accessible to team members. It must not be accessible to team members with the `quarantine` role. Unauthorized users should be redirected to the /login page, with query param `?error=unauthorized`. Requires fresh session, no older than 10 minutes. 2. Put it in a structured .md…

> Might as well clean it up and make it machine readable at that point?

For me this looks pretty machine readable.

## Requirements

  AUTH.1: Accessible to team members.
  AUTH.2: Not be accessible to members with `quarantine` role.
  AUTH.3: Redirects unauthorized users to /login.
    AUTH.3.1: Redirect path includes `?error=unauthorized`.
  AUTH.4: Requires fresh session, no older than 10 minutes.
Yes, yaml is more "parseble". But I still need to use some format conventions inside yaml. So I could just use them inside markdown as well.

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

#203

Post by felooboolooomba »

Anything ending in "maxxing" will be seen as a joke, treated with contempt or both. The poor guy is livestreaming his acute body dysmorphic disorder. Social media is making money off him and we're all either laughing or astonished.

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

#204

Post by skeedle »

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…

Beyond writing the spec down, you can share the spec or use someone else's spec. That's why spex.build was created, to be a hub with versioned specs so people can just create their own implementations, in the language, style, and particulars that they want.

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

#205

Post by moffers »

jacquesm wrote: post #195
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…

You have rediscovered the job of Software Analyst, which until the early 90's was a thing. Then that all got upended and we ended up with a mix between product owners, project managers and developers / devops but I think that that ignores the fact that Analyst is a different set of skills.

I came up as a software requirements analyst before the weird transition between business analyst to product owner to product manager to technical product manager. But living in requirements for 15+ years really gave me a leg up on these “let’s go back to requirements!” efforts.

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

#206

Post by lelanthran »

jfreds wrote: post #197
lelanthran wrote: post #180

Earlier quoted context omitted.

> Yes, I agree. If you tell humans "do not think of pink elephants", they are more likely to think about pink elephants. > Therefore, you must not use humans for any important work. Counterpoint, all important work done in the history of humans were done by... humans, and yet I see no pink elephants created as a result of telling humans "do not think of pink elephants".

I’ve seen loads of very bad/wrong code written by humans

> I’ve seen loads of very bad/wrong code written by humans

Have you seen any pink elephants?

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

#207

Post by codebolt »

Stehfyn wrote: post #196
chrisldgk wrote: post #187

At this point, why not just write the code yourself? Defining exactly what the product is supposed to do is the hard part, writing code is the easy part. Write your specs as code and you have your product - why let your LLM do the fun part?

Just because I am capable of "writing all that code", doesn't make the option preferable to defining a vast majority of spec up front and having an LLM generate an implementation. I am already going to spend the brain power on reviewing the code. I am already going to spend the brain power on pontificating edge cases, external module interactions, and next steps. Why not fast forward to that point and save 80% of the…

I'm with you all the way here. I derive zero pleasure from simply typing out the code once the spec is clear. Having a fast forward button to skip that phase is a pure win in my book.

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

#208

Post by Yokohiii »

scandox wrote: post #79
hansmayer wrote: post #74

Earlier quoted context omitted.

> 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?

All through the agile era I wrote detailed specs for projects and then followed an agile process. The most successful parts of every project were the ones that we were able to spec best even when they diverged significantly from the original spec. You don't plan to follow the plan. You plan in order to understand the whole problem space. Obviously no plan survives contact with reality.

> You plan in order to understand the whole problem space.

I like to do spikes to understand problem spaces before planning. The planning is then usually effortless and just to get in sync with stakeholders.

But in that regard AI coding is really backwards. We don't necessarily need hard separation of planning and coding, but we need a deliberate separation of experimental/explorative coding and the code that is supposed to make it into prod. AI coding does all that in the same place, I don't even want to know how hard it is to "fix" AI code that started on behalf of a completely wrong premise. AIs certainly don't have a good measure when to refactor something completely messed up.

Post reply on HN