w_t_payne

Agent-first engineering infrastructure:- The "OS" for sovereign re-industrialisation.

The systems engineering V-model provides us with a general-purpose approach to solving difficult problems. It comes with an array of proven and trusted standards and document-oriented processes.

Given the number and detail of these documents and processes, automating some realisation of V-model is almost trivial. Tools like Codex and Claude Code are hardly less reliable and trustworthy than human engineers, and the existing standards already contain ways of mitigating the impact of imperfect work performed by error-prone agents.

The generality of this "Autonomous Systems Engineer" gives it a genuine claim to be something approaching AGI. Certainly it enables us to tackle much bigger and more challenging problems than we could with only the LLMs on their own. (Yes, it's "just another harness-of-harnesses", but that doesn't mean that what it can do isn't significant).

In addition to providing automation of high-integrity engineering practices, my project also provides a disciplined communication layer that sits on top of A2A or other similar protocols, enabling small agent-first engineering organisations to exchange well-defined highly-assured documents and accelerate b2b collaboration - enabling "swarms" of small, agile businesses to take on larger and more demanding challenges than they would be able to individually.

The systemic risk is that future bans will be much broader in scope and will impact more than one US-based provider. I really don't like that we're moving into a world where heavily AI-dependent economies can be effectively shut down either by the US government or the Chinese government at the stroke of a pen. This really is a forcing function which makes us question if the risks associated with large "cloud-based" models are worth it, and if we need to find out if we can do more with smaller, local models - and whether such research is now a matter of critical national security.

We're just not that good at managing AI yet.

Current agent-based systems are little more than toys ... but this situation is improving very rapidly.

The problem is mostly a cultural one.

In my personal experience, the automotive industry has a problem with aggression and dishonesty, both of which seem to go hand-in-hand.

Both of these cultural traits tend to have a negative impact on quality and safety.

I have a general system for representing metadata in source files. (I use YAML documents embedded in block comments).

Some of this metadata gives traceability information for requirements, tests etc.. while other metadata enables me to associate a maturity level with each file.

My build system understands this metadata and uses it to inform e.g. the minimum test coverage that it expects on a file-by-file basis.

The same metadata is used to ensure that all of the other components that a file references are at the same level of maturity or higher.

I also have metadata for each file (partly derived from location in the repository) that gives each file a number which defines it's position in a hierarchy of design elements.

The position in the hierarchy helps to indicate what the purpose of the file is. I use this to make a distinction between those core, foundational, stable design elements upon which other design elements may build, and those more peripheral, ephemeral and 'agile' design elements which can be quickly tailored to meet the needs of a client or partner.

This means that a (hopefully stable) core API component can be prevented from relying upon a (perhaps less stable) bespoke customer-specific component. It also means that there's more freedom in changing and adapting peripheral designs as you can have confidence that it's stability is not something that is going to be relied upon.

I do exactly this in my side project. I have a set of rules which put restrictions on which packages and modules can be included from other packages and modules. For example, a high maturity package is not allowed to depend upon a low maturity package. Similarly, a core library package is not allowed to rely on a package that is specific to a particular product or a particular piece of bespoke development. In this way, much of the potential for circular dependencies is eliminated, and the purpose and internet is clearly communicated.

(I don't do this using sourcery though ... I have my own set of rules)

Diagrams are great for communication and collaboration with non technical experts.

Code is great for creativity and working in the flow state.

Both are useful. I'd also argue that both are necessary.

It's helpful to think of this as akin to a DDOS-like attack on the Russian internal security infrastructure.

They've only got so much bandwidth - money, personnel and time - to deal with all of the myriad security issues which keep popping up.

The more people we can reach out to, the more 'leads' the security services will have to investigate, then the less effective they will be at propping up Putin's empire of fear.

Putin holds power because everyone is so afraid. As soon as the security services stop being effective, and people learn that they don't need to be afraid any longer ... then the only thing keeping him in power will begin to evaporate.

It's more than a miniscule chance. And it's not just about the shift in public opinion. It's also about consuming the limited bandwidth that the Russian security services have available to deal with stuff like this.

Think of it like DDOS-ing their internal security apperatus.

We can allow fear to turn us all into slaves, or we can take simple acts like this to defend our freedom.

Acting together, we can reach out to hundreds of thousands of individuals. The Russian police cannot arrest all who are contacted, and even if they try, all of that time, money and manpower that they pour into policing is time, money and manpower that is taken away from brutalizing people in Ukraine.

So even if someone is arrested; even if they are imprisoned -- they can be proud to know that they have done something tangible and significant to help save lives.

Also, try to reach out to fellow technology professionals inside Russia and help them to find a way to get out.

Opportunities for technology professionals who want to escape Russia?

And a cornered rat may bite.

I can't imagine how tough life will get in Russia as a result