Gotcha,

But this means we need to provide not only the same query (and be sure that the tokenizer is the same) but also provide the seed for the number generation. In this case we will have a deterministic outcome. (Unless we provide the list of numbers used, which for me feels wasteful)

But at this point none of the providers have this feature.

And I don’t think the open source have this also. But open source can be updated/changed.

No, the random part happens in the query.
There is also random in the training, but the query also generate more random numbers.
Otherwise this would be a deterministic procedure, and it’s not.

So you are suggesting that we should have the metadata for every decision and direction. This is a N^N amount of data. Keeping this data is wastefull (even more than the usage of LLM right now). Not saying that is is useless, but for sure this won’t help to mitigate the cognition since this data don’t carry meaning for us humans.

[…] can’t LLMs solve the cognitive debt problem better then people? […]

Better, probably not. And I’ll give you one example. In a codebase there was an issue with Auth, after few runs of the LLM, the best suggestion resulted in 30~40% of change in the Auth workflow.

Took me a couple hours to figure out that the problem was a misconfiguration key (camelCase to snake_case in the vault store). Fixing this on the store (not on the code) fixed the Auth workflow.

This two hours were the cognitive debt. And keep in mind, I’m familiar with this part of the code. A Mechanical Parrot happy-trigger boyz would accept the change in the codebase as an attempt to fix it.

So, mechanical parrot can help? Sure. But better than people, probably not. At least not yet, not with the current set of tool, not with the promise of fully solving it.

[…] exact input and node activation is all you’d need for forensics, the only reason to refeed would old input plus new input mix, […]

This is badly wrong. The same node can point to multiple places depending on the K factor on this. And this isn’t even the T applied to it. So, the same node can infer multiple different others. This is the nature of the probabilistic of LLM.

First, I’m sorry. I attribute LLM use when I had only suspicions about it. And this is on me. If you weren’t using LLM for the message, this is on me.

This is where the open spec tries to help/solve […]

I’m interested in open spec since reading your article. I wasn’t aware before. […]

This is a derivate methodology from the SpecKit (which is a piece of crap, stay away from it). It helps to certain points, but this is still bandaid in it. Not a real solution.

It depends what you think is large enough. I work in microservices where the effort […]

Looks like we work in very different kind of projects. I’m used to jump into garbage projects to fix it. Often the projects that other people tried to make something new and fumbled so hard that the company owner had to buy my labour and knowledge to fix the shit.

Yet, microservice is the point were LLMs fails the most. Not having the full context of other services and without the good test case for it, the product will be fated to fail. So I think you may not have a full cycle on the software development, the green field is always easy, and this wasn’t never the problem.

Look on the history, the first months of a product is always the most productive (way before any LLM would ever exist), the real issues appears years in the development, when the cumulative decisions start to group and becames a problem, where every new change breaks other. The technical debt that I spoke in the article.

This isn’t on the first week of the project, this is years in it.

In short, microservice is already a bad design for most of products, very few products require to be microservices, and combined with the LLM lack of view on the product as a whole makes this even worse. So I would suggest you to validate your own assumptions on the topic.

There is a good chance that you are either not fully validating, or not seeing the product as a whole.

Wrong, from the experiments on the academia, […]

I challenge this notion. I have real, measurable productivity gains of 20-30% which […]

But I think you missed my larger point, which was that the developers […]

That’s very funny. The same academic research who found out that the usage of LLM delayed the deliverables in ~19% had a section where the developers using the tool thought (wrongly) that they were ~25% faster.

You are only proving the paper.

Regarding the idea, I’ll think about it (like I always do), but making shorter text will not make my style. When I’m reading blogs I’m looking for the similar size text, this usually fits in the commute time, have a deeper conversation/meaning.

Again, thanks for reading.

I’ll be honest, I had to look on the dictionary to understand this subtle meaning.
Thanks, I learned a new thing today! :D

But in the days of old, the replacement of human, or generation of domain/tribal knowledge were in the range of human capability to learn the new parts of a system.

With the LLM of today this scale is far flipped on the wrong side, and no product fully LLM will be manageable in a few years.

Hey there! Thanks for the comment, and reading it.

I know that sometimes hearing the same voice speaking on the same topic can be problematic. But on the other side of the same coin, have fewer voices pointing to the problem is also a problem. For me, writing the blog is a way to organize my own mind and be able to create a reasoning on some topic.

And sometimes, repeating the echoed words that the industry is repeating.

Either way, thanks again for reading, and even more for the comment.

Wooow, this message is as long as my post, love it!

The interesting thing to me is that, in order for an LLM project to be successful, […]

This is where the open spec tries to help/solve. But this is a bandaid. Without a lot of hand-holding the models will make shity decisions/code. And this is cumulative, the more you try to steer the wheel, the worse it gets. I can specify details, but a 3 years old project is in this shape, and no amount of LLM will solve/help.

The beauty of that model is that you can be 2/3 of the way through a project, […]

I understand this point, but it’s flaky at best. To be honest, with a large enough project a decision will take longer, if not impossible in a LLM driven codebase. It will be years to debugging, breaking down and rebuilding to even get close. Or spend the paycheck of 5 engineers annually for a single migration.

And this considers the the current LLM are heavily subsided.

Now, with a real developer, they eventually build their own cognition and their own mental […]

Wrong, from the experiments on the academia, we get the fact that engineers with AI are often slower, because the problem was never in the code, code is the tool, it was the acquiring the right data, model and get the knowledge of the product to make the changes needed.

Presentatio […]

I try to keep around 1.5k to 2k words a week. It’s not always the case, some weeks I’m somewhat more inspired, sometimes I need some refinement, but this is a personal view, I want the reader to have a “conversation” with the author. This is the type of metaphor I try to use.

Either way, thanks for reading.

Ps.: Do you always use LLMs to write your messages? I would love to read your own words. Don’t be the meat proxy for the LLM.

I think I got your point.

But if a system is done in a proper secure way, and does have the proper audits, this won’t be a problem in my humble view.

Voting online does carry a different problem, the anonymity problem. If the vote is open and visible to everyone, online voting carrying a CitzenID + Hash from a user focused device, should be enough. Of course this would still bring other problems

(multiple devices for the same person, or old devices trying to mimic a user… there is plenty of problems, mostly a business problem, not a technical one)

In my blog post I describe a similar flow for data access that follows similar steps.

Looks like we were thinking on the same path.

Usually done with a government issued ID, which wasn’t digital, the moment it is digital how to prevent from being used (the information) without your consent?

I understand the feeling on the dictatorship view of the things.

The problem, in my perspective is that, the wrong set of people (aka.: big tech) already have this data, if not even more than data, or the private surveillance companies (aka.: pala||n%t65||) have this data.

This is where the danger lives. This data can and will be used for profit. To pray on the small guy, to make life of the common worse.

I know that the regime in some countries (like US), trusting the government is hard. But with the right set of audits, encryption and some push from the people. Data can be secure and private store. And only with the permission of the owner of the data provided to the right person, for the right amount of time.

Just to be clear, I know this is mostly wishful thinking, and utopian view.
But we need to start in some point this change.

I agree, on the past […]

This, to some extent, already exists as law in the US. In some jurisdictions, the OS must soon request the age from the user and provide it to some applications. It’s not verification though, or at least it’s not required to be.

Sadly the regime in US is kind of crazy right now. So the trust in the government is degrading, and maybe can be recover in the next decade. But for sure change is needed, on the age verification also.

But I think that age verification should be a device level API, and this follows to the next…

Linux users could simply add a simple form with “I was born 01-01-1900” […]

This started a whole war over systemd even adding a field for it (not a form). If they added a required form, it would probably start WW3.

Linux is a unique case, while they are open, flexible and easy to make your own distro, this also implies that a public distro should implement this API, and since this API is on the OS not on Kernel. Which means people fighting, but they can just ignore this API and make it return false to any and every request.

While distros like Ubuntu and maybe Fedora would follow (providing the baseline for the dependent distros), so they can also add a third-party validation layer, which also can be replaced with the government, or a fake one that always says that you are over 99 years old.

Truth to be told, this is a band-aid on the storage and ownership problem, the focus of the post. With the correct layer the OS can keep your “age” with a lease, and you on your phone can use the app to renew the lease whenever you need.

Again, this isn’t a perfect solution, I would even call it a solution since it have so many holes in it. But it’s the point of the conversation.

But on the MicroSlop, Gargle and iPear worlds, […]

No thanks. I’m not validating, so I’d be picking up the next Motorola phone with GrapheneOS on it instead.

Hell yeah!
Totally, and with fake API’s to make every page guessing my age wrong! This data sucker can suck my…
Jokes aside, I’m with you on this one, let the OS choose, even if this is just a form with “Birth” field and let the government verification as a different problem.

Like I discussed in the post, the moment you have heavy fines for keeping illegal data, and requires the user to take action to lease the information, we will start to notice how much data these big-tech have on us.

Ps.: Thanks for reading the post and following on the conversation.

I agree, on the past I had a proposal that the OS should have a device level API to provide this information, in this case apps and (the browser as an APP) would be able to consume this information from the device. And it’s up to the device manufacturer (or the OS installed) to add a age system.

I not denying that there is holes in this idea. Linux users could simply add a simple form with “I was born 01-01-1900” and everything would continue the same. But on the MicroSlop, Gargle and iPear worlds, they would be able to validate once and keep the information on the device. And each webpage, app and such won’t be able to ingest your personal/private data.

On this post, I do explore little bit this, but I do focus on the idea of storage and access of data.

Did you read the post?
It’s not that. It’s clearly a distrust (which is also part of the post).
But the problem with trust can be solved with “how to access data”.

Edit.
Since you clearly didn’t read here a snippet

[…] if you don’t trust the government, the encrypted data is useless to the government, and we can audit it, including audit by private companies. So even if we don’t trust the government, it can work.[…]

[…] If a company can’t store my personal data, how can they access it? […]

If you don’t trust, that’s fine. This is good. Government should be transparent, and should be auditable. To be honest we have close ideas, and we want the same thing (I guess), privacy and security for our data.

(and keep our data away from datahouses and bigtech)

That was a little bit agressive. I’ll give you the opportunity to learn from your mistake and discuss what bother you in this blog post.

My problema isn’t the age verification, but the privacy. But how to solve it the age without leaking data to third party servers?

Funny that when it’s a Chinese company, it’s bad. When it’s USA company, it’s creative use of AI.

This is a freaking good read.