mrbnprck

Finally a readable README!

thats why pr size needs to stay scoped

Actually you do have to store those, as proof (but MUST be destroyed after 10 years). This is very typical in AML (Anti Money Laundering) laws.

Good thing there's, at least EU wide, EUDI (EU Digital Identity Wallet) around the corner which legally allows using cryptographic proofs instead of just storing as much data as possible of the user.

This addresses exactly this issue of having to disclose this amount of information solely as proof.

true, its much rather a "play out"

Feels a bit like the eletricity outage in spain where people had a brief moment where they actually got off the internet phone and enjoyed real-life.

Take a look at openrouter there are a few alternative deepseek model providers that follow an even cheaper pricing strategy.

Funnily even if deepseek themselves increase price 2-3x they are still more affordable.

not to forget the cognitive strain of the constant back and forth between LLM and you.

One challenge is when knowing how the code should look like, the LLM solution always looks weird, and one tries to maunally steer against it, so accepting a bit of "good enough" is unavoidable to gain some productivity

Tend to adopt RFC standards for specs, works pretty well. My general rule of thumb is describe scope/concerns/interfaces at a high level, details at any wanted depth. That makes the LLM generated code reasonably stable and bounds it to a clearly defined boundary. Whatever ambiguity is left in details is then treated "expectedly unstable".

we all do

There already are use-cases for automatic software deployment where monitoring is ingested back to the AI, which then judges to rollback/fix a feature if certain metrics spike/user complaints arive.

If you had the data basis (user reports, trends, ...) you could let the AI decide upon that what to build.

You mean RFC? ;)

I'm writing the specs by hand.

The LLM solely helps with research and retaining the normative document layout (RFC 7322).

Since the spec grounds the underlying implementation I have to fully understand it, writing the spec manually prevents infecting the spec with the typical LLM specification slop.

When writing the specs, the goal is to systematically keep the right balance between scope and depth:

- Scope takes the most effort because it's the only thing preventing the model from escaping an intended boundary, that includes things like stable constraints/interfaces/data models

- Depth is something where I can tolerate "non-normative" interpretations by the LLM. Unless I need a stable implementation, I can decide how much I manually invest into depth vs. letting the model figure the "good enough" solution.

Since the scope/boundaries are explicitly set, the internals are pretty encapsulated and the model comparing an implementation with the spec can identify the "non-normative" pieces and communicate those to me. Then I can decide between "good enough" or to refine these non-normative implementations and make them normative.

From my various experiments the spec vs. code ratio is roughly 1/8.

Isn't maintainability mostly about applying basic engineering principles e.g. separation of concerns, single responsibility, dependency inversion, open-closed etc..? If these topics are addressed in the normative representation, and correctly translated by an LLM into code (especially by slicing up the specifications into measurable outcomes to set the intended foundation), then future change e.g. maintainability becomes essentially easy as well, no?

Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.

Yes, actually that's what I'd had argued a few years ago as well.

It turns out that there are now a few more people that want to get their hands on building software, that don't necessarily understand code, but do have a fundamental idea of system design / requirements.

As you said code has always been a much more explicit representation of those specs, yet arguably introduces lots of noise, necessary to make the program compilable.

Us devs already had the obligation of writing technical documentation for non-technical people, just not at an explicit depth. From an efficiency PoV making that documentation more explicit is much cheaper than manually writing the compilable code. Hurts to say but AI got pretty good with the latter.

I've recently started experimenting with grounding LLM driven implementation/verification on RFC based normative specifications, to avoid having to manually steer the LLM during implementation and dealing with reviewing sloppy pull requests.

It works quite well, as it puts your entire focus on writing (hopefully) unambiguous specifications vs. having to discuss unwanted changes with an LLM during code-review. One flaw is that this only works great if you know exactly what you want, which is not always the case.