Simone Coelho
This is not a resume. This is how I got here.
I started programming on a Radio Shack TRS-80 that my father brought home from work in 1980. I was nine years old. He didn't know what it was. It sat in a box in his room for a while before I found it. We lived on a farm, and there wasn't a lot of excitement during certain times of the year — the weather didn't help. For some reason, I found comfort in that computer.
It had a tape drive that took thirty minutes to load a program. The computer came with a book that taught BASIC — I read the whole thing. To be fair, the book was quite simple, very clearly written. It made perfect sense.
I wanted an Atari, but my dad wouldn't buy me one because he said video games weren't educational. So I built my own game instead. I wrote a Ping Pong program on the TRS-80 where the pixels were so large I could make an entire paddle with three pixels in a row. It wasn't as good as the Atari, but it was pretty cool. And apparently educational enough.
I went through a variety of computers after that — Apple II, Commodore 64, Macintosh, and eventually the IBM PC. I was lucky to have been exposed to that many machines, that many operating systems, that many different ways of thinking about how software works.
When I was fifteen, I built a Pascal compiler as a science project. Not a parser. Not a tokenizer. A compiler — the kind that takes source code in and produces something executable on the other side. That's where my obsession with compilers, data structures, and the mechanics of how intent becomes execution was born.
I went on to write my college thesis on compilers in 1993, then spent several years building compilers and low-level systems professionally — parsers, symbol tables, type checkers, code generators. After that, two decades of data transformation systems, integration protocols, enterprise architecture. Different domains, but the same instinct running through all of it: separate analysis from execution. Resolve before you run. Validate the program before you emit the executable.
After college, I went to work at PeopleSoft, where I worked on the PeopleCode compiler and language features. I traveled all over Latin America for many years — Brazil, Colombia, Chile, Argentina, Guatemala, Costa Rica, Panama, Mexico, Portugal, Spain. Different cultures, different laws, different tax legislation, different ways of thinking about the same business problems. It gave me a perspective I couldn't have gotten any other way.
Later I co-founded a document transformation technology company. We built software that could access, transform, and control the contents of over 380 unstructured file formats — native binary identification, document forensics, metadata extraction and normalization. We were acquired by Xerox, where I led engineering for several years. After that, enterprise architecture at scale — Fortune 500 implementations, experimentation platforms, analytics.
I still have my day job. I've been building what I'm about to describe on nights and weekends, because I couldn't stop thinking about it.
I'm not here to sell you anything. This isn't a product launch, and it isn't a fundraising pitch. What I want to do is show you a different way of thinking about autonomous AI — one that I've been building quietly for a year and a half, and that I think matters.
The autonomous agent space has already proven that giving models a real computer to work in — a sandbox where they can write code, browse the web, produce files — changes what AI can do. Others got there first, and they deserve credit for it. That part of the conversation is settled.
But one day I was deep in building a workflow for one of these agents, wiring up tool calls and conditional edges, and I thought out loud: this is dumb. Why isn't anybody compiling this?
I've always believed that a computer on its own is a million times more powerful when it works in combination with intelligence — providing the tools, the environment, the gateway so that if the model needs a tool, it can materialize it. The model writes the tool. It invents the solution. It thinks in code.
This idea — that the AI should control the code, not the code controlling the AI — is the foundation of the Code-Act research paper, and I want to credit it directly.
Even a fast, lightweight model like GPT-4o Mini or Claude Haiku is capable of generating 13, 14, 15 steps of code linked serially with dependencies — with very little error. I've seen coding agents in the terminal spin over errors a thousand times more than I've seen a lightweight model fail creating batch steps inside a governed sandbox.
I don't know yet exactly where this goes — which industries, which use cases, which direction. I'm sharing this because I want to find people who think about these problems the same way. What I've built is just the beginning. As models become smarter, the compilation architecture becomes more powerful — not less.
You can read the founder's note, the full architecture thesis, or go straight to the proof artifacts on GitHub.
If you see what I see, I'd genuinely like to meet you.
Amadalis is a name I created from the overlapping sounds and syllables of my wife's name, my own, and my children's names. It represents the entire family. I registered it because I thought it was beautiful, and because whatever I build next should carry something personal.
Get in touch
If you think about these problems the same way, or just want to talk about compilers and autonomous systems.
Contact me