← Back to work— Before AI · 04

Engineering discipline — the lens that runs through everything

In development· 2007–present

The other three domains describe what I am building. This one describes how, and where the discipline comes from. A decade before I wrote my first production agent or shipped my first VST, I spent ten years inside an engineering culture that does not exist in most software work. Heavy-industry infrastructure engineering — copper mining megaprojects, mineral processing plants, water treatment facilities, tailings dam structures — operates under constraints that software people rarely encounter. A mistake does not roll back with a git revert. An over-cost is not a line on a spreadsheet, it is months of rework, renegotiated contracts, and careers ended. A failed pressure vessel is not a 500 error, it is a fatality investigation. That environment changes how you think about every artifact you produce, and once the reflex is there, it does not leave. Four ideas from that decade keep surfacing in everything I build now. Cost-and-change management as observability. In capital projects on the order of a billion dollars, nobody cares about the headline number — they care about the delta between what the budget said last week and what it says this week, and why. Every trend gets logged. Every scope change gets tagged with an owner, an estimate, a schedule impact, and an approval chain. Every estimate comes with a contingency band because the number without the band is a lie. That practice translates directly to modern systems work. The cost-per-token dashboards, the FinOps circuit breakers, the evidence ledgers in scientific imaging, the fencing-token protocols in agent swarms — all of them are the same instinct applied to a new substrate. Do not trust a number you cannot audit. Do not ship a system whose state you cannot reconstruct. Observability is not a feature you add at the end, it is the artifact the project produces alongside the work. Contingency and risk analysis as design input. Before a major project begins execution, you do a formal Contingency and Risk Analysis — you enumerate the failure modes, assign probabilities, estimate cost and schedule impact, and build the mitigation plan into the budget from day zero. You do not hope nothing goes wrong. You design the envelope for when it will. That is the same posture I take with every system now. Before a swarm goes to production, a chaos injector runs against it. Before a plugin ships, pluginval Level 10 tortures it. Before an imaging pipeline produces an artifact, the artifact has to carry its own provenance. The question is never will this fail? — the question is always when it fails, what happens next, and can we prove it was handled correctly? Cross-disciplinary coordination at scale. Managing change on projects where construction, procurement, safety, engineering, and PMO teams all had legitimate but conflicting claims on the same scope taught me that the hard part of a complex system is almost never the individual components — it is the interfaces. The dual-LLM pattern in my agent frameworks, the event-bus architecture in the biological-organism systems, the six-mode shell in the imaging pipeline, the three control modes in a single reverb engine — they are all the same move: make the interfaces legible, make the handoffs observable, make every contract between two components something you can inspect. That is not a software insight. That is a project-controls insight applied to software. Building from whiteboard to revenue. Founding a financial-coaching company in a country that did not have a category for what I was selling, winning the top government-backed startup competition, producing a national video course, being featured across CNN Chile, Canal 13, MEGA, and national radio — that experience is not on this page as a credential. It is here because it is the other half of the discipline. Engineering teaches you how to build correct systems. Entrepreneurship teaches you that a correct system nobody adopts is a failed system. Every architecture decision I make now is filtered through both lenses: is it technically sound, and will the person who has to live with it actually use it that way? The elegance that does not survive contact with a user is not elegance, it is decoration. Before any of that, the foundation: a six-year civil engineering degree, an undergraduate thesis on activated-sludge biological process modeling integrated with SCADA-style control loops (which turns out, twenty years later, to have been training for everything I do now in autopoietic systems), two university lectureships, and a professional photography practice across portrait, commercial, wedding, and fine art that ran for a decade in parallel with everything else. The side quests are not separate from the engineering. They are the engineering, on different substrates.

cost engineeringEPCMproject controlsSCADArisk analysisentrepreneurship
— Building something where this problem lives?Start a conversation