# Can We Automate the Work of a Software Engineer? The Story Behind HEALER > Source: > Published: 2026-08-22 00:45:20+00:00 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](https://habr.com/ru/articles/1057236/) 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. 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**. 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. 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. 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. 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.** 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. 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. 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**. 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 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**. Consider a simple resource leak. Suppose a diagnostic detects that a function opens a file without reliably closing it. ``` python 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: ``` python 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. 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. 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. 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. 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 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.** 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. Shows what HEALER learned from previous cycles and what changes were made. 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. Shows the current operating mode and system state. 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.** 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. 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: 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. 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: 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. 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: 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. 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. 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: 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. **📚 Read the full PAD+ AI series:** **🌐 PAD+ AI — live platform:** [Open PAD+ AI on Render](https://pad-plus-ai.onrender.com/) **💻 PAD+ AI repository:** [PAD+ AI on GitHub](https://github.com/Ovladimirovich/pad-plus-ai) **💻 X-Ray integration kit:** [X-Ray Integration Kit on GitHub](https://github.com/Ovladimirovich/xray-integration-kit) 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](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](https://t.me/padplusai) 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?**