From AI Curiosity to Everyday Craft: Closing the Adoption Gap (and Getting to Vibe Coding)

AI is showing up around work, but for most teams it is still not part of the everyday craft.

Some people use it constantly. Most people dabble. Others avoid it, not because they are against it, but because they are unsure where it fits, what "good" looks like, and how to use it safely.

At [MyCompany], that uncertainty has become an adoption gap. We see flashes of great output, then inconsistent results, and a lingering feeling that AI is either magic or noise.

This post is a working proposal to close that gap: treat AI as a first-class part of our engineering workflow, rethink the workstation around agent collaboration, and make outcomes observable from prompt to PR. The goal is not hype. The goal is more leverage, less confusion, and a culture where people can "vibe code" responsibly.

The Problem Isn't Interest. It's "How."

When someone isn't using AI at work, the reason is often practical:

"I don't know what to ask."
"I tried it once and it wasn't helpful."
"I'm worried it'll introduce bugs or security issues."
"I don't know how to integrate it into PRs and reviews."
"I don't want to be judged for using it."

If we want broad adoption, we can't rely on individuals to invent their own playbooks. Some will create great workflows; others won't know how to start. Either way, the organization ends up with uneven results and no shared language.

So the real opportunity is to formalize standard approaches: common patterns, shared tooling, and training that makes AI feel safe, useful, and routine.

What We Mean by "Vibe Coding" (At Work)

"Vibe coding" is a brand-new term, and right now it means everything and nothing. Sometimes it's used to describe chaotic behavior (prompt, paste, ship). Sometimes it's used to describe a genuinely productive workflow.

Underneath the meme, the real idea is simple: driving development through an AI proxy (one agent, many agents, or a mix of agents and humans) so the developer can spend more time steering and less time typing.

The ambiguity is a problem. If we want this to be safe, friendly, and normal, we should steer the terminology internally - not just inherit whatever the internet means this month.

The Reality: It's a Landscape, Not a Single Technique

When people say "vibe coding," they might mean any of these modes:

Inline assistance (copilot-style): human writes code, AI suggests deltas
Chat pair-programming: human stays primary actor, AI proposes snippets and explanations
Task delegation to an agent: human defines scope + constraints, agent edits files and runs commands
Multi-agent workflows: one agent plans, others implement, one reviews/validates

Each mode has different risks, evidence needs, and review expectations. Treating them all as one thing makes it hard to teach, hard to review, and hard to normalize.

A Term We Can Own: "Craft Coding"

Externally, "vibe coding" is a useful reference point. Internally, we need a more precise name for what we actually want people doing day-to-day. I'll call it Craft Coding:

Craft Coding = agent-proxied development where intent stays human, and evidence stays mandatory.

Craft Coding is not "trust the vibes." It's a workflow with three non-negotiables:

Intent is explicit: the goal, constraints, and definition of done are written down
Feedback loops are tight: tests, type checks, local runs, staging deploys (whatever fits the change)
Quality gates stay real: review, CI, security, performance - and rollback is considered

Techniques We Should Normalize (So It's Okay To Do)

If we want people to feel safe using AI proxies, we should name the techniques and teach them:

Plan-then-edit: agent proposes a plan + risks before touching code
Diff-first collaboration: changes come as small diffs with clear checkpoints
Evidence-first finishing: agent gathers the proof (tests/lint/repro) and attaches it to the PR
Scoped delegation: directory/module boundaries, timeboxes, and "don't touch" zones are explicit
Review companionship: agents help reviewers find edge cases, not replace judgment

When we normalize these patterns, people aren't "doing something weird." They're following a shared craft.

Training: Make It a Skill, Not a Personality Trait

We should treat this like any other capability rollout: train it, practice it, and make it observable.

A lightweight training path could look like:

Foundations: what agents can/can't do, and how to ask for useful work
Safety: data handling, prompt hygiene, and secure-by-default constraints
Workflows: plan-then-edit, spike-and-propose, refactor guardrails, review companion
Evidence: what "done" requires for different change types (bugfix vs refactor vs feature)
Graduation: engineers submit a small PR using Craft Coding, with artifacts attached

The point is speed and accountability: we can move faster if we build an environment where responsible agent-proxied development is normal, visible, and safe.

Rethinking the Workstation: From Editor-Centric to Workflow-Centric

Traditional engineering setups assume a human is the primary actor, and tools support writing code. AI changes this: now we have actors (agents) doing work on our behalf. That means the workstation needs to support:

Delegation: "Go investigate X", "Implement Y behind a flag", "Propose three options"
Visibility: What did the agent do? What files changed? What commands ran? What evidence supports the change?
Control: Approve, reject, rollback, constrain scope, and steer effectively
Repeatability: The ability to reproduce outcomes, not just accept them

If we don't redesign for that, people will keep using AI in fragile ways (copy/paste from chat, untracked changes, unclear provenance), which naturally reduces trust.

The Missing Piece: Observability for Code-Generating Agents

If we want agent and "agent swarm" workflows, we need to see actions and outcomes clearly. Today, many AI-assisted changes are effectively "black box": a chunk of code appears, and reviewers are left to reverse-engineer the reasoning.

That doesn't scale.

We should aim for agent observability, similar in spirit to production observability:

Traceability: What tasks were attempted, in what order?
Artifacts: Links to diffs, logs, test results, screenshots (if relevant), benchmarks, etc.
Decisions: What options were considered, and why this one was chosen?
Constraints: What rules did the agent follow (security boundaries, time limits, file scope)?
Outcomes: What changed? What tests passed? What risks remain?

If we make this normal, code review becomes easier, learning accelerates, and people stop feeling like they have to "trust the vibes."

Standardizing How We Use Agents: A Shared Playbook

To close the adoption gap, we should define a small set of "blessed" workflows that anyone can follow. Not 50 rules. Just a few repeatable patterns.

Here are some candidates:

1) The "Explain, Then Change" Workflow

Agent produces a short plan and risk notes before making edits
Human approves direction
Agent implements in small commits with clear messages
CI + tests are run, results attached
PR includes an "Agent Summary" section: what changed, why, evidence

2) The "Spike and Propose" Workflow (Great for uncertainty)

Agent explores multiple approaches
Produces a recommendation with tradeoffs
Optionally includes a small prototype branch
Human chooses, then implementation proceeds

3) The "Review Companion" Workflow

Agent reads a PR and highlights likely bugs, missing tests, edge cases, and docs gaps
Human reviewer uses it as a second set of eyes (not as an authority)

4) The "Refactor Guardrails" Workflow

Agent refactors only within a defined scope (directory, module, or file list)
Requires before/after tests or performance checks
Produces a rollback-friendly sequence of commits

These patterns make AI usage legible. They also reduce the social risk: people aren't "doing something weird," they're following a known approach.

What "Good" Looks Like: Evidence Over Confidence

To make people comfortable, we should reward evidence rather than confidence.

For agent-driven changes, "evidence" can be:

Tests added or updated
Existing tests run (and results recorded)
Type checks/lints passed
Benchmarks (when relevant)
Repro steps for a bugfix
Feature flags for risky changes
Clear rollback path

This is how we turn vibe coding into a professional superpower instead of a gamble.

Practical Next Steps for [MyCompany]

If we want this to stick, we should tackle it like any other capability rollout: training, tooling, and feedback loops.

Step 1: Create a "Minimum Standard" for AI-Assisted Work

A short internal guideline covering:

What data is allowed in prompts
How to document agent contributions in PRs
Required evidence for different change types (bugfix vs refactor vs feature)
When to avoid AI (or require extra review)

Step 2: Provide a Default Tooling Path

People shouldn't have to assemble their own setup. We can pick and support:

A standard "agent workstation" configuration
A way to capture agent actions (commands, diffs, test outputs)
A template for PR writeups that includes agent traces/artifacts

Step 3: Run "Vibe Coding Office Hours"

Low-friction sessions where people bring real tasks and learn:

How to scope prompts
How to iterate safely
How to use agents for investigation, implementation, and review
How to avoid common traps (over-trusting, under-specifying, skipping evidence)

Step 4: Measure Adoption and Outcomes

Not vanity metrics like "number of prompts," but:

Cycle time improvements
Reduction in rework
Test coverage movement in touched areas
Developer self-reported confidence
Review quality and defect rates

The Point: Make AI Collaboration Normal, Visible, and Safe

If we do nothing, AI adoption will remain uneven. A few people will get a lot of leverage; most will watch from the sidelines. If we do this well, we get something better than "more AI":

Shared language for how to use it
Standard workflows that reduce risk and anxiety
Stronger code review through better visibility
A culture where people can move fast and keep quality high

That's the version of vibe coding worth building: high-agency engineering with clear guardrails and clear evidence.