At Moores Lab AI, a lot of what we build sits at the edge of what’s possible: complex systems, fast-moving workloads, and verification problems that don’t come with an instruction manual. In that kind of environment, how you think is just as important as what you ship.
Today, our Principal Architect Lucas Kisabeth shares the principles he leans on most:
1. The most expensive system is the one that shouldn’t exist.
The biggest cost in engineering isn’t cloud spend or CPUs, rather people’s time and attention.
When we build something that doesn’t truly need to exist, we don’t just pay for the initial implementation. We sign up for years of:
- meetings and planning
- edge cases and bugs
- migrations and refactors
- “who owns this?” questions and collapse when the SME leaves for that big offer from Zuckerberg
As the company grows, that cost doesn’t scale linearly; it compounds.
So before implementing something, challenge the premise as hard as you can:
Do we actually need this? What happens if we don’t build it?
If it’s not clearly worth the ongoing cost, the best optimization is to let it never exist.
Deletion is a first-class skill.
2. Essential complexity doesn’t require implementation complexity.
A lot of what we do is inherently hard. That’s essential complexity: the unavoidable difficulty of the domain itself—real-world constraints, physics, timing, concurrency, state. You don’t get to delete that.
What we do control is implementation complexity: how we choose to express that problem in code and architecture.
There’s a quote from Einstein that I love:
“If you can’t explain it to a 6-year-old, you don’t understand it yourself.”
I try to channel that idea into implementation:
- Best case: write an implementation that a freshman CS student could easily follow.
- If that’s impossible: still do so where you can, then close the gap with comments that a freshman could easily follow.
- If that still isn’t enough: take a moment to appreciate that we didn’t hire any 6-year-olds, then write documentation that makes the higher-level idea clear to everyone.
The goal isn’t to pretend the domain is simple. It’s to express that complexity in the least confusing way we honestly can.
Essential complexity is the cost of solving meaningful problems.
Implementation complexity is a choice.
Or, as Leonardo da Vinci put it, “Simplicity is the ultimate sophistication.”
3. You’re definitely wrong. Optimize for that.
Even with good judgment, solid reasoning, and careful design, some of our assumptions are definitely wrong about requirements, edge cases, scale, or how people will actually use what we build. That’s not a personal failure; it’s just how reality works.
So try to design systems and workflows that assume future-you will know more than present-you:
- code that’s easy to delete or reshape
- boundaries that can move without a full rewrite
- long-running tasks that validate inputs and assumptions early, and fail fast with useful errors instead of quietly wasting hours
- feedback loops (tests, metrics, reviews, user signals) that tell us quickly when the world doesn’t match our mental model
The point isn’t to be right the first time.
It’s to make it cheap and safe to become less wrong.
Lucas’s playbook lines up with how we think about engineering across Moores Lab AI: build only what matters, express hard problems as clearly as possible, and assume we’ll learn faster than we can plan.
If we keep building systems that are easy to delete, easy to understand, and easy to correct, we don’t just move faster—we give engineers more room to solve the problems that actually move the industry forward.
