Entering a new phase of 2025, I’m curious about robotics developments in 2026. This article documents my thinking on AI-driven engineering enterprises, structured for both personal clarity and guidance for others.

From Classic to Vibe Coding in the Enterprise

Traditional engineering prioritized predictability and clean abstractions. However, today’s constraints have shifted: code costs less, iterations accelerate, and demand grows continuously. The real bottleneck now involves deciding what should exist and pivoting before sunk costs create inertia. This transition marks the shift toward “vibe coding.”

Classic Coding vs Vibe Coding

Classic models excelled under different constraints. Vibe coding emphasizes clarity and adaptability over precision. Humans determine what should exist and why; machines handle mechanics. The critical vulnerability emerges when intent remains unclear—then rapid execution moves in wrong directions.

Vibe Coding as Higher-Level Abstraction

Vibe coding represents another step up the abstraction stack. Software continuously removes mechanical details so engineers focus on meaning. It operates above programming languages rather than replacing them. Just as developers stopped thinking about registers, future engineers will emphasize behavior, boundaries, and failure modes over syntax.

Ownership, Quality, and Failure

As leverage increases, these patterns shift together. Quality cannot depend on understanding every code line once AI participates. Quality becomes systemic: contracts matter more than comments, tests express intent, monitoring proves essential, and rollback capability is expected. Failures occur more frequently but recover faster than traditional infrequent-but-severe failures.

Judgment Becomes the Scarce Skill

AI excels at patterns but lacks judgment. The critical question shifts from “Is this correct?” to “Should this exist?” Experience, not syntax, answers this question.

Change Volume and the Merge Problem

Increased output makes coordination the bottleneck. Vibe’s speed enables rapid iteration but risks unclear scope hallucination, creating large PRs and merge conflicts simultaneously. These problems signal changes are oversized or intent is vague, not tooling failures. The goal involves changes easily combined, undone, and understood—requiring thoughtful team sizing.

Product and Engineering Must Move Together

Without product workflow changes, AI accelerates wrong work. Clear intent beats detailed specifications. Product and engineering become co-authors of outcomes rather than relay-race participants.

Enterprise Safety Without Slowing Down

Enterprises redesign risk management rather than eliminating it. The shift moves from asking who approved something toward understanding why systems allowed it. This approach proves harder but scales better and may require fewer meetings.

Baby-Steps Implementation

I haven’t witnessed these practices at scale yet. I propose three initial focuses:

1. Generate specs from existing code

Extract behavior, contracts, and assumptions from current systems, surfacing gaps between intended and actual functionality.

2. Anchor on intent before new changes

Be explicit about what should exist and why, reducing surprises and improving both human and machine effectiveness.

3. Keep blast radius small, protect with tests

Start in low-risk areas with small changes, introducing excessive testing and documented guardrails for learning rather than speed.

Closing

I view vibe coding not as abandoning engineering discipline but elevating it. Work shifts from syntax to judgment, enabling creativity. Less code writing occurs; more system shaping happens. Though uncomfortable for quality-focused teams, this represents genuine leverage advancement.

I haven’t yet read Gene Kim and Steve Yegge’s recently released “Vibe Coding” book—curious about alignment with professional thinking on the subject.