An autonomous software engineering runtime built to work with real projects, keep track of what is happening, act on the project, and verify the result.
Most AI development tools start with a prompt and try to produce a useful answer.
AEOWUN starts with the software project itself. The runtime keeps track of the workspace, project state, tools, execution, and what the system has actually learned from previous work.
A language model can reason about the work, but it does not get to define reality. The runtime decides what actions are allowed, what state is authoritative, and whether the result actually happened.
That distinction came from actually building these systems. When something goes wrong, adding another prompt usually isn't the answer. Sometimes the missing piece is state. Sometimes it is tooling. Sometimes it is authority. Sometimes the model simply should not be responsible for the job in the first place.
The runtime keeps track of the project and what condition it is actually in instead of relying on the model to remember everything.
The runtime controls what actions can happen and how those actions affect the project.
A model saying something worked isn't proof. The resulting state has to be checked.
The model reasons about the work. The runtime controls the work.
AEOWUN isn't one large model prompt. It is a collection of software components with different responsibilities. A major part of building it has been figuring out which responsibilities belong where.
Owns the engineering loop. Tasks enter here, workspaces are created and tracked here, workers operate through here, and state changes flow back through the runtime rather than being scattered across independent orchestration paths.
A shared state surface for execution-critical information. The important part isn't simply storing data. It is making it clear who is allowed to establish, change, or verify that data.
Keeps isolated filesystem state so the runtime can reason about changes without treating model intent as reality. The project can be inspected before, during, and after mutations.
Watches the engineering loop for behavior that looks like repeated failure rather than progress. Autonomy without a way to recognize that it is going nowhere is just an expensive infinite loop.
Traces failures through the project instead of stopping at the first visible error. The goal is to find the part of the system that actually caused the problem rather than repeatedly fixing symptoms.
Separates "the system says it worked" from "the system can show that it worked." Verification is treated as its own responsibility instead of being another optimistic response from the same component that performed the operation.
Different problems, different environments, and a lot of experimentation. Most of these projects taught me something that eventually showed up somewhere else.
A programming environment I started because I didn't want to relearn everything I already knew every time I picked up another language. The system is built around transferring concepts I already understand into a different language and identifying what I actually need to learn.
A local network monitoring and containment system. It started with wanting better visibility into what was actually happening on a network and grew into experiments with discovery, device identity, persistence, DNS policy, traffic observation, and automated containment.
An experimental simulation built around alchemy, interconnected systems, and world-building. It is less serious than the other projects, but it is still another exercise in making independent systems interact and seeing what happens when they start producing consequences for one another.
An industrial shop-management system built around actual shop workflow rather than a generic CRUD application. It deals with persistent work orders, vehicles, technicians, reactive state, and the practical problem of making software fit the way work actually happens.
A lot of the architecture here exists because something broke, behaved differently than expected, or exposed a problem I hadn't accounted for yet. I don't think failure is particularly interesting by itself. Figuring out what the failure says about the design is.
When something doesn't work, the goal isn't just to patch the visible symptom. I want to understand what assumption was wrong, what responsibility was in the wrong place, and what the system needs to do differently next time.
One of the problems I kept running into was letting too many parts of the system change important state. If everything can declare something true, eventually nothing actually means anything. AEOWUN therefore gives execution-critical state explicit authority.
# ccb.py
if key.startswith(("truth:", "execution:")):
if role not in [
ROLE_SYSTEM,
ROLE_TRUTH_WITNESS
]:
raise ValueError(
"AUTHORITY_VIOLATION"
)One of the easiest mistakes an AI system can make is saying it did something when it didn't. AEOWUN doesn't treat a tool response or model response as proof. It checks the workspace and compares the resulting state.
# shadow_fs.py
def get_hash(self):
hasher = hashlib.sha256()
for key in sorted(self.buffer):
hasher.update(
data["content"].encode()
)
return hasher.hexdigest()Some problems are reasoning problems. Some aren't. I found that pushing deterministic work into a language model created unnecessary failure modes. Parsing, symbol lookup, structured manipulation, and other repeatable work belongs in software when software can do it better.
# deterministic work
parse()
index()
validate()
execute()
verify()
# model
reason()Once a project gets large enough, searching strings isn't enough. AEOWUN uses structural parsing so the runtime can reason about declarations, symbols, relationships, and source structure without pretending that source code is just text.
# source structure
SOURCE
└── AST
├── SYMBOLS
├── REFERENCES
├── CALLS
└── RELATIONSHIPSAutonomous behavior needs a definition of failure. Otherwise a system can continue taking technically valid actions while making no actual progress. AEOWUN watches for repeated failure patterns and treats lack of progress as a runtime problem.
# conceptual loop
observe()
reason()
act()
verify()
if no_progress:
intervene()A recurring lesson has been that adding another manager, another state machine, or another recovery mechanism can make a system worse. Some of the hardest engineering work has been consolidating duplicated responsibilities and deciding which component should actually own the work.
# fewer authorities
HOST RUNTIME
↓
WORKSPACE
↓
TOOLS
↓
EVIDENCE
not:
manager → manager → manager → ???At one point the system could keep trying the same failed approach over and over. That isn't useful autonomy. It's just a loop. The answer wasn't another instruction telling the model to "try harder." The runtime needed a way to recognize repetitive failure and stop it.
I found that some things simply shouldn't be left to an LLM. JSON manipulation, symbol lookup, parsing, and similar tasks are better handled by software that gives the same answer every time. That led to moving more of this work into deterministic tooling and Tree-sitter.
More than once, a problem that looked like a missing feature turned out to be too many components trying to solve the same problem. Multiple orchestration paths, duplicated state, and indirect recovery logic made the system harder to reason about. The fix was consolidation, not another layer.
A network system can't make a decision once and assume everything stayed that way. AEGIS compares what the network is doing against the state it believes should exist so it can detect when reality changes.
When I hit something I don't understand, I don't want the system to hide that gap. I learn what I'm missing, test the idea in the implementation, and then decide whether the architecture actually needs it. That has led me into areas ranging from language parsing and runtime orchestration to networking, persistence, and verification.
These aren't rules I wrote down before I started. Most of them came from building something the wrong way and eventually understanding why.
If multiple components believe they are authoritative, debugging becomes archaeology. State needs a clear owner and a clear path for changing it.
If a deterministic function can solve a problem, there is usually little reason to make a probabilistic model solve it through language.
A failure isn't automatically a reason to patch the line that crashed. It can expose a bad abstraction, misplaced responsibility, missing state, or an assumption that was never actually true.
I have learned the hard way that another abstraction can make a system look more sophisticated while making it harder to understand. If a piece of architecture doesn't solve a real problem, it probably shouldn't exist yet.
I don't try to know everything before starting. I build until I hit the edge of what I understand, then I learn the part that is missing. The project is usually what tells me what I need to learn next.
I build software because I keep running into problems that I want better tools for. Most of the projects here started that way.
I don't really have a single category for what I do. I end up moving between software architecture, AI systems, networking, programming tools, simulations, and whatever else the problem requires.
These are the main systems I'm working on. They are separate projects, but a lot of the ideas and engineering work overlap. Problems found in one project often change how I approach another.
Autonomous Software Engineering Runtime
Programming / Language Learning System
Network Monitoring & Defense
Industrial Shop Workflow
I learned by building things, breaking them, figuring out why they broke, and trying again.
I don't have a traditional computer-science background. I learned most of this by actually building software and running into problems I didn't know how to solve yet.
When I don't know something, I learn it because the project needs it. That has meant learning different languages, frameworks, parsing techniques, networking concepts, databases, operating-system behavior, software architecture, and a lot of things I didn't originally set out to learn.
A lot of the software here started with a simple thought: there has to be a better way to do this.
I don't think being self-taught means I don't have anything left to learn. It's basically the opposite. I am used to finding the part I don't understand and going after it until I do.
I don't have the conventional paper trail. I have the software.
VIEW RESUME.PDFI don't usually start with a technology and then look for something to use it for. I start with something that isn't working the way I want and build toward a solution.
The first visible problem isn't always the real one. I try to understand what the system is actually doing before deciding what needs to change.
I learn a lot faster when there is something real in front of me. I would rather build a rough working implementation and discover its problems than spend months designing something I haven't tested against reality.
Once something works, I want to know where it stops working. Failures, edge cases, bad assumptions, performance problems, and unexpected behavior are usually where the useful information is.
If the problem exposes something I don't understand, that becomes the next thing to learn. I don't see that as a detour. It is part of building the system.
A patch that makes an error disappear isn't necessarily a fix. If the failure came from the architecture, eventually the architecture has to change.