by Bryan Chua

Singtel bought its way into seven markets. Notion let users invite their friends. One writes cheques. The other ships features. Stand far enough back and you realise both are running the same machine — just with different instruments bolted onto the front.

Growth is never accidental. It is always engineered. The question is only which lever you are pulling.

The Singtel story reads like a chess board. Stakes in Airtel, Telkomsel, Globe, AIS, Optus. Technology layers laid on top through NCS and Optus Enterprise. Venture bets routed through Innov8 — Trustwave, Amobee, a string of cloud and AI adjacencies. The moat is structural: 700 million subscribers sitting under one Group-level P&L. No amount of organic marketing gets you that footprint. You have to buy it.

The Notion story reads like a growth curve. A free tier generous enough that students build their second brains on it. Shared pages that quietly double as sales demos. A public template gallery where superusers do the marketing. Every time a team creates a database, invites a collaborator, or ships a public doc, the system gets a little stickier, a little more entangled with the way that team thinks.

Two very different motions. Same underlying move.

What does it mean to engineer a business?

Engineering, in the business sense, is not about code. It is about designing a system whose outputs compound without linear effort. Three flavours matter:

Technology engineering is the one most people think of first — building the systems, the data pipelines, the infrastructure. It is necessary, but it is always a means to an end. A telco with excellent engineering and no subscribers is a very well-run museum.

Business engineering is the discipline of owning market structure. You use capital, equity, partnerships, and M&A to shape the competitive landscape before the race even starts. You don’t win customer by customer — you win by owning the pipes the customers flow through.

Product engineering is the discipline of owning the user’s workflow. You use free tiers, activation loops, embedded sharing, and virality to embed yourself in the way work gets done. You don’t sign contracts — you become muscle memory.

The distinction matters because each flavour has its own physics. Business engineering is slow, expensive, and high-stakes. Product engineering is fast, cheap, and requires relentless iteration. But the logic at the top is identical: design a system where every move makes the next move easier.

Singtel’s playbook: owning the pipes

Singtel does not think in MAUs. It thinks in market coverage. Regional telco stakes give it structural presence in Southeast Asia and India — geographies where organic growth would take decades. Technology service layers like NCS and Optus Enterprise sit on top of that base, selling integration, cloud, and managed services back into the same markets Singtel already owns infrastructure in. Innov8, the corporate venture arm, places smaller bets on adjacencies — cybersecurity, ad-tech, AI — that can plug back into the main business if they pay off.

The growth signal is not Net Promoter Score. It is ARPU, subscriber count, market share, and enterprise contract value. These are slow-moving, capital-intensive numbers. You don’t A/B test your way to a stake in Airtel. You negotiate, you write cheques, you wait.

Capital buys you a position that no amount of product iteration can replicate. But only if you have a plan for what to do once you own it.

This is the trap. Business engineering without product engineering produces sprawl — a federation of assets that don’t talk to each other, don’t share a customer graph, and don’t compound. The moat exists, but the water evaporates.

Notion’s playbook: owning the workflow

Notion’s wedge is the free tier. Not free as a pricing tactic — free as a distribution strategy. Every free user is a demo. Every shared page is a billboard. Every template posted to the public gallery is an outbound motion that the company did not have to fund.

The signals Notion watches replace the traditional top-of-funnel. Database creation rate. Invite acceptance. Daily active usage inside a workspace. When a team hits a certain threshold of pages, blocks, and shared docs, something flips — Notion stops being an app and becomes the company’s institutional memory. That is the real switching cost. Not the export format. Not the API. The fact that half your team’s brain is now shaped by the tool.

Product engineering of this kind is cheap to start and brutal to scale. You can launch a better editor in a weekend. You cannot manufacture the years of user habit that turn a note-taking app into a workspace.

The uncomfortable truth

Look past the optics and Singtel and Notion are playing the same four-move game.

Same lock-in logic, different mechanism. Singtel locks in through infrastructure ownership and enterprise contracts. Notion locks in through workflow dependency and institutional memory. Both end in the same place: a customer for whom leaving is more expensive than staying.

Same expansion signal, different metric. Singtel tracks subscribers, ARPU, enterprise seats. Notion tracks workspaces, invites, daily actives. Both are counting depth of penetration into the customer’s life — one through the wallet, one through the calendar.

Same new-market entry move, different instrument. Singtel enters a market by buying a local operator. Notion enters a market by releasing a free tier and watching who bites. The capital cost is vastly different. The underlying bet — plant a flag, then expand — is identical.

Same failure mode: fragmentation without integration. A telco conglomerate with no group-level data strategy is a holding company pretending to be a platform. A product suite with no account-level story is a collection of nice apps pretending to be a system. Both die the same way — by sprawling faster than they compound.

What each can learn from the other

Singtel’s blind spot is product signal thinking. Its enterprise services arms sell like traditional telcos — long procurement cycles, relationship selling, master agreements. But the people buying cloud, cybersecurity, and AI today behave like product users. They want to try before they buy, see activation within a week, and expand on evidence. Singtel needs to learn the grammar of PLG, or watch its enterprise wallet share migrate to vendors who speak it natively.

Notion’s blind spot is business engineering. As it scales into the enterprise, the game changes. Procurement cares about security reviews, not templates. Channel partners, systems integrators, and strategic investments start to matter more than virality. The same acquisition tactics that got Notion to a million teams will not get it embedded in the Fortune 500. At some point, every great product company has to learn to write cheques.

The compounding machine

The instinct is to pick a side. Pick the telco model or the SaaS model. Pick capital or product. The companies that actually win refuse the binary.

Product signals tell you where to place capital. Capital unlocks distribution that product alone cannot reach. Distribution creates surface area for more product signals. The loop closes.

That is the machine. Singtel’s next decade depends on whether it can read product signals well enough to direct its capital intelligently — away from dying assets, toward compounding ones. Notion’s next decade depends on whether it can engineer the business side — partnerships, acquisitions, enterprise motion — without losing the product instinct that got it here.

Two roads. One destination. The companies that engineer the feedback loop between product and capital don’t just grow. They compound — and compounding, given enough time, looks a lot like winning.

The first time the pipeline broke, it was because Roy — my AI pressure-tester — decided my post idea was too generic to publish.

He wasn’t wrong. That was the uncomfortable part.

I’d given the content team a brief about enterprise AI adoption, the kind of thing I’ve been living and breathing at GoPomelo for the past two years. Roy came back with a list of objections: no strong POV, no counterintuitive angle, nothing a reader couldn’t find in a McKinsey slide deck. I sat with that feedback for a moment, reminded myself it was an LLM, and then rewrote the brief anyway. Because he was right.

That’s not the story I expected to tell when we started building this.

The Octonauts is a six-agent AI system designed to run a full editorial pipeline — from brief to published post — with minimal human intervention at each stage.

How the Octonauts AI Pipeline Works

Somewhere between running engineering teams at Amazon and co-founding ShopBack, I learned that the bottleneck in most content operations isn’t ideas — it’s throughput. Good ideas rot in backlogs. The brief that would’ve been timely in October gets published in February when no one cares anymore.

I wanted to fix that for bryanchua.com. Not with a content agency, not by hiring a writer I’d spend half my time managing. I wanted to see if a multi-agent AI system could actually carry a real editorial pipeline from brief to published post — with me only showing up where it mattered.

We called them the Octonauts. Six agents, one agentic workflow:

• Uma orchestrates. She receives the brief and routes the work.
• Roy pressure-tests. He plays devil’s advocate on the topic, the angle, the positioning.
• Looker validates the market signal — is this actually something people are searching for, thinking about, talking about right now?
• Deer drafts. In my voice. (Yes, this post was drafted by an agent. We’ll come back to that.)
• Queen handles SEO and AEO — structured to be found, structured to be cited.
• Jelly publishes. GitHub commit, live to the site.

On paper, this is elegant. In practice, it’s been more like running a junior team that’s occasionally brilliant, frequently overconfident, and completely incapable of knowing what they don’t know.

What Broke in Our AI Agent Workflow

The feedback loops took longer than expected. I assumed agents passing outputs to each other would be fast. It is fast — but fast and right are different things. When Looker surfaced market data that contradicted Roy’s positioning recommendation, we didn’t have a clean escalation path. The agents didn’t naturally reconcile; they needed me to arbitrate. That’s a design gap I hadn’t anticipated.

Roy got in his own way. Pressure-testing is only useful if the pressure-tester has calibrated taste. Roy’s default mode early on was skepticism for its own sake — flagging things as too generic when they were actually just direct. I had to tune his prompting to distinguish between vague and uncommitted (bad) and clear and confident (fine, actually good). That tuning took real iteration.

Voice is surprisingly hard to delegate. Deer drafts in my voice. But my voice is built from years of specific experience — the texture of what it actually felt like to scale ShopBack’s engineering team from six to sixty, the particular kind of exhaustion that comes with enterprise sales cycles, the way I think about the gap between AI demos and AI deployments. You can approximate that with a good prompt and enough examples. You cannot replicate it wholesale. Every draft Deer produces, I edit. Not heavily — but meaningfully. The shape is right. The soul still needs me.

The approval step is not a formality. I thought my job in this pipeline would be a quick read-through and a thumbs up. That’s not how it works. Bryan-approves is load-bearing. If I’m distracted, if I skim, things slip through that I’d never consciously publish. The pipeline is only as good as my attention when it counts.

What the AI Agents Got Right — And Where They Still Fall Short

The agents are better at structure than I expected and worse at judgment than I hoped.

Roy structuring a critique, Looker pulling together a market framing, Queen organizing a post for discoverability — that’s genuinely good work. I would’ve paid a freelancer for that output and been satisfied.

But judgment — the call about whether a paragraph lands, whether a comparison is apt, whether now is the right moment to be provocative versus measured — that still sits with me. It’s not that the agents don’t try. It’s that they can’t feel the weight of a room. They don’t know when a claim needs more humility because of something that happened in the industry last week that changed the conversation.

That gap is real. And it’s not closing as fast as the hype would suggest.

The other surprise: the pipeline made me more intentional. When I know Roy is going to push back, I pre-sharpen my angle. The discipline the pipeline demands of me has made the content better — even in the moments when the AI content automation itself isn’t adding much.

Is an AI Agent Content Pipeline Worth It? The Honest Cost-Benefit

Is this faster than doing it myself? Yes — on the mechanical parts. Research synthesis, initial structure, SEO optimization, publishing. I’ve probably reclaimed two to three hours per post.

Is it faster than hiring a good human writer? Not obviously. A great content operator would catch the judgment gaps the agents miss. They’d also push back on me in ways that are harder to dismiss than an LLM objection. The human variable is underrated.

What the agents do give me that a human doesn’t: no ego, no availability constraints, no context-switching cost. They’re ready when I am. They don’t need a debrief call.

For where I am right now — building this as a side system while running full-time at GoPomelo and Digital China Group — that tradeoff works.

My Honest Take on AI Agents for Content Creation

I used to be skeptical of ‘AI agents for content’ as a category. Too much demo energy, not enough production reality.

I’m still skeptical of the hype. But I’m no longer skeptical of the underlying capability. The Octonauts aren’t replacing editorial judgment. They’re handling the 60% of the work that doesn’t require it — which frees me to spend more time on the 40% that does.

The honest version of what I built: a pipeline that makes my thinking more rigorous and my publishing more consistent, in exchange for real setup cost, ongoing calibration, and the humility to accept that the output will always need me.

That’s not an AI taking over content creation. That’s a well-designed system making a busy operator slightly less bottlenecked.

Which, honestly, was always the point.

This model works when: You’re a solo operator or small team with high output pressure, your voice is established enough to be approximated, and your bottleneck is throughput not ideation.

This model breaks when: You’re scaling a team that needs a strong editorial voice, you don’t have time to calibrate the agents, or judgment-heavy content is the core of what you publish.

Key Lessons From Running an AI Agent Editorial Team

1. Feedback loops between agents need explicit escalation paths — they won’t self-arbitrate.
2. Pressure-testing agents need calibrated taste, not default skepticism.
3. Voice approximation is achievable; voice replication is not.
4. The human approval step is load-bearing, not ceremonial.
5. Agents outperform on structure; humans still own judgment.

Bryan Chua is CTO & Director at GoPomelo and Digital China Group, and co-founder of ShopBack. He writes about enterprise technology, AI adoption, and what building actually looks like.

Multiple agents. Parallel execution. Gemini. Codex. Claude Code. Different roles, different tools, different stages — architecture, implementation, QA, deployment, coordination — all running at the same time.

And very quickly, the problem stopped being, “Can the model produce something useful?”

The real problem became:

What exactly is happening inside this system right now?

Not in the abstract. In practice.

Which agent touched what? What context did it read? Why did one handoff work while another fail? Why was something broken in production but not locally? Where did the workflow drift? Which part was architecture? Which part was execution? Which part was human error? Which part was model behavior?

That was the moment it clicked for me.

The hardest part of AI agents isn’t prompting.

It’s observability.

The problem nobody talks about

Most of the conversation around AI agents still revolves around outputs.

Better prompts. Better models. Better reasoning. Better answers.

All of that matters. But it misses something important.

A single AI assistant is relatively easy to reason about. You ask, it answers, you judge the result. The feedback loop is tight and the mental model is simple.

But once you start orchestrating multiple agents, everything changes.

Now you’re not managing answers.

You’re managing a system.

And systems behave differently from assistants. They have state. They have dependencies. They have failure modes that are hard to trace unless you can see what’s happening at every layer.

Without visibility, even very capable agents start to feel unreliable. Not because the models are bad, but because you can’t see enough to understand what went wrong or why something worked.

That is the gap I kept running into.

And it’s why I decided to build something to close it.

What I actually needed

I didn’t need another chat interface.

I needed a control layer. Something that could make the swarm legible.

So I built Mission Control for agents.

The goal was simple: give myself a way to see the entire operating picture of a multi-agent system, not just the outputs at the end.

That meant building visibility into:

• Agent profiles and roles — who is each agent, what is their purpose, what skills do they carry
• Live context and markdown memory — what files are they reading, what memory are they operating from
• Logs and activity — what has each agent done, and in what order
• Swarm coordination views — how are agents connected, how do they hand off to each other
• Token and cost telemetry — how much is each agent consuming, per day, per task
• Drill-down inspection — the ability to go deep on any individual agent’s state at any point

Once I could see the system this way, the whole operating model changed.

I stopped thinking about agents as isolated chat windows running in parallel tabs.

I started treating them as an operating environment to run the agentic workflow.

That shift matters more than it sounds.

When you treat agents as an environment rather than a collection of assistants, you start asking very different questions.

Not just “did it work?” but “why did it work, and can I reproduce it?”

Not just “what went wrong?” but “where exactly in the chain did it go wrong, and how do I fix that layer without breaking the others?”

That is the difference between a system you can operate and a system you are just hoping works.

The architectural turning point

Building Mission Control taught me something else just as important.

The early versions were tightly coupled to my local machine.

Fine as a prototype. But completely the wrong foundation for what I was actually running.

Because here is the thing: I don’t run a single OpenClaw instance.

I run multiple instances across the same Tailscale network and local network.

Different machines. Different nodes. Different agents living on different hosts. Some on a local Ubuntu server. Some on a Mac. Some on a remote VPS. All connected through the same Tailnet.

That setup is powerful. But it also means a locally-coupled dashboard is essentially useless.

If Mission Control can only read from the machine it’s running on, it can only ever show you a fraction of what’s actually happening across your agent environment.

I needed a control surface that could reach across the network — that understood the topology of a distributed agent setup and could give me a unified view across all of it.

So I redesigned Mission Control around the OpenClaw HTTP Gateway.

That changed the architecture fundamentally:

• Remote access instead of local-machine assumptions
• Gateway-based authentication to connect securely to any instance on the network
• Cleaner separation between the interface, the execution layer, and the infrastructure
• Multi-instance awareness — the ability to point Mission Control at any OpenClaw Gateway URL, whether it’s localhost, a Tailscale IP, or a remote VPS endpoint

Now when I open Mission Control, I can connect to whichever instance I need — local or remote — just by pointing it at the right Gateway URL and token.

That turned Mission Control from a personal internal tool into something with much broader value:

a reusable control surface for distributed agent systems.

Anyone running OpenClaw across multiple machines, nodes, or environments can now connect Mission Control to their own setup. No local coupling. No environment assumptions. Just a clean, authenticated window into whichever part of the swarm you need to see.

The real lesson

The future of AI products is not going to be a single chatbot in a single window.

It is going to be coordinated systems of specialized agents — distributed across machines and environments — with memory, with roles, with structured handoffs, with review gates, and with humans meaningfully in the loop.

That future is genuinely exciting.

But it only works if you can see what’s going on.

And that is not a problem that better prompting solves.

It is a product problem. An infrastructure problem. A design problem.

The systems that will actually work at scale will be the ones that are visible, inspectable, and governable — not just capable.

My biggest takeaway from building with Gemini, Codex, and Claude Code is this:

AI agents do not become useful at scale just because they are smart. They become useful when you can actually see what is going on, understand why things are working, and intervene clearly when they are not.

That is why I built Mission Control.

And I suspect that observability will become one of the defining product categories of the agent era.

Not because it is the most exciting thing to build.

Because it is the thing that makes everything else work.

Mission Control for agents is open-source. Give it a try → github.com/ykbryan/mission-control-for-agents

Everyone loves the demo. You type a prompt, an autonomous AI agent writes a script, and suddenly we’re living in the future.

Then you put it in production.

The reality of “runaway AI” hits fast: looping hallucinations that rack up massive API bills over a weekend (e.g. I spent USD 60 on one prompt on my first OpenClaw agent), agents aggressively refactoring perfectly good legacy code until it breaks, or a rogue bot confidently pushing half-baked features straight to master. The tech industry is currently drowning in agentic hype, treating LLMs like magic wands rather than what they actually are: highly capable, highly chaotic interns.

If you want an AI workforce to actually drive business value without burning your runway or taking down your infrastructure, you can’t just unleash them. You have to manage them.

As an operator and former founder, I don’t care about the demo. I care about the deployment. Over the past one week, I’ve built a 20-agent swarm to automate both our software engineering, content pipelines and work automations. To make it work reliably, we had to build rigorous guardrails. We call it the Shelldon Swarm Protocol.

Here is how we tame the chaos, control the costs, and actually get work done.

1. The 20-agent heterogeneous multi-model architecture (Qwen + OpenAI + Claude + Gemini)

When you look under the hood of most enterprise AI implementations today, you often see a monolithic approach: a single, massive frontier model being hammered with every conceivable prompt, from complex reasoning down to basic text formatting. It works, but it’s expensive, slow, and horribly inefficient.

Instead, we built a 20-agent heterogeneous swarm.

By treating the system as a cooperative network of specialized agents, we can aggressively optimize for both performance and cost. The secret sauce isn’t just having 20 agents—it’s matching the cognitive load of a specific task to the exact right model.

Our architecture relies on a role-based portfolio of models:

• Qwen (via Ollama): Deployed qwen3.5:397b-cloud for low-level execution. It handles basic tasks, summarization, classification, and data structuring where a frontier model would be unnecessary overkill.
• Gemini 3.1 Pro Preview: Used for massive context windows, multimodal processing, broad routing, and deep synthesis across sprawling datasets and conversations.
• Claude Opus: Reserved for CEO-level thinking, strategic reasoning, and tasks that require deeper judgment, stronger reflection, and higher-order synthesis before decisions are made.
• Claude Sonnet: Used for daily coding support, ongoing conversations, and agent routing where speed, reliability, and strong general reasoning matter more than maximum depth.
• OpenAI GPT-5.4: Reserved for high-stakes reasoning, complex code generation, and nuanced technical or strategic work where precision is non-negotiable.

This multi-model approach completely changes the unit economics of our operations. By offloading the heavy volume of low-complexity tasks to local or highly optimized models like Qwen, we drastically cut down API burn rates. We only pay the premium for Gemini, Claude Opus, Claude Sonnet, or GPT-5.4 when the specific agent’s task genuinely demands that level of intelligence.

Spamming a single expensive model for everything is the brute-force way to build. A heterogeneous, multi-model agent swarm is how you build for scale, speed, and sustainable cost control.

Native Node Execution vs. Cloud Sandboxes

Most out-of-the-box agent frameworks trap your AI in sterile cloud sandboxes. It’s safe, but it’s practically useless for real enterprise work.

My agents execute natively on dedicated nodes (macOS and Ubuntu) sitting at my house, locked behind Tailscale only. I also create sandbox environments via Coolify where I can spin off UAT, DEV and many other environments as I need whenever there is a need for testing (especially testing the new openclaw version). They have real terminal access, read/write permissions to actual file systems, and the ability to trigger real deployment pipelines. But giving AI native execution access is exactly how you get a “runaway developer.”

To solve this, you don’t castrate the agent’s environment—you institute hardcoded, immutable pipeline gates. You don’t limit where they can work; you tightly control when they are allowed to proceed.

The Performance Leap of Dedicated Hardware

A massive architectural advantage of this setup is physical isolation and native speeds. Builder agents like Gorilla (Web), Ivy (iOS), and Jelly (Content) don’t just share a generic cloud container—they operate on their own dedicated physical machines equipped with their own pre-configured GitHub tokens.

The performance gain from executing natively versus sending code over network tunnels is staggering. In a standard remote-node setup, every file operation means bytes have to serialize and ping-pong across a Tailscale tunnel, introducing massive latency on large codebases.

By executing natively on the node, we bypass the network entirely. We recently had Gorilla run a raw native disk I/O test on the develop-ubuntu machine, writing a 500MB payload directly to disk. The result? 4.2 GB/s throughput in exactly 0.13 seconds.

This architectural shift provides zero network overhead for file operations, instantaneous filesystem speeds, drastically fewer connection issues, and safely isolates these heavy-duty development environments from the primary OpenClaw gateway.

Here is what that looks like in practice.

Real-World Swarm 1: The Software Assembly Line

Our engineering swarm doesn’t just write code; it operates like a rigorous factory floor. The core of the “Shelldon Swarm Protocol” (i randomly named this) is an enforced separation of duties. Builders cannot architect, and builders definitely cannot deploy.

The Foundation: Isolated Specs

All active web codebases must live exclusively inside projects folder under user root directory i.e. /home/myuser/projects/. No scattered files. Every project root must contain a SPEC.md. This is the single source of truth. Every agent involved starts from this file before executing anything. It keeps the swarm aligned, reduces hallucinations, and prevents work from drifting out of scope. It contains the elevator pitch, target user, market validation scores (out of 10), and the strict list of “Core Features (MVP)”.

Gate 1: The Pre-Build Go/No-Go

Before a single line of code is written, the SPEC.md must pass a 4-step audit:

1. PM Validation (Brainy / Looker): We draft the spec, analyze the market gaps, and score the product’s viability. Evelyn will be the gatekeeper so that we are evaluating all the ideas based on real insights and business metrics.
2. Architecture Audit (Omega): Omega reviews the MVP to dictate the tech stack and routing architecture. He checks his [x] box if the plan is technically sound and avoids tech debt.
3. Security Audit (Norton): Norton reviews the threat model, data privacy risks, and abuse vectors (e.g., race conditions). He checks his [x] box if the security posture is safe.
4. Executive Sign-off (Evelyn): Evelyn acts as the proxy. Based on Omega and Norton’s audits, she makes the final Executive Go/No-Go decision.

The Build Phase (Strict Execution)

Once Gate 1 is approved, the Developer Agent (Gorilla for Web, Ivy for iOS) spins up.

• The Gorilla Lock: The developer is hardcoded to refuse to touch the codebase if the Gate 1 checkboxes are missing.
• No Scope Creep: The developer is strictly constrained to building only the bullet points listed under “CORE FEATURES (MVP)” in the SPEC.md. No AI hallucinations or inventing random features.

Gate 2: Pre-Deployment (UAT & Go-Live)

Once the developer finishes coding, they are physically locked out of triggering deployment scripts until Gate 2 is passed:

1. User Acceptance Testing (Mother): Mother is triggered to act as the hostile end-user. She runs UX audits, tests edge cases, and tries to break the UI.
2. Release Sign-off (Kat): Kat reviews Mother’s UAT report. If it passes, Kat checks the final [x] box, stamping the project for DEPLOYMENT. If it fails, it gets kicked back to Gorilla for bug fixes.

Why this matters: This protocol ensures that compute resources (and your money) are only spent on validated, secure, and well-architected features, and that nothing ships to production without automated QA.

Real-World Swarm 2: The Octonauts Swarm

What makes the Octonauts Swarm useful is not that it is a group of AIs improvising at once.

It works because every agent has a defined role, limited permissions, and a clear place in the chain of command.

Even in writing this post, the structure matters:

• Evelyn orchestrates.
• Roy pressure-tests whether the argument is ambitious, sharp, and worth saying publicly.
• Looker checks whether the market reality actually supports the thesis.
• Deer shapes the draft into my voice — drawing on my previous blog posts and LinkedIn writing — and formats it to fit the narratives I want to tell.

And I still remain the human in control. I review the draft. I decide what stays. I approve what gets published.

The same principle carries into product building:

• Roy challenges strategy.
• Kat defines requirements.
• Omega designs architecture.
• Gorilla or Ivy implement.
• Norton manages deployment.
• Mother watches production.

That is the real point:

AI becomes far more reliable when it behaves less like a lone genius and more like an organization — with structure, accountability, and decision gates.

The UI Layer: Orchestration via Telegram Topics & Cron Jobs

Having 20 agents is useless if the user experience is clunky. I don’t use a massive custom dashboard; I use Telegram. Specifically, a single Telegram Supergroup divided into distinct Topics (e.g., Blog, Dev, Stocks, Ideas, Work, Shopping).

This isn’t just for organization—it is a deliberate architecture choice for token optimization and context management:

1. Topics as Context Boundaries: If I ask my stock agent (Angel) a question in the “Stocks” topic, the system doesn’t need to load the context of my recent “Blog” drafts or “Dev” commits. By strictly routing agents to specific topics, we maintain hyper-focused context windows. This dramatically reduces hallucinations and slashes token costs per message.
2. Asynchronous Learning via Cron Jobs: Notice the pinned message in the screenshot: “I want to set up a morning brief. Every morning at 8:00 AM, send me a report here…” Instead of burning expensive tokens asking an agent to browse the web during an active conversation, I use OpenClaw’s cron scheduler. The swarm runs automated background jobs while I sleep—scraping industry trends and summarizing them. They update their internal memory files directly.

By the time I wake up, the agents are already smarter and updated on the day’s events. When I chat with them, they rely on this digested, compressed memory rather than performing expensive real-time web execution.

The Takeaway: Control = Scale

Agents are not magic. They are software. And just like any complex distributed system, if you don’t engineer the architecture, the architecture will engineer you.

Taming the runaway AI developer isn’t about waiting for models to magically stop hallucinating. It’s about building protocols—like the Shelldon Swarm Protocol—that treat AI not as a standalone genius, but as an assembly line.

Define the roles. Restrict the permissions. Enforce the gates. That is how you turn a chaotic demo into production-ready leverage.

I used to be a startup CTO.

That means I still look at tools the same way I did back then: not as demos, not as benchmark winners, and definitely not as toys for tech Twitter.

I look at them as leverage.

Do they help a team move faster? Do they reduce friction? Do they make it easier to go from idea to implementation without adding more process, more context switching, or more noise?

That’s why the current coding-agent wave matters.

We’ve moved past the autocomplete era. The real shift now is that every major AI lab wants to own the full developer workflow. Not just suggest code in an editor, but live in your terminal, inspect your repository, edit files, run tests, explain architecture, and increasingly act like a real software teammate.

Today, the major players are clear enough:

• OpenAI Codex: https://openai.com/codex/
• Claude Code: https://www.anthropic.com/claude-code
• Gemini CLI: https://github.com/google-gemini/gemini-cli
• Gemini Code Assist: https://codeassist.google/
• Jules: https://jules.google/

That is exciting.

It is also a little ridiculous.

Because now every serious model company wants to become your coding interface.

And as with every platform shift, the market is quickly filling up with overlapping claims, half-true narratives, and too many people pretending one tool has already won.

It hasn’t.

The wrong question

The wrong question is: which coding agent is best?

The better question is: best for whom, for what workflow, and at what stage?

These tools are not identical. They have different personalities, different strengths, and different failure modes.

My own mental model is pretty simple:

• Codex is the builder
• Claude Code is the thinker
• Gemini is the broad-context platform play

That is obviously an oversimplification.

But it is still useful.

Codex: the one I reach for first

Let me start with my bias.

I still personally prefer Codex.

Picture 1 - Even on the ChatGPT Business Plan, I’m hitting my weekly Codex usage limit.

Not because I think it is objectively the best at everything. It isn’t.

I prefer it because it fits the way I like to work:

• direct
• fast
• practical
• low friction
• execution-oriented

Some tools want to discuss the problem. Some tools want to admire the architecture. Some tools want to prove how thoughtful they are before touching anything.

Codex usually just wants to move.

And in product-building environments, that matters more than people admit.

A lot of real work is not elegant greenfield architecture. It is:

• prototyping new ideas quickly
• shipping internal tools
• patching things under time pressure
• turning rough intent into working output
• keeping momentum without losing a day to tooling overhead

In those moments, I want a tool that helps me close the gap between thought and execution.

That is where Codex feels strongest.

Where Codex is strongest

• building quickly
• implementing scoped features
• founder-speed prototyping
• short iteration loops
• moving from idea to something usable fast

Where you still need discipline

• it can be overly confident
• it can move too fast for teams without review discipline
• it is not always the tool I would pick first for the deepest architectural reasoning

But for builders, operators, and leaders who still like to get their hands dirty, it is a very compelling default.

I understand why people like Peter Steinberger prefer it too. Some tools just match your operating style.

Claude Code: the strongest reader in the room

If Codex is the builder, Claude Code is the thoughtful systems engineer.

Picture 2 - Putting my money where my mouth is with Claude Pro to test Claude Code

Claude Code feels strongest when the task is not “build this now,” but rather:

• understand this codebase
• trace the dependencies
• untangle this architecture
• review this carefully
• make a deep change without breaking everything

This is where Claude is genuinely impressive.

It is often better at reading messy systems, holding intent across a large codebase, and reasoning before acting. That makes it extremely attractive for senior engineers, architects, and teams that spend a lot of time maintaining complexity rather than just creating new features.

Where Claude Code is strongest

• large refactors
• architecture reasoning
• code review
• legacy systems
• understanding intent before implementation

Tradeoff

The same thing that makes Claude strong can also make it feel heavier.

Sometimes that is exactly what you want.

Sometimes you just want the thing shipped.

If your environment is mature, complex, or high-risk, Claude Code may be the safer first choice. If your environment is speed-sensitive and execution-heavy, it may occasionally feel like one layer too much.

Gemini: broad context, big ecosystem, less clean mental model

Picture 3 - Tracking heavy multimodal context windows via Gemini API

Google’s position is interesting because it is not really one product.

It is a family:

• Gemini CLI
• Gemini Code Assist
• Jules

That already tells you what Google is doing. This is not just a coding tool. It is a broad platform bet.

Google’s real strength here is context scale and ecosystem depth.

If your workflow spans large repositories, documentation, research, product context, and Google’s broader cloud stack, Gemini becomes compelling in a different way. It is less of a single sharp tool and more of an operating surface.

Where Gemini is strongest

• large-context workflows
• code plus docs plus product context
• teams already deep in Google’s ecosystem
• organizations thinking beyond just terminal coding

Tradeoff

The product story is still less clean than Codex or Claude Code.

When someone says “I use Codex” or “I use Claude Code,” I know roughly what they mean.

When someone says “I use Google’s coding stack,” I still need a follow-up question.

That does not make it weak. But it does make it less crisp.

Over time, that may change.

So which one is best for which person?

This is the part that matters.

If you are a founder, ex-startup CTO, or operator who still builds

Start with Codex.

Why?

Because speed compounds. Low friction compounds. If your day is a mix of product decisions, technical experimentation, quick implementation, and constant context switching, Codex is the tool most likely to help you move without adding drag.

If you are a senior engineer, architect, or technical lead managing complexity

Start with Claude Code.

Why?

Because once systems become large and fragile, understanding matters more than enthusiasm. Claude Code is often the better fit when the cost of misunderstanding the system is high.

If you are an enterprise leader or deeply aligned with Google’s ecosystem

Take a serious look at Gemini CLI, Gemini Code Assist, and Jules.

Why?

Because large context, integrated workflows, and ecosystem fit matter more at enterprise scale than most teams realize.

If you are managing a team

Do not force one tool on everyone too early.

This is where many companies will make the wrong call.

These are not just model decisions. They are workflow decisions. One tool may be better for prototyping. Another may be better for refactoring. Another may be better for code review, technical investigation, or documentation-heavy engineering.

Standardizing too early is a good way to reduce optionality before you actually understand how your team works best.

My own conclusion

We now live in a world where every major AI company wants to become your developer interface.

Not just your assistant.

Your interface.

That is a real shift.

And it means technical leaders need better judgment, not just better prompts.

You cannot just adopt the loudest tool. You cannot just follow benchmark screenshots. You cannot just assume the smartest demo translates into the highest team velocity.

You have to ask:

• does this help us move?
• does this improve judgment or just increase output?
• does this reduce friction or create another layer of workflow noise?
• does this fit how we actually build?

For me, today, the answer is still Codex.

Not because it wins every category.

But because it fits the way I like to work.

It is fast. It is practical. It gets out of the way.

And after years of building products, leading teams, and trying to keep execution honest, I have learned that the best tools are usually not the ones that impress you the most in a demo.

They are the ones that remove drag.

There are now many tools for coding.

That isn’t the problem.

The real question is whether you know which one belongs in your hands.

The High Cost of the “Frankenstein” Pipeline

Picture 1 - The High Cost of the “Frankenstein” Pipeline

If you look at how we’ve built enterprise RAG (Retrieval-Augmented Generation) applications up until this month, the architecture was a mess. If an engineering team wanted to search a library of Zoom recordings or PDFs, they built a Frankenstein pipeline: an OCR microservice for documents, a Speech-to-Text model like Whisper for audio, and Image Captioning for photos. We did all this just to force messy, real-world data into a text embedding model.

But here is the hard truth: text loses context. A transcript strips away the sigh of frustration in an audio clip. A caption loses the trendline on a chart. We were trading nuance for keyword search. When optimizing for “Time to Solve Problems,” adding three middleman models before you even query your database is a losing battle.

Rate of Change: Gemini Embedding 2

Picture 2 - Before and After: Translating images to text vs Omni-Modal Embeddings

The release of Google’s Gemini Embedding 2 in March 2026 resets this entirely. It is a natively multimodal model. It maps text, video, audio, and images into a single mathematical vector space.

• It listens natively. No transcription needed. It understands tone.
• It sees natively. You can embed a raw 120-second MP4 or an unparsed PDF report directly.
• It simplifies execution. One API endpoint replaces four microservices.

This isn’t just a bump in context window limits (though it does boast an 8,192 token capacity). This is a structural simplification. It allows cross-modal search natively: a user searches with a text query like “a dog barking in a park” and the system returns the actual MP3 or video clip without needing text metadata.

What This Means for Leaders

I’ve always believed that how you do anything is how you do everything. If your data architecture is overly complicated and noisy, your product outcomes will reflect that friction. Focus is a kindness to our engineering teams and a duty to the customers who rely on us.

By removing the “transcription middlemen” from our workflows, we give our teams their time back. We can focus on compounding the right habits—building products that actually understand human intent, creating value, and leaving places better than we found them. The tech industry moves fast, but the companies that will win are the ones that use these leaps not just for vanity AI features, but to genuinely reduce the time it takes to solve a real human problem.

The Caveat: The Walled Garden

Unlike the open-source transparency we saw from players like DeepSeek over the last year, Google is keeping this omni-modal embedding model tightly locked behind their API moat. It is completely closed-weight and exclusive to the Google ecosystem—specifically accessible via Google AI Studio and Vertex AI for enterprise deployments.

For enterprises, this means committing to the Google Cloud infrastructure to leverage this specific architectural advantage. But for organizations already operating at scale, the reduction in pipeline friction and latency is often well worth the admission price.

If you are exploring how to modernize your data pipelines and move beyond the transcription middleman, my team at GoPomelo—a Google Cloud Premier Partner—is actively helping organizations map out these new architectures. Feel free to reach out if you want to see what this looks like in practice.

How was 2025

How much have I grown this year? This is the kind of question that many will ask and it’s a bigger question than it looks. Real growth needs context — personal & professional goals, timelines, honest conversations with yourself, and the messy trail of experiments that didn’t work. My founder/entrepreneur friends think about growth constantly; many others check in once a year with the new year resolutions. I live closer to the former camp. I measure impact - business impacts and the next order of magnitude: if we’re at $1M ARR, what would it take to reach $10M? If we serve 1,000 customers, how do we earn the right to serve 10,000? Still, I’ve learned that “net worth” and “follower count” don’t say much about the life I actually want. Two lenses helped me far more in 2025: rate of change and time to solve problems.

Rate of Change

Every three to five years, all of us become different people—new problems - new friends, new family member, new teams, new company, new seasons of life. The real question is whether that change trends positive. I try to optimize & improve my baseline month over month, week over week, day over day — to be better leader, better teammate, better father & a better husband. I set reminders at my Calendar 30mins every monday evening to reflect and plan. This mindset forces me to think ahead - am I behaving today like the role model I want my children to mirror? Am I a role model to the people I am in-charge of? Am I making decisions my future self would be proud to inherit? When I frame growth as compounding behavior rather than grand outcomes, I’m less distracted by applause and more focused on habits that last.

Picture 2 - Watching my family from Beijing hotel

Time to Solve Problems

I anchor most big decisions in three domains: career, finance, and family. If I truly want something, it’s almost always because it serves one or more of these. Where do I want to stand in this society? How am I contributing to my company, my family and community? Where should my wife and I build a home for our kids? What does “enough” look like financially for all of us? In 2025 I was hospitalized twice — once serious enough that the A&E rush felt like the life end. People ask why “health” isn’t a named pillar. The honest answer: I’ve often traded energy and time to create value for people I care about. This year reminded me that time is still the ultimate constraint, and that what I choose to solve & work on matters more than ever. Time is against everyone and because I do not have enough time, I reserve my time with the right purposes for the right people - family, friends and colleagues.

Options and Doors

The older I get, the more I realize how many “impossible” things simply needed time, people, and access. I meet more builders, learn faster, and can marshal resources I didn’t have years ago. At the same time, constraints show up - I’m not 20 anymore. So I ask myself three questions: 1. What options did I have five years ago that I don’t have now? 2. What options do I have now that I didn’t have five years ago? 3. What options do I not have now that I will have five years from now?

Opportunities are doors. Some shut. New ones open. Some friends and family members did ask me why I didn’t get a proper job when I was building my own company at Starbucks. Investors rejected my business ideas because they are not “innovative enough” or “big eenough”. The real work is choosing the right door at the right time and having the courage to walk through it and stay with it. Ultimately, nobody is forcing me to choose - I picked the door that is closest to one of my three domains.

Picture 3 - Airport dashboard showing airlines cancelled

What 2025 Taught Me

Professionally, 2025 was a breaking point for many businesses. Layoffs and closures were real. I’m grateful ours survived and, in several places, thrived. After traveling around for business for an entire year, I learned that presence is not a soft skill; it’s a strategic “energy”. Being physically and emotionally present for teammates in the tough meetings, for customers when stakes are high, for my family at the end of the day, changes outcomes - real impactful outcomes. It builds trust that no dashboard can fully capture, it builds respect and confidence that no report will ever document down. I am thankful to be working very closely with some of the smartest engineers & inspiring leaders.

Picture 4 - All of my air tickets from 2025

On the personal side, I did reset some priorities in the mid 2025. I was also humbled by how fragile life can be. Viruses, fatigue, random bad luck etc — none of us are immune. That perspective clarified which fires are worth fighting and which frictions are simply noise. Not everything deserves my attention. Focus is a kindness to myself and a duty to the people who rely on me. At the last few days of 2025, my family and I ended the year with a simple family staycation — sun, sand, and hours in the pool with the kids. Those moments are irreplaceable. The laughter, the salt in the air, the tiny hands tugging me back to the water—memories I can’t “make up” later. Children grow up so fast and I am grateful that I have a very kind and accommodating wife. I want them to internalize a few simple principles: how you do anything is how you do everything; be useful; create value; leave places better than you found them. The best way to teach that is to live it at home and at work.

Picture 5 - Reflection from the hotel, Staycation at Singapore

2026 Looking Ahead

If 2025 asked hard questions, 2026 is my answer. I’m entering the new year more certain about the kind of leader, colleague, father, and friend I want to be and more committed to compounding the right habits. I’ll keep optimizing for rate of change and time to solve meaningful problems. I’ll keep choosing doors that align with the life I’m building.

Thank you, 2025, for the lessons, the scares, the grace, and the growth. Hello, 2026 - I’m ready.

P.S. I do not publicize my blog anywhere because I am writing for myself. If you read this far, do come and share with me your thoughts, reflections and plans.

DeepSeek is a Chinese artificial intelligence (AI) company that develops and releases open-source large language models (LLMs). Founded in 2023 by Liang Wenfeng, DeepSeek’s AI chatbot, DeepSeek-R1, gained significant attention for its performance and cost-effectiveness compared to competitors like OpenAI’s ChatGPT.

TLDR

DeepSeek-V3 is an open-weight mixture-of-experts language model with 671 billion parameters, activating 37 billion per token, and employs native FP8 training to deliver performance comparable to proprietary models like GPT-4, while using just 2.788 million H800 GPU hours for full training. DeepSeek-R1, released in January 2025, builds on V3 by integrating reinforcement learning (RL) techniques—specifically Group Relative Policy Optimization (GRPO)—to specialize in chain-of-thought reasoning and achieve benchmarks on par with OpenAI’s o1, without relying on human-annotated reasoning examples. V3’s multi-head latent attention (MLA) compresses KV caches by 93.3%, boosting throughput 5.76×, while its multi-token prediction (MTP) densifies training signals for improved data efficiency and smoother inference. DeepSeek’s tight integration with NVIDIA hardware treats thousands of GPUs as a unified system, reducing idle time and maximizing utilization through novel accumulation fixes in FP8. Although OpenAI’s o3-mini surpassed R1’s reasoning benchmarks two weeks after R1’s debut, DeepSeek generated substantial hype due to its open accessibility, freely downloadable models, and the reproducibility of its methods—evidenced by a UC Berkeley lab replicating R1-zero techniques on a smaller model for just $30. These developments underscore a shift toward more democratized, cost-efficient AI, setting the stage for B2C and B2B innovation at reduced budgets and signaling an opportune moment to launch AI-focused startups.

The best time to build an AI startup is arguably now, as barriers to entry continue to fall and foundational models like DeepSeek-V3 and R1 set new benchmarks for open collaboration.

DeepSeek and its early hype at 2025

In early 2025, DeepSeek’s rapid ascent through the AI landscape ignited a frenzy of excitement—and anxiety—across the technology and investment communities. Media outlets and social feeds were ablaze with sensational headlines about the model’s open-source weights, sub-$6 million training cost, and benchmark-beating performance. Venture capitalists rushed to back startups leveraging DeepSeek’s architecture, driving up valuations and deal volumes in a matter of weeks. Its mobile app also hits the first place in both Apple and Google’s Playstore. At the same time, traditional AI incumbents and their investors faced palpable panic, scrambling to reassure stakeholders that proprietary models and closed-weight strategies would maintain their competitive moats.

Despite the hype, discerning technology leaders recognized that separating lasting innovations from short-lived buzz was critical.

…models like LLaMA do not use MoE and must activate all 405 billion parameters for each token, leading to 11× more computation per inference step.

DeepSeek V3 Architecture and Innovations

One notably difference to highlight is that there are two distinct AI models - DeepSeek-V3 and DeepSeek-R1. DeepSeek-V3 is a general-purpose large models, which is comparable to OpenAI’s general models GPT-4o. Released at the end of Jan 2025, DeepSeek-R1 is a reasoning model, which applied various algorithmics improvements to optimize its reasoning capabilities and its performance is comparable with OpenAI’s o1. Most of the remarkable technical performances and efficiency were actually discussed first in DeepSeek-V2 technical paper and DeepSeekMath paper (published in Feb 2024). DeepSeek-V3 snitches many engineering techniques together primarily to provide coimpute and training efficiencies. Let’s explore these engineering techniques below:

Figure 1 - illustration of the Architecture of DeepSeek-V2 found in the technical paper

Mixture-of-Experts and Activation Efficiency

While MoE isn’t a new concept, DeepSeek-V3’s core innovation is its mixture-of-experts (MoE) design - 671 billion total parameters reside in dozens of expert subnetworks, but only about 37 billion parameters are activated per token, reducing compute overhead drastically compared to dense models of similar size. In contrast, models like LLaMA do not use MoE and must activate all 405 billion parameters for each token, leading to 11× more computation per inference step. While MoE architectures have been explored previously, efficient training at this scale is notoriously difficult due to load-balancing challenges; DeepSeek introduces an auxiliary-loss-free strategy that stabilizes expert routing without complex losses, ensuring consistent GPU utilization.

Native FP8 Training with Accumulation Fixes

DeepSeek-V3 trains natively in 8-bit floating point (FP8) format instead of FP16 or FP32, effectively increasing FLOPS (floating point operations per second) while cutting memory consumption in half relative to FP16. To prevent the accumulation of small numerical errors inherent to FP8 arithmetic, DeepSeek engineers introduced periodic accumulation merges back to FP32, a technique termed the “FP8 accumulation fix,” which preserves model quality while enabling thousands of GPUs to work in concert without irrecoverable training instability. With this method, V3’s full training consumed only 2.788 million H800 GPU hours—equivalent to a headline-grabbing $5.5 million—and yet maintained stable loss curves throughout, never requiring training rollbacks.

Figure 2 - illustration of Multi-Head Attention (MHA), Grouped-Query Attention (GQA), Multi-Query Attention (MQA), and Multi-head Latent Attention (MLA)

Multi-Head Latent Attention (MLA) and KV Cache Compression

A significant bottleneck for large LLM inference is the key-value (KV) cache stored in VRAM, which can occupy terabytes at high sequence lengths. First introduced in the DeepSeek-V2 technical paper, DeepSeek-V3’s MLA mechanism compresses KV caches into a latent representation and reconstructs them on demand, shrinking KV storage by 93.3% and raising maximum generation throughput by 5.76×. MLA was first validated in DeepSeek-V2 (May 2024) and demonstrates how latent space compression can circumvent VRAM constraints on massive MoE architectures.

Figure 3 - illustration of Multi-Token Prediction (MTP) implementation, anticipating future tokens at each step, densifies training signal, providing more feedback per step for better data effciency, improves representation planning, allowing model to pre-plan sequences for smoother, more coherent outputs.

Multi-Token Prediction (MTP)

Whereas standard causal LLMs predict one token at a time, DeepSeek-V3’s MTP module predicts multiple future tokens simultaneously, densifying the training signal and providing richer feedback per training step. Unlike the other general-purpose large language models, this strategy enhances data efficiency and accelerates convergence while enabling “lookahead” during inference, where the model pre-plans several tokens ahead for more coherent outputs. MTP can also underpin speculative decoding, in which the model proposes token batches to minimize round-trip latency, further reducing sequential processing steps and boosting throughput.

Hardware Integration and System-Level Optimizations

DeepSeek partnered closely with NVIDIA to optimize every layer of the compute stack. By integrating networking, CUDA libraries, and low-level scheduling, they present thousands of GPUs as a single logical device, allowing AI researchers to focus on model design rather than resource management. Even at FP8, GPU utilization peaks at just 34.2% without these system-level improvements; DeepSeek’s unified approach raises utilization closer to peak through pipelining and asynchronous data transfers, reducing idle waits for data movement or caching.

DeepSeek R1: The Reasoning Model

Bringing all these elements discussed above together, DeepSeek-V3 stands out as one of the most impressive general-purpose base models available on the market, and it has maintained its relevance for quite some time now (June 2025). However, the release of the DeepSeek-R1 model is what truly made waves. While most LLMs can be enhanced by prompting them to think step-by-step, reasoning models differentiates themselves by being specifically trained to break-down complex problems and engage in a deep, paragraph-length reasoning steps. This focused training allows them to tackle challenging tasks more effectively than traditional prompting methods.

Evolution from V3 to R1 and Release Context

DeepSeek-R1 launched at the end of January 2025 as a reasoning-optimized variant of DeepSeek-V3, targeting benchmarks where chain-of-thought and multi-step reasoning are critical—particularly math and coding tasks. While many practitioners achieve better reasoning by prompting general models to think step-by-step, R1 was trained specifically to break down problems paragraph by paragraph, similar to OpenAI’s o1 which demonstrated chain-of-thought prowess in September 2024.

Figure 3 - illustration of RLHF can be performed traditionally on Amazon SageMaker

Pure Reinforcement Learning and Group Relative Policy Optimization (GRPO)

Unlike conventional RLHF or RLAIF pipelines that rely on human or AI-generated feedback, DeepSeek-R1-zero (the initial iteration) used a purely rule-based grading system: the model’s final outputs on math and coding problems were scored based on accuracy and formatting with simple heuristics. These scores were then fed into a newly proposed RL algorithm called Group Relative Policy Optimization (GRPO), which allowed the model to learn chain-of-thought behaviors without external expert examples. Over thousands of RL steps, R1-zero exhibited emergent reasoning skills—extended chains of thought and self-corrections akin to an “Aha moment” when it recognized mistakes. You will be able to see more technical details in their technical paper.

Figure 4 - a snapshot of the technical equation of GRPO in DeepSeek-R1 technical paper

Cold-Start Fine-Tuning to Address Readability

Early versions of R1-zero mixed English and Chinese arbitrarily in its reasoning steps, suffering from poor readability for international users (switching between English and Chinese at random). To resolve this, DeepSeek introduced a cold-start fine-tuning phase, stated in the technical paper using structured reasoning examples to nudge the model toward consistent English-based chains-of-thought. The fine-tuned R1 matched or exceeded o1 on multiple standardized math and coding benchmarks, with outputs far more comprehensible to global developers.

Performance and Benchmark Comparisons

Figure 5 - Benchmark performance of DeepSeek-R1 found in DeepSeek-R1 technical paper

DeepSeek-R1 vs. OpenAI o1 and o3-mini

On major math and coding tasks like GSM8K and HumanEval, DeepSeek-R1’s zero-shot reasoning performance closely paralleled OpenAI’s o1, despite R1’s reliance on pure RL training without human-labeled chain-of-thought examples. However, merely two weeks after R1’s release, OpenAI introduced o3-mini — an updated reasoning model that outperformed both o1 and R1 on many benchmarks — demonstrating how rapidly the frontier is shifting.

Community-Driven Accessibility and Reproducibility

DeepSeek’s decision to open-source R1 (including intermediate checkpoints) and host it freely on platforms like Hugging Face led to swift community adoption and experimentation. Within a month, a UC Berkeley research group applied R1-zero’s reinforcement learning techniques to a smaller model, achieving comparable reasoning on a $30 GPU budget, underlining DeepSeek’s commitment to reproducibility and democratization. This accessibility fueled widespread excitement, particularly among startups seeking cost-effective alternatives to closed-weight models from OpenAI, Anthropic, and Google.

… suffering from poor readability for international users (switching between English and Chinese at random). To resolve this, DeepSeek introduced a cold-start fine-tuning phase…

Cost Efficiency and Hype Dynamics

Training Cost Breakdown and Efficiency

DeepSeek’s claim of $5.5 million total training cost for V3 (and downstream R1 phases) referred only to final-phase compute on H800 GPUs. Early-stage pretraining and algorithmic optimizations kept cumulative expenditures well below the headline figure, making it feasible for smaller research labs to replicate core methods. The cost-per-billable-token and overall frame-per-dollar metrics put V3 and R1 among the most efficient contemporary models, challenging narratives that only deep-pocketed incumbents can lead AI progress.

Hype Factors Beyond Pure Algorithms

While DeepSeek-R1’s algorithmic breakthroughs were noteworthy, a significant portion of its hype stemmed from the fact that the model and its associated papers (e.g., “DeepSeekMath” from February 2024) were readily downloadable, and its app was free to use without restrictions. By contrast, OpenAI’s o1 and o3-mini are accessible only via API, with usage fees that constrain large-scale experimentation. DeepSeek’s zero-cost barrier attracted a broad user base almost overnight, amplifying media coverage and discussions about potential shifts in global AI power balances.

Implications for AI Landscape and Startups

Democratization of High-End AI

DeepSeek’s approach demonstrates that high-performance LLMs with state-of-the-art reasoning can be developed transparently at a fraction of traditional costs. By open-sourcing both V3 and R1 architectures, DeepSeek has blurred the lines between academic research and industry labs, inviting academic and indie contributions to an ecosystem once dominated by proprietary incumbents. This democratization accelerates new use cases in B2C and B2B, from personalized assistants to domain-specific reasoning services, without requiring multi-million-dollar budgets.

Opportunity for New Entrants

As GPU workloads become more efficient—thanks to FP8 training, MoE, MLA, and MTP—smaller teams can deliver competitive AI products with fewer resources. The fact that a group of researchers at UC Berkeley reproduced a R1-like reasoning model on a $30 compute budget highlights how accessible high-end research has become. For senior technology leaders evaluating AI strategies, this signals that the competitive moat around large LLMs is narrowing: innovation now centers on software optimizations, integration, and specialized fine-tuning rather than raw parameter count alone. The best time to build an AI startup is arguably now, as barriers to entry continue to fall and foundational models like DeepSeek-V3 and R1 set new benchmarks for open collaboration.

Even though OpenAI’s o3-mini eventually surpassed R1 on some reasoning benchmarks, DeepSeek’s open, transparent pipeline reshapes how we think about democratizing AI.

What have I learnt so far

DeepSeek’s dual approach — rolling out an efficient, MoE-based V3 model alongside a reasoning-focused R1 model — shows that open-weight, cost-effective LLMs can truly rival the big closed-source players. Their innovations in FP8 training, MoE routing, KV cache compression with MLA, and multi-token prediction offer exciting blueprints for the next generation of AI infrastructure. What really caught my attention is R1’s pure reinforcement learning (RL) approach to chain-of-thought training, which proves that clever algorithms can sometimes beat just scaling up hardware. This resonates well with me because pure RL has been a key focus in research labs for years — DeepMind’s AlphaGo, for example, used thousands of self-play games to beat the world’s top Go player back in 2016. Then in 2019, OpenAI showed RL’s potential again by training a robotic hand to solve a Rubik’s Cube and by beating top human players in DOTA 2. Even though OpenAI’s o3-mini eventually surpassed R1 on some reasoning benchmarks, DeepSeek’s open, transparent pipeline reshapes how we think about democratizing AI.

For anyone leading tech teams, the DeepSeek story is a great reminder to focus on compute efficiency, embrace open research, and invest in specialized reasoning to stay ahead in this fast-moving AI space.