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?
[dead]
Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
211–220 of 316 posts
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#212Earlier quoted context omitted.
> 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 t…
[dead]
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#213Earlier quoted context omitted.
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.
It always amazes me how bad the software world is at keeping lessons learned as learned, especially when compared to say engineering. It's as if every 20 years or so we throw away the books and reinvent it all from first principles, hopefully this time with fewer mistakes overall but usually we end up finding both new ones and re-do some old ones.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#214AI psychosis is literal psychosis in humans associated with AI use. I don't think the author is psychotic? We have all these useful new terms for AI phenomena, if we can keep them straight...
Fair critique, voiced elsewhere in this thread as well, I am regretting my use of the term.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#215AI psychosis is literal psychosis in humans associated with AI use. I don't think the author is psychotic? We have all these useful new terms for AI phenomena, if we can keep them straight...
Fair critique, voiced elsewhere in this thread as well, I am regretting my use of the term.
I absolutely understand that, because that response puts me in one after a couple times.
> You’re absolutely right! Let me fix that.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#216Author 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.
There is a lot of room to reevaluate the lessons of software development pre-web in the context of the current environment.
Like, if waterfall of a project can be done in 2 weeks, is it agile now?
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#217Stopped at "Specsmaxxing".
Right? Just gross...
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#218Earlier quoted context omitted.
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.
There is a lot of room to reevaluate the lessons of software development pre-web in the context of the current environment. Like, if waterfall of a project can be done in 2 weeks, is it agile now?
That doesn't do justice to either waterfall or agile.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#219Earlier quoted context omitted.
That's what the article is about - overcoming problems with AI cooding tools using specs in Yaml. If we've got that far, it might be better to write specs in a proper programming language instead and skip the AI layer altogether
Think the idea is to still get monumental acceleration between fancy YAML specs (bullet points with some indentation that an intelligent technical manager could write) and production ready code.
I have yet to see the monumental acceleration tbh. For people who never tried writing code themselves a semi-formal spec is definitely a step in the right direction though
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#220Earlier quoted context omitted.
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.
100% the opposite here. I derive all the pleasure from writing code, which is why I'm still writing code.