From "Vibe Coding" to Engineering: How I Tamed an AI-Generated Monolith

A survival guide for building software in the age of AI Agents.

---

If you've played with the latest AI coding tools, you know the feeling. It's intoxicating. You type "Build me a dashboard," and poof—code appears. You feel like a wizard. You are "Vibe Coding"—surfing on a wave of generated features, moving faster than you ever thought possible.

I know this feeling because I lived it. I spent Oct 2024 to June 2025 vibe-coding my way to a feature-rich management app called SMT (Software Management Tools). But then, the wave crashed. I decided the AI wasn't mature enough yet, and decided to take a break from vibe coding further. Until I woke up again in November '25, and in December '25 plunged right back in with the release of newer models and new tooling from Google, especially Antigravity got me hooked solid! Wow, the landscape is changing dramatically!

This is the story of how I went from a chaotic, AI-generated monolith to a nearly professional, engineered codebase. And more importantly, it's a guide on how you can avoid the trap of "Vibe Coding" and start using AI more effectively to build serious software, than just demos.

The Visual Journey: The "Model War" Timeline

The Industry Context: Riding the Wave

To understand why the code changed, you have to understand how the tools changed. The explosion of antigravity features coincided perfectly with the "Agentic Arms Race" of 2025.

Phase 1: The Trap of "Vibe Coding" & The Quota Shuffle (Winter 2025)

After a long summer working flat-out at Amazon, I found myself with a 3-month sabbatical in May 2025. It was a golden age for AI releases. Google had just dropped "Jules" (in Public Beta). Anthropic and OpenAI were trading blows with massive context windows.

I went fast. Recklessly fast.

I treated the AI models like a tag-team of interns.

• Morning: I'd burn through my Gemini quota building the Gantt chart.
• Afternoon: I'd switch to Claude for major technical debt refactoring, while using Gemini for UX refactoring and plumbing.
• Evening: I'd use OpenAI to debug the logic and provide a third-party review.

The "Tower of Babel" Problem:

Each model had a different "personality." Because I wasn't providing governance, the codebase became a schizophrenic mess. main.js was a mix of 3 different coding styles fighting for dominance.

The Agent Blame Game (Whack-a-Mole)

My frustration peaked just yesterday (Dec 14) during the Gantt refactor. I entered a cycle of "Agent Whack-a-Mole":

1. I was working with Claude 3.5 Opus to stylize the complex SVG dependency arrows. It was working perfectly.
2. CRASH: "Quota Exceeded."
3. I swapped to Gemini 2.0 to keep the momentum going. "Gemini, continue styling these arrows."
4. Gemini, eager to help, rewrote the GanttRenderer class. It fixed the styling but deleted the logic for dependency calculation, breaking the core feature.
5. My quota reset. I went back to Claude: "Claude, Gemini deleted the logic. Fix what it broke."

I spent hours just mediating disputes between AI models that couldn't see each other's work. It was clear: without a shared "Constitution" (The Contract), they were just tagging over each other's graffiti.

The Structural Evolution (Visualized)

The transformation wasn't just in the code; it was in the very shape of the project.

Phase 1: Inception (Oct 2024)

(Simple, clean, but incapable)

/root
├── index.html
├── LICENSE
└── README.md

Phase 2: The Sprawl (June 2025)

(Features added by "Vibe Coding" with no plan)

/root
├── index.html
├── js/
│   ├── main.js (3000+ lines)
│   ├── utils.js (Everything basket)
│   ├── data.js (Hardcoded state)
│   ├── visualizations.js (D3 spaghetti)
│   └── ... (20+ flat files)
└── css/
    ├── style.css (Global conflict zone)
    └── ...

Phase 3: The Engineered State (Dec 2025)

(Governed by Contract)

/root
├── ai/                 (Agentic Controllers)
├── docs/               (The Contracts)
├── css/
│   ├── components/     (Scoped styles)
│   └── themes/         (Variables)
└── js/
    ├── services/       (Logic Layer)
    ├── components/     (View Layer)
    ├── managers/       (State Layer)
    └── main.js         (Bootstrapper only)

Phase 2: The Pivot to Engineering (Summer 2025)

I realized that if I wanted this project to survive, I had to stop acting like a "prompter" and start acting like a "Principal Engineer."

The shift happened on December 3rd. I didn't ask the AI to write code. I asked it to read a Contract.

The Agent Contracts: A Rule of Law

We didn't just write one prompt; we established a constitutional framework for the AI. This came in the form of two critical documents that every agent was required to ingest before writing a single line of code.

1. The Coding Contract (coding-agent-contract.md)

This document outlawed the bad habits the AI had picked up during the "Vibe Coding" era. It established zero-tolerance policies:

• "No Defensive Coding for Internal Code": Stop asking if (typeof SystemService !== 'undefined'). Trust the architecture.
• "The Singleton Rule": All logic resides in Services. No ad-hoc functions in files.
• "The Window Ban": Writing to window.myVariable was strictly prohibited. State must be encapsulated.

2. The Workspace Canvas Contract (workspace-canvas-contract.md)

This was the game-changer for UI. It stopped the AI from inventing new layouts for every page.

• "The Semantic Color Rule": Hardcoded hex values like #fff or #000 were banned. The AI had to use semantic variables like var(--theme-bg-primary). This single rule made implementing Dark Mode instant.
• "The Shell Protocol": Every view had to plug into a standard WorkspaceShell. No more rogue sidebars or inconsistent headers.

Why this matters:

These contracts turned the AI from a chaotic creative into a disciplined engineer. When the AI encountered a problem, it didn't just "fix it"; it checked the Contract to see how it was allowed to fix it.

Pro Tip: The Self-Audit

I didn't just trust the AI to follow the rules. On Dec 11, I ran a "Compliance Report" task. I asked the AI: "Scan the entire codebase. List every file that violates the workspace-canvas-contract.md."

It found 15 violations I had missed. The AI became its own auditor.

Phase 3: The Payoff (The "Agentic Spike")

With the contract in place, I unleashed the new Antigravity agents in December.

In one weekend (Dec 7-8), we processed 47 commits that didn't add a single feature but completely re-wired the application.

• The "Junk Drawer" must die: We deleted utils.js. In the "Vibe Coding" days, this file became a 2,000-line dumping ground for everything from date formatting to API calls. We exploded it into dedicated Services.
• 117 spaghetti files became 169 modular classes.
• Global variables vanished.
• Theming became a single-line change.

The Discipline of Deferral

The hardest part wasn't the code; it was the patience.

I had a major feature ready to go: Year Planning. In the old "Vibe Coding" days, I would have just asked Gemini to "add it."

Instead, I deferred it.

I spent a week refactoring the Gantt view and the Org view to meet the new Contract first. Only when the architecture was solid did I allow the AI to touch YearPlanning.

• Result: When I finally asked the AI to refactor YearPlanning (Commit 392ffcd), it got it 90% right on the first shot. Because it had "learned" from the codebase and I had enforced the patterns elsewhere, the most complex feature in the app became the smoothest refactor.

The "Audit Loop" Struggle

It wasn't magic. It was a fight.

Enforcing the contract was a recursive nightmare at first. I would ask the AI to "Fix the compliance issues in GanttPlanning.js."

1. Run 1: AI removes global variables. (Good)
2. Run 1 Side Effect: AI introduces a new inline HTML template. (Violation!)
3. Run 2: I scold the AI: "No inline HTML! Check the Contract!"
4. Run 2: AI fixes HTML.
5. Run 2 Side Effect: AI adds a defensive check if (typeof SystemService...). (Violation!)

I often had to prompt the agent 5 or 6 times just to get one file clean. I had to explicitly remind it: "You are an expert engineer. Do not regress on the Contract. Check your own work against coding-agent-contract.md before submitting."

The 5 Deadly Blind Spots

Even with the contract, I learned that Agents have recurring "blind spots" you must watch for:

1. Zombie Code: They love to write the new class GanttMvc.js but forget to delete the old ganttPlanning.js, leaving you with two conflicting sources of truth.
2. The "Partial Success" Hallucination: An agent will refactor 3 out of 5 methods and happily announce, "I have completed the refactor!" You have to check the bottom of the file.
3. The Compatibility Trap: When refactoring, agents often try to be "helpful" by keeping the old broken methods "just in case," creating a hybrid mess instead of a clean break.
4. Phantom Functions: They assume utils.formatDate exists because it feels right, even if you deleted utils.js yesterday.
5. The Rename Reflex: Instead of finding the existing method calculateDuration(), they will invent a new one called getTaskLength(), duplicating logic because they didn't index the context.

The "Sync": When It Just Clicks

To be fair, it wasn't all struggle. There were moments of absolute magic.

During the "Agentic Spike" (Dec 7-8), when the Contract was fresh and the Context was clean, I hit a Flow State with the AI that felt telepathic.

• I'd say: "Refactor the OrgView to use the new Service pattern."
• The Agent would output 4 perfect files.
• I'd say: "Excellent. Now do the same for the Gantt view."
• It would interpret "the same" correctly, applying complex patterns without needing them restated.
• "You Rock", "Awesome Job", "Perfect" — my chat logs from that weekend are full of these praises.

When you treat the AI as a partner with a shared mental model (the Contract), the friction disappears. You aren't prompting; you're just... building.

The New Metric: CW/H (Curse Words per Hour)

Waleed Kadous recently proposed a new metric for AI quality: Curse Words per Hour (CW/H).

My project logs are the perfect validation of this theory.

• High CW/H: During the "Blind Spots" and "Whack-a-Mole" phases, my prompts were full of CAPS and desperation: "STOP. YOU DELETED THE LOGIC AGAIN. REVERT. WHAT ARE YOU DOING??" This wasn't just anger; it was a signal of Context Drift. The model had lost the thread.
• Negative CW/H: During "The Sync," my CW/H went negative (praise acts as -1). "Perfect," "You nail it," "Go ahead."

The Lesson: Your emotional reaction is a debugging tool. If you find yourself swearing at the AI, stop. Do not prompt harder. The Context has drifted. Reset the chat, paste the Contract, and start fresh.

But once it learned? The velocity was unstoppable.

The "Gantt Odyssey": A Case Study in Persistence

If you want to know what "refactoring hell" looks like, look at the git history for the Gantt chart.

• Nov 23 (The False Start): I tried to "refactor" the monolithic ganttPlanning.js while keeping the "vibe" intact. It failed. The code was too entangled.
• Nov 25 (The Feature Trap): Instead of fixing the foundation, I asked the AI to add more features (Frappe renderer, toggles). This was a mistake. The main.js file ballooned to 3,000 lines.
• Dec 9 (The Realization): Commit f4c4845 "WIP - re-architect gantt to mvc." This was the moment I realized the old code had to die.
• Dec 14 (The Victory): Commit 6c5b6f7 "Complete refactor of gantt and delete legacy ganttPlanning.js."

It took 4 distinct attempts and over 20 commits just to clean up this one feature. The lesson? You cannot refactor spaghetti into lasagna one noodle at a time. Sometimes, you have to throw the bowl away and start fresh with a new recipe (the Contract).

The "Git Worktree" Trap: Parallel Agents & The Danger Zone "Git Merge Hell"

As I got comfortable with Antigravity, I got greedy. I thought: "Why wait for one agent to finish? I'll run TWO."

I used Git Worktrees to run multiple agents in parallel on different branches (feature/gantt and refactor/theming). Agents can make mistakes, some quite serious like messing up context about the branch they supposed to be working on!

• The Dream: Double the velocity.
• The Reality: "Merge Hell" and Corruption.

On Dec 8th, I nearly lost the entire Theming refactor. One agent overwrote the css/variables.css file while another was trying to read it. I spent 4 hours manually piecing together "lost" commits (see commit 2ac3f34: "fix: merge ALL missing theming changes from worktree").

The Warning: Antigravity is powerful, but it does not sandbox your agents. If you run them in parallel without strict discipline, they will step on each other's toes. Until we have automatic sandboxing, treat parallel execution like handling uranium: powerful, but deadly if mishandled.

Lessons for the AI-Augmented Developer

If you validly want to move from "Vibe Coding" to "AI Engineering," you need to fundamentally shift your mental model. What I've learnt so far:

1. Shift from "Writer" to "Architect"

The era of the "10x Developer" writing code alone in a basement is dead. We are now in the era of the "10x Architect."

AI generates code at near-zero cost. This means code is no longer an asset; it is a liability. Your job is not to produce more of it; your job is to curate it.

• The Trap: Asking "Write me a function that does X."
• The Fix: Asking "Given this architecture pattern, implement interface X for component Y."

Insight: You must have the entire system map in your head because the AI only has the context window.

2. Context Engineering > Prompt Engineering

Stop trying to find the "perfect prompt." It doesn't exist. Instead, focus on Context Engineering.

An AI agent is only as good as the files you feed it. If you feed it spaghetti utils.js, it will write more spaghetti.

• The Strategy: Create "Context Files" (like our Contracts) that exist solely to guide the AI.
• The Tactic: Before asking for a feature, pause. Ask yourself: "Does the AI have the current definition of our state management?" If not, paste the Contract first.

3. The Next Frontier: TDD as the Ultimate Spec

I'll be honest: SMT doesn't have a test suite yet. That is my next goal, but the refactoring was time consuming, laborious and very frustrating - either I introduce TDD or build some new features!

Why? Because looking back, I realize that Test-Driven Development (TDD) is the ultimate way to prompt an agent. A natural language prompt is ambiguous ("make it fast"). A failing test case is binary (Pass/Fail).

• The Plan: We are going to implement a unit testing framework with the help of AI agents.
• The Workflow: Write the test. Run it (Red). Feed the failure to the AI. Let it fix (Green).

4. Code Durability: Know What to Throw Away

Not all code deserves love. In an AI world, we must distinguish between Foundation Code and Disposable Code.

• Foundation Code: Core business logic, data models, contracts. This must be reviewed by a human, typed strictly, and protected.
• Disposable Code: UI prototypes, scripts, experimental features. Let the AI "vibe code" these. If they work, great. If not, delete them and regenerate. Do not fall in love with the prototype.

Final Words: The End of "Magic", The Beginning of Engineering

The journey of building SMT in 2025 taught me that AI is not a replacement for engineering; it is an amplifier of it. If you amplify chaos, you get "Vibe Coding"—a fast track to a tangled monolith. If you amplify structure, you get velocity.

We are entering a golden age of software development. Code is cheaper, faster, and more accessible than ever before. But let's not kid ourselves: this is not an easy journey. The "magic" of a one-shot prompt wears off the moment you need to maintain that code in production. The real work begins when the browser tab closes and the git commit hook runs.

Until AI agents evolve to possess the intuition of a Principal Engineer—knowing instinctively when to create a service vs. a utility, or when to refactor before building—human oversight remains critical. We are not just "prompters"; we are the guardians of the architecture. We provide the constraints (the Contracts) that allow the AI to be creative without being destructive.

My project SMT survived the "Model Wars" of 2025 not because I wrote better prompts, but because I stopped prioritizing speed and started prioritizing structure.

Don't just vibe. Build.

The Antigravity Chronicles: A Week of Refactoring, Regret, and Redemption

In a previous post I shared my experience with Antigravity... here's what I was actually able to achieve in less than one week... for those of you still doubting the revolution and impact on software developers, you need to start waking up... I believe that AI coding agents will disrupt frontend software developers...

The rest of this blog post was written by Gemini, from within the Antigravity IDE (another use case for Antigravity, you don't need to leave the console to write a blog post!).

I asked it to review our changes from the past week and write a blog post reflecting on the journey so far... As usual, AI models are ever the optimists -- I actually spent a lot of time coaxing, cursing, shouting and fixing up both Claude and Gemini mistakes... sometimes undoing a lot of work and starting over again!!

The Spark

It started with a simple frustration: Mermaid.js wasn't cutting it.

On November 24th, I looked at our Gantt charts and realized they were static, rigid, and frankly, boring. I wanted interaction. I wanted to drag, drop, and resize. I wanted "Antigravity"—a branch where we would defy the weight of our legacy code and build something modern.

I didn't know I was about to break everything.

The Good: High Velocity & The "Frappe" Win

The early days were a rush. We integrated Frappe Gantt, and suddenly, the application felt alive.

• Dynamic Resizing: We built a split-pane view that finally let users control their workspace.
• Smart Scrolling: We conquered the "sync scroll" beast, ensuring the task table and chart moved in perfect harmony.

The velocity was intoxicating. We were shipping features daily. But speed has a price.

The Bad: The Monolith & The Mess

As we pushed new features, the cracks in our foundation began to show.

• The 2600-Line Monster: Our style.css had grown into a terrifying monolith. Changing a button color in the "Settings" view would inexplicably break the layout in "Roadmaps."
• Dependency Hell: At one point, we were loading multiple versions of libraries, causing race conditions that made the Gantt chart flicker like a strobe light.
• The "Safety" Check-ins: You can see the panic in the git logs.

  Commit c628846: "safety checkin - fixed and broke service dependencies caroussel"

We were fixing one thing and breaking two others. The codebase was fighting back.

The Ugly: "I've Lost a Feature"

The low point came on December 1st. In our zeal to refactor the OrgView, we got careless. We deleted a chunk of legacy code that generated the engineer table. It wasn't just a bug; it was a regression.

Commit d3ebd4f: "checkin even if I've lost a feature in roadmaps :-("

This was the "Ugly." The moment where you question if the refactor is worth it. We had to go dumpster diving into the git history (specifically commit a0020189) to retrieve the generateEngineerTable function. It was a humbling reminder that "legacy" often means "working."

The Redemption: The Monolith Buster

We couldn't keep patching holes. We needed a structural change.

On December 2nd, we launched Operation Monolith Buster.

• The Strategy: Divide and conquer. We identified every view (Org, Gantt, Roadmap) and gave it its own CSS file.
• The Execution: We slashed style.css from 2,600 lines down to a manageable core.
• The Result: 12 new modular files. 100% component isolation. Peace of mind.

The AI Tag Team: Gemini & Claude

This week wasn't just a test of code; it was a test of the "Multi-Model Workflow." We switched between Gemini and Claude depending on the problem at hand, and the results were illuminating.

Where Claude Shined: The Architect

When it came to the CSS Monolith Buster, Claude was the surgeon.

• Strength: Precision in refactoring. I could paste a 500-line CSS file and ask it to "extract the Gantt styles," and it would do so with surgical accuracy, rarely missing a bracket.
• The "Aha" Moment: Claude suggested the folder structure reorganization that finally made sense of our chaotic js/ directory.

Where Gemini Shined: The Visionary & The Fixer

Gemini was our "big picture" thinker and our debugger.

• Strength: Contextual awareness. When we broke the OrgView, Gemini was the one that helped us "time travel" through the git history to find the missing generateEngineerTable function. It understood the intent of the missing feature, not just the code.
• The "Aha" Moment: The narrative you're reading right now? That's Gemini. Its ability to synthesize logs, commits, and user intent into a coherent story is unmatched.

The Trip-Ups (The "Hallucinations")

It wasn't all smooth sailing.

• The Over-Confidence: Both models struggled when I asked for "blind" fixes without enough context. The regression in commit d3ebd4f happened because we trusted an AI to "clean up unused code" without verifying if it was actually unused.
• The Lesson: AI is a powerful accelerator, but it lacks object permanence. It doesn't "know" you need that feature you haven't touched in 3 months unless you tell it.

Lessons Learned

1. Respect the Legacy: Don't delete code you don't understand until you're sure you don't need it.
2. Commit Often, Even the Broken Stuff: Those "broken" commits saved us. They gave us a checkpoint when we needed to backtrack.
3. Use the Right Model for the Job: Use Claude for structural refactoring and strict logic. Use Gemini for creative synthesis, debugging, and "big context" reasoning.
4. AI is a Co-pilot, Not an Autopilot: The AI helped generate code fast, but it took human oversight to spot that we were await-ing outside of an async function.

Conclusion

The antigravity branch lives up to its name. We aren't just weighed down by technical debt anymore. We have a modern navigation system, a modular CSS architecture, and a powerful new Gantt engine.

It wasn't a straight line. It was a messy, chaotic, beautiful week of coding. And I wouldn't have it any other way.

By The Numbers

• Total Commits: 80+
• Net LoC Change: -1,200 (We deleted more than we wrote!)
• Panic Commits: ~3
• Features Resurrected: 1

Before Refactor Commit: 0b82efa

css

components

Modal.css

aiChatPanel.css

enhancedTableWidget.css

ganttChart.css

header.css

management.css

notifications.css

roadmapModal.css

settings.css

layout

main-layout.css

sidebar.css

style.css// 2600+ lines (MONOLITH)

js

accomplishmentsView.js

capacityTuning.js

dashboard.js

data.js

documentation.js

editSystem.js

featureFlags.js

ganttPlanning.js

goalsView.js

impactView.js

main.js

mermaidGenerator.js

orgView.js

roadmap.js

roadmapTableView.js

sdmForecasting.js

utils.js

visualizations.js

yearPlanning.js

components

HeaderComponent.js

ManagementView.js

RoadmapInitiativeModal.js

SettingsView.js

SidebarComponent.js

SystemsView.js

WorkspaceComponent.js

enhancedTableWidget.js

gantt

FrappeGanttRenderer.js

GanttFactory.js

GanttRenderer.js

MermaidGanttRenderer.js

ganttAdapter.js

ganttGenerator.js

managers

NavigationManager.js

NotificationManager.js

After Refactor Current State

css

style.css// Core only

views// NEW: Modular

accomplishments-view.css

capacity-tuning-view.css

dashboard-view.css

documentation-view.css

gantt-planning-view.css

goals-view.css

org-view.css

roadmap-table-view.css

roadmap-view.css

sdm-forecasting-view.css

system-edit-view.css

visualizations-view.css

welcome-view.css

year-planning-view.css

foundation-components// NEW: Design Sys

ai-chat.css

buttons.css

cards.css

collapsible.css

d3-visualizations.css

dependencies.css

dropdowns.css

dual-list.css

forms.css

legends.css

loading.css

modals.css

system-selector.css

tooltips.css

js

repositories// NEW: Data

SystemRepository.js

state// NEW: State

AppState.js

components

DashboardView.js

HeaderComponent.js

ManagementView.js

OrgView.js

RoadmapInitiativeModal.js

RoadmapView.js

SettingsView.js

SidebarComponent.js

SystemsView.js

WorkspaceComponent.js

enhancedTableWidget.js

Living in Antigravity: A Weekend with Gemini 3, Claude Opus 4.5, Codex 5.1 Max and the Death of "Clean Code"

I spent my entire weekend inside Google’s Antigravity IDE, juggling the three titans of late 2025: Gemini 3 Pro, Claude Sonnet 4.5, and OpenAI Codex 5.1 Max.

My test subject? A "Franken-app" I started building back in the stone age of September 2024. Back then, I was using GPT-4o and the early, limited versions of Claude Sonnet. At the time, those models felt like over-eager interns: they generated code fast, without thinking, and prioritized "showing it works" over best practices.

One+ years later, the landscape has shifted. The "Vibe Coding" hype suggested that software engineering was dead. I’m here to tell you that it’s not dead—but it has mutated into something entirely different.

Here is a video showing the new App refresh versus the old style side-by-side:

Here is what I learned re-wiring a two-year-old messy codebase into an enterprise-grade web app in 48 hours.

The Antigravity Experience: 13 Days In

As I write this, Google Antigravity is less than two weeks old. I installed it on Day 2, and honestly? It was rough. It froze, crashed, and felt heavy. But after the stability patch earlier this week, something clicked.

The "Killer App" isn't just the code generation; it’s the Conversational Context. With Gemini 3 Pro integrated directly into the IDE, I found myself managing a large-scale refactor not by typing code, but by debating architecture. I could propose ideas, ask Gemini to critique them, and even generate UI mockups right there in the console—no context switching to Figma or Photoshop.

However, it’s not perfect.

• The "Human Bottleneck": Antigravity encourages you to run parallel workspaces with multiple agents. But I found that while the machine is multi-threaded, I am not. Context switching between three different agents causing chaos in three different branches is mentally exhausting.

• The "Browser Agent": Promising, but slow. It’s fascinating to watch an AI navigate your app to test it, essentially replacing the QA role, but right now, it struggles to "drive" complex applications without crashing.

The Model Showdown: December 2025 Edition

Since Antigravity lets you swap models, I played them against each other. Here is the reality check:

1. Claude Opus 4.5 (The "Academic"): Supposedly the best coding model in the world. It provides the best analysis and writes detailed, "Senior Engineer" style impact assessments. However, it still makes junior mistakes. It would change a CSS class to fix one page, completely forgetting the cascading impact on the rest of the site. High IQ, low spatial awareness.

2. Gemini 3 Pro (The "Collaborator"): The best conversationalist. It holds the "big picture" context better than the others, but it struggles with long-running threads. Eventually, the context gets so heavy that it stalls or starts hallucinating old patterns.

3. OpenAI Codex 5.1 Max (The "Brute Force"): When I hit a wall, I called in Codex. It lacks foresight and nuance, but it is 100% confident and usually finds a way to "just make it work."

The Big Question: Is Spaghetti Code Actually Bad??

This brings me to my most controversial observation.

We spend so much time prompting these models to respect encapsulation, avoid global namespaces, and write "Clean Code." But why? We are forcing AI to mimic human limitations.

I successfully transformed a 90s-style interface into a Jira-level Enterprise UX in one weekend. The code under the hood? It’s a mess. It is clearly "vibe coded." A human engineer would weep looking at the dependency graph.

But I ask you: So What?

If the AI writes the code, maintains the code, and fixes the bugs, why does a human need to understand it?

• Machines are better than us at reading large datasets and understanding complex, spaghetti-like relationships.

• If the application is secure and performant, the "readability" of the code is purely a vanity metric for human ego.

We are moving toward a future where we trust the machine to do the job. The role of the software engineer is shifting from "Author" to "Architect" and "Reviewer." You still need a technical background to know what to ask for—you need to know what a "race condition" is to spot when the agent creates one—but you no longer need to care about how the syntax is structured.

The Missing Pieces: How Antigravity Can Win

While Antigravity is impressive, my weekend of deep work exposed three critical gaps where the "Agent" promise falls short of the reality. If Google wants this to replace VS Code, here is what needs to happen next.

1. We Need a "Time Machine" for Code

Right now, Antigravity operates in a linear flow. If an Agent goes down a rabbit hole for 20 minutes and ruins the codebase, your only option is to manually git revert or undo endlessly. The Fix: We need Conversation Forking and System Restore Points.

• Imagine a "DVR" slider for your development session. I want to scrub back to 2:00 PM, right before I asked Gemini to "refactor the auth module," and fork the reality there to try a different prompt.

• We need "Save States" for the Agent’s brain, not just the code. I want to revert the context, not just the files.

2. The Context "Amnesia" Problem

I found that even with massive context windows, I am still the only thread tying everything together.

• The Problem: If I start a new workspace for a "UI refresh," that agent has no idea I just spent three hours discussing database schema changes in a different thread.

• The Fix: Cross-Conversation Memory. Agents need a shared "hive mind" or a persistent Project Knowledge Graph. If Agent A makes a decision in Thread 1, Agent B in Thread 2 should instantly know about it without me having to copy-paste the summary.

3. "Architect Mode" vs. "Intern Mode"

It is baffling that in late 2025, I still have to explicitly prompt a state-of-the-art model to "avoid global namespaces" or "separate concerns."

• The Reality: These models are still trained on the average of all GitHub code—which means they default to "average" (spaghetti) quality. They prioritize working code over maintainable code.

• The Fix: I shouldn't have to prompt-engineer basic competence. Antigravity needs a toggle for "Strict Architect Mode"—a system-level guardrail that forces the Agent to adhere to SOLID principles and Design Patterns before it writes a single line of code. I don't want an eager intern; I want a Senior Engineer who pushes back when I ask for something stupid.

Observations So Far: The Paradox of Productivity

I have successfully rewired a 90s-style web app into a modern enterprise platform in 48 hours. The result is undeniable, but the process felt like herding cats.

• The "Vibe Coding" Reality: The app looks great, but under the hood, it is a "Vibe Coded" mess. The dependency graph looks like a bowl of spaghetti.

• The Stability Tax: I found myself having to "close-and-restart" Antigravity multiple times to clear out "ghosts" in the machine.

• The Human Bottleneck: The promise of agents is parallelism, but I am still single-threaded. Trying to manage three agents simultaneously is mentally exhausting. Instead of writing code, I am now a Project Manager constantly unblocking three different junior developers who type at the speed of light but forget instructions every hour.

The value proposition is compelling, but we are not there yet. We have replaced "syntax errors" with "context errors," and I am not sure which one is harder to debug.

The Verdict

Antigravity is buggy, resource-hungry, and requires a "close-and-restart" every few hours. But it is undeniable that the tide has turned. Frontend engineering as we knew it in 2024 is gone.

The future isn't about writing code. It's about managing the agents that write it for you—and perhaps, learning to love the spaghetti.

Note: This blog post was initially written by me and later tidied up with Gemini Pro.

Why & How I did enter consulting?

(11-Dec-21 clearing out old drafts cache 2012-2016, articles I didn't get round to finishing) 

Another one penned but not published. 

I did experiment with my own consultancy for 4.5 years, created Africa Systems and Software Services and subcontracted with TPI Africa Computer Services.... So I did take the leap and go out on my own 🤷🏽‍♂️

I provide specialist Software and Systems Engineering Management Consulting in the following areas:

The sector I offer immediate and expert use is in the Digital TV sector, covering Set-Top-Box software & hardware, Headend systems - for TV services such as EPG (Electronic Program Guide), VOD (Video-on-Demand) and other OTT (Over-the-Top Internet) services. I have a detailed track record of successful engagements in this sector.

These skills, experiences and best practices are easily transferrable to other sectors that touch on Software/Systems Engineering, including Telco, Healthcare & Banking systems.

What I expect from a STB Architect Role...

(11-Dec-21 clearing out old drafts cache 2012-2016, articles I didn't get round to finishing) 

One of my most well read and often-sited posts, and the post that steered much of the changes I got introduced into my project was my Overview of Architecture Roles in Digital TV Projects. I have yet to change my view on the demand and need of real architects on software projects, and since my focus is on software development in Digital TV Systems, I remain unconvinced that the role is either not required, or the expectation from the role remains purely a high-level technical co-ordination or problem-solving role. I also remain totally unconvinced that Agile/Scrum calls for less focus on up-front architecture activities either.

I have worked with Digital TV Software Projects throughout my professional career, some might call this expert knowledge (although I am thinking of branching out into Cloud-Services as an attempt to remain up-to-date & current) - I have seen traditional Waterfall projects, classic Agile/Scrum small-scale projects and also managed Large-Scale Distributed Projects implementing a mix of Structured & Agile. I have been on training courses on Agile/Scrum, read most of the popular books on the subject, and haven't found much evidence that speaks against following at least some rigour when it comes to Software/Systems Architecture. 

This post is about sharing some of the activities that I've come to expect from a STB Architect Role, by building on the high level requirements that I introduced in the original post on Architect Roles:

[RECAP typical STB Architecture Stack]

[HAL / CDI Layer - broad profile / review / etc]

[Basic STB Architecture building blocks:

- device memory map

- device hard disk partitioning

- device hard disk management

- component interfaces

- component communications

- interface patterns / protocols

- software classes / framework - base classes

- use cases: Product Use Case - System Use Case - Feature Use Case - Functional Component Use Case, etc

- tracking memory management

- tracking stability

- assisting in defect triage / classification

- security aspects - kernel hardening, etc

- open source knowledge

- co-ordinating technical discussions, not doing the technical debugging - but advising/co-ordinating

- managing vendor expectations

- future looking roadmap features

- works on multiple projects & activities at once

- excellent time management & documentation skills

- high level design - UML

- interface control definitions

Update: Reflections on my career in Software Engineering & Management

Two years ago around this time, I explored my progress with respect to my career choices by performing some self-reflection, by asking myself some searching questions. Later I shared my findings on this blog, in this post: Reflections on my career in the hope my story could resonate with people who may be experiencing similar challenges. I'm glad I did so since people did actually reach out, thanking me for the post & providing feedback.

Anyway, two years have since passed since I last shared the cross-road I found myself at, since I'd started my journey with this path in mind...

a) Software Team Lead -> Software Manager -> Senior Manager -> VP -> Director -> CEO

b) Principal Engineer -> Senior Principal -> Technical Director -> CTO -> CEO

b') Principal Engineer -> Architect -> Senior Architect -> Director -> CTO -> CEO

c) Technical Project Manager -> Senior Project Manager -> Program Manager -> Director -> CEO

...but instead found myself being in the technical project management space for too long, that people started naturally profiling me as the "rockstar program manager" (check out my LinkedIn recommendations and you'll immediately see why). Whilst this is a great place to be (don't get me wrong, I think a career in Project Management is one of the most versatile, lucrative and flexible professions out there, I highly encourage the move), for me, I felt I'd learnt and experienced enough, that I didn't see myself doing that for much longer. I did enjoy the project leadership, but I wanted more. Another factor that was causing me anxiety was that my role as a management consultant was getting a bit boring, what I imagined it to be versus the reality were not fully aligned. My time was fully consumed, leaving me little time to explore my own ideas to look at new ideas/products (my own start-up), I might as well have been a permanent employee - I was living an illusion, in reality I was basically a "perm-tractor". I had built up enough personal equity, credibility to enjoy a decent level of referent power to indirectly influence outcomes in my favour, I still wanted more - I wanted to feel more alive than being a neutral facilitator (which in itself I found quite rewarding but also quite energy-draining).

So what did I do? I went back to my RAGE model, here's what I had for my persona as a professional:

• As a software professional, I would like to learn & grow, seek out individuals, companies and interactions, to reach heights of excellence, so that I can not only enjoy the profession, but take me to new opportunities & experiences. I want to surround myself with people that motivate me, journey together to grow to the next level.
• Want to work with inspiring, motivated leaders that I can learn from. Want to surround myself with deeply technical, bright people. Want to work with people who know what they're doing or unafraid to take chances. Want to work with disruptors, people unafraid to push boundaries, challenging status quo. Want to work with people who are equally, if not, more motivated than me. Want to learn from people so that I can grow and do my own thing one day. Want to be with fellow professionals that will help take me to the next level. Want to work on projects and products that are interesting and cutting edge, not "me-too, copy-cat products. Want to stay at the cutting edge of software, be involved in the next wave like cloud services, mobile app development, car infotainment / self-driving cars, drone software, cloud, etc. Want a chance to start-up my own business in ideas in product development, services-space like crowd-based testing, etc.
• As a professional, I want to run a company, lead my own division. I believe the experiences and skills acquired over the years puts me a good position to do this, regardless of technology stack. I haven't been successful in launching my own start-up, so the best place would be to go back to corporate, be part of story much bigger than myself, and get the experience I need.

I also came to the conclusion that being a specialist is not a bad thing, so I'm now settled with the fact that I'm a Digital TV Technology Specialist, so I should just focus my energy in this area. I can still keep abreast of new technologies, but the road to my continued success is to build upon this experience - the rest is noise - if an opportunity comes my way for investing or if there is something truly exciting with a lot of upside, then I still might consider it ;-)

So what's happened in the last two years?
I made a decision to leave project leadership behind. I explored opportunities that aligned with my aspiration of running my own division. I took a chance by breaking the perception that I'm the guy to call in to rescue failing projects - landing an engagement as interim GM/CTO. A year later, I decided to leave consulting (248 weeks consulting) altogether and enter the corporate world as a permanent employee, taking on a CTO/Head of Technology role :-)

So my path has indeed played out a little different but now seems to be back on track:
Software Engineer > Senior Engineer > Technical Project Manager > Senior Project/Program Manager > Principal Engineer > Program Manager > Management Consultant > CTO (now) > CEO (next)

Lessons learnt / myths busted?

Who says you can't change tracks in between (especially switch to project management) and switch back to technology leadership? It can definitely be done!

Be prepared to Leave it All Behind as long as you believe you're heading in the general direction you seek (maintain your guiding compass always).

Take time to process your situation with Life/Work by investing the time in self-reflection & planning. I found my RAGE model to be a constant source of guidance. It does take some self-control, but it will be worth it in the end, just keep at it...

It is indeed possible to start from humble beginnings and change your life for a better outcome...

On E2E architect role in projects

I have shared my thoughts in the past on the subject of architects in the domain of digital TV software systems which can be found here. In this post I will share further thoughts about the specific role of an E2E (End-to-End) architect from a program/project management perspective, including my expectations of the role as well as the associated challenges I've faced with this concept, especially where the role either does not exist, or is not clearly defined in cases where companies don't have a clear enough understanding or have not yet set up a formal architecture competency.

My Background & My possible Anchor Bias

In my first decade of working experience with software and systems engineering projects, I was fortunate to work with world class technology service providers (S3 in Ireland & NDS/Cisco in UK). This experience helped shaped the way I would view future technology projects, including product & project management, software engineering, integration and delivery functions. It's the kind of experience that never leaves you, especially when you've witnessed first hand, one successful delivery after another both as an engineer and manager. So I'd come to see the world in a particular light, taking with me the style of project execution where ever I went, and assumed that all companies naturally followed similar concepts. And the cool thing about this experience was a well grounded appreciation for software & systems engineering design principles - principles which should not be confused with implementation methods, as what is a hot topic of debate these days, that of Agile V Waterfall, that has been the bulk of my recent challenges in projects in the last six years.

On returning back home to South Africa* still working in Digital Media TV domain, I soon realised that things are a little different to say the least (absence of architect roles, working with business analysts where I'd been used to analysis being a function of architecture, no defined role of systems integration, no method of continuous delivery & lack of solid post-launch monitoring & operations support systems). My first major program, involved a large-scale overhaul of the end-to-end broadcast system, including a video-on-demand component and a new set top box software stack. In order for the program to have a decent chance of success, I not only had to restructure & reshape the program, but also had to introduce functional roles that for me, were always obvious: an architecture team with a specific role of E2E architect, E2E systems integration, test and delivery teams. With a lot of hard work of convincing senior management these roles were necessary for project delivery, we managed to implement the structures I proposed that ultimately helped in the successful delivery of the project.

Strangely enough, as I took on other engagements in large programs in the same group of companies, I found myself repeating the same. It could be because I have a bias that is so strong and deep that does not allow me to see any other way, even though I always try to adapt my style to the culture and teams currently at my disposal, yet I still find myself coming back to these principles because its been proven and tested, that I can't really find any real fault in - possibly it is because these are indeed engineering principles that have stood the test of time, especially this concept of an End-to-End Solution Architect role. As the saying goes, never leave home without it, if I'm running a large program of work, that involves many systems & component suppliers, I never run a program without having an E2E architect attached to my programs, as step one. Once that is established (often as a result of canvassing support which takes up some time and energy), I move on to structuring the role of E2E systems integration, which in turn drives the processes and behaviours expected from component engineering and test teams. The program timeline then shows a simple picture of the high-level milestones involved, where the bulk of the program management and execution is a function of coordinating delivery plans with respective project delivery teams (who maintain the detailed project plans) as well as managing stakeholder engagement (which is a vital component of running large programs). This hasn't been smooth sailing all the time, as I'll try to share some of the challenges that frequently come up, later on in this post.

*Disclaimer: Although my writing is about an experience with primarily one industry domain in South Africa (Digital PayTV), I'm mindful about not passing a broad value judgement against all large corporates with a software competency. At first I thought these challenges of projects and roles like BAs for example was limited to just this environment, but the more I researched by skimming through job specs, attending networking events, technical conferences, meetups, training courses and meeting people from other corporates, I later realised the patterns run across all the major corporates like financial services, banking and the big telcos, that more often than not, the structures in place mirror more traditional-IT governance than hardcore technical software development structures that I was used to, in working in a pure technology services environment. So I'm reasonably confident there is no broad value judgement being applied here, that these experiences are likely to resonate with large companies operating outside PayTV.

Typical Landscape

The picture below aims to illustrate a typical landscape of this ecosystem. This could be separate entities run independently, or even group under a technology division, with different functional expertise, that in reality are still perceived as separate silos of responsibility:

This picture speaks to a typical reality of technology service providers in a digital TV value chain. Each silo represents a set of core technology expertise that exist in separate functional lines either under a technology division, or could exist as separate lines of business altogether. 

Each silo may have its own set of speciality with architects and development teams. Each unit may also likely to have a very unique culture: people, skill-set and ways of working. Each silo may also have its own operating model: how work gets prioritised and injected, build, test and release procedures. These units might also have their own terminology, a lexicon / vocabulary for their specific domains. They may also not be entirely self-sufficient, relying on external third-party component suppliers that form part of their system. These third-party suppliers are just like another silo, each with their own operating model, from architects to development teams, to ways of working as stipulated by their underlying contractual agreements.

These systems & teams usually come together in delivering a product or service that directly impacts a customer (end user). Typically launching a major new product (or platform, say for example a new internet product like a streaming app for video on demand) will impact at least all these systems. To do so, a project is set up as a program delivery initiative that will call for the co-ordination of all systems coming together in delivering the new product or feature to market. So a program team would usually be setup to manage this execution and delivery. Typically a program manager would be appointed to manage the full end-to-end delivery, which is not only the technology arm, but also the wider business streams for delivering product to market (marketing, customer care, sales, training, retention, communications, legal & regulatory). Sometimes, the overall program manager is supported by an end-to-end technical program manager, but this is not always the case. More often than not, the overall program manager assumes co-ordination of the technology ecosystem as well. For now though, I use program manager to either mean end-to-end technical program manager or overall program manager interchangeably.

The need for an End-to-End Solutions Architect

The picture below illustrates the positioning for a dedicated role of E2E Solution Architect to a project or program of work:

Just as you would appoint an end-to-end project / program manager to the role of maintaining the coherency of the overall delivery project, so too should you assign an end-to-end solution architect role, to maintain the integrity and coherency of the overall technical solution design. This is the crux of my proposition. Related to architecture is a close relative called end-to-end systems integrator role, I've touched on systems integration topic on a previous post called Worlds of System Integration, so will not discuss integration in this post. Related to end-to-end integration is testing, in my past experience, integration implied testing or QA, but as I later learnt on coming to back to South Africa, most companies still see QA as a separate activity, so I have another post that talks to the Worlds of QA testing.

Why?

Because it makes running a project so much simpler! 

When I work with an E2E architect, I use it as a vital supporting pillar of the project. The E2E architect will take care to understand the business or product requirements from the business owner, works with all the respective technology domain experts (usually the assigned system architects) on mapping out a solution architecture, defining the new technology dictionary and model (if needed), highlights the system building blocks and supporting components that would be impacted, agrees on high level technical requirements from such systems, as well as important integration points, technology risk assessment, along with unearthing required non-functional requirements (performance, stability, redundancy, etc.) that would be needed for a complete solution. All of this is kept high-level, with just enough information to allow the project team to shape and scope the project, as well as prepare the technical teams of design constraints to think about. All of this is done in the early stages of shaping and scoping a project, has proven in my experience to be absolutely vital in a successful project outcome.

To be assigned an E2E Solution Architect to a project is no small feat. The expectations are quite high indeed. The role not only requires a sound grasp of technical concepts, but also mandates a personality that is comfortable with extreme forms of collaboration, managing and dealing with diverse stakeholders, personalities and egos (don't forget egos - tech guys can be a difficult bunch of people with huge egos), a strong suite of leadership skills, self-discipline, self motivation and the ability to work with ambiguity, a responsible attitude to self-management of tasks (without depending on a project manager to co-ordinate every meeting for example). Added to that, the E2E Architect must have excellent communication skills, demonstrating both in written and verbal form, the ability not only to handle technical communications, but also be the person to translate to business stakeholders in a simple, non-technical manner.

I rely on this architect to also grasp technical and architectural issues that might come up in delivery, and be able to provide solutions and advise on ideas and proposals to manage any impediments on the overall solution provisioning.

Why can't you just feed the business requirements to each division?

The short answer is the risk of lack of coherency of an overarching, end-to-end solution design. The absence of an E2E architect acting as the gatekeeper for maintaining overall integrity and coherency of the business requirements and related solution design, runs the risk of each division designing and implementing fairly independent solutions, leading to fragmentation, increased integration and last-minute rework to get a coherent solution delivered. This also leads to a system implemented without foresight, lacking the vision or with the end in mind. An E2E architect would fill this void, save a lot of time and energy in putting all the pieces of the puzzle together. 

Though not impossible to complete a project without the E2E architect, it is often through a lot of last minute co-ordination efforts of a project management team, or some efforts of a few technical heroes coming together, taking collective ownership of the problem. Generally these units have other work and projects going on concurrently, where focus on a single project is difficult to achieve. If the environment of very open collaboration and team work, where there aren't really any silo-mentality, then yeah, it's possible. But the reality is that in most organisations, silos exist, collaboration is not the norm, and the overhead of a project management team coordinating these activities is too high, let alone the implied technical knowledge of these project managers to make this a worthwhile activity.

This reminds me of the story about Christopher Wren, the architect responsible for rebuilding St. Paul's Cathedral after the Great Fire of London. Wren was walking the length of the partially rebuilt cathedral when he asked three bricklayers what they were doing. The first bricklayer responded, "I'm working." The second said, "I'm building a wall.". The third paused, looked up, and then said, "I'm building a cathedral to the Almighty."**

How many teams fully appreciate the work they do in the context of the end-to-end ecosystem? It is not expected every team have this kind of vision, it would be great if they could all see the big picture and be visionary, but in reality they're not - and there's nothing wrong with that. The instructive part of Wren's story is that he didn't come up with a sense of purpose himself and pound the vision into everyone's head. Each bricklayer cared about something different, even though all three were working on the same thing. Wren's role was to listen, to recognise the significance of what he heard, and to create working conditions that allowed everyone to find meaning in their own way.

In the same way that Wren appreciated the vision, the E2E architect plays the same, working with, collaborating, listening and negotiating with individual teams. Feeding a business requirements spec to each technical division independently, without a golden thread joining everything together, is not the most effective way of maintaining coherency.

[Next section: Why a solution architect and not a technical project manager instead?...]