Forem: Rabieb

10 Months Experience With AI-Generated Software - Vibe Coding only

Rabieb — Sat, 09 May 2026 04:54:35 +0000

When AI commoditizes implementation, truth itself becomes the new engineering discipline

Neil Hoyne recently shared a report examining the operational reality of AI-assisted software development inside modern companies.

Its central message was far more cautious than the public AI narrative dominating boardrooms and LinkedIn feeds. AI, the report argues, is not a miracle solution for struggling organizations. It is an amplifier. Companies with clear systems, disciplined engineering cultures, and strong operational foundations may accelerate dramatically.

But organizations already suffering from fragmented processes, unclear ownership, weak governance, or architectural drift often experience the opposite effect: complexity compounds faster than they can control it. Technical debt accumulates invisibly. Verification costs rise. Governance pressure intensifies. Internal contradictions scale across teams and systems simultaneously.

The result is a growing dilemma for many companies: AI increases production capacity at the exact moment organizational coherence becomes harder to preserve.

The report is right.

And yet, over the last months, something deeply unusual happened during the development of matbakh.app.

Not because the report was wrong. But because reality became stranger than the report itself.

matbakh.app was built almost entirely through AI-assisted generation. The codebase, the runtime architecture, the infrastructure topology, the onboarding systems, the governance layers, the explainability runtime, the AWS orchestration, the continuity models, the disclosure systems, the AI analysis pipelines, the authority routing, the drift controls, the constitutional invariants, the observability structure, the persistence contracts, and even large parts of the operational documentation were generated collaboratively with AI systems.

Not copied from templates. Not scaffolded lightly. Generated.

Human orchestration remained central. But traditional implementation labor largely disappeared.

And according to the logic of the report, this should have collapsed under its own weight.

In many moments, it nearly did.

Because the report’s warnings were not theoretical. They appeared everywhere.

AI accelerated:

duplicate runtime paths
transform drift
authority conflicts
hidden state coupling
orphaned flows
contract mismatches
disclosure inconsistencies
persistence fragmentation
architectural crossover

The report warns that “code can be a liability, not an asset.” That became painfully real. AI made generation almost frictionless, but verification became brutally expensive. Entire days were spent tracing runtime contradictions that no human intentionally designed, but that emerged naturally from high-speed AI generation.

The report warns about “hidden fees.” That was also true. The real cost was never tokens or inference. The real cost was governance. Validation. Runtime forensics. Boundary enforcement. Architectural reconciliation. Truth maintenance.

The report warns that “AI amplifies dysfunction.” That also proved true.

But something else emerged alongside the dysfunction.

A second reality.

Because while the codebase drifted, another layer began to evolve in response: governance itself.

Not corporate governance. Runtime governance.

At some point, the project stopped behaving like a normal startup codebase and started behaving more like a constitutional system.

Authority boundaries appeared:

disclosure authority
render authority
onboarding authority
persistence authority
identity authority
continuity authority
Invariants were introduced:
fail-closed disclosure
continuity preservation
anti-crossover routing
session-context authority
onboarding atomicity
runtime legality enforcement

Drift detection systems emerged. Topology validation emerged. Constitutional hardening emerged. Evidence-backed runtime verification emerged.

The strange part is this:

None of this was planned upfront.

It emerged because AI generation created pressure so intense that the only way to survive was to explicitly define truth.

The report argues that AI amplifies organizational maturity.

matbakh.app suggests something more unsettling: organizational maturity itself may begin emerging as a survival response to AI-generated complexity.

That is a very different claim.

Traditionally, engineering maturity came first. Then systems scaled.

Here, the system scaled first. Maturity was forced into existence afterward.

This is dangerous. But also extraordinary.

Because the project simultaneously validates and contradicts the report.

The report is correct that AI can accelerate chaos. It absolutely did.

But the report implicitly assumes that governance structures must already exist before AI acceleration becomes viable.

That assumption may no longer be fully true.

Under enough pressure, governance itself can become an emergent property.

The role of the human changed fundamentally in this process.

The human was no longer primarily:

writing functions
implementing endpoints
building interfaces
wiring infrastructure

Instead, the human became:

a boundary setter
a contradiction detector
a truth maintainer
a runtime constitutional architect

The work shifted upward.

The hard part was no longer creating software. The hard part became preserving coherence.

This may be the real transition happening in the AI era.

Not: “AI writes code.”

But: “AI forces humans to become governors of systemic truth.”

That is a much more profound shift.

And it explains why so many AI-generated systems currently feel unstable.

Most organizations are still optimizing for code production. But AI has already commoditized production.

The scarce resource is now:

coherence
continuity
runtime integrity
disclosure boundaries
architectural truth

The report argues that the future belongs to organizations capable of surviving the learning curve.

I think that is correct.

But matbakh.app revealed something else too:

The learning curve is not merely technical.

It is philosophical.

Because once AI can generate almost anything, the defining question is no longer: “Can we build it?”

The defining question becomes: “What is allowed to become true inside the system?”

And that changes software engineering completely.

Report is here:
The ROI of AI-assisted Software Development by Google Cloud

{https://media.licdn.com/dms/document/media/v2/D4E1FAQFUQnGnnetorg/feedshare-document-sanitized-pdf/B4EZ4ILbdTH0A8-/0/1778253681944?e=1778868000&v=beta&t=iecF0i7Zu6iuVHszHmhsu-eCrzRbEFxnycyBd3QRFqQ}

From Spec to Shipping in Hours: How Kiro Helped Us Build Matbakh’s Visibility Coach

Rabieb — Mon, 15 Sep 2025 07:20:42 +0000

TL;DR

With Kiro as our AI-powered IDE and a tight spec, we shipped a working Visibility Coach for restaurants in hours, not weeks. Kiro handled spec-to-code, enforced steering & hooks, and helped us produce a stable CLI that generates Top-5 Next Best Actions plus a one-page Markdown playbook. We closed the loop with tests, type safety, and format/lint gates to make the demo rock-solid for the hackathon.

Problem & Outcome

Local restaurants and cafés are great at hospitality—but struggle with digital visibility. Our goal was to give them confidence and clarity: “Do these five things next,” packaged in a shareable, one-page playbook.

Outcome: a minimal, reproducible pipeline from a restaurant URL/mini-profile → scores → plan → Markdown. Everything is small, deterministic, and built to demo in under three minutes.

Why Kiro

We used Kiro to collapse the “talk → code → test → iterate” loop into a single, guided flow:

Spec-to-Code: We wrote a crisp spec (/.kiro/specs/visibility_coach.md) with user stories, acceptance criteria, and a test plan.
Steering: A /.kiro/steering.yaml defined architecture, coding rules, and quality gates (TypeScript strict, ESLint/Prettier, Jest).
Hooks: Lightweight scripts in /.kiro/hooks keep code and tests aligned whenever specs or commits change.

This setup let us stay focused on product outcomes instead of yak-shaving.

How We Built It

Architecture (MVP)

Input: URL or mini profile { name, city, category }
Core:
- parser.ts (normalizes input)
- scorer.ts (deterministic visibility scores)
- planner.ts (picks exactly 5 actions)
Renderer: markdown_renderer.ts (one-page plan with LaTeX equation for priority)

Priority formula (transparent & auditable):

$$
\mathrm{priority}(a_i)=w_i\cdot \Delta \mathrm{impact}(a_i) - \mathrm{effort}(a_i)
$$

Kiro-Driven Build Log (highlights)

Task 1 — Public scaffold with /.kiro (specs, steering, hooks), MIT license, clean README.
Task 2 — Core + CLI + tests:
- Type-safe TS modules, unit & snapshot tests.
- CLI writes output/visibility_playbook.md and prints Top-5 actions.
Task 2.1 — Hooks stabilized:
- Prettier formatting + ESLint v9 flat config (ESM), jest transform fixed.
- Hooks now run cleanly on pre-commit/spec change.

What Kiro actually produced/verified:

Deterministic outputs for demo.
Green test runs and formatting/lint gates.
Repeatable project structure jurors can run quickly.

What Worked (Kiro Successes)

Spec-to-Code you can trust: Kiro turned a single source of truth (the spec) into working code and tests we could iterate on rapidly.
Fast guardrails: Steering + hooks meant no “it works only once” surprises. Prettier/ESLint/TypeScript/Jest ran in a loop, keeping quality stable.
Small surface, big clarity: We resisted scope creep (no scraping, no external APIs in MVP), so our 3-minute demo is a clean narrative from spec → run → value.

In numbers (from our runs):

8/8 test suites passed
12/12 tests passed
Snapshots: 2/2 passed
CLI saved the playbook to: output/visibility_playbook.md
Example console output (excerpt):

Top-5 actions:
1. Tighten visual & copy consistency (priority: 8)
2. Activate UGC with a simple incentive (priority: 8)
3. Post 3 IG reels/week with local hooks (priority: 7)
4. Establish a gentle review cadence (priority: 7)
5. Fix Google Business Profile basics (priority: 5)

Markdown saved to: .../output/visibility_playbook.md

Our Kiro Workflow (Repeatable Pattern)

Write/adjust spec → commit
Kiro generates/updates stubs & tests
Run hooks (format, lint, typecheck, test)
Refine via conversational prompts (we shared practically all Kiro outputs with our AI coach and kept prompts tight to avoid drift)
Demo run (CLI prints Top-5 and exports Markdown)

This loop is easy to teach and review—a big plus for hackathon judges.

Challenges (and Constructive Feedback for Kiro)

Kiro is powerful and already tied into our AWS workflow—huge win. We also hit real-world edges that, if improved, would make Kiro even better:

Spec tunnel vision & duplication: New specs sometimes spawned duplicate files instead of reusing existing ones → repo bloat.
Inconsistent naming: Parameter names could drift; consistent naming templates would help.
Session transitions: On session switches, context could vanish—continuity needs strengthening.
Auto-actions without checkpoint: After certain CLI actions, Kiro ran ahead without a user confirm step; a pre-execution prompt would save time.
Overload crashes & history loss: When overloaded, Kiro could crash and lose chat history; better recovery would reduce ambiguity.
Forgetting despite steering files: At times, Kiro didn’t leverage existing repo context and created duplicates.
Silent background work: Occasionally ran without visible “working” state; a consistent status channel would help.
Partial prompt execution: Sometimes only the first instruction of a multi-step prompt was executed.
Non-actionable intent: Kiro declared intent to implement, but no change followed—clear next-step guidance would help.
Access continuity: Clear, predictable access beyond trial periods keeps teams committed to Kiro long term.

We’re sharing this list to be helpful—we like Kiro and want it to win.

What We Learned

Specs are force multipliers. A crisp spec makes AI pairing predictable.
Determinism beats “wow.” Judges and users prefer reproducibility over fragile complexity.
Evidence > claims. One run should make the value obvious—URL in, five actions out.

What’s Next

Ship the VC as a complete MVP (persona outputs + robust export) and begin field tests with 4 early adopters in Munich (incl. Oktoberfest hosts).
Packages + Stripe for the first 100 customers in our home market.
Admin Audit Dashboard (GDPR transparency, anomaly detection, export).
Persona-adaptive prompt templates (A/B test messaging).
Forecasting expansion (evaluating Gemini / LLaMA integrations).

Try the Demo Locally

npm install
npm run build
node dist/cli/index.js
# outputs Top-5 actions and writes output/visibility_playbook.md

Closing

Kiro helped us turn a well-defined spec into a working product with a clean story: paste a URL → get five decisive actions and a one-page plan. That’s the kind of leverage small hospitality teams need—and the kind of repeatable development loop we’ll keep using as we scale Matbakh’s Visibility Coach.

From Spec to Shipping in Hours: How Kiro Helped Us Build Matbakh’s Visibility Coach