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

261–270 of 316 posts

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

#261

Post by alasano »

jochem9 wrote: post #49
arikrahman wrote: post #8

I use OpenSpec for my spec management, and I scrolled down to the comparison. The gripe seems to be with a semantic difference. Specs describing a current system is the basis for AS/IS Gap Analysis. Also, I mainly pursue these tools so that I can have AI accelerate this process and broker an agreement after negotiating specs with the agent.

I'm also doing openspec for a few months now and it's really good if you invest enough in the specs (in the beginning I skimmed over much, now I pay attention to all details and fix anything that's wrong or where I see a gap). The one thing I like that OP brings is to tie specs and code together. The openspec flow does help a lot in keeping code synced with specs, but when a spec changes, AI needs to find the relevan…

I enjoy the OpenSpec format but I think maintaining the main specs is not worth it.

I've stopped doing it entirely and just archive directly after implementation.

When you do the sync process, it just keeps drifting and drifting until you have duplication and contradictions across specs.

I agree that tying the specs and code together helps for that but it still seems like extra overhead, even if the value is better justified here.

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

#262

Post by surgical_fire »

lelanthran wrote: post #243
surgical_fire wrote: post #231

Earlier quoted context omitted.

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

I've never seen a spec survive first contact with implementation. The spec is refined while writing the code. Hell, you probably couldn't even build a simple bike shed from plans without having to revise them while building, so I am skeptical that without writing you are going to pinpoint the problems in the spec. Reading only gets you a short way towards learning.

> I've never seen a spec survive first contact with implementation. The spec is refined while writing the code.

Neither have I. This does not make the spec useless. I don't spec hoping that it will be the source of truth, I spec because planning more often than not allows me to spot inconsistencies and ambiguity ahead of time, not halfway through implementation.

> Hell, you probably couldn't even build a simple bike shed from plans without having to revise them while building, so I am skeptical that without writing you are going to pinpoint the problems in the spec.

I think you are using specification and design wrong.

It's not supposed to be a bible that implementation can't deviate from. It's a plan, not law. It's okay for the plan to be adjusted in contact with reality.

It's still useful to know ahead of time constraints, expected output, assumptions, premises, etc.

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

#263

Post by user3939382 »

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.

Or referring more to the process of building the specs, requirements engineer(ing). Imho agile became a way of hand waving most of this critical process and responsibility, in place of a new inefficient and ill-defined process.

Yes, you don’t know the nuances of all specs upfront and revision will be necessary. Turning the ship with arbitrary degrees of freedom outside of bullet points on a roadmap is not an efficient way to resolve that for many projects.

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

#265

Post by kaffekaka »

chrisweekly wrote: post #189
scandox wrote: post #79

Earlier quoted context omitted.

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.

"Plans are worthless, but planning is essential."

Pointless nit, but replace "essential" with "invaluable" for a play with words.

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

#266

Post by bdangubic »

rzzzt wrote: post #250
mpyne wrote: post #234

Earlier quoted context omitted.

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

The DoD's 2167 standard from the late '80s mentions the following documentation that should be produced as part of the development process (section 6.2 and Appendix D): - System/Segment Specification - Software Development Plan - Software Configuration Management Plan - Software Quality Evaluation Plan - Software Requirements Specification - Interface Requirements Specification - Software Standards and Procedures Man…

at one point or another in my career (gov contracting) I had to write or co-write or review every one of these. and without fail, within 6-12 months they would be stale/inaccurate/obsolete/… the truth is, even on projects where sufficient time is allocated to write these, there is never (literally) time allocated to keep them up-to-date

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

#267

Post by sltr »

Twey wrote: post #130
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…

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!

spec isn't code. There's a C language specification and many implementations. There are a handful of browsers each implementing HTML, JS, and CSS specs in their own way.

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

#268

Post by kaffekaka »

Yokohiii wrote: post #208
scandox wrote: post #79

Earlier quoted context omitted.

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

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

This is a very good point. The AI speedup some PMs fantasize about is skipping planning and instead generate code directly from end user discussions, POC-ing our way into shipping.

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

#269

Post by behaviors »

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…

The exact reason you should start with one first. I support maximum specification. Atomic if you will. Lucky for modern development, you don't have to write it, you just have to proof it. If you can read a spec, it can guide your development, might as well have a system to manage them.

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

#270

Post by user3939382 »

colinmarc wrote: post #10

Wow - I love programming in YAML! You know what would make this really fun? Sprinkle in some Jinja. Then we'll be cooking with gas.

I just started learning GitLab CI scripts and this was my first exposure to the concept of having executable code inside yaml files. I was like what kind of hell is this?
Post reply on HN