Earlier quoted context omitted.
I solved this five months ago with recursive-mode: recursive-mode.dev/introduction
Thanks! Looks great, bookmarked.
Curious to hear how it works for you.
Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
281–290 of 316 posts
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#282What is yours agentic development experience with elixir? I used to like elixir a lot during a pre agentic era, but with coding agents it feels like the language isn't the best choice - slow compile time, weak type system (at least it was a year ago, I know there is work on that front), small ecosystem...
I find agents work well with Elixir, but you should reach for it when the product benefits from Elixir/BEAM features. A slow compile time is a minor annoyance compared to the greater architectural decision. Elixir hot-reloading with Tidewave works well for agent loops though.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#283Author 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!
I agree with you, I think the replies are misunderstanding the basis for code and specs and making semantic distinctions. Code is specs, just in a different syntax for machines to understand. This is a pillar of the discipline of the discipline of requirement specifications that Uncle Bob talks about in Clean Agile.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#284Earlier quoted context omitted.
This is a particular artifact of the government system process. These are contracted pieces of work that Company A would deliver, Company B would administer, and Company C would be contracted out for additional work. Further, all specifications were created ahead of time because changes would cost extra. (Anyone who has done government contracting can talk to the shenanigans involved with it - I have not lived in thi…
> This is a particular artifact of the government system process. Yes, a government process meant to implement the waterfall approach. If you look at Dr. Royce's paper which originated the concept, he was very explicit that it required upwards of thousands of pages of documentation to be written up front, if you were doing it "right". By the time the required documentation had all been written, there should be essent…
Indeed, I came across this not as a contractor but in my university textbook :) I wanted to collect the document list that forms the "thousands of pages" mentioned above in the waterfall model.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#285Earlier quoted context omitted.
> 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…
> 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. My point is that without writing, you can't surface the type of problems you usually surface. The AI isn't going to surface those problems for you. It's rare when reviewing that you think "Oh shit, this approach is totally wrong, we need to throw it away", whil…
> It's rare when reviewing that you think "Oh shit, this approach is totally wrong, we need to throw it away", while it's common when writing code to have that reaction.
That's not my experience. It is actually very common for specifications and design to be reviewed and improved.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#286[deleted]
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#287Earlier quoted context omitted.
"Plans are worthless, but planning is essential."
Pointless nit, but replace "essential" with "invaluable" for a play with words.
I like wordplay too, but in this case it'd have risked muddling the lone point I was making. Doubling down on tangents, since you like wordplay I bet you'd enjoy
https://tiledwords.com/
which has been posted on HN a couple times.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#288Earlier quoted context omitted.
> This is a particular artifact of the government system process. Yes, a government process meant to implement the waterfall approach. If you look at Dr. Royce's paper which originated the concept, he was very explicit that it required upwards of thousands of pages of documentation to be written up front, if you were doing it "right". By the time the required documentation had all been written, there should be essent…
Indeed, I came across this not as a contractor but in my university textbook :) I wanted to collect the document list that forms the "thousands of pages" mentioned above in the waterfall model.
Yeah and that's helpful too, because we typically talk about caricatures about both agile and waterfall and I think people truly don't realize that waterfall isn't simply "think about what you do before you do it" and nor is agile "code first; think later".
If people truly understood what waterfall is and how it's supposed to be carried out, they'd be less apt to recommend it. Nothing prevents a team from employing planning in an agile effort, but doing this doesn't turn it into a waterfall project and you shouldn't describe it as such.
If anything, teams that refuse to use agile (thinking it inherently means meetings, story points and not looking beyond 14 days) often send up choosing something even simpler, like cooking up a simple design doc of 4-6 pages before implementing it.
But that's still not waterfall, it's just another of the infinite renditions of agile methods that are out there, just without the consultancies issuing formal training certs.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#289Earlier 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!
>The traditional name for this spec is ‘source code’ Specs are the end goal, not how the software look at a moment in time.
Specs also evolve over time. There's no ‘end goal’ because requirements are always changing.
Specs are traditionally more forward-looking only because, by removing a lot of the implementation details that are required to write code, the specification can be written to be much broader in scope than code in an equivalent time period. But periodically we invent software that lets us automatically fill in more details of the software that now don't need to be specified by humans, and a level of specification that was previously ‘spec’ turns into ‘code’.
Re: Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML
#290Earlier 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!
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.
And given a C description of a program, a C runtime can implement that program in various different ways — interpreted vs compiled, explicit memory management vs garbage collection, different pointer sizes and memory layouts, parallelism at various points or not. It's turtles all the way down :) It just becomes ‘code’ at the point where a computer can execute it (in one way or another) without further human intervention.