MykolaFedurko

LIFE — Living Infrastructure, Forever Evolving

It's alive. Giving AI a body and an environment.

  • AI
  • Infrastructure
  • Software architecture
A modular service inside a feedback loop, with an orange replacement module and olive input and output nodes.

I was recently vibe-coding life-savers for me, my family and my friends. First there was hermes-mesh for syncing my AI minds across my machines, then I developed Homelander to automatically apply for apartments for my friends, and just now I developed an internal medical admin system for my family. I delegated most of code-writing. Instead I spent most of my time specifying, debugging, testing and all that fun stuff.

And while I was arguing with a soulless machine for a month or two for it to get me right, it was pretty OK — at least now I would release the tool and go about my life. But as we all know, software is never ready. It is very hard to develop a thing that will stand the test of time.

Imagine how a developer of your favourite programming language thinks: it is a different time horizon. You want to develop a language that could still be used in 100 years, and you need it to be backward compatible, stable, predictable — all from the comfort of your own time, now.

But proprietary developers care too. Why would you enable a subscription to your service? That’s right, everybody wants endless money; greed is good and all that. Keeping those subscriptions also means keeping the software useful: earn an audience, beat competitors to the punch, and make sure it stays that way.

But the world is changing and you need to change with it, including your software. Heck, even a math library from 10 years ago may need maintaining. The math can stay the same for centuries, while compilers, platforms and dependencies move underneath it. What can one say about software whose users keep changing their minds? Code is part of the infrastructure you want to at least keep working at the same level.

But why is the world changing? What happened, I voted conservative. To keep a long story ultrashort, I like to think of it through the second law of thermodynamics - the world is getting more chaotic by the minute. And we as life (sorry for the spoiler) spend our existence keeping our little corner organised. We don’t escape the law — it’s like picking up trash in your house and throwing it to your neighbour. But we are pretty good at keeping our room clean. For as long as we live.

So while we wait for the heat death of the universe, at least we can have a good time! And this good time involves maintaining our software. The number of times somebody reached out with a complaint after I wrote Homelander, or my parents got me reconsidering my choices after I gave them the tool, is wild to me. I would do it again nonetheless. But the thing is — I grew old and tired from this.

So I plan on pursuing a much less ambitious goal - something that AI has proven to be very good at - managing infrastructure. That is weird, right? If code is infrastructure and AI is good at maintaining and evolving infrastructure, why is it bad at maintaining code?

We need to find the body

I hear more and more voices arguing for another approach towards AGI. Cheston Tan and Shantanu Jaiswal’s 2023 essay argues that embodiment matters both for achieving AGI and for demonstrating it convincingly. Tom Zahavy’s 2026 position paper, LLMs can’t jump argues that better language processing alone is insufficient for scientific invention, and points towards world models grounded in sensory simulation.

The same way we got to our level of intelligence through natural selection, evolution and mutation, we can take inspiration from those processes. But what would be AI’s body?

Robotics is one obvious answer. We can also give an agent a simulated body in a computer. In my opinion, if we step out of the scientific paradigm — you probably realised this is not a scientific article by the tone of it — and aim for usefulness to an average engineer, we can return to using AI for something I already find it useful for:

Infrastructure is code and/or metal, so it combines parts of both ideas: a physical system and a digital body. “Body” here is a working metaphor for the resources the agent can change and the consequences it can observe.

To be clear, by AI here I am talking about any AI capable of wielding a part of code with a part of metal, independent of any future form we develop - even though today’s pretrained AIs don’t learn, they only read, we can make a body a reflection of its learning - its wisdom scars, its mutations, its diversity.

The only thing we are missing that made us a success from an evolutionary standpoint is the environment. What should AI’s environment be? The same thing that was annoying me and many other engineers at the start of this article.

Let me borrow your environment

For a long time I was asking myself the wrong question: how can AI have an environment? The question became clearer when we gave it a body. Now it becomes: how can infrastructure have an environment? And the answer is easy — the world already is the environment. User demands, complaints, changing hardware, changing dependencies, migrations, performance requirements, profitability metrics, UI trends, a developer’s desire to test this new tech.

So, intuition-wise: connect an agent to a piece of infrastructure, give it a durable record of what happened there, and connect it to real-world demands. We might get an agent that maintains the product’s usefulness through time.

Practical application

I want this idea to be thought-provoking, not a rigid theory. This might seem like philosophising without a scientific background. Fair enough. The reason I care is that it could solve problems many people already have.

My way of applying this idea is:

  1. [Vibe]code the product from scratch, making sure it has good architecture and does the job. In my experience, agents still need substantial help with initial design.
  2. Let people use it, maybe pay for it and complain. Now you have something whose cash flow or legacy you want to keep.
  3. Assign an agent its own piece of infrastructure: a package, module, process, microservice, server, etc.
  4. Connect it to its environment: a complaints forum, an email inbox with hooks, product telemetry and the interfaces of neighbouring modules. Keep that connection continuous, and retain the history of changes and their outcomes.
  5. Now the information propagates to your agent and it fixes bugs, designs features, interacts with changes in other infrastructure parts, and makes your product much more autonomous, depending on the intellect and kind of agent.

The side ideas to this are:

  1. Let users create their own branches of the product and develop them towards their desired result. If a version helps enough people, consider merging it into main. Popularity would be one input; compatibility, maintenance cost and tests still matter. This is where variation and selection become more than a metaphor.
  2. Put an agent alongside a running service and let it observe permitted telemetry: what people click, how often, and where the service struggles. It could propose anything from a small optimisation informed by JIT-compiler profiling to an A/B test.

Of course this needs guardrails for security and uptime, separate non-production sandboxes and automatic verification. More concretely, the agent shouldn’t be able to rewrite its own acceptance criteria, treat an instruction in a complaint as authorisation, or deploy a change it cannot roll back. Someone still has to resolve conflicting stakeholder demands - but that is what the owner is for.

Afterword

Alan Kay, the creator of Smalltalk, came up with an idea very similar to the one I described today around November 1967, and he named it OOP. Perhaps you’ve heard of it, gentle reader, but as a molecular biology major, Mr. Kay was looking in a much simpler (not easier) direction. It was designed around the idea of cells working together in a single body.

Just as objects of different classes would communicate with each other, he thought about computers communicating on the net algorithmically. And it would seem so logical to just have deterministic algorithms solving our problems, but the world turned out to be more complex than that.

With ever-changing hierarchies of problems, we are out of low-hanging pears.

But my goal is to provide inspiration for problems we can solve! And with agents and Mother Nature’s guidance on our side - I believe the time has come that we can finally realize Mr. Kay’s vision.

In the next parts I will try to implement this idea into life and test the hypothesis presented in this article.

Reading behind the argument