Technology comes after understanding.
Before I choose a model, a framework or an automation platform, I want to understand the problem and the system it lives in. AI is one tool the system might use. It isn't the starting assumption.
The loop
Problem
What outcome are we trying to produce, and how does it happen today? Start with what we're trying to cause, not with what we want to build.
System
Map the people, process, technology, data, timing and ownership around the problem. Most failures live in the handoffs between them, not inside any one tool.
Hypothesis
Make the belief explicit: changing X should produce Y, because of Z. If we can't say it that plainly, we don't understand it yet.
Build
Build something real enough to test the riskiest assumption, inside the real operating environment rather than as an isolated demo.
Evidence
Look at what actually changed and compare it with what we expected. Decide in advance what result would prove us wrong.
Learn
Whether it worked or not, understand why. Then find the next constraint and go again.
↺ back to Problem
Questions I ask before building.
- What outcome are we trying to produce?
- What has to be true for it to work?
- Where does information move, and where does ownership change?
- What is actually constraining the outcome?
- Which assumptions haven't been tested?
- What should stay deterministic, and where can AI genuinely help?
- How will we know whether it worked?
Ideas that shape how I work.
These aren't methodologies I'm selling. They're ideas I've studied that change the decisions I make.
- First principles
- Help me reduce a problem to what must actually be true, and separate real constraints from inherited habits.
- Systems thinking
- Shows how the parts depend on each other. Changing one step can move the problem somewhere else, so I look upstream and downstream before I change anything.
- Theory of Constraints
- Points me to where intervention matters. Automating ten tasks that aren't the bottleneck produces impressive technology and very little value.
- Lean Startup
- Keeps the build focused on learning. An early build isn't a stripped-down version of the final product. It's designed to test the assumption that matters most before we invest further.
- The scientific method
- Turns assumptions into hypotheses that evidence can challenge. A result that disproves the hypothesis still teaches us something about the system.
Find the constraint.
Automating the greatest number of tasks doesn't necessarily produce the greatest improvement. The important question is what's currently constraining the outcome.
Try it: automate any step of a pipeline and watch the output →
Deterministic or probabilistic?
Not every step needs an LLM. Every Lab demo marks each step with one of these three.
Deterministic
If something can be handled reliably with rules, a query or an integration, that's often the better engineering choice.
AI / probabilistic
Where language, ambiguity, interpretation or synthesis create real value.
Human judgment
People stay in the loop where their judgment matters most.