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

231–240 of 316 posts

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

#231

Post by surgical_fire »

lelanthran wrote: post #224
Stehfyn wrote: post #196

Earlier 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 am already going to spend the brain power on reviewing the code. Very few devs are actually reviewing any generated code. > Why not fast forward to that point and save 80% of the time If you are saving 80% of time, you aren't actually reviewing the code.

> Very few devs are actually reviewing any generated code.

Just because very few devs are qualified at doing their fucking job, it doesn't make someone trying to use AI properly wrong.

> If you are saving 80% of time, you aren't actually reviewing the code.

The idea is that if you spend time in specification ahead of time, reviewing and validating will be easier and less time consuming later.

I haven't tried it myself, but the idea rings true to me.

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

#232

Post by arvid-lind »

jacquesm wrote: post #213
moffers wrote: post #205

Earlier quoted context omitted.

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.

It's almost like "move fast and break things" isn't such a good mantra.

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

#234

Post by mpyne »

ebiester wrote: post #216
jacquesm wrote: post #195

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

> Like, if waterfall of a project can be done in 2 weeks, is it agile now?

Sure. The thing is, the waterfall guys would tell you it's impossible to do it in 2 weeks because you need to have written down everything first. "Thousands of pages" was the terms they used.

Agile guys would point you to the Agile manifesto which would lead you to "working code over documentation" and "people over process".

A 2 week period to go from initial spec to product in a user's hands to capture feedback and make changes from there is much closer to agile than to waterfall. In fact it's more or less exactly some older versions of Scrum (which didn't permit deviating from the planned sprint user stories midway through the sprint, instead changes influenced the subsequent sprint).

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

#236

Post by Stehfyn »

honr wrote: post #228
codebolt wrote: post #207

Earlier quoted context omitted.

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.

I do get pleasure from typing out the code in some languages (and not in others; hello javascript, java!). Similarly, I love writing text with a calligraphy or fountain pen. However, I can't dedicate too of the much work / business time to whatever is more pleasurable. So, I "doodle" some text / ideas / planning with a calligraphy pen, and type in some code, occasionally, both mainly for the fun aspects. There are si…

Personally, this is an experience I thought about first before writing my comment. I think in the days pre-AI coding assists, I believe you describe the intrinsically human experience that's requisite to write code by hand. The wonder, the joy, the frustration, the confusion, the elation--the discovery. These days, the things I wonder about lie deeper and deeper behind more and more lines of code, through journey's that provide less and less joy, and thusly becoming more and more unreachable as I'm human, bound by an excess of things in addition to time. AI has helped me rediscover some of this sporadic creativity demonstrably due its ability to prototype recreational ideas on a whim

Professionally, I'm employed writing safety-critical avionics software. Superfluous amounts of cogent tooling putting guardrails on agents has enabled me to spend heaps more time to think deeply about how the software should work at a systemic level. The code by definition must be heavily criticized and battle-tested before it can go out the door to begin with. Albeit a beautiful part of coding, those sporadic bursts of creativity drive the code leaving my desk less and less, and I feel strongly that has made its quality paradoxically better since I'd spent much more time on broader implications and interactions.

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

#237

Post by esseph »

felooboolooomba wrote: post #203

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.

> Anything ending in "maxxing" will be seen as a joke, treated with contempt or both.

Always was.

> Social media is making money off him

Yes, and he's been making a TON of money as well.

> and we're all either laughing or astonished

So social media, got it. Social media LOVES controversial assholes, they just keep making money hand over fist (look at the Paul brothers for example).

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

#238

Post by martythemaniak »

There's a lot of people wondering "Why not just do this all in code", to which there is a very simple and straightforward answer: compression.

An LLM/agent can take 100 tokens worth of spec and turn it into 1000 tokens worth of code. We all understand this well enough in the most basic case: you type a one line comment and the LLM will give you the correct 10 line function. But this scales - 10 line comment into 100 line function, 100 line spec into a 1000 line object etc. Depending on the work, you could get more or less than 10x compression. The disagreements are all largely "what what level of resolution should devs be operating", my opinion is that the current sweet spot it roughly 1000 tokens of spec (~750 word doc/3 pages) producing 10000 tokens (~1000loc)

This compression allows your spec to be much denser and more readable than raw code. It can be shared, understood and modified by non-dev partners more easily, gives you flexibility into how it's implemented etc.

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

#239

Post by moregrist »

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…

If you can define the spec up front, this is probably true.

For anything large, the spec becomes increasingly more complicated. Look at software schedules in the old waterfall days of the 80s/90s: the spec / planning period was maybe 30-70% of the project.

Unless you’re working on pretty routine stuff, the real problem is that the customer (which might be you) almost never knows what they want. The spec will change the minute a customer gets something to play with.

This was the real value of agile in my mind: letting a customer change their mind as early as possible.

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

#240

Post by rufasterisco »

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…

What not just record the conversation? If contains all that is needed. The initial at large scoping, the failed attempts at doing x and not y, how that specific line of code solves that specific edge case, etc.

When it’s time to review, review both code and conversation. 200 “user written messages asking why and what”? Likely a good PR. 15 “yes, yeah, ok, whatever”? Well you might want to give that PR some love.

It feels to me that when we commit, we throw away half, if not most, of the work done by not recording it.

Post reply on HN