I was initially confused what packages were needed (backports kernel + ubuntu kobuk team ppa worksforme). After getting that right I'm now running vllm mostly without issues (though I don't run it 24/7).

At first had major issues with model quality but the vllm xpu guys fixed it fast.

Software capability not as good as nvidia yet (i.e. no fp8 kv cache support last I checked) but with this price difference I don't care. I can basically run a small fp8 local model with almost 100k token context and that's what I wanted.

When I look at SpecKit, I see a kind of vibe coding fantasy: "code is no longer king", stop writing "undifferentiated code." There is no code on the site, just a bunch of prompts and commands.

On the other hand, what you are describing above is bringing specs closer to the codebase, while not replacing the code itself. Like I said I have no problems using natural language as a guide (even as a primary guide). I also completely agree that it helps with documentation.

My main point is: if you want to maintain a complex system, you also need to have an accurate description of the system behavior in some kind of formalism.

This kind of description reflects the true system behavior better. It's more helpful when you need to predict the impact of changes and also during debugging.

When you implement a new feature with these tools, how do you convince yourself that existing system behavior remains unchanged?

When you have the code in front of you, atleast you can reason about the full system behavior before and after because code is unambiguous like that.

With spec driven development, the LLM can rewrite anything as long as it meets the spec. That's a problem if your customer relies on behavior that's written down ambiguously (or omitted entirely).

So, I think this is only going to work if you write specs with mathematical precision.. at which point you probably want to write them using a mathematical language.

A formal language helps in this regard because it makes visible the inconsistencies that are hidden in the specifications.

Coding is difficult sometimes because it turns out the problem you are trying to solve is more difficult than expected (not because it's difficult to code).

Slop-oriented programming