This has given really good results in terms of helping decide whether to extract these helper functions or not - they have to both be memorable enough in name and arguments that the code calling them can understand what's going on without always having to dive in, and also provide a meaningful compression of the logic above so that it can be comprehended without having to jump across many hundreds of lines.

2. Brand quality went down to equivalent or less of no-name dropshipped goods in order to keep similar dollar prices for goods.

3. Cost of real estate spiked incredibly, putting even more pressure on retail margins.

4. American logistics is seriously good, in cities 24-hour delivery can be common even for small or inexpensive things.

5. Once there wasn't a quality or convenience reason to prefer the shopping mall, many were already struggling quietly, they just hadn't run out of cash yet.

6. The pandemic happened right as all these things converged, accelerated all of them, and wasn't really recoverable.

This allows for a business model for the authors to provide contracted support for the product, and keeping SQLite as a product/brand without having to compete with an army of consultants wanting to compete and make money off of their product, startups wanting to fork it, rename it, and sell it to you, etc.

It's pretty smart and has, for a quarter century, resulted in a high quality piece of software that is sustainable to produce and maintain.

It would not be unusual for the person being told to write the process document to be brought into a room with a notebook, be shown written or electronic materials in the room, take notes in a provided notebook, have that notebook be handed over after the meeting for a (non-technical) security review, then receive the notebook pages some days/weeks later and have those notes be what is used to develop the document. Security culture is good for security but bad for error-free processes involving people.

And it turns out the quality of output you get from both the humans and the models is highly correlated with the quality of the specification you write before you start coding.

Letting a model run amok within the constraints of your spec is actually great for specification development! You get instant feedback of what you wrongly specified or underspecified. On top of this, you learn how to write specifications where critical information that needs to be used together isn't spread across thousands of pages - thinking about context windows when writing documentation is useful for both human and AI consumers.

If everyone is synced to +/- 20ns, that's great. Then when someone flies over your datacenter with an GPS jammer (purposeful or accidental), this needs to not be a bad day where suddenly database transactions happen out of order, or you have an outage.

The other benefit of building in this uncertainty to the underlying software design is you don't have to have your entire infrastructure on the same hardware stack. If you have one datacenter that's 20yrs old, has no GPS infrastructure, and operates purely on NTP - this can still run the same software, just much more slowly. You might even keep some of this around for testing - and now you have ongoing data showing what will happen to your distributed system if GPS were to go away in a chunk of the world for some sustained period of time.

And in a brighter future, if we're able to synchronize everyone's clocks to +/- 1ns, the intervals just get smaller and we see improved performance without having to rethink the entire design.

There's a ton of standardization work that really should be done before these are safe for library APIs. Mostly fine to just write an application that uses one of these crates though.

2. Can modern GPU hardware efficiently make system calls? (if you can do this, you can eventually build just about anything, treating the CPU as just another subordinate processor).

3. At what order-of-magnitude size might being GPU-native break down? (Can CUDA dynamically load new code modules into an existing process? That used to be problematic years ago)

Thinking about what's possible, this looks like an exceptionally fun project. Congrats on working on an idea that seems crazy at first glance but seems more and more possible the more you think about it. Still it's all a gamble of whether it'll perform well enough to be worth writing applications this way.

A huge amount of effort goes into just searching for what relevant APIs are meant to be used without reinventing things that already exist in other parts of the codebase. I can send ten different instantiations of an agent off to go find me patterns already in use in code that should be applied to this spot but aren't yet. It can also search through a bug database quite well and look for the exact kinds of mistakes that the last ten years of people just like me made solving problems just like the one I'm currently working on. And it finds a lot.

Is this better than having the engineer who wrote the code and knows it very well? Hell no. But you don't always have that. And at the largest scale you really can't, because it's too large to fit in any one person's memory. So it certainly does devolve to searching and reading and summarizing for a lot of the time.

It's great fun for doing signal analysis, but I'd never want to try and implement a full-duplex communication system in production with it.

It also requires rewriting all your apps.

It also might require hardware support to not be significantly slower.

"Just sandbox each app" has much fewer barriers to entry, so people have been doing that instead.

And systems like Android have been working with discrete permissions / capabilities, because they were able to start from scratch in a lot of ways, and didn't need to be compatible with 50 years of applications.

1. LLM runs using the system prompt + your input as context.

2. Initial output looks like "I need more information, I need to run "

3. Piece of code runs that looks for tool tags and performs the API calls via MCP.

4. Output of the tool call gets appended as additional context just as if you'd typed it yourself as part of your initial request.

5. Go back to step 1, run the LLM again.

So you can see here that there is no difference between "content" and "prompt". It's all equivalent input to the LLM, which is calling itself in a loop with input that it generated/fetched for itself.

A lot of safety here happens at step #3, trying to look at the LLM's output and go "should I actually perform the tool call the LLM asked for?". In some cases, this is just spitting the tool call at the user and asking them to click Approve/Deny... and after a hundred times the user just blindly presses Approve on everything, including the tool call called "bash(sudo rm -rf /)". Pwned.

2. If you are publishing research, any time spent beyond what's necessary for the paper is a net loss, because you could be working on the next advancement instead of doing all the work of making the code more portable and reusable.

3. If you're trying to use that research in an internal effort, you'll take the next step to "make it work on my cloud", and any effort beyond that is also a net loss for your team.

4. If the amount of work necessary to prototype something that you can write a paper with is 1x, the amount of work necessary to scale that on one specific machine configuration is something like >= 10x, and the amount of work to make that a reusable library that can build and run anywhere is more like 100x.

So it really comes down to - who is going to do the majority of this work? How is it funded? How is it organized?

This can be compared to other human endeavours, too. Take the nuclear industry and its development as a parallel. The actual physics of nuclear fission is understood at this point and can be taught to lots of people. But to get from there to building a functional prototype reactor is a larger project (10x scale), and then scaling that to an entire powerplant complex that can be built in a variety of physical locations and run safely for decades is again orders of magnitude larger.

(The problem of course is you still need these junior engineers to exist in order to have the next generatino of senior engineers, so we must now also think about what our junior folks should be doing to be valuable AND learn).