weekly prompts 04 | AI adoption isn't merely technical
why AI adoption is blocked by capability and trust?
this is a tech section in experimental’s newsletter. if you prefer follow weekly prompts on linkedin & unfollow this section here on substack.
march 8th, 2026
this week: why AI adoption is blocked by capability and trust, and how it plays out inside your pipeline the moment a model enters it.
let’s go (:
____
git fetch: the AI adoption gap
anthropic published a report on where AI is theoretically capable of making a dent and where it already should have, but hasn’t.
blue is theoretical coverage per job category. red is observed adoption. stare at legal and business & finance for a second:
in 2019 i was at deloitte automating workflows for accountants and lawyers. not with llms, but with robotic process automation, scripts, macros, and it was the low-code wave! so, uipath, power automate, the whole thing... technology that was already objectively faster and more precise than a human being.
the promise was clear: business people would do what developers do. everyone would automate everything with drag and drop. no engineers needed. and further out, so much of finance and accounting would be automated that entire roles would disappear.
___
git push --force: shipping automation nobody asked for
what actually happened: companies put real effort into getting business people to do it. they ran training sessions, bought licenses, made decks about the future of work. and still, nobody in a suit wanted to touch it for 40 hours a week. they had actual jobs, automation was someone else’s problem.
or they saw the automation wave oversell and underdeliver, maybe?
the platforms got expensive fast, only large companies could afford them at scale, and you still needed an orchestrator specialist, a developer for the edge cases, and someone to make sure people actually used the thing: yes, a surprising number of useful automations were built, handed over, and quietly never ran in production.
six years later models are better, we are what? 2 years in AI? but the chart still looks like this:
my instinct is to say: the gap has never really been about the capability of the technology, or about turning the business worker into a technical one with a powerful tool... actually, i don’t think that gap ever fully closes, it has always been more about access control and internal politics.
legal and finance, to keep the example, haven’t adopted more AI partly because the models still aren’t reliable enough for the liability surface those industries carry. a hallucinated clause in a contract isn’t a trust problem. it’s a product problem, and they’re correctly pricing the cost of a silent failure in a regulated environment, so the gap is still there.
now, don’t get me wrong. AI-based solutions will take a meaningful share of these occupations, because part of trust is downstream of capability. when the systems become reliable enough, adoption follows.
today i’m playing a bit of both sides here. i’m skeptical about how fast the gap closes, but at the same time my long-term prediction is almost a bit utopian, or catastrophic, depending on how you look at it...
___
git branch: the startup window
that complexity is usually framed as an opportunity for mid-sized companies and we’ve heard the argument before with mobile, cloud, low-code: being small and fast is a structural advantage.
but this time the window is shorter, my guess is: one to two years for small and mid-sized companies to move before big solutions consolidate, depending on the industry.
the window closes faster than small companies can operationalize, because speed at the prototype stage doesn’t compound. execution does, so when large firms move, they move with distribution, compliance infrastructure, and customer trust already built.
___
git permissions: who gets access to the sauce
so the honest version of the opportunity isn’t “small is better”, it’s more closer to this: there’s a window where experimentation is cheap enough that you can build something real before the category gets defined for you.
that window is open, but it’s also temporary, and it requires operational follow-through that most companies “moving fast” aren’t actually doing.
the move for mid-sized companies isn’t to imagine a long future inside that gap, it’s to capture it while it’s open: you can now build a working prototype in days instead of months... not just replicating existing processes, but enriching them with knowledge that wasn’t accessible before.
but to do that, business owners who want any shot at competing with increasingly monopolistic firms have to do something uncomfortable: they have to hand their entire sauce to a random developer. their processes. their exceptions. their workarounds. every undocumented thing keeping the operation running. all of it. on a shared drive. with someone they met three weeks ago.
the developer sits in the middle of this, building the trust layer that neither side can provide on their own: between the model, the client expectations of handing over their entire process logic to someone they met three weeks ago, and the big players that already dominate the market.
this was already a bottleneck during the automation wave. now the trust stack has more layers:
0_ trust the developer
1_ trust the model
2_ trust how the developer is using the model.
that third one is invisible to most clients, it’s where the real costs hide, and where the biggest misconceptions live right now... which brings me to what i was building this week.
___
git log: tracing the disappearance
I’m building a competitive analysis platform for a client. the core of it: read and classify a large volume of industry documents: the kind of work that used to require a dedicated research team at a large firm. AI makes it possible at a different cost curve. but AI in the middle of a real system is a different animal than AI in a demo.
most of the pipeline was built quickly with AI assistance. fast enough that someone who doesn’t usually work with this stack could get something running, which is the promise of this moment: you can assemble a working system much faster than before. ofc.
but speed hides a different kind of fragility. the prompt was loose, the contracts between stages weren’t clearly defined, and everything looked correct at the surface level, until you looked at the data.
the file classification pipeline looked fine. the dashboard showed “X files classified.” the process completed without exceptions. logs were clean... it wasn’t fine.
files were entering the pipeline, going through every stage, and not showing up in the database. no error. no warning. the pipeline thought it had done its job. the database had no idea those files ever existed.
three distinct failure modes, each quieter than the last:
_ the first: a nearly-empty file. the code identified it, decided there wasn’t enough content to justify an AI call, skipped it. no output. no database row. the file evaporated.
_ the second: the AI reads a document and returns “Global Brand.” the system checks the taxonomy — there’s Global Brand Owner, Regional Brand Owner — but “Global Brand” without “Owner”? not recognized. rejected, silently. no note that it was attempted. the field disappears.
_ the third: even if the first two let something through, a final check verified whether the value had a matching entry in the taxonomy table. wrong capitalization, incomplete seed data — it printed a warning to the console and moved on. the row was never inserted. the file appeared classified in the JSON output. the database had no idea it existed.
none of this is new! empty record handling, taxonomy mismatches, constraint validation errors... the AI layer doesn’t introduce new failure modes, it just makes the old ones harder to anticipate, and harder to catch, because the output looks reasonable. the fix has a name: defensive programming, but how to implement it now that the contract is probabilistic?
____
git blame: the contract nobody wrote
in traditional systems, observability is about capturing state: what happened, when, with what inputs. logs, stack traces, metrics... the contracts can be confuse, but are explicit: types, function signatures, tests. when something breaks, the system tells you.
AI-in-the-middle systems are different. the contract isn’t explicit anymore, your code calls a model, the model returns something that looks reasonable, passes the validation you wrote, and still maps to nothing your system understands.
the instinct is to patch the edges: add more aliases, loosen the matching, make the search more tolerant, but that assumes the model behaves like deterministic code. it doesn’t. the output will always produce edge cases, that’s not a bug you close, it’s the nature of the contract you’re working with, which creates a tension you can’t resolve cleanly.
you need the model to reason beyond your explicit rules, that’s the whole point! but you also need it not to invent things your system can’t handle. so, the more freedom you give it, the more value it can generate. the more you constrain it, the safer the pipeline becomes (but then you have what, an expensive regex?)
the questions to worry about now are: how much uncertainty your system tolerates, at which step, and what failure costs if it goes undetected. (can you answer that in AI speed?)
right now, developers sit in the middle of that calibration. part of the job is still technical, schemas, validation layers, defensive checks... and translating messy business processes into something a probabilistic system can operate inside: defining the contracts, anticipating the failure modes, deciding what “good enough” actually means for that pipeline.
__
git rebase: developers removed from history
and there’s an uncomfortable implication here. the reason so much scaffolding exists today is partly because models still struggle to follow structured contracts reliably. the expectation, explicitly promised by the people building them, is that this improves... as structured output, tool use, and self-correction get better, some of that scaffolding shrinks.
if that happens, the translation layer developers are currently building starts to stabilize and historically, when translation layers stabilize, platforms absorb them. cloud platforms absorbed infrastructure management. payment platforms absorbed the complexity of payment networks.
which means the interesting gap in those adoption charts will actually be filled by the AI companies themselves. it might be what happens to everyone whose value today comes from translating between the business and the machine (developers, consultants, internal operators) when the platform learns to speak both languages.
___
git push origin monopoly
if that translation layer stabilizes fast enough, the business logic currently being extracted to build these systems doesn’t just power the company that implemented it... it flows upstream into the platforms themselves.
and historically, when platforms absorb the complexity of a layer, they also absorb a large part of the value created in that layer... so the real risk isn’t only that developers become less necessary as translators (sorry for bringin that up last minute lol), but it’s that if this shift happens quickly enough, the gap between capability and trust that companies are currently bridging with their own AI systems becomes the raw material for the next generation of platform monopolies.
in other words: the question isn’t just who fills the gap. it’s who captures it once it closes.
___
quick note: this newsletter was previously in Portuguese as “commits da semana.” it’s now in english “weekly prompts”, to reach more people. if you were here before: olá, bem-vindo à versão gringa (:
___
until the next prompt, Michelle (:
