wyum

I've always thought of it as a sand mandala.

I have the same feeling when I come across a new one. It's easy to throw something together that's good enough. That's why I open sourced spekk. I don't think there's a product here, just a way of thinking and doing I want to share.

FWIW, there are about ten people using Spekk at my agency daily. The standardization across people and projects is helpful to us. It's built for teams like us, not just me. There are definitely some features that took us a few weeks to months to get right, even AI assisted, and I think that has value whether you use our tool or ask your AI to copy parts of it.

We're a small team though, so your point still stands.

I think modeling languages for code gen fall short because they aren't expressive enough and basically have to become programming languages and their users, programmers. This is the line of thinking that leads to "the specs are the code" conclusion.

I believe writing specs is different with AI for a few reasons: (1) natural language is expressive enough and the team collaborates at this level already, (2) LLMs can fill in the gaps, point out inconsistencies, and reliably map natlang to code, and (3) LLMs can read and refine specs at superhuman speeds, which makes spec maintenance economically viable for the first time ever outside of high stakes applications.

For this to work over the long run, specs must take a certain form. IMO: they must focus on original intent and what must be true after implementation (assertions) rather than implementation details. I also don't think one needs to specify anything an LLM can easily infer, so specs should be kept lean.

For spec drift, my team uses a sandboxed agent that checks for drift daily, triages, and surfaces issues. Beyond fixing specs, this has revealed a lot of product level miscommunications and helps us get ahead of them.

No offense taken. I'd also say I overthink things, so this question hits home.

The existence of similar tools has certainly given me pause several times. I was aware of SpecKit (GitHub) and Kiro (Amazon) when I started in January of this year. I Googled around and asked AI to find and evaluate similar things to my idea. Somehow I genuinely missed openspec, which seems to have had 20k GitHub stars at that time. I look at this and realize how bad I've been about sharing and promoting spekk.

I've continued to iterate on my idea because nobody else is as focused on the concept of declarative, living specifications that evolve with the code. From the beginning that has been Spekk's differentiator.

I've definitely had doubts about whether building my own version is "worth it."

Some wisdom I've gained as I get older is that the world is a complex place. There are many valid ways to solve the same problem, and every version has its audience and community.

The other thing is that even in this age of AI, putting sustained effort into a thing is still a scarce resource. The best software still takes time to mature and refine. It never ceases to amaze me how many small but important decisions and features go into what many see as "just markdown files and skills."

Appreciate the question.

Thanks for having a look!

On removing cruft: one of the key features of spekk is an "observer" agent role that is tasked with finding drift. On a production codebase, I run this daily in a sandbox. It pulls the latest changes and looks for specs that are mismatched from the implementation, preferring to look at specs and code that changed recently and prioritizing "major" drift events. The observer agent then opens a PR wkth its observations (markdown with YAML like the specs). It also posts a summary to Slack, but that's optional. The sandbox agent code is part of the spekk-cli codebase.

The trouble with AI attribution is that there are basically three categories:

1. 100% human 0% AI.

2. 100% AI, 0% human.

3. Everything in between.

1 and 2 are easy enough, but in 3 the human effort is not clearly legible or even measurable.

Agreed - we need a different designation than "co-author."

I'm not sure who did it first (CoPilot maybe?), but for me it was Claude Code that started putting its name on everything.

Advertising seems like the main reason, and maybe trying to over-anthropomorphize the tools.

Attribution as a "source" I would agree, and I used to put stack overflow links in my docstrings/comments for reference.

But I would not ever call the StackOverflow user a "co-author" on my commits.

I think that distinction matters.

I immediately prohibited Claude and other agents from adding themselves as co-authors. I have never liked this.

I take responsibility when I am driving the AI. I wouldn't call my vehicle the "co-driver," even in cruise control (or these days, self-driving mode). Yes, it's doing a ton of work for me, but it is still just a tool.

I do think it's useful to log what model was used, but not as "co-author."

Exception: if a cloud agent designs and authors a commit autonomously, then it can be the "author," if only because I want it to be clear that my hands weren't on the wheel.

I was curious why we don't hear about locust swarms anymore in the US

Turns out this species - the Rocky Mountain locust was made accidentally extinct by settlers. Although the swarms could be huge, they had a small and concentrated breeding ground that was destroyed by farming and cows. Wikipedia says the last specimen was collected in 1904.