The way I think about it is that building something truly successful comes with a tremendous amount of momentum. So much momentum that growth for these companies still occurs.

The people hired into a mature organization are literally there just to keep the lights on and let the momentum do its work. They also create and grow their little fiefdoms.

You can try and build something and innovate there, but it takes a deeply concerted effort to try and sustain it. Even if something is made wildly successful and is growing 50-100% year over year, it still likely pales in comparison to the 0.005% growth of the large core business.

Even if the new innovation is given space to breath, it can be killed at any point by the core business as the fiefdoms look over and say: that should be part of my org, or those resources can be better spent on the core business. So instead of waiting the years it takes for the new, small thing to grow large enough to be important it is easily killed by the parts of the organization just keeping the lights on.

That said, the final point is one I take issue with:

> For example, I’ve got these color-changing lights. They speak a protocol I’ve never heard of, and I have no idea where to even begin. I could spend a month digging through manuals and working it out from scratch—or I could ask an LLM to write a client library for me. The security consequences are minimal, it’s a constrained use case that I can verify by hand, and I wouldn’t be pushing tech debt on anyone else. I still write plenty of code, and I could stop any time. What would be the harm?

To me, there is no intrinsic value in solving this problem other than rote problem solving reps to make you a better problem solver. There isn't anything fundamental about the protocol they've never heard of that operates the lights. It's likely similar to many other well-thought out protocols in the best case and in the worst case is something slapped together.

There are certainly deeper, more fundamental concepts to learn like congestion control algorithms in TCP. Most things in software though are just learning another engineer's preferences for how they thought to build something.

I poke at this because if an exercise only yields the benefit of another rep of solving a problem, then it holds less water to me. I personally don't think there will be fewer problems to solve with this technology, just a different sort at a different layer of the stack.

It's built using biscuits and written in rust. I'm really into it. Using capability security as a model makes building things feel like they snap together a lot more naturally. At least for me.

I've also got a blog post describing it in more detail: https://www.hessra.net/blog/what-problem-led-me-to-capabilit...

There's an interesting aspect to the LLM debt being taken on though in that I'm sure some are taking it on now in the bet/hopes that further advancements in LLMs will make it more easily addressable in the future before it is a real problem.

To try and give an example, say that you want to make a module that transforms some data and you ask the LLM to do it. It generates a module with tons of single-layer if-else branches with a huge LoC. Maybe one human dev looks at it and says, "great this solves my problem and the LoC and verbosity isn't an issue even though it is ugly". Maybe the second looks at it and says, "there's definitely some abstraction I can find to make this easier to understand and build on top of."

Depending on the scenario and context, either of them could be correct.

I am curious why the author doesn't think this saves them time (i.e. makes them more productive).

I never had terribly high output as a programmer. I certainly think LLMs have helped increased the amount of code that I can write, net total, in a year. Not to superhuman levels or even super-me levels, just me++.

But, I think the total time spent producing code has gone down to a fraction and has allowed me more time to spend thinking about what my code is meant to solve.

I wonder about two things: 1. maybe added productivity isn't going to be found in total code produced, because there is a limit on how much useful code can be produced that is based on external factors 2. do some devs look at the output of an LLM and "get the ick" because they didn't write it and LLM-code is often more verbose and "ugly", even though it may work? (this is a total supposition and not an accusation in any way. i also understand that poorly thought out, overly verbose code comes with problems over time)

We've built a new auth platform with some new identity primitives and capability-style tokens using biscuits.

Right now, I'm trying to figure out ways to apply it and am looking into offering integrations with extremely fine-grained access control that wouldn't have it otherwise. So adding a fine-grained access layer in front of stuff like backend-for-frontend (BFF) systems, brownfield stuff with poor auth, or even OAuth stuff that just have really coarse scopes.

Are there any integrations out there that people want but the access control is bad for them? I'll build one for you!

It's a full identity and authorization platform targeted for service-to-service use cases. But my focus the last couple months has been to make provisioning identity super easy, and I think I've done that (at least compared to something like SPIRE).

So if anybody has CI/CD pipelines, AI agents, edge-functions, or multi-cloud workloads they want to give auditable identity, I can help!

This post proposes a simple model based on where identity originates (self-proven / attested / asserted), what privileges it has at birth, and how it lives over time (disposable vs durable). I’ve also mapped common systems like SSH, SPIFFE/SPIRE, API keys, IoT, and AI agents into it.

I’d be very interested in counterexamples, ways this breaks down in real systems, or prior art I’ve missed.