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

221–230 of 316 posts

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

#221

Post by brendanmc6 »

vessenes wrote: post #132
brendanmc6 wrote: post #41

Earlier quoted context omitted.

Should I apologize for being excited about something I built and use daily and for wanting people to try it, discuss it, critique it? Not sure by the tone of your message.

Don't apologize. Keep writing and trying things. Ignore the haters and non-curious, listen to the (even if salty) interested. There's a fair amount of talk right now about the value being in the verification layer -- once there's a hard verification loop, the agents can do amazing things without getting (permanently) sidetracked. I think what you're working on is half way there -- in essence, you're probably relying…

Totally agree. This is 100% where I want to be focusing my energy next! A lot to learn and explore still, just need to find the time.

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

#222

Post by sigmonsays »

codebolt wrote: post #207
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'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.

a spec can be wrong until you prove it is right..

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

#223

Post by Yokohiii »

brendanmc6 wrote: post #185
kibwen wrote: post #162

Earlier quoted context omitted.

> Does the business mandate we use a cache for this hot path? No, but the business set performance targets, and the cache was a sensible way to satisfy them. See the difference? This seems confused. Specs are free to include as much or as little detail as they deem necessary. If a spec only wants to suggest vague performance goals and handwave the details, that's permitted. But if specs want to specify the exact mean…

I think we are actually saying the same thing! We could think of situations where the cache would be verboten (sensitive info), or where it would be mandatory, like in your example, or optional like in my example. My aim was to voice disagreement with the "code is spec" crowd, whom I think are using a different (and in my opinion tautological / useless / counterproductive) definition of spec. Probably because they ar…

> In your "time complexity is a downstream requirement" example, which is a great one, I think you would prefer to have well-maintained written documentation of that criterion that lives outside of the procedural code itself, would you not? How much attention that doc gets is a matter of process and preference, but I'm advocating it should get more (spec-first).

That is a huge mixed bag. It helps to have an high level overview of an algorithm. If you want to be very accurate about an algorithm, then that documentation is potentially harder to digest then the actual code. I personally don't even know how to express an sophisticated algo in natural language without falling back to pseudo code. Then you also have to verify a purely natural language defined algo with a very slow feedback loop (agentic PR cycle) against a test. Which seems to be a guarantee for myself to get sloppy because it's annoying.

There are a lot of reasons to theorize about algos in spoken or written natural language. For me it's questionable why you'd prefer the natural language to be the reference implementation when all you want is the code. That only makes sense if you never want to look at code.

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

#224

Post by lelanthran »

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

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

#225

Post by docheinestages »

I think the whole point of using an LLM is so that you don't have to write your spec in a specific language. Sure, spec-driven development makes sense, because you need to specify how and what you exactly want to build, test, and ship. But writing specs in YAML is really swimming against the current.

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

#226

Post by lelanthran »

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…

> To put it in simpler terms, the point is to write down high level specs in a way that coding assistants can parse them and implement them.

I have never seen a non-trivial product that didn't have the spec modified during development due to finding rare business edge cases when actual implementation happened.

It's a fantasy to think that all you need to do is give an agent a spec; every team I have been on over the last 30 years have needed to refine the spec while developing.

That's the whole reason for Agile in the first place.

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

#227

Post by Yokohiii »

augment_me wrote: post #12

Completely subjective take, but I feel like 95% of these "tools" that are prompt-engineering inventions created by the authors with their bias and to suit their needs don't have anything supporting them besides the authors' subjective experience. I have seen the same idea with processes, pipelines, lists, bullet points, jsons, yamls, trees, prioritization queues all for LLM context and instruction alignment. It's lik…

The inherent lack of distinction for LLMs between code, structured formats and natural language is ridiculous. Before the AI era we had a trend to increase type safety everywhere. Now we just sling code and natural text around and hope it works.

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

#228

Post by honr »

codebolt wrote: post #207
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'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 side benefits to both, too. Writing some plans slowly and "beautifully" drags them out and I get to think longer on them, so the sporadic "nice looking plans" are often more well thought. And doing the coding all by myself stops my brain from losing the ability. I was initially in the 100% AI-writes-all-code camp for a while and noticed I am getting notably slow in some personal coding skills. It is too early to treat specs as the new code and old languages as assembly (but I admit we might get there some day).

In other words, I think AI doing 90-99% of the coding, depending on the language verbosity and AI accuracy for the code at hand, is quite reasonable.

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

#229

Post by Stehfyn »

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.

I use a multimodal approach to defining my spec: different layers of criteria for how the software looks, behaves, what it produces, and under what constraints.

For the literal code:

• A healthy cocktail of /WX + /Wall, plus clang-tidy with very few suppressions

• An extremely opinionated mix of clang-format and LLM-generated bespoke formatting that AST-based tools cant express

• Hungarian notation; all stack locals pre-hoisted, declared in order of appearance, and separated from subsequent assignments

• Enforced dataflow: all memory accesses are bounded independent of branch resolution, with only data-oblivious indexing

• Functions have a single point of return

In a C89 workflow, this pushes agents to produce code where wrong business/domain decisions are unmistakably obvious, while eliminating the vast majority of bug classes before I ever read it.

So yeah, Ill reassert 80%, if not more.

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

#230

Post by oblio »

girvo wrote: post #50
jwpapi wrote: post #26

And once you’ve written all these specs you realize it became so slow that it’s faster to do it yourself in editor

People don’t actually track wall clock time, I’ve noticed.

Nope, they never do.

That's how you end up with those cooking recipes that only "take 5 minutes". Sure, if you don't count buying all the ingredients, cleaning and preparing them, cleaning up the pots and pans (and probably the worktop, stove, etc), a lot of things can take 5 minutes. Even trivial stuff like scrambled eggs don't actually take 5 minutes when you take everything into account.

Reminds me when I automated a manual service deployment that only "took 5 minutes". Sure, copying the binaries only took 5 minutes, but coordinating between various departments to deactivate the relevant monitoring bits, turning off the services, invalidate the caches, etc, etc actually took half a day with humans involved. Once automated and parallelized the thing took about 10 minutes for a data center.

Post reply on HN