In my previous article, I wrote about X-Ray — an observability system that grew out of my work on PAD+ AI.
Read the X-Ray article on Habr
Before X-Ray, I could see two things:
Request → Response
After X-Ray, every request became a detailed execution map.
I could see individual phases, calls, timings, failures, state transitions, and causal relationships inside the pipeline.
At first, that seemed to solve the problem.
It didn't.
It created a new one.
The Strange Algorithm
After X-Ray appeared, I stopped looking for problems manually.
X-Ray was finding them for me.
But then I noticed something strange.
Every time it reported a problem, I was doing almost exactly the same thing:
Read the diagnostic
↓
Find the cause
↓
Design a fix
↓
Apply the change
↓
Run tests
↓
Keep or rollback
Then repeat.
Day after day.
Week after week.
And eventually I realized:
I wasn't making a new engineering decision every time. I was repeatedly executing the same algorithm.
That led to a much more interesting question:
If a system can already observe and diagnose its own problems, why couldn't it execute the engineering loop as well?
That question became the starting point for HEALER.
Not "Self-Healing" — Automating the Engineering Loop
The term self-healing is already widely used.
Usually it means something relatively simple:
Failure → Detect → Restart
A crashed container gets restarted.
A failed service gets recreated.
A node disappears and another one takes over.
Useful, but I was interested in something different.
I wanted to automate the engineering process itself.
Not just:
"Something failed. Restart it."
But:
"Something is wrong. Find out why. Propose a change. Apply it safely. Verify the result. Roll back if necessary. Remember what happened."
So before writing the implementation, I wrote down the cycle.
1. Detect a problem
↓
2. Diagnose the cause
↓
3. Generate a fix
↓
4. Verify the fix
↓
5. Roll back if verification fails
↓
6. Learn from the result
Once the process was explicit, the architecture became much easier to design.
Six Layers
Instead of building one giant "AI repair agent", I split HEALER into independent layers.
Layer 5: Meta-Learning
↑
│ remembers results
│
Layer 4: Orchestrator
↑
│ controls the cycle
│
Layer 3: Verification
↑
│ tests the proposed change
│
Layer 2: Patch Engine
↑
│ generates code changes
│
Layer 1: Diagnostics
↑
│ detects and analyzes problems
│
Layer 0: X-Ray Kernel
│
└── execution evidence
Each layer has a specific responsibility.
Layer 0 — X-Ray
X-Ray provides the execution evidence.
It records what happened inside the application: phases, timings, errors, relationships and execution state.
HEALER doesn't have to guess what happened.
It can start with a trace.
Layer 1 — Diagnostics
Diagnostics analyzes the available execution data and looks for known classes of problems.
The current implementation contains multiple detectors covering issues such as resource leaks, slow operations, import-related problems and causal violations.
The important part is the separation:
X-Ray observes. Diagnostics interprets.
Layer 2 — Patch Engine
Once a problem has been identified, HEALER needs to construct a possible correction.
For Python code, the Patch Engine can work with the AST (Abstract Syntax Tree) rather than blindly modifying text.
That gives the system a structural representation of the code it is modifying.
Layer 3 — Verification
A generated patch is not considered successful simply because it was generated.
It has to survive verification.
The basic principle is:
Patch
↓
Syntax check
↓
Tests
↓
Result
If verification fails, the change should not remain in the codebase.
Layer 4 — Orchestrator
The Orchestrator controls the overall cycle and determines how HEALER operates.
The architecture supports different levels of automation, including monitoring, suggestion and automatic execution.
This is important because autonomous code modification should not have to be an all-or-nothing decision.
Layer 5 — Meta-Learning
The final layer records what happened.
A successful repair is useful information.
A failed repair is useful information too.
The goal is not to make the system magically "smarter", but to accumulate structured experience that can influence future repair attempts.
The Moment I Stopped Writing the Fixes
The strangest part wasn't the first automatically generated patch.
It was realizing that the complete engineering loop could be executed without me manually performing every step.
Previously:
X-Ray
↓
I read the report
↓
I found the cause
↓
I wrote the fix
↓
I ran the tests
↓
I rolled back if necessary
With HEALER:
X-Ray
↓
Diagnostics
↓
Patch Engine
↓
Backup
↓
Verification
↓
Meta-Learning
↓
Rollback if necessary
The difference is subtle but important.
HEALER isn't simply another component that "fixes bugs".
It is an attempt to turn a repeated engineering workflow into an executable system.
A Real Example
Consider a simple resource leak.
Suppose a diagnostic detects that a function opens a file without reliably closing it.
Before
def read_config():
f = open("config.json", "r")
data = json.load(f)
return data
The diagnostic identifies the problematic pattern.
The Patch Engine can transform the structure of the code into:
After
def read_config():
with open("config.json", "r") as f:
data = json.load(f)
return data
But generating this code is only the middle of the process.
HEALER then has to deal with the consequences.
Step 1 — Backup
Before modifying the file, the original version is preserved.
For example:
read_config.py
read_config.py.healer.bak
The backup provides a recovery point.
Step 2 — Verification
The modified code is checked.
At minimum, the system needs to establish that the generated code is syntactically valid and that the relevant tests pass.
Generated patch
↓
Syntax validation
↓
Tests
↓
PASS
Only then is the repair considered successful.
Step 3 — Rollback
Now consider the opposite scenario.
The generated patch causes a test failure.
The process becomes:
Patch
↓
Verification
↓
FAIL
↓
Rollback
↓
Original code restored
This is one of the most important principles of the entire system.
Autonomous modification without autonomous verification is dangerous.
The ability to undo a change is therefore not an optional feature. It is part of the architecture.
What Does HEALER Actually Automate?
This distinction matters.
HEALER does not mean:
"An AI programmer that can independently build any software."
That's not what I am claiming.
The current system automates a much narrower and more measurable problem:
Can a system observe a known class of engineering problem, diagnose it, construct a candidate repair, verify the repair, and recover safely when the repair fails?
That is a much more interesting engineering question.
And it is testable.
HEALER Inside PAD+ AI
HEALER didn't appear as an isolated project.
It emerged from PAD+ AI → X-Ray → HEALER.
The progression was almost inevitable:
PAD+ AI
Cognitive architecture
↓
X-Ray
Observe execution
↓
HEALER
Act on detected problems
PAD+ AI provided the complex execution environment.
X-Ray provided visibility.
HEALER became the experimental layer that could act on that visibility.
This separation is important because observability and automated intervention should not be the same thing.
X-Ray observes. HEALER acts.
Seeing HEALER in PAD+ AI
HEALER is integrated into the PAD+ AI platform and can be inspected through the application interface.
The HEALER section currently exposes several parts of the system.
Reflection Panel
Shows what HEALER learned from previous cycles and what changes were made.
Trace Panel
HEALER activity is itself observable through the X-Ray tracing channel.
That means the system doesn't have a blind spot simply because the component performing the repair is autonomous.
Bridge Status
Shows the current operating mode and system state.
Auto-Cycle
Allows the automatic diagnostic/repair cycle to be enabled and monitored.
The frontend also receives events through WebSocket, including detector activity and cycle results.
So the goal isn't to create a mysterious autonomous process running somewhere in the background.
The goal is almost the opposite:
make the autonomous process observable.
Why X-Ray Had to Come First
This is probably the most important architectural lesson I learned while building the system.
Imagine giving an automated repair system permission to modify code without first having a reliable picture of what happened.
You would have:
Unknown problem
↓
Unknown reasoning
↓
Automatic modification
That is a dangerous combination.
With X-Ray:
Observed execution
↓
Diagnostic evidence
↓
Candidate repair
↓
Verification
↓
Controlled modification
The repair mechanism is therefore built on top of evidence, rather than operating entirely from assumptions.
Testing the System
Before allowing a system like this to modify code, the obvious question is:
Does the repair cycle itself work?
The current HEALER implementation has been tested with:
- 121 unit tests
- smoke testing across all six layers
- 9 diagnostic integration scenarios
- a demo run containing 201 completed traces
- 115 diagnostic reports generated by the detector layer
The current implementation is also designed to be self-contained, using Python's standard library rather than requiring a large external runtime.
These numbers are not proof that autonomous software engineering is solved.
They are simply evidence that the current experimental implementation can execute and test the intended workflow.
And that distinction matters.
The Important Limitation
There is an easy trap here.
Once you see a system successfully detect a resource leak, generate a patch, run tests and keep the result, it is tempting to conclude:
"We've built a self-programming AI."
We haven't.
A controlled repair of a known problem class is very different from general software engineering.
Real software contains:
- ambiguous requirements;
- architectural trade-offs;
- undocumented dependencies;
- business constraints;
- hidden assumptions;
- security implications;
- changes whose correctness cannot be established by unit tests alone.
A passing test suite does not automatically mean that an architectural decision was correct.
That is exactly why HEALER is still an experimental research platform, rather than a claim that autonomous programming has been solved.
The Next Problem
X-Ray answered one question:
What happened inside the system?
HEALER started answering another:
Can the system act on what it observes?
But this creates a much harder question.
If the system can:
- observe;
- diagnose;
- modify;
- verify;
- rollback;
- learn from previous repairs...
then eventually we have to ask:
Who decides what should be changed in the first place?
A detector can tell us that something is wrong.
A patch engine can propose a correction.
A test can tell us whether the correction passes a defined validation.
But none of those things necessarily tells us whether the architecture itself should change.
And that is where the next layer of the problem begins.
What's Next?
The evolution of the project currently looks like this:
PAD+ AI
│
├── Cognitive Architecture
│
└── X-Ray
│
└── Observability
│
└── HEALER
│
├── Diagnostics
├── Patch Engine
├── Verification
├── Rollback
└── Meta-Learning
The next question isn't simply:
"Can we make HEALER repair more bugs?"
It is much more fundamental:
Can an AI system distinguish between a local implementation problem and a deeper architectural problem?
That's where I want to take the research next.
And this is also where I am looking for other engineers and researchers who want to experiment with the system rather than simply watch a demo.
Want to Experiment With It?
PAD+ AI is an open research platform.
The goal isn't to build another AI chatbot.
The goal is to investigate what happens when an LLM-based system is surrounded by explicit architecture for memory, state, observability, verification and controlled evolution.
If you're interested in:
- AI agents;
- LLM orchestration;
- AI observability;
- autonomous software engineering;
- Python infrastructure;
- cognitive architectures;
- debugging and verification;
I'd be much more interested in your experiments, criticism and pull requests than in people simply clicking through the demo.
The HEALER repository is currently private while the architecture is being stabilized, but I can provide access to people who want to study the implementation or contribute.
Links & Resources
📚 Read the full PAD+ AI series:
- Part 1: Building a modular cognitive architecture around modern language models
- Part 2: X-Ray for AI — or how I stopped understanding my own neural network and built my own APM
🌐 PAD+ AI — live platform:
Open PAD+ AI on Render
💻 PAD+ AI repository:
PAD+ AI on GitHub
💻 X-Ray integration kit:
X-Ray Integration Kit on GitHub
The X-Ray repository is currently private. If you want to examine the architecture or participate in its development, contact me via Telegram and I can provide access to interested contributors.
💻 HEALER:
https://github.com/Ovladimirovich/Healer.git
The HEALER repository is currently private. If you want to examine the architecture or participate in its development, contact me via Telegram and I can provide access to interested contributors.
💬 Telegram:
PAD+ AI Telegram
One Last Question
When I started PAD+ AI, I wanted to understand whether an LLM could become part of a larger cognitive architecture.
X-Ray came from the need to understand what that architecture was actually doing.
HEALER came from the realization that once you can observe a complex system, you can begin asking whether some of the work of maintaining it can itself be automated.
Now I am left with a harder question:
If an AI system can eventually diagnose, modify and verify its own code — where does the engineer's job actually begin and end?
Top comments (0)