Unfinished thoughts. Open questions. Hypotheses I haven't fully tested. These aren't articles — they're the kind of things I write down so I don't forget them, and publish so they might be useful to someone else.
Everyone talks about building better AI agents. Nobody talks about how to know if they actually work. Evaluation is the hardest unsolved problem in applied AI — not the model, not the infrastructure, not the tooling. Until we have rigorous evaluation frameworks, everything else is building on sand.
The word 'orchestration' implies a conductor telling each instrument what to do. But the most resilient multi-agent systems I've seen behave more like jazz — agents with shared context and loose coordination, improvising within constraints. The question is: how do you design the constraints without killing the flexibility?
The highest-leverage thing an engineering leader can do is make decisions quickly. Not recklessly — but quickly. Every day a decision sits unresolved is a day the team operates under uncertainty. Uncertainty is expensive. The cost of a wrong decision you can reverse is almost always lower than the cost of waiting.
The first cloud war was about compute. The second was about data. The third — the one starting now — is about AI infrastructure that operates within national and regulatory boundaries. The companies that figure out how to run full LLM stacks in air-gapped, regulated environments will have a decade-long moat.
Every AI coding tool benchmarks on 'lines of code written' or 'PRs merged per week.' But the most expensive thing in software engineering isn't writing code — it's debugging the wrong code, maintaining legacy decisions, and onboarding engineers onto systems they don't understand. I want an AI that helps with those things.
Product discipline is mostly the discipline of saying no. Every feature you add is a feature you have to maintain, explain, and eventually deprecate. The question isn't 'can we build this?' — it's 'what is the minimum viable thing that solves the actual problem?' Most teams never get to that question.
In five years, 'prompt engineer' will sound like 'Flash developer' — a role that existed during a specific technological transition. The underlying skill (communicating precise intent to a system) is permanent. The syntax-level craft of prompting will be abstracted away. Build the durable skill, not the temporary one.
As context windows grow toward 1M tokens, the temptation is to dump everything in and let the model figure it out. But retrieval discipline — deciding what context matters and why — is a form of engineering clarity. Systems that require careful context design tend to be better understood and more maintainable than ones where you just stuff the whole codebase in.
These evolve. Some will become blog posts. Some will be proven wrong. That's the point.