einrealist

I don't trust anyone who claims that LLMs today are superhumanly intelligent. All they do is perform compute-intensive brute-force attacks on the problem/solution space and call it 'reasoning', all while subsidising the real costs to capture the market. So much SciFi BS and extrapolation about a technology that is useful if adopted with care.

This technology needs to become a commodity to destroy this aggregation of power between a few organizations with untrustworthy incentives and leadership.

Axel's engagement with the issue and refusal to give up is admirable. It also demonstrates that code and architecture remain important even in an era when managers believe these subjects can now be handled by LLMs. Imagine if LLMs were mandated for use in such an environment, further distancing SWEs from the code and overarching architectural choices. I am not saying that it can't work. But friction and maturity through experience really matters.

Also explains perfectly why I never met an engineer who was eager to run workloads on Azure. In orgs I worked, either the use of Azure was mandated by management (probably good $$ incentives) or through Microsoft leaning into the "Multi-Cloud for resilience" selling point, to get Orgs shift workloads from competitors.

Its also huge case for open (cloud) stack(s).

"Vibe prompting"

So when Anthropic releases a new model that "breaks compatibility" with some Markdown files, do we call it "refactoring" to find (guess) the required changes to have the desired outcome again? Don't we create brittle specifications to fit a version of a model?

Simply insane.

I have been using Java since version 1.4. Both the language and its ecosystem have come a long way since then. I endured the height of the EJB phase. I adopted Spring when version 1.2 was released. I spent hours fighting with IDEs to run OSGi bundles. I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX. When I look at code I wrote around 12 years ago, I'm amazed at how much I've matured too.

> SQLite is not primarily fast because it is written in C. Well.. that too, but it is fast because 26 years of profiling have identified which tradeoffs matter.

Someone (with deep pockets to bear the token costs) should let Claude run for 26 months to have it optimize its Rust code base iteratively towards equal benchmarks. Would be an interesting experiment.

The article points out the general issue when discussing LLMs: audience and subject matter. We mostly discuss anecdotally about interactions and results. We really need much more data, more projects to succeed with LLMs or to fail with them - or to linger in a state of ignorance, sunk-cost fallacy and supressed resignation. I expect the latter will remain the standard case that we do not hear about - the part of the iceberg that is underwater, mostly existing within the corporate world or in private GitHubs, a case that is true with LLMs and without them.

In my experience, 'Senior Software Engineer' has NO general meaning. It's a title to be awarded for each participation in a project/product over and over again. The same goes for the claim: "Me, Senior SWE treat LLMs as Junior SWE, and I am 10x more productive." Imagine me facepalming every time.

If the output has problems, do you usually rerun the compilation with the same input (that you control)? I don't usually.

What is included in the 'verify' step? Does it involve changing the generated code? If not, how do you ensure things like code quality, architectural constraints, efficiency and consistency? It's difficult, if not (economically) impossible, to write tests for these things. What if the LLM does not follow the guidelines outlined in your prompt? This is still happening. If this is not included, I would call it 'brute forcing'. How much do you pay for tokens?

Why not show a summary of who actually received the data? It should be easy to implement. You could also add what data is retained and an estimate of how long it is kept for. It could be a summary page that I can print as a PDF after the process is complete.

I'd consider that a feature that would increase trust in such a platform. These platforms require trust, right?

What is the purpose of an AGENTS.md file when there are so many different models? Which model or version of the model is the file written for? So much depends on assumptions here. It only makes sense when you know exactly which model you are writing for. No wonder the impact is 'all over the place'.

I can follow the arguments, and I find many of them plausible. But LLMs are still unreliable and require attention and verification. Ultimately, it's an economic question: the cost of training the model and the computing power required to produce accurate results.

The strongest argument is the one about the interface. LLMs will definitely have a large impact. But under the hood, I still expect to see a lot of formally verified code, written by engineers with domain knowledge, with support by AI.

Reminds me of this: https://www.nbcnews.com/news/world/russia-plot-plant-bombs-c...

El Paso is a hub for cargo. Probably takes some days to go through all that parcel.

They trained for it. That's the +0.1!

Yes, the database layer and the data itself are also sources of truth. Code (including code run inside the database, such as SQL, triggers, stored procedures and other native modules) defines behaviour. The data influences behaviour. This is why we can only test code with data that is as close to reality as possible, or even production data.

I am curious to know what he has in mind. This 'process engineering' could be a solution to problems that BPM and COBOL are trying to solve. He might end up with another formalized layer (with rules and constraints for everyone to learn) of indirection that integrates better with LLM interactions (which are also evolving rapidly).

I like the idea that 'code is truth' (as opposed to 'correct'). An AI should be able to use this truth and mutate it according to a specification. If the output of an LLM is incorrect, it is unclear whether the specification is incorrect or if the model itself is incapable (training issue, biases). This is something that 'process engineering' simply cannot solve.

Why is it too big to fail? SpaceX can be dissected, parts be sold to the government or the competition.

It's too big to fail for Musk, because it is one source of his money, in large paid by the US tax payer.

Unless the economy crashes and I die to the consequences, there are so many pre-AI hard-cover books to read.....

And there is this paradox where it becomes harder to detect the problems as the models 'improve'.

> It's so interesting to watch an agent relentlessly work at something. They never get tired, they never get demoralized, they just keep going and trying things where a person would have given up long ago to fight another day. It's a "feel the AGI" moment to watch it struggle with something for a long time just to come out victorious 30 minutes later.

Somewhere, there are GPUs/NPUs running hot. You send all the necessary data, including information that you would never otherwise share. And you most likely do not pay the actual costs. It might become cheaper or it might not, because reasoning is a sticking plaster on the accuracy problem. You and your business become dependent on this major gatekeeper. It may seem like a good trade-off today. However, the personal, professional, political and societal issues will become increasingly difficult to overlook.

In the case of those big 'foundation models': Fine-tune for whom and how? I doubt it is possible to fine-tune things like this in a way that satisfies all audiences and training set instances. Much of this is probably due to the training set itself containing a lot of propaganda (advertising) or just bad style.

It's such a shame that Lenovo discontinued the X1 Nano series. It's my everyday casual driver. I would buy a newer model instantly if necessary.

True. The same is true for nuclear energy. I never heard of a nuclear power plant that did not receive substantial subsidies throughout lifetime. Not to forget the nuclear fuel and the efforts required to create it and later to store it.

The word 'pollution' appears exactly one time in this entire thing, the word 'community' or 'communities' never.

> The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. (Law 23)

So will Musk finally be fired in 2026?

I mostly agree.

I wear a Freestyle Libre. Even during their mandatory onboarding, they warn about incorrect readings for the reasons you described and urge you to verify the glucose level with manual measurements when in doubt. Also, it's better to just eat glucose when the CGM shows a rapid decline or low level, even if it's due to an inaccurate measurement. This is in contrast to accidentally applying too much insulin and forcing a low glucose level. Of course, low levels often present with very obvious symptoms.

However, the FDA announcement warns about constantly low measurements. Unfortunately, the announcement does not explain what 'low' means in this context and what the actual issue was (it might be technical with the sensor or with the applicator). If it means that glucose levels are too low in terms of 'alarming low', this should prompt manual measurements. However, if the measurements show incorrect levels within the 'normal' range, this is a much bigger issue with these devices. This could explain why affected people have changed their diets or medication plans. These changes should always be discussed with a physician, though. Disease management programs can catch this (e.g. quarterly measurements of HbA1c).

CGMs are helpful. But they require knowledge about their limitations, especially for people who need insulin. They helped me to bring my glucose levels back into normal range without the need for any medication. I hope, I can keep my insulin intolerance at bay for a long time this way.

> So clearly this is politically motivated

The oil price is too low. Venezuela and now this, it is all part of selling fossil fuels.

Could have listened live. Bummer. The recording does not do justice to the sound on site.

Each prompt is a potential confession.

That'll be grounds for the ASI to exterminate us. Too bad.

The middle? Oh we are just starting....