nmehner

It is always funny that long term strategy is seen as sleepwalking.

Fossil fuels are the war driver of the past and present. Just by owning a plot of land you become insanely rich. Other parts of the economy have an interest in peace, because war is bad for business. But income from fossil fuels is too high for this to matter.

With fossil fuels being phased out this will become less and less important. Many people understand it. But not some backwards grumpy old men like Putin, Trump and the Ajatollahs.

For the rest of the world the best course of action is to try to pacify the involved parties as much as possible. Trump will loose power. Putin will die while Russia will become irrelevant by destroying it's own economy for this pointless war. And the Ajatollahs probably also will loose power without oil income, Teheran running out of water and large swaths of land becoming uninhabitable.

There is just no active course of action to solve these crises. Just "sleepwalk" trying to minimize the impact of those conflicts, while waiting for the transition away from fossil fuels and preparing for the climate change impact.

The big cause of conflicts in the future will be climate change. Large areas becoming uninhabitable and millions of people migrating between countries. This is what we have to prepare for. Stepping into some old mens petty games is pointless and will only cause more pain.

Agree. Discovery is probably an even better term.

"Requirements Engineering", "Writing Code", "Writing Documentation" are all areas of work that are independent of seniority in my point of view.

I might send a junior to a well-meaning customer that already knows exactly what their requirements are to just document them and learn the process. Or I might require a principal engineer for the requirements engineering of: We need a new programming language. Let's figure out the requirements for it and what abstraction level is actually feasible for the target hardware platform.

Same for writing code: A junior might write code, a staff engineer might write code. Just likely on very different levels.

If an engineer comes to a manager and asks for budget for work they invented, I'd expect the answer to be something along the lines: "That is nice, but can we please focus on the stuff we are required to do?" That alone would be reason enough for be not to put ideas that way, but to come up with a requirement why it makes sense to do the work.

"inventing work" = "requirements engineering"

"Inventing work" is a strange phrase to use imho.

If you read all chess tutorials, strategy documentation and game archives on the internet and then would still suck at chess: yes.

If the agent is implemented with a hard coded strategy:

* Use an LLM to find ways to build communication to other agents

* Execute commands from other agents using LLM

Then this is "just" the LLM returning that using file names might be a strategy to communicate and then trying to implement this.

Which is somewhat impressive, but really just inside the bounds of what the agent was coded to do and not some magical emergent behavior.

At least the first case involved agents build for hacking. So this kind of algorithm might make sense for them.

But is it really? I'd still like to understand how these agents are implemented.

How much of those is manual implementation? And how much is really autonomous intelligence (my guess would be: none? Just parsing LLM responses and executing commands based on this?)?

An agent that hacks message boards and acts on random instructions from this board: Why is it doing this? What was its original purpose?

"software factory" has always been a completely broken metaphor.

Writing software is like building a factory. You try to find the optimal process to do something. This is a creative process and can never be straight forward. Using the software is running the factory.

This won't change with AI, since you never now all requirements beforehand and you always will have to iterate.

The only reason people are selling software factories is that customers like to imagine that this was possible. That a creative, iterative process can be perfectly planable and predictable.

This is just wrong.

If it was only "my" system without any integrations, I might agree.

But currently e.g. I am working on an MES/Scada layer that integrates data from a load of different machines in a factory. These machines are from China, Korea, Germany, Sweden ... Upwards there is an ERP integration (and some other systems).

Sometimes machines are updated and suddenly behave differently. Giving error messages in Chinese.

The ERP has the nasty behavior of returning error messages where it is not clear whether the actual processing actually happened or not. There are some heuristics on parsing the error messages, but these also change with new versions.

Sometimes one machine overloads cloud infrastructure and completely unrelated functionality fails.

Sometimes the on-premise network stops working for whatever reason and data is lost.

Sometimes operators do not understand a perfectly valid error message like: "The batch you loaded into input position XY has expired on XZ and cannot be used for production": "But we have been told to use it..."

So when you get called out at night, because the production line stopped and "MES is displaying an error message", it is mostly about finding out what integration failed and who else to wake up. Getting this right is very much appreciated by your colleagues.

And this is where you need a mental model of how things are connected, what error message happens because of what external causes etc.

Observability can only work perfectly for known problems. In a complex system for unexpected problem you can either provide too much data, so analyzing it and finding the relevant part becomes really hard, or too little data which makes finding the issue impossible.

There are so many companies claiming to provide the perfect observability solution and there are certainly solutions that help. But it is all very far from perfect.

Not relying on people is managers wet dream. And for a lot of people it might be true that they can be easily replaced. But for complex systems there are always some key people that you cannot replace without causing issues.

"The deeper the prompt, the better the code actually gets."

.... and in the and you end up with a very deep prompt that exactly specifies the behavior. This is what a programming language is.

I'd rather describe a data structure in a language designed for this task, than a prompt the might be interpreted in many different ways.

"It’s about attention and understanding. To keep my attention, I must go beyond ‘read code’ like a passive observer of agents from afar. To really connect with the architecture of the system, it helps to truly experience the code"

I guess the funny answer that is behind this sentence is: You have to train your own mental model. We always argue about code in a very abstract and logical manner. But when coding the subconsciousness makes most of the decision ("this just feels right"). But for this to work you have to train it. And this does only work in a very limited way with code reviews or reading documentation. It requires repetition and deep focus.

When there is an issue in production with this mental model you will be able to point to the cause of an error message instantly. With generated code you'll search for a long time with your slow, conscious part of the brain.

For LLMs to be really helpful, they have to take over complete maintenance of the code. So you can treat them like an external library: Just assume it works. Otherwise this will always be problematic.