> AI risk is string theory for computer programmers. It's fun to think about, interesting, and completely inaccessible to experiment given our current technology. You can build crystal palaces of thought, working from first principles, then climb up inside them and pull the ladder up behind you. People who can reach preposterous conclusions from a long chain of abstract reasoning, and feel confident in their truth, are the wrong people to be running a culture.
I understand how people running in the same scene fall into the echo chamber effect and get gulped into the cult, but why does everybody want to be a prophet?
It can’t, unless you descend into sophistry. We came up with and defined the word “consciousness” specifically to fit our own understanding of the collection of behaviors we do that seem to apply only to us. What it means is based on what _we humans_ do, not something observed objectively, so it’s more like a human trait than a thing by itself that we fit into.
In the case of Claude or others, it is not just an advertisement, it's the weird shape the industry is spinning LLM-assisted-coding as a "co-author" relationship where it should be thought of more like a user-using-a-tool relationship. When you make a design with Photoshop or InDesign, it's not "co-designed by Photoshop", it's just a tool and you used the filters it provides.
It is slightly weird that people accepted this new trend just like that, probably because they think this is being transparent and wanting to give attribution, but it'd be more useful like what the Linux kernel "AI Coding Assistants" page describes, something like `AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]`, at least we get to know which model was used and/if any additional tooling on top. And `Assisted-by:` is more appropriate for that purpose than `Co-authored-by`.
Everyone is trying to figure out how and what are the optimal use cases. It could be like you said but it doesn’t have to be. There’s a lot of incentive for it not to end up like that.
For now it’s the exact same reason why you’d use Python when you’re writing by hand: so the code is more easily readable/editable by humans who are more likely to know Python than something like Zig. But I understand the point the post is trying to make, I don’t think we’re there yet.
Humble mention, I’ve been thinking the same thing with Ossature for the last couple of months since I started working on it: https://ossature.dev
The models are already good enough for code generation. What we need is the harness around them actually deterministically enforcing a specific path and “leashing” the models output to be aligned with the intention of the user as much as possible. You can’t make the output of the model deterministic, but you can make everything around it to be so.
Trying to make enforcements work with prompts is like a government agency investigating/auditing itself, there’s no incentive to find problems, so you’ll always inevitably get the “All Good, Boss!”
I wrote something similar recently about how agent-generated code lacks the institutional memory that human-written code has. There's nobody to ask why a decision was made (1).
“Specsmaxxing” is basically the right response to this. When you can't rely on authorial memory, you have to put the intent somewhere durable. Specs become the source of truth by default if we continue down the road of AI generated code.
The title of the article is more on the sensationalist side unfortunately, the actual paper gives a different view [1].
There are two parts worth quoting:
> Although cortical reductions sometimes reflect a process of neurodegeneration, they can also be a sign of refinement and specialization of neural circuits. Adolescence, for instance, is a life period characterized by the continued elimination of redundant synapses (i.e. synaptic pruning) which parallels cognitive and emotional development (Selemon 2013). In the context of the transition to parent-hood, several examples across human and non-human mammals show functional improvements after reductions in brain markers (Pawluski et al. 2022).
And:
> Although we found converging evidence of cortical reductions
across the two samples, a number of divergent findings also emerged. First, when disentangling the cortical volume reduction, Californian fathers displayed significant reductions in area and Spanish fathers in thickness. Changes in the area may reflect changes in the number of cells located between radial columns of the brain, while changes in thickness may reflect changes in the number of cells within ontogenic columns (Petanjek et al. 2011). Secondly, the volume of the dorsal attentional network, which supports goal-directed attention, was significantly reduced in Spanish fathers, while it did not show significant changes in Californian fathers. Combined with the default mode network,
this network may control sustained attention (Spreng et al. 2010, 2013), a behavior that is often required during childrearing. It is possible that these inconsistent results at the statistical level
may be due to the different scan timing windows or to cultural or behavioral differences. For example, due to more generous paternity leave policies in Spain
Exactly this. The audit pass in Ossature is specifically for that "unclear spec" case, you resolve ambiguities in the spec before generation starts rather than discovering them mid-conversation and losing them the next session. Once the plan is clean, the LLM never needs to ask a clarifying question. Memories and agent files are patching over the fact that intent was never properly captured to begin with.
Allium looks interesting, making behavioral intent explicit in a structured format rather than prose is very close to what I'm trying to do with Ossature actually.
Ossature uses two markdown formats, SMD[1] for describing behavior and AMD for structure (components, file paths, data models). AMDs[2] link back to their parent SMD so behavior and structure stay connected. Both are meant to be written, reviewed, and/or owned by humans, the LLM only reads the relevant parts during generation. One thing I am thinking about for the future is making the template structure for this customizable per project, because "spec" means different things to different teams/projects. Right now the format is fixed, but I am thinking about a schema-based way to declare which sections are required, their order, and basic content constraints, so teams can adapt the spec structure to how they think about software without having to learn a grammar language to do it (though maybe peg-based underneath anyway, not sure).
The formal approach you describe is probably more precise for expressing system properties. Would be interesting to see how practical it is to maintain it as a project grows.
All three of these are real. The audit pass in Ossature is meant to catch the first two before generation starts, it reads across all specs and flags underspecified behavior, missing details, and contradictions. You resolve those, update the specs, and re-audit until the plan is clean. It's not perfect but it shifts a lot of the discovery earlier in the process.
The third point is harder. You still need to know your tooling well enough to write a spec that works with it. That part hasn't gone away.
Very much the same thinking. Ossature already structures work that way at the plan level during audit, so curious to see where you take it. Happy to share more about the TOML approach if useful. Feel free to reach out (me at my domain)
The hierarchy you describe (intent -> plan -> code -> tests) maps well to how Ossature works. The difference is that your approach builds scaffolding around Claude Code to recover structure that chat naturally loses, whereas Ossature takes chat out of the generation pipeline entirely. Specs are the source of truth before anything is generated, so there's no drift to compensate for, the audit and build plan handle that upfront.
The judge finding is interesting though. Right now verification during build for each task in Ossature is command-based, compile, tests, that kind of thing. A judge checking spec-to-code fidelity rather than (or maybe in addition to?) runtime correctness is worth thinking about.
You framed it better than I would. The part I'm still working through is making re-planning feel cheap when specs change. Right now if you change something early, downstream tasks get invalidated and the cascade isn't always obvious. Ideally when the project gets built, and then specs change, nothing of the generated code should change if an irrelevant part of the spec changed, this is a bit harder to do properly but I have some ideas.
I agree that, this is what makes it not waterfall. You're iterating on the spec and not backtracking from broken code. The spec is the "source code", replanning and rebuilding is just "recompiling".
Right, the spec/build separation is exactly the idea and Ossature is already built that way on the build side.
I agree a dedicated layer for intent capture makes a lot of sense. I thought about that as well, I am just not fully convinced it has to be conversational (or free-form conversational). Writing a prompt to get the right spec change is still a skill in itself, and it feels like it'd just be shifting the problem upstream rather than actually solving it. A structured editing experience over specs feels like it'd be more tractable to me. But the explicit vs inferred distinction you mention is interesting and worth thinking through more.
> AI risk is string theory for computer programmers. It's fun to think about, interesting, and completely inaccessible to experiment given our current technology. You can build crystal palaces of thought, working from first principles, then climb up inside them and pull the ladder up behind you. People who can reach preposterous conclusions from a long chain of abstract reasoning, and feel confident in their truth, are the wrong people to be running a culture.
I understand how people running in the same scene fall into the echo chamber effect and get gulped into the cult, but why does everybody want to be a prophet?