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

191–200 of 316 posts

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

#191

Post by OHfsfuiohsef »

hypendev wrote: post #113
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?

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 t…

Continuous integration and demos to stakeholders (devs, designers, product managers etc) every 2 weeks - these practices are now engrained :-) It's frequent to then do corrections after these demos, and that really helps ensuring the product manager is getting what their customers need.

Easy to forget waterfall in 1970s / 80s really meant teams working on their own for months and then realizing there is no way to assemble the whole product from the parts. Or that the industry has moved on and the product is obsolete.

Agile as "devs can do what they want" never really existed ;-) Managers always have to plan / T-Shirt size resources (time, devs) to some degree. For stuff that's really hard to break into tasks, the magic word is "the plan is to do a POC first".

Coming from someone who also doesn't like teams being asked to break their unknowns into 30 known tasks. It's a compromise... I agree with all your points on how Agile is abused / misunderstood. Yet i believe in the progress from continuous integration and regular demos to stakeholders as a sign we did change something....

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

#192

Post by algoth1 »

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…

So basically, talk with a rubber duck, but record the conversation

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

#193

Post by chrisweekly »

try-working wrote: post #121
mike_hearn wrote: post #107

Earlier quoted context omitted.

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 solved this five months ago with recursive-mode: recursive-mode.dev/introduction

Thanks! Looks great, bookmarked.

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

#194

Post by brendanmc6 »

matthova wrote: post #166

Generally excited to try it out. The only thing that gives me pause is the idea of asking Claude to install a specific package. I know this is a bit naive as I’m probably downloading so many other things without my knowledge, but planning to read/fork the source before running any install commands

If you do end up taking a closer look (very much appreciated), take a peek at this security checklist I went over before publishing. I'm also scarred by all the supply chain attacks lately, do let me know if anything is missing.

https://github.com/acai-sh/cli/blob/main/docs/security.md

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

#195

Post by jacquesm »

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.

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

#196

Post by Stehfyn »

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 time (and brain power/attention/motivation to boot)?

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

#197

Post by jfreds »

lelanthran wrote: post #180
jychang wrote: post #179

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.

> 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

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

#198

Post by BoredPositron »

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…

Not a developer would come to mind.

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

#199

Post by Yokohiii »

fragmede wrote: post #171
Twey wrote: post #130

Earlier quoted context omitted.

The traditional name for this spec is ‘source code’ — a canonical source of truth for the behaviour of a system that is as human-readable as we know how to make it, that will be processed by automated tools into a less-readable derived artefact for a computer to execute. Checking the compiled artefact into the codebase without checking in its source code has always been a risky move!

Technology evolves and traditions change. What persists is the role, not the filename and its extension. Weddings are still weddings even after things went from painted portraits to film cameras to camcorders to smartphones to livestreams. Same with birthdays. Cards became phone calls, Facebook wall posts, group chats, shared albums, or generated videos (Sora, RIP). The tradition of having a deck of punch cards evolv…

> The important part is a human-auditable directive, not an opaque, generated artifact as the thing that matters.

Your arguments create a false dichotomy. You look at it from consumer perspective, while coding and it's artifacts are usually done by suppliers. If you change camcorder to tv advertisement, the requirements shift. The human auditable directive and the outcome matter. Coca Cola probably has very high standards for their IP (the directive) and doesn't care about the outcome (AI slop ads). The result is disgruntled consumers.

If you don't care about the "opaque" generated artifact, then you are Coca Cola.

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

#200

Post by ffsm8 »

locknitpicker wrote: post #174
ffsm8 wrote: post #134

Why is the vibecoding crowd still holding onto the idea that markdown (or here yml) is a better spec then code ? Seriously, it's just not Write your code like it's your spec and your software will be more stable, maintainable clearer to read. Code is not transient, it is your friggin spec itself And if your code isn't structured like it's a spec, then your code is garbage from the perspective of LLM driven developmen…

> Why is the vibecoding crowd still holding onto the idea that markdown (or here yml) is a better spec then code? From your comments it sounds like you are oblivious to the whole problem domain. The whole point of these tools and frameworks is to provide a high level description of not only what features are already implemented in a project but also and more importantly what features you want to implement. To put it…

Oh I've researched it and did two projects entirely like that, both scaled to 150k loc and I believe 90k loc last summer to fall.

That approach just doesn't scale unless you don't care about your product whatsoever, hence my comment

I've successfully been working on various personal projects with highly stable functionality since I stopped that approach and instead focused more into leveraging my codebase to become the spec.

Very low maintenance and great to add features after the initial hurdle of structuring your codebase that it's less about implementation detail and more about spec. So a lot less "smart" code and less highly advanced abstraction, and a lot more declaratively structured - boring and potentially repetitive, but easier to place good AGENTS.md and doctexts on areas which have requirements which may be unclear just from looking at the code for example. Then running multiple "QA" agents over the diff before you look at it yourself for the final review

So yeah, sorry but your imagination is running wild

Post reply on HN