Post

Increasingly convinced that specs are now the source and that code is an artifact akin to a lockfile.

Isolating a program from complex systems for testing is a lot of effort. Often solved with dependency injection of mocks, or exterior composition (to mocks). Mocks can drift and DI introduces codepath complexity. So: Build mock env from specs

Distributing software libraries for multiple languages is extremely costly for a software company (such as bluesky). Quality drifts between languages, maintenance burden is huge. So: Build _ API in our teams' lang from specs

17/9/26, 3:30 pm1 repost59 likes

JauntyWunderKind

@jauntywunderkind.bsky.social

you're saying we must keep regenerating our software systems? the Phoenix Architecture ideas, that specs are enduring, the code changes, sure resonate with me. /cc @chadfowler.com bsky.app/profile/chad...

Chad Fowler@chadfowler.com

@handle.invalid

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?

JauntyWunderKind

@jauntywunderkind.bsky.social

easing your platform to make leveraging shear layers (Stewart Brand et al) easier is probably required, probably something you need to get good at if you are serious about regeneration. internal simplicity seems very much not the point, that things can become weird mutants, destined to be replaced

This one might be too extravagant so we'll see, but... Writing software for each platform (native ios, native android, web, etc) is extremely costly and requires middleware ecosystems like react native So: Build app for target platform from specs

@dnf.bsky.social

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

@distributed.camp

TFW we all use IDL for specs to make ambiguities clear ftp.kaist.ac.kr/ietf/draft-f... youtu.be/fYw-0Qu0WCo

youtu.beMentat CalculationsYouTube video by Jesse Webster

JauntyWunderKind

@jauntywunderkind.bsky.social

watch out atprot, agproto (agentproto-idl) is coming! (this is my first time hearing of this: i'm just being silly. but also: neat!)

the qps on this one are pretty comical. you never know what's gonna set people off

Sam ooOOooOoo Turner

@renrut-mas.bsky.social

Your approach of scattergunning the most inane shit is a pretty solid strategy then.

@jsherman999.bsky.social

I was labelled spam for promoting this idea that the specs are the new valuable artifact. good luck in the comments ;)

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.

Oh I so want this, a static pds and a static api server that return known results and reject api calls that aren’t in a known state. And publish the JSON for both requests and responses.

@essaywells.bsky.social

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.

undefined behavior in the c compiler

@pottfrillan.bsky.social

UB in C is not "anything you *didn't* explicitly specify to work the same way [may vary]". Almost all behavior is defined in C, with a (mostly) well-defined list of exceptions. This is very different from everything being undefined unless you explicitly nail it down

@peterlewis.design

Shopify just implemented something like that

shopify.engineeringNative is now the future of mobile at Shopify (2026) - ShopifyCoding agents changed what it costs to build mobile apps twice. Here’s why Shopify is moving from React Native back to Swift and Kotlin.

Yeah. I took a run at it about 5 months ago, but didn't have time to get to (that's right!) the 2nd 80%, so I had to leave it at "promising but unproven."

The second 80% still needs someone with a deep understanding of the language and platform itself, for now. But spec and harnessing means that you only need 1 or 2 platform experts, instead of multiple teams.

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

Deterministic iOS native app -> Android native app is already possible and productionized. (I’ve shipped with it) skip.dev

skip.devOne Swift Codebase.<br>Two Native Platforms.Skip lets you write one app in Swift and SwiftUI and ship it natively on both iOS and Android.