Post

True that. I remember coming up with the wording of an error dialog during coding, and concede that a agent probably has enough info for that. But I also word it with knowledge of the user's demographic.

github.com/juxt/allium

An analogy I've been using in a work SDD environment is a video editing project and a render. People getting over the hump of the code being a render you view, see a mistake in, modify the project, re-render...and then throw away the original render, has been the friction point.

Same mindset but I havent figured out how to make the workflow natural. I think iterative refinement feels more natural and needs to be first class. Compiling takes too long and is too variable github.com/pboueri/inte...

we need a standard way to write spec ...

I've got a story about this, if we ever meet at the bsky polycule.

Oh that's been how I see things for a minute now. I barely care about the source code anymore, the spec is sacred. If the code breaks a model can re-make it by following the spec. If the spec is wrong ... well god help us.

This is the approach my division has taken at work and it has been one of the worst, most self-destructive engineering decisions I have seen in my lifetime

"Super fast, zero bugs"

you can't directly EXECUTE the spec, you can't interrogate it online, and sometimes it takes less information to just have the code than the overall spec justifying it takes up; natural language shifts and changes in different times and places and contexts,

It’s funny I was thinking about your last twert about this and thinking “theres no way he wants to… not check in the code, right? That’s too many tokens…”

The (spec -> code -> "oh no, not like that" -> spec) loop helps a lot.

Specs are great but insufficient, I find. They need to be accompanied by additional lower level architectural requirements and considerations: requirements around information hiding, acceptable code complexity, module boundaries etc. A lot of these are enforceable via static analysis tooling

same art re top skeets and then i hit reply

I think whatever would go in the acceptance tests for a competing implementation is a good heuristic

the amount of handwaving here could power a wind farm

Prompt engineering is back, baby!

On Exactitude in Science by Borges. It's about maps, but also specs-as-source: kwarc.info/teaching/TDM...

See? See?! And here I was even envisioning @blowdart.me in a dark office corner film-noir style cackling with delight as I wrote that. And a spoon sticking out from a half-eaten can of beans on the desk.

our team has gone full spec-driven. It was an interesting challenge as we are very opinionated on design, which doesn't translate to words, but we worked out a solid workflow there

Only half serious, but a lot of the practice of formal specification boils down to "how much can we simplify our model of the system and still have something useful enough for analysis?" Like do we have to specify that a particular batch job runs nightly, or is "it runs sometimes" enough?

Specs as intent and shipping as drift is what I would keep in view. An agent per service captures the tribal knowledge but it also captures the drift as if it were the spec, and then nothing tells you which way the build has wandered.

Enduring specs protect users but shift complexity into adapters, migrations and ops, creating hidden integration cost. Do you prioritise stable external contracts or internal simplicity when planning a regeneration?

It’s not extravagant at all. I’ve been doing multi-language codegen to solve these issues for 20 years.

Amending upstream is extremely hard to do. Monkeypatching, inheritance, configuration (if allowed), or forking. So: import spec, amend with your specs, lock in with tests

Ok ok wait, then you build a reference endpoint - a server that's basically a dummy, no live data, stateless as far as possible - that can be used during development to verify against. Then it's basically a oneshot project to build apps on any platform, any language.

This means there is no reason for anything you *didn't* explicitly specify to work the same way, and this will at some point bite you in the ass.

Shopify just implemented something like that

“Nondeterministicly build other platform from specs” is a bandaid. If the spec is precise enough to do that effectively, it will look *a lot* like real code. And If we’re close to real code, we might as well be writing it with a compiler.

The only reason we need the code base not to change/evolve is that we have an incomplete set of tests due to "undocumented features". (e.g. the code is creating a race condition, and if it wins when it's supposed to lose, or loses when it's supposed to win, it fails.)

this is a dangerous mindset imo. have you considered the increasing reality of coding mad cow disease

A function is a proof of the theorem that is that function's type. It's a fact about the universe. We build more complex theorems out of simpler ones; the top-level theorem (articulated as a spec) is simply that, the top level, not all the layers below it.

I have many opinions, but I will instead just leave this classic paper that I suggest everyone read before placing their own opinions in the comments: No Silver Bullet Essence and Accidents of Software Engineering by Frederick P. Brooks, Jr. www.cs.unc.edu/techreports/...

Feels like immutability is too strong a word to use here, since the code output would be still nondeterministic output. But yes, overall, this is the trajectory I see too.

I'm iffy about some of the spec-driven coding stuff, but that's mighty close to putting the code *behind* the tool where the human can't get unfettered access. The tool can distill the codebase in a durable way because it can't be backdoored, and (re)builds solely from its internal representation.

I have my own practices that I'm refining, because I basically treat it like my source code

I think spec writing for agents demands specificity that conflicts with the “move fast and break shit” mentality that increasingly permeated software development over the last decade plus. The quality of the thing being built benefits from the clarity and context, regardless of who/what codes it.

You have to run the code to find out what’s in the code!

I already get that with some threat models.

code is a liquid

code is a liquid

I dunno I like types a lot and code can be less reliant on English (or whatever) as a first language to express nuance

Isn’t a lockfile purely declarative? Whereas (most) code is imperative. Seems like an important distinction

Yeah. I was agreeing with ya

OHNO

Old experience from theater/literature: "The important thing is not what is said, but who says it". Corollary ∴ "who wrote the specs?"

yup

Yes.

I strongly suspect current AIs will indeed change how most people write code, although I'm not sure what the next stable plateau will look like. Also, it probably won't affect literally everyone. After all, some people still write assembly by hand today.

Oh. Ohno. Don't bring back the memories.

Fuck it. I probably need to do this

atproto for specs… or… atproto for uml bsky.app/profile/pfra...

(did i get that right? wild if true)

Wonderful article. It is correct that one of its primary intents was to visualize and reason about a system under construction and as a consequence, most of the artifacts I expected one to make using the UML would be thrown away. I’d add that a…

The biggest issue with all of these diagramming and notation languages is that they are impenetrable to outsiders. I spent weeks on a system architecture in ArchiMate but explaining hash line vs solid line with a solid diamond vs open arrow meant I had to bin it and redraw it using flowcharts

SysMLv2 seems poised to have a similar sort of ambiguity though at least there will be an executable semantics however convoluted.

Also, purely fwiw, I think ultimately whatever standard emerges is going to have to be text based. That's people want to write and read. That's the domain models swim in. Diagrams are just too labor intensive and take up too much space on the page :( As much as I love UML

See that's why I say it was the *methodology* of UML that dragged it down. The graphs are expressive, but the methodology behind them is a slog Also, constructing diagrams is a burden compared to just typing stuff in imho a formal specification language would have to dodge both of those

I'm playing with using specs to generate a project that manages itself with constructs within its own code, with the goal that there'll be a kind of "second-order" spec that is type-safe and compiler-verified. Right now it just generates its own CLAUDE.md files but it might get weird soon.

Yes, but this isn't a new thing. Moggi (I think) talked about it in papers in the late 80s or early 90s. Well-typed programs are already this way; the code is a static artifact of the program's behavior at runtime.

I think your right but it also feels like we’re not quite there yet. Or is this now your practical day to day? And if so what does that look like for you folks? Would love a blog sized expansion of this idea

We've always been spec heavy with the protocol, but now all new software projects since the start of the year have been spec first

Came to a similar conclusion, a while ago -- but specs and tests.

I'm not sure if I like it, but this sounds right.

TRUE

I feel similarly except my spec is some set of integration tests

This is the world I live in

We something more specific than gherkin but higher level abstraction than source code

Specs need to be verifiable at this stage but that probably gets relaxed in the future

If it's a library, I'm pretty interested in seeing the public API. I'll ask the AI to give me the API so I can review it before it goes to work. That seems like a pretty big chunk of a spec? In some cases, a spec might be considered the cross-language equivalent of an API.

I also think that under a certain complexity threshold, the set of prompts that created that thing are much more important than people think rn. I'm finding good, clear prompting is a challenge for some people, even some very good coders. that results in churn, 'why does this model suck now'

bsky.app/profile/jooc...