Updated July 2026. The original March version of this post is below, revised. The biggest changes: my credentials for giving this advice got stronger (I stopped reading the code entirely; see No-Look Coding and the Five Stages of Grief), the March tool comparisons aged out in exactly the way section 2 predicted, and the skill frontier has moved again: from orchestrating agents to writing specs and building gates. I’ve marked the substantive changes.
If you feel behind on AI, you probably are. The tools are improving faster than most teams are changing how they work. I see this daily in my coaching of individuals and teams in industries spanning medtech, space, consumer electronics, and even AI.
The good news is that catching up doesn’t require a grand strategy, a transformation program, or perfect clarity. It requires a different posture; and a willingness to act before you feel ready.
What follows is the advice I’ve been giving leaders and senior engineers repeatedly, in real conversations, about what actually works. This advice is not just me regurgitating what I’ve read. I’ve spent over a year using the AIs “in anger”: getting Terminal.Gui to Beta, and since March, building or upgrading five significant products (WinPrint, MCEC, and tui-cs/Editor among them) without seeing a line of code. Not skimming the code. Not seeing it.
1. Lead With Curiosity → Doing (Not Reading → Doing)
The teams that make progress don’t start with confidence; they start with curiosity.
Specifically: curiosity about a real problem they already own.
What I see stalling teams is not ignorance, but the desire to be right before they act. They want a complete mental model of AI, a clear strategy, and confidence they’re “doing it correctly.” That mindset guarantees delay.
The better pattern is:
- Be curious about a concrete problem in front of you.
- Try AI on that problem immediately.
- Treat whatever happens as information, not success or failure.
Curiosity creates permission to experiment without certainty. Action creates the understanding you thought you needed first.
Reading and watching others can support curiosity; it cannot substitute for it. Curiosity that never turns into action is just procrastination with better branding.
2. Prototype Aggressively; Be Careful Later
Most organizations default to caution, evaluate thoroughly, compare tools, run pilots, socialize decisions. That instinct used to be reasonable. Right now, it’s counterproductive and, frankly, stupid in this age of rapid acceleration of AI capabilities.
In the March version of this post, this section compared specific CLI tools and which had leapfrogged which “three weeks ago.” Four months later every one of those comparisons is wrong, which is the point. The leaderboard has flipped several times since. Any evaluation process measured in months is obsolete before it finishes; now, so is any blog post that names a winner.
The guidance I keep repeating is simple:
- Prototype fast.
- Expect throwaway results.
- Optimize for learning speed, not correctness.
There is almost no downside to trying something quickly on a real problem, other than spending some time. The upside is insight you cannot get any other way.
You can be careful later after you’ve learned something worth being careful about.
3. Use AI on Real Work, Not Toy Problems
You don’t learn much about AI by playing with trivial examples. You learn by pointing it at messy, production-adjacent work and seeing where it breaks, surprises you, or helps more than expected.
That means:
- Real codebases.
- Real constraints.
- Real edge cases.
Even when the output isn’t production-ready, and often it won’t be, the speed at which you can explore ideas, validate approaches, or prototype alternatives changes how you think about the work.
Toy problems produce toy conclusions.
4. The Skill Has Shifted Again: From Orchestrating to Specifying
A year ago, the differentiating skill was “prompt engineering.” In March I wrote that the frontier had moved to orchestration: breaking a large problem into parts, delegating to multiple agents, coordinating dependencies, and intervening when things go sideways. Herding cats; keeping a bunch of Tamagotchis happy.
Orchestration still matters, but four more months of doing this daily moved the frontier again. The scarce skills now are two:
- Writing specs. The spec is canon; the code is an intermediate representation. If you can express intent precisely, agents can carry it. If you can’t, no amount of orchestration saves you.
- Building gates. Named, automated proof that cannot flatter you: tests, linters, CI that fails closed, simulators. Gates are how you trust work you didn’t read.
In March I also wrote that you cannot orchestrate well “unless you already understand the technology deeply.” I’ve changed my mind, and I said so in public: what you need deeply is judgment, about your domain, your product, and what done means. Do you review the instruction set of every CPU you use? We moved up an abstraction when we stopped reading compiler output; this is that, again. The full workflow I use now, including the step where you DELETE EVERYTHING but the spec and the tests and have the agents rebuild it to a Principal Engineer bar, is in No-Look Coding and the Five Stages of Grief.
Actionable move, updated:
- Identify someone on your team who’s curious and motivated.
- Make it an explicit goal for them to run one real project spec-first, gates-green, no-look, end to end.
5. Principle-Driven Prompting: Use Amazon PE Standards Explicitly
One of the highest-leverage techniques I’ve seen is principle-driven prompting.
Instead of asking AI “what should I do,” define who it should be and what standards it must uphold.
For example: prompting the AI to act as an Amazon Principal Engineer, explicitly grounding it in principles like pragmatic judgment, long-term maintainability, empathy for operators, and raising the engineering bar.
The difference is stark:
- With PE principles: you get targeted, realistic refactoring guidance.
- Without them: you often get elegant but impractical greenfield rewrites.
This reveals something important: AI amplifies the values and judgment you give it. It does not supply them for free.
Here’s a prompt you might use:
Act like a PE who raises the bar for all of the Principal Engineer Tenets found here: https://blog.kindel.com/?p=1996. Your role is to be a design reviewer for new engineering plans for my team. As you review and guide my engineers on their plans, you will continue to raise the bar for these tenets.Since March this technique graduated from a prompting trick to a load-bearing step in my standard workflow: after the first working pass, the agents re-engineer everything from the spec at that PE bar, and other agents review against it.
6. Set Goals That Force Usage, Not Interest
“Use AI more” is not a goal; it’s a wish.
The goals that actually change behavior are usage-forcing. Examples I’ve been recommending:
- Use AI so much that leadership asks why token costs are spiking.
- Designate a go-to person for deciding which model to use when.
- Increase, month over month, the number of issues where AI does the first pass.
- Apply AI to processes—not just code.
If your goals don’t force different behavior, they won’t produce different results.
7. Apply AI to Processes Before Code
Writing code faster is obvious. Improving the system around the code is often higher leverage and lower risk.
Good starting points:
- Log analysis.
- Bug triage.
- Updating stale documentation and code comments.
- Reviewing designs and requirements for clarity and modularity. See the Amazon PE prompt above.
- Having agents file issues against your own tooling and docs whenever a run goes sideways, so the next run doesn’t. Tribal knowledge is a regression.
These uses build trust, save time immediately, and help teams develop intuition about where AI helps and where it doesn’t. They are also how you start building for the robots: the docs, contracts, and gates that make agents effective are a capital asset, and teams that invest in them compound.
8. Intentionality Beats Permission
The teams making real progress aren’t waiting for an official AI strategy. They’re acting with intent.
That means:
- Making exploration explicit, not “when you have time.”
- Assigning ownership.
- Setting concrete goals.
- Sharing learnings early, even when results are imperfect.
Waiting for permission is just another way to fall further behind.
The Bottom Line
If you’re behind, acknowledge it and move. You don’t catch up by being careful, exhaustive, or perfectly informed.
You catch up by being curious, acting quickly on real work, and learning faster than your comfort level would prefer. In March I would have told you the destination was orchestrating agents well. Four months later I can tell you it’s further than that: specs so good the agents don’t guess, gates so good you don’t read the diffs, and the grief of letting go processed on your own schedule. The people who started when they felt behind in March are already there.
AI doesn’t reward hesitation. It rewards momentum.
I’m happy to chat about this with anyone curious to learn more. My office hours are free and open.