Vibe coding and the 90-day wall
AI tools make building fast, but unconstrained prompting builds a "payday loan" of technical debt. At 90 days, the codebase decays, and making simple changes becomes a struggle.
AI Help
AI activity does not become business impact by itself.
Most mid-market companies are not short on AI activity. They have pilots, tools, use cases, committees,
strategy decks, and experiments.
What they lack is the operating model to decide which AI bets matter, fund learning without fake certainty, redesign
workflows around value, and give sponsors a clear answer to the question:
“What did you do with my money?”
I help leadership teams move from AI Theater to real business impact — using product-style operating discipline and AI-native advisory workflows to create sponsor-ready visibility with minimum additional work.
The Reset
Stop treating every AI idea the same.
AI Theater usually starts innocently: a few useful experiments, a few impressive demos, a few leaders asking teams to move faster. Then the list grows faster than the decision system around it.
I work with you to build a practical way to discuss AI work across product, technology, finance, and leadership. The shared language matters because every function tends to see a different version of the same bet.
The goal is a simple routine for deciding which bets deserve more depth, which need to change, and which are mostly consuming attention.
What I Look For First
The useful question is not how many AI ideas you have.
When AI work is not paying off, I look for the decision problem underneath the activity. Sometimes the issue is a weak value story. Sometimes nobody owns adoption. Sometimes the bet is technically interesting but too far away from the constraint the business actually has.
The first read usually comes from five questions:
- Which AI bets are active, and which ones are only staying alive because nobody has said no?
- What workflow is supposed to change if the bet works?
- Who would pull for the change because it makes their work better?
- What evidence would justify more funding, more attention, or a stop decision?
- Where did AI speed up one step while the rest of the value stream stayed slow?
Why It's Needed
Your funding process wants certainty. AI rarely gives it.
AI can make some work faster, but it does not remove uncertainty. Many organizations still fund AI like traditional IT work: upfront business cases, annual allocations, and milestone reporting.
That creates false certainty. Models change, vendor promises change, and teams learn what users will actually adopt only after they touch the workflow. A year's worth of pilots can become a noisy list of demos before anyone knows which bets deserve depth.
That is the blocker: real money is being spent, but there is no lightweight way to adapt, grow what works, or stop what does not. The way you make funding decisions has to match the reality of AI work.
Is This For You?
When the AI work is hard to explain.
This tends to fit mid-market leaders who have already spent real money on AI and are hearing the accountability question: "What changed?"
This is worth looking at when:
- You have a pile of pilots: You have 20 different AI efforts running in silos, but no shared way to decide what should grow, change, or stop.
- Priorities keep changing: Leadership changes AI priorities every quarter based on external hype, and teams start to tune out.
- You cannot explain what changed: You have spent real money on AI licenses, pilots, or consultants, but the CFO and the board are asking what the business can feel now.
The Resistance Risk
You can mandate tool usage. You cannot mandate adoption.
The biggest risk in AI work often is not the model. It is whether the people who do the work see a reason to use it. When leadership mandates tool rollouts from the top down, teams push back. They check the compliance box, use the tool to generate some noise, but their daily work stays the same.
I help you treat AI adoption as something people have to want because it makes the work better. If teams are resisting a new AI tool or workflow, it is often because the change has not solved their daily friction.
We start with people who are close to the problem, find where their work is stuck, and invite them to shape the AI changes. Their friction becomes useful information, not resistance to overcome.
AI-Native Delivery
The way we work models the shift you are trying to make
A lot of AI transformation work is still delivered like traditional consulting: interviews, workshops, slide decks, and months of manual synthesis.
If the goal is to help your organization operate differently with AI, the transformation work itself should run on AI.
My engagements use AI-native workflows, agents, copilots, skills, and reusable advisory assets to accelerate delivery: synthesizing interviews, mapping portfolios, identifying workflow bottlenecks, drafting value hypotheses, and preparing sponsor decision-support dashboards.
The point is not to automate leadership judgment. It is to reduce governance drag and manual reporting so humans can focus on what matters: strategy, tradeoffs, risk, trust, funding, and choices.
What to Expect
A working sprint, not a static plan.
- 01
See what is in flight
We start with the pilots, tools, spending, and plans already in motion. Then we add a few direct signals from the people closest to the work.
- 02
Sort the bets
We separate the AI bets that could matter from the smaller experiments. We define what would make each bet worth more time, more money, or a stop decision.
- 03
Change the decision routine
We work with the people making business, product, and finance decisions so AI work is reviewed by learning and value, not just status.
- 04
Try it with real decisions
You try the new routine on real AI decisions, adjust it when it gets awkward, and keep what helps leaders make better calls.
Sound Familiar?
Friction points that stall AI value.
A pile of pilots, not a portfolio
You have 20 AI efforts running in silos. Nobody can say which ones matter, which are risky, which are working, and which should stop.
The code is fast, the review is stuck
Developers generate code instantly, but pull requests back up in code review queues. Reviewing massive AI diffs is exhausting, leading to rubber-stamping or stalled releases.
Spec starvation and rework
Because coding is nearly free, developers code vague specifications instantly. This turns uncertainty into massive rework cycles rather than actual learning.
What Looks Different
What I see when AI work starts creating value
AI value usually shows up as better choices, not more activity
They are making AI decisions differently. After 20 years working with organizations on product, portfolio, and agility problems, these are the moves I would look for.
- 01
They see AI bets as a portfolio
They don't just have a list of pilots. They can see what's in flight, what's risky, and which bets actually deserve budget and focus.
- 02
They shift reviews upstream
Instead of reviewing massive, thousand-line AI-generated code diffs, engineering leads review the Markdown specification (intent) before code is generated.
- 03
They stage funding by confidence
They fund learning milestones, not project roadmaps. They buy information to answer the riskiest viability and feasibility questions before scaling investments.
- 04
They close the product-FDE loop
Embedded deployment engineers do not build bespoke, unmaintainable client silos. They act as field sensors, feeding local workflow patterns back to the core platform.
- 05
They earn adoption in the workflow
They treat AI adoption as a workflow pull, not a top-down mandate. If teams aren't pulling for the tool, they don't buy seats.
- 06
They govern in the flow
They express the operating model as a living configuration layer ('ambient intelligence') that travels with the work, rather than slides or playbooks.
Questions I Get
Questions leaders ask when AI investment is not turning into impact
Why are our AI pilots not paying off? +
Usually because the pilot proved that AI can produce an artifact, not that the work changed in a way the business can feel. The next move is to identify the constraint, clarify who owns adoption, define what evidence would justify more investment, and stop treating every pilot as equally important. For the deeper diagnosis, read Why Your AI Effort Has Activity But Not Impact.
How do we move from AI pilots to real use? +
Do not make the decision only about technical readiness. A serious AI bet needs someone to own the work, enough data access, clear risk controls, real adoption pull, support, and evidence that it helps. If those pieces are missing, the pilot may keep looking promising while never becoming part of how work gets done. A useful starting point is If AI Coding Made Engineering Faster, Why Isn't The Business Faster?.
Where should we start if AI adoption is not getting traction? +
Start where traction is missing. Look at the active AI bets, the workflows they are supposed to change, the people who need to pull for them, and the decisions that are waiting. If the portfolio is noisy, narrow it. If adoption is weak, treat it as a product problem. If engineering got faster but value did not, find where the bottleneck moved. The AI strategy hub at AI Strategy: From AI Activity to Business Impact maps the related articles.
We've already spent a lot on AI. Is the answer to slow down? +
Not slow down — get intentional. Most AI portfolios have too many bets running at the same depth. The fastest path to value is usually fewer bets with more depth, better ownership, and clearer funding logic. That's the shift from FOMO to JOMO — from reacting to every AI announcement to making deliberate bets where the business constraint actually sits.
How is this different from the AI strategy work we already did? +
Most AI strategy produces a list of things to build. The gap is rarely the list. It is how bets get funded, who owns the result, how decisions get made when the data is incomplete, and whether teams can actually adopt what gets built. That's the layer I work at.
Our problem is technical — we need better models and data infrastructure. +
Sometimes. But in most organizations I work with, the AI works well enough in demos. The breakdown happens moving from demo to production, from one team to cross-functional, from experiment to business result. If your POCs keep impressing but never shipping, the bottleneck probably isn't the model.
Are you selling AI software? +
No. I do not sell seats, usage, or a software platform. I use AI-native workflows, agents, copilots, skills, and reusable advisory assets as part of the service infrastructure. They help us synthesize findings faster, reduce reporting overhead, and build better decision-support tools. Human judgment stays where it matters: strategy, tradeoffs, risk, trust, and leadership decisions.
Are you an AI implementation vendor? +
No. I do not focus on vendor selection, data engineering, model training, or software integration. I focus on the operating model and governance: portfolio visibility, staged funding, closing the product-FDE loop, shifting reviews upstream, and sponsor-ready decision cadences.
We're a mid-market company, not huge. Is this relevant? +
Mid-market organizations often have a real advantage: shorter decision chains, less political friction, and more ability to move quickly. But they also have less room for expensive mistakes. The organizations I typically work with range from a few hundred to a few thousand people: big enough for the coordination problem to be real, small enough to actually fix it.
What does working together actually look like? +
It depends on where you are. Some teams need help seeing their AI work in one place and deciding what matters. Others know the problem but need help changing how AI work gets framed, owned, and reviewed. I'd rather understand your situation first than describe a standard answer. That's what the conversation below is for.
Next Conversation
Let's figure out what's actually stuck
Bring your current AI situation: what you've invested in, what's working, and what still feels stuck. No pitch, no one-size-fits-all answer. I'll share what I see and you'll leave with a clearer picture of where the real constraint may be.