You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 23 minutes
Key takeaways:
- Plan technical decisions by how costly they are to reverse, not by how important they feel.
- Present your AI roadmap as assumptions, not firm conclusions.
- Build the thinnest possible end-to-end version before committing to a full direction.
Three months. That’s roughly the interval at which the “right way” to build something in AI shifts under you. A new agent harness lands and makes the orchestration you spent a quarter on look overweight. A better retrieval pattern quietly changes what “good” looks like for the feature you’re mid-flight on. A new evaluation technique shows that the numbers you’ve been reporting for two months don’t actually measure what you thought they did.
Any engineering leader shipping AI features has felt a version of this. The problem is that the standard playbook for setting technical direction, i.e. pick a stack, draw a two-year roadmap, and commit the team doesn’t survive contact with a field where the toolkit itself is being rebuilt every quarter.
Not every new pattern is worth adopting, and not everything worth adopting can be adopted mid-flight. The answer isn’t to freeze on what you have or to chase every release. It’s to plan differently.
Below are three practices I rely on for setting direction when the ground keeps moving: separating the bets you make, communicating direction as assumptions rather than certainties, and shipping the thinnest version first.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Separate the bets you’d hate to reverse
Not every technical decision costs the same to unwind. Choosing a schema for your evaluation data is a decision you’ll live with for a long time. Choosing which model variant serves a given feature this quarter is a decision you should be ready to change on a few weeks’ notice.
The clearest way I’ve found to keep this straight is to sort every direction-setting decision into two buckets: costly-to-reverse commitments and reversible experiments.
The commitments deserve slow and careful deliberation, the kind of design review where you invite the skeptics. The experiments deserve a bias toward action. The cost of moving fast is small for such decisions, and you’ll learn more from shipping than from discussing.
In practice, the boundary I aim for in AI systems is this: architecture and interfaces are commitments, orchestration and prompts are experiments. If the interface between the product and the model layer is clean – a single abstraction that takes structured input, returns structured output, and hides the specifics – then swapping a model variant for a newer one, switching from single-shot prompting to a planning loop, or moving from server-side to on-device inference becomes a few days of work instead of a quarter of refactoring.
On a personal agent outside of work I’ve been running for a few months, that reads my calendar and inbox, prepares drafts, and schedules replies, the thing I’m glad I committed to early wasn’t the model, it was the tool-use schema.
I defined a small set of tools (read_calendar, send_draft, search_thread) with strict input and output shapes, and treated the model itself as swappable behind that. When I moved from one model variant to another six weeks in, the agent’s behavior changed but the surrounding code didn’t.
I’ve seen the same pattern hold up in my day to day work as well: the model file, the API endpoint can move around, as long as the contract of the rest of the app/code depends on it stays stable. The failure mode on the other side is over-abstraction. Building a fully model-agnostic layer before you’ve shipped anything is its own form of waste.
The rough rule I use: abstract when you have two real implementations in play, not before.
Communicate direction as assumptions, not conclusions
Early on, when I presented technical direction to senior leadership, my instinct was to sound as certain as possible, i.e. firm dates on the roadmap, a picked stack, a clear path from where we were to where we’d end up. However, given the pace AI moves now, that instinct doesn’t survive very long.
Evaluation results came in and the approach we’d committed to isn’t clearing the bar we need. Or a capability we’d designed the plan around hadn’t shipped on the timeline we expected. Either way, walking the plan back a few weeks later is uncomfortable for everyone in the room.
I’ve since moved to a different format. Every document now names its assumptions explicitly. Something like: “this plan the latency and cost profile of the model tier we’re using stays in the current range. If any of these change, here is what we would revisit.”
There are two payoffs. Leadership gets a more accurate picture of the risk they’re carrying, which is what they need to make portfolio decisions. When an assumption breaks, and one will, the conversation isn’t “the plan failed,” it’s “assumption three changed, here’s the revised plan.”
That’s a much easier conversation, and it protects the team’s credibility. The related habit is separating known’s from known-unknowns in every update. When I’m honest about what I don’t know, leadership tends to trust me more when I say I do know something. On the other hand, when I pretend to be certain about things I’m not, I lose that trust the first time I’m proven wrong.
More like this
Ship the thinnest version first
The strongest antidote to premature lock-in I’ve found is refusing to commit to a direction until you’ve built the smallest end-to-end version of it. Not a prototype in one component. The whole path, front to back, working for one user on one input, even if every piece is held together with duct tape. What you learn in the two weeks it takes to build that thin slice will usually tell you more about the plan than two months of design review.
On the same personal agent, I built the crudest possible end-to-end version first: read one calendar event, draft one reply, send it. No planning layer. No memory. No fallback handling. That two-week version taught me things about latency, tool-use reliability, and error handling that I could not have anticipated from design alone and it shaped every architectural decision I made afterward. When I later added the planning layer, I already knew where the real cost centers were, which made scoping the work for the fully fledged AI agent honest rather than optimistic.
The instinct to skip this step is understandable: shipping a thin slice feels slow compared to designing the “real” version. However, designing the real version of assumptions that haven’t been tested is almost always the more expensive path.
Every hour spent on a thin slice buys back days of arguing about architecture in the abstract, and it gives leadership something concrete to look at when they ask how it’s going. The other benefit is that a thin slice creates a natural review point. You built it to answer specific questions, and once it answers them, that’s your decision moment.
New York • September 15 & 16, 2026
Don’t figure it out alone. Learn what works at LDX3 New York.
The direction is the process
The instinct in a fast-moving field is either to keep everything provisional and never commit, or to plant a flag and hope reality cooperates. Neither works.
What has worked for me is treating technical direction as a portfolio of bets with different reversal costs, communicating those bets to leadership as assumptions rather than certainties, and validating each direction with the thinnest end-to-end version you can build before committing to the full one.
None of this makes the uncertainty go away. Evaluation results will still land unexpectedly. A better pattern will still emerge halfway through a plan you’ve already committed to, but it shifts the team from reacting to change to expecting it, and it gives senior leadership the honest picture they need to back the work.
