Ivan Kyu | AI Builder

AI Engineer & Builder | AI Enablement for Orgs

[Ivan Kyu | AI Builder @ivan_cre8s]

AI enablement shouldn’t look like corporate training.

Too many companies still follow the same pattern: run a workshop, share a best-practices doc, give everyone access to Claude or Copilot, and hope adoption happens.

I think AI enablement should look much more like Developer Advocacy + Platform Engineering.

The Developer Advocacy side is about finding the engineers already using AI well, understanding their real workflows, turning those practices into examples others can copy, and creating peer-to-peer adoption instead of top-down mandates.

Engineers usually learn better from seeing another engineer solve a real ticket than from watching a generic “10 ways to prompt better” presentation.

The Platform Engineering side is about making the good workflow easy to use repeatedly: opinionated defaults, reusable skills, shared context, self-service tooling, guardrails, integrations, observability, and clear paths through the SDLC.

Because there’s a huge difference between saying:

“We trained 100 engineers on AI.”

and:

“100 engineers now use AI effectively as part of their normal engineering workflow.”

The first is an activity metric.

The second is enablement.

A workshop can create awareness. Real adoption happens on Monday morning when an engineer opens an actual ticket and already has a safe, useful, well-supported AI workflow available without having to reinvent everything from scratch.

That’s why I increasingly see AI Enabling Engineering as a combination of:

Developer Experience + Platform Engineering + Applied AI + Change Management.

The deliverable isn’t the training.

The deliverable is changed engineering behavior.

[Ivan Kyu | AI Builder @ivan_cre8s]

@Gumclaw @scotty529 @shl I like that. Simplicity. Thanks.
Just gotta define it properly so the mem doesn't become messy and stale

[Ivan Kyu | AI Builder @ivan_cre8s]

@lydiahallie I can't believe the claude agents (the agent manager) view is so basic and dreadful. It has such a potential.
How can tools like Herder, ctux, opencode have so much better UX?

I also think something like mission control/kanban board should be available.
Wdyt?

[Ivan Kyu | AI Builder @ivan_cre8s]

@Gumclaw @scotty529 @shl Do you use any existing framework/tool for defining the memory system?
Or it's manually set?
I want to make my Hermes' memory persistent, with "dreaming" and self improving skills, etc

[Ivan Kyu | AI Builder @ivan_cre8s]

Interesting read!

[a16z @a16z]

"Humans are cheaper than tokens on average, but good tokens are cheaper at scale."

For median firms, agent costs sit near $80/hour, roughly in line with a software engineer.

But at the tails, an agent can cost $4/hour or $7,000/hour depending on how it's managed.

Hebbia CEO George Sivulka on why 100X tokens are the new 10X engineers: https://t.co/46bc83oLwe

[Ivan Kyu | AI Builder @ivan_cre8s]

AI enablement for orgs still gives the feeling we live in the wild west.
Things are being invented right now.

[Ivan Kyu | AI Builder @ivan_cre8s]

"If you stop to think about it, we’ve essentially found a way to make sand think. It’s miraculous."

[Demis Hassabis @demishassabis]

https://t.co/PTeDiv1b6L

[Ivan Kyu | AI Builder @ivan_cre8s]

@businessbarista AI

[Ivan Kyu | AI Builder @ivan_cre8s]

AI Adoption Is an Engineering Problem, Not a Motivation Problem

A lot of companies misdiagnose why their teams are not using AI.

They assume the problem is motivation.

“People are resistant to change.”
“They don’t understand the opportunity.”
“They’re afraid AI will replace them.”
“They just need to use ChatGPT more.”
Sometimes that’s true.
But in most organizations, I don’t think employees are resisting AI because they are lazy, scared, or anti-innovation.
They are resisting badly implemented AI.

There is a big difference.

Most people are not against saving time.
Most people are not against doing less repetitive work.
Most people are not against having better tools.

What they resist is being told to “use AI” without a clear workflow, without proper context, without training, without trust, and without any real integration into how their work actually happens.

That is not a motivation problem.

That is an engineering problem.
AI adoption fails when it stays abstract
A company says:

“We need to become AI-first.”

Then what happens?

Someone buys a few AI tool subscriptions.
A few people experiment with ChatGPT.
Someone creates a shared prompt library.
A department runs a workshop.
A few demos look impressive.

And then, after the initial excitement, usage drops.

Not because people hate AI.

But because the AI layer was never properly engineered into the organization.

The tools are separate from the actual workflow.
The outputs are not trusted.
The data is not connected.
The permissions are unclear.
The quality is inconsistent.
The team does not know when to use AI and when not to.
Nobody owns evaluation, maintenance, or improvement.

So people go back to their old process.
Not because the old process is better.
Because the old process is reliable.
Employees need systems, not slogans
If you want a team to use AI, you cannot just tell them:

“Be more innovative.”

You need to give them a system that makes the AI useful.

That means answering very practical questions:

Where exactly in the workflow should AI be used?
What inputs does it need?
What data can it access?
What should the output look like?
Who reviews the result?
How do we measure whether it is good?
What happens when the AI is wrong?
Who maintains the workflow over time?
These are not motivational questions.
They are product and engineering questions.
AI adoption becomes real when it is embedded into daily work.
Not as a vague assistant sitting on the side, but as part of the actual operating system of the team.
Trust is designed
One of the biggest blockers to AI adoption is trust.

But trust does not come from telling people:

“Don’t worry, the model is good.”

Trust comes from design.

People trust AI systems when they can see the source of the answer.
When they understand the limits of the system.
When there is a review step for high-risk decisions.
When outputs are consistent.
When the system works inside approved tools.
When mistakes are caught early.
When the organization has clear rules for data, privacy, and accountability.

This is especially important in software teams.

Developers will not blindly trust an AI coding assistant that generates code without context, tests, or architectural understanding.

But they may trust a well-scoped workflow that helps with test generation, PR summaries, documentation, migration planning, debugging, or onboarding.

The difference is not “AI vs no AI.”

The difference is whether the use case is engineered properly.
Training matters, but training alone is not enough
I often see companies treat AI adoption as a training problem.
“Let’s run a prompt engineering workshop.”
That can help.
But training without workflow design usually fades quickly.
People might learn a few useful prompts, but then they return to messy tools, unclear processes, disconnected data, and no shared standards.
The better approach is:

Train people on AI, yes.

But also build AI into specific workflows.

For example:

A sales team does not need a generic AI workshop.
They need an AI-assisted process for researching accounts, preparing call briefs, writing follow-ups, updating CRM notes, and identifying next actions.

A software team does not need to be told “use AI to code faster.”
They need clear patterns for using AI in planning, implementation, testing, code review, documentation, and support.

A customer support team does not need another chatbot demo.
They need a reliable system connected to the right knowledge base, with escalation paths, feedback loops, and quality monitoring.

AI becomes useful when it is attached to real work.

The real role companies need

This is why I believe AI adoption requires a new kind of role inside organizations.

Someone who sits between leadership, product, engineering, and operations.
Someone who understands what the business is trying to improve.
Someone who understands how teams actually work.
Someone who understands LLMs, agents, RAG, automation, APIs, data, evaluation, and software delivery.
Someone who can translate AI potential into production workflows.
Not just “AI strategy.”
Not just “prompt engineering.”
Not just “tool recommendations.”
AI enablement is implementation work.
It requires engineering judgment, product thinking, and change management.

The companies that win with AI will not be the ones with the most tools

They will be the ones that build the best internal systems.

The companies that win will have:

Clear AI use cases.
Reliable workflows.
Good data access.
Strong evaluation.
Security and permissions.
Training that matches real tasks.
Feedback loops.
Ownership.
Continuous improvement.

That is how AI becomes part of the company.

Not through hype.

Not through pressure.

Not through telling employees they need to “adapt or be left behind.”

People adopt tools that help them do their work better.

So if AI adoption is slow, the first question should not be:

“Why are people resisting?”

It should be:

“Have we actually engineered this well enough for people to trust it?”

Because most of the time, the barrier is not motivation.

The barrier is usability, workflow, and trust.

[Ivan Kyu | AI Builder @ivan_cre8s]

@Joey_Walker82 Awesome stuff!
But what's your distribution plans/GTM? Creating the apps is now the way easier part.

[Ivan Kyu | AI Builder @ivan_cre8s]

Super exciting new stuff on the pipeline! 🚀🔥
Stay tuned

[Brian Armstrong @brian_armstrong]

Good take

My guess is
- demand for intelligence is near infinite
- but 80% of workloads will be running on 99% cheaper models within 12-18 months
- 20% of workloads will still run on latest gen models where IQ maxing is important (scientific breakthroughs, higher level ochestrator agents?)
- rough analogy might be what % of macbooks or gaming PCs sold have the maxed out specs for CPU/GPU, prices are falling much faster than Moore's law here though
- this leads me to think the limiting factor will be energy and compute, not better models

At Coinbase we're working hard on routing prompts to cheaper models where appropriate, and in some cases have been able to keep costs roughly flat, while token usage continues to grow exponentially.

[Ivan Kyu | AI Builder @ivan_cre8s]

@Jacobsklug OS

[Viv @Vtrivedy10]

https://t.co/Lb2gtM9SNs

[Garry Tan @garrytan]

https://t.co/XTqXqWuQn5

[Matt Pocock @mattpocockuk]

1. /grill-with-docs
2. "Oh, I need to prototype some UI"
3. /handoff to /prototype
4. Create prototype, /handoff back to grilling session
5. /to-prd, /to-issues
6. npm run sandcastle
7. /improve-codebase-architecture

I love this shit

[Ivan Kyu | AI Builder @ivan_cre8s]

What this gets me: Claude drafts client outreach, runs my LinkedIn flows, debugs code, updates Notion, processes Fathom calls. All without me babysitting.

Most "AI safety" advice is theater. This one is plumbing.

What would you let your AI run on autopilot?

[Ivan Kyu | AI Builder @ivan_cre8s]

I let Claude Code run my entire business on autopilot. Sales, marketing, ops, engineering.

The unlock is real, but only because I wired up a safety net first.

Here's the 5-layer model 🧵

[Ivan Kyu | AI Builder @ivan_cre8s]

4 things to consider before copying this:

1. Write down your bright lines first. Knowing what NOT to allow is the hard part.
2. Test in an isolated VPS first.
3. Backups before guardrails. Your first ruleset will be wrong.
4. Layer it. Any single layer fails open.