stcg

I don't know, but there is a small market for something similar: taking older cars (often oldtimers) and building in a new electric motor. My guess is that those cars will have little privacy problems.

I would love new open source cars by the way, that would be really cool

Exactly, it's just unfamiliar to most people.

I find Clojure (a Lisp) more readable than many other languages. It's the style I like for pseudocode. Because I used it a lot. It's familiar.

"Easy" is relative and doesn't mean anything without a subject. Easy for whom?

> proxy SDK monetization

Wait what? I never heard of that. I call that a botnet

Fun read! I love the depth in seemingly superficial texts. Sometimes I similarly ponder claims or questions in advertisements.

> Oxiis is a universal, friction-drive motor system that transforms any conventional bicycle into a smart e-bike. Its name fuses the Greek Oxis (agility) and Axis (pivot)—perfectly reflecting how its high-performance drive core delivers ultimate acceleration and instant, nimble responsiveness right to your ride.

This sounds like LLM-generated to me, but I find it difficult to point out why.

I have a similar experience with GPT 5.6 sol.

Nowadays I often prompt like "I heard there is also this different direction, what do you think about that?"

Another thing I do is asking the agent to make a decision matrix for choices. It's useful to discuss, give feedback on, and signals that it's a discussion, not a request for a particular direction.

It's then also easy to say: create a prototype for multiple directions so I can compare the solutions.

That way I choose the problem, I choose the solution, but the agent can help me discover solutions, make tradeoffs visible, and implement solutions.

That is also what I do now (both with NixOs and Guix Os), both for personal computers and for servers.

- I inspect the agent's changes, and only apply them - at once - if they are OK. So I have no half applied bad changes to my system, and I can catch critical mistakes before they are applied.

- I can roll back the changes by just doing a `git revert` and reapplying

- The agent cannot read secrets or unrelated data, just config.

- The agent gets the full configuration of all systems at once, without having to maintain parallel documentation (which can get out of sync) or rediscover each time from scratch (access my running systems, for example with `ssh root@server`).

- It's harder for the agent to miss some aspect of the configuration, because it's all in my dotfiles. If it's not there, it's nowhere

Yet another case of mistaking price for value.

When evaluating whether public money is well spent on education it must be more important how valuable it is to the public, not what the price for the work is to the individuals.

I like the "what if these workers stopped today" test:

Pick a profession. For example pick from 'trader', 'dentist', 'cleaner', 'sales person' or 'nurse'. Then imagine that all people in that profession stop working today.

How bad would it be for society? Is it better or worse than some other profession? Compare this to how well-payed the profession is.

I think this is a much better test for value to society than looking at what people get payed.

For example, I think it would be much worse if all nurses stop working than if all bankers stop working. Yet bankers tend to get paid more.

I like the word "botspeak".

Another example of typical botspeak is "smoke test". Why not just say "test"? It feels like a way of downplaying the ability to detect problems.

What makes you think it is slop? The emdash?

A letter from me addressed to the agent, describing me and the goals of the project. Not AI-generated, no code or commands.

Nothing specific to the technology, because that gets out of sync fast, or might steer the agent in the wrong direction.

Smart models can figure these things out themselves.

If for example the agent repeatedly wrongly guesses the command to run tests, I prefer to change the code so the wrong guess will actually work the next time. Or I will find what in the project lead to the wrong assumption and fix that.

This is like saying "A slow leak is cheaper than a burst pipe"

Yes, okay. But with both you will have a bad time cleaning up.

There is a third option: good abstractions.

I did see this pattern described in the blog in practice a lot (and fell victim to it myself) and I think that in general this comes down to inexperienced programmers. Object oriented programming makes it worse.

Teaching these programmers that they should not abstract is not the solution. It is blocking their growth.

Teach them how to make better interfaces instead.