For most developers, it solves a problem you probably don’t have, and it introduces complexity you definitely don’t need.

Please don’t switch to TOON just because it’s shiny.

1. Let’s Start With the Weird Part: JSON Everywhere… Except in Prompts

One of the first things that impressed me in the LLM world was this idea:
”Let’s use JSON to talk to models. It’s structured! Machines love it!”

Sounds nice. But then you look at how real LLM prompts are built.

Claude’s Smart Prompt Maker? This is a tool for helping create prompts.
Plain text.

GitHub Copilot’s own internal prompts?
Again: plain text.
You can open this file yourself and see how they build prompts for editing code:
inlineChatEditCodePrompt.tsx

The output they expect? Pure text.

Not JSON. Not TOON. Just text.

So we have this strange situation:

• Prompt engineering tools use text.

• Real-world LLM products use text.

• Yet people want to wrap everything in JSON or TOON to be “modern” and “structured.”

And that is already a red flag.

2. Most LLM Context Is Text, Not Some Fancy Format

For most real use cases, context is:

• plain text (descriptions, docs, comments),

• or code (when talking to dev tools like AI commit / AI test, Mavka-style tools, etc.).

The value comes from what you say, not from how many brackets or headers you add.

TOON is tightly tied to structured, table-like data. That’s a very narrow slice of what developers actually do with LLMs day to day:

• writing commit messages,

• generating tests,

• refactoring code,

• explaining errors,

• summarizing logs in natural language.

In many of these, TOON adds more ceremony than value. Your model doesn’t need a new “format religion.” It needs clear instructions and relevant context.

3. About Token Savings: CSV and Compact JSON Already Beat TOON

Advocates of TOON love to talk about token savings. They show cases where TOON beats JSON in token count. Fine.

But look at the same problem with a bit of discipline.

If you:

• clean up your JSON,

• or use a compacted JSON structure,

• or even switch to CSV when you have tabular data,

you can often do better than TOON.

In TOON’s own benchmarks, CSV comes out more compact than TOON. CSV is simpler, easier to parse, and already well understood. For many “rows and columns” problems, CSV wins.

Even worse (for TOON): when they compared TOON to compacted JSON in complex domains (see their own mixed-structure track on GitHub), compact JSON beat TOON in every scenario.

So the supposed story:

“TOON is the future, JSON is old and bloated”

quickly turns into:

“CSV and compact JSON quietly win in practice.”

If a “revolutionary” format can’t consistently beat a cleaned-up version of JSON, you have to ask: is this really a breakthrough, or just a rebrand?

4. My Read: Duolingo Solved Their Problem, Then Sold It as a Movement

Here’s how TOON looks to me.

Duolingo had:

• a very specific internal problem,

• in a very specific domain,

• with very specific constraints.

They designed TOON to fix their issue. That’s totally fine. Every serious company builds internal tools.

But then comes the investor story:

• “We invented a new AI data format!”

• “We’re on the cutting edge of LLM protocols!”

• “Look how advanced we are!”

Suddenly, an internal optimization turns into a public “standard”, complete with blogs, talks, and hype. Now developers are told:

“If you’re serious about LLMs, you should look at TOON.”

My view: this is not about your problems as a developer.
This is about their narrative as a company.

5. The Real Risk: Solving Fake Problems, Creating Real Ones

When you adopt a hyped format like TOON too early, you risk:

• Solving the wrong problem
  You optimize token count a tiny bit instead of fixing bad prompts, irrelevant context, or poor evaluation.

• Adding complexity to your stack
  Now you need converters, validators, libraries, and mental overhead just to talk to a model… that is totally fine with text and basic structure.

• Locking yourself into a niche format
  JSON and CSV are universal. TOON is not. You’re tying your system to someone else’s experiment.

• Confusing your team
  Your devs now have to learn a custom syntax instead of focusing on model behavior and domain logic.

This is classic hype-driven engineering:

1. Pick a trendy technology.

2. Force it into your stack.

3. Then discover all the new problems it created.

4. Spend months fixing those instead of actual business issues.

6. What I Recommend Instead

Before you even think about TOON, do this:

• Start with plain text prompts.
  Make them clear, explicit, and well-structured.

• Use CSV for large, regular tables of data.
  Simple, compact, proven, easy to work with.

• Use compact JSON where structure truly matters.
  Avoid bloat. Remove unnecessary nesting and repetitive keys when you can.

• Measure first, don’t assume.
  Run the same task with:

  • plain text + some structure,

  • CSV,

  • compact JSON,

  • and, if you really want, TOON.

Then compare:

• token count,

• latency,

• model quality for your specific domain,

• complexity of your codebase.

Most of the time, you’ll discover:

• TOON is not magic,

• your existing tools are already good enough,

• your biggest gain comes from better prompts, not brand-new formats.

Why rollback matters more than “perfect releases”

We love to pretend we can predict everything with tests, reviews, and checklists. But look at the last few years:

• CrowdStrike 2024: a faulty Falcon Sensor content update bricked ~8.5M Windows machines with BSOD, disrupting airlines, banks, hospitals, and governments worldwide, with losses estimated around $10B+. The protection agent behaved like malware itself – pushed everywhere, with no quick escape hatch.

• Cloudflare 2019: a bad regex in the WAF config → 100% CPU across edge servers → global outage.

• Facebook 2021: a planned BGP change → entire network disappears from the internet.

• Cloudflare 2025: another cascading failure, again showing how small config changes can trigger massive outages.

In every one of these, the technical bug is almost boring. The real story is: they had no safe way to roll back instantly once things started going wrong.

That’s the lesson for us: the question is not “How do we avoid all bugs?” but “When we inevitably ship a bad one, how fast can we get out of it?”

For desktop apps, this is even more brutal: you’re pushing code onto thousands or millions of independent machines you don’t control. If you mess up, you can’t just fix the server and be done – you’ve delivered a time bomb to every endpoint. That’s why your release and rollback strategy is part of your product, not just your CI/CD config.

The mindset shift: from “prevent failure” to “survive failure”

I’m not a fan of the belief that “with enough planning, nothing bad will happen.” Complexity doesn’t care about your optimism. Every new feature, library, integration, and OS version multiplies your failure modes.

So instead of chasing some fantasy of perfect prediction, design for these realities:

• You will ship a bad build.

• You will only discover the worst failures in production, under real user conditions.

• Sometimes your monitoring won’t even catch it; your first signal is a flood of support tickets.

• When that happens, your only question is: Can we safely undo this in minutes, not days?

That’s what a good desktop release strategy buys you.

Principles for sane desktop release & rollback

For most of us (unlike CrowdStrike, where security constraints are extreme), we absolutely can and should build automatic release & rollback. At minimum strategy looks like this:

1. Release in chunks, never “all at once”

You want to control your blast radius.

For desktop:

• Start with internal / dogfood (your own machines, IT, support, engineering).

• Then maybe 1–5% of external users (a “ring 1” or canary cohort).

• Only then ramp up to 25%, 50%, 100% – with checks and pauses in between.

This is the desktop equivalent of ring deployments or canary releases on the server side. If CrowdStrike had shipped that content update to 1% first, they’d still have had a bad day – but not a $10B disaster.

2. Implement a ring / wave model

Microsoft’s classic model is:

• Ring 0 – internal/dev, very tolerant of bugs.

• Ring 1 – early adopters, opt‑in, understand risk.

• Ring 2+ – broader user base, more conservative.

For a desktop updater, that means:

• The update service knows which ring a machine belongs to.

• New versions or definitions are first offered to inner rings.

• You only promote an update to the next ring if metrics look healthy.

3. Health checks and auto‑revert on the client

Don’t just ship a binary and hope. The desktop agent itself should protect the user:

• Startup sanity checks: after updating, the app should verify basic invariants: can it start, can it talk to the server, is config readable, no critical exceptions on boot.

• Watchdog / supervisor: a small, stable component that monitors the new version. If it sees repeated crashes or failed starts, it can:

  • Flip back to the previous known‑good version.

  • Disable the broken feature flag.

  • Contact the update server with a failure signal.

This is the “health check” equivalent for desktop. On the server we use probes and metrics; on desktop we need built‑in “is this update killing the app or the OS?” checks.

4. Be able to roll back immediately

Rollback must not be a meeting. It must be:

• A single operation in your release system: “promote previous version”, “disable version X”, or “switch canary off”.

• For desktop, ideally:

  • The update server stops offering the bad version.

  • For machines that already updated, the agent can:

    • Roll back to the older package that it still has cached.

    • Or receive a special rollback command that forces downgrade.

Your rule of thumb: if rollback requires humans logging into endpoints or writing manual instructions to customers, you don’t have rollback. You have damage control.

5. Strong validation of updates and configuration

CrowdStrike’s specific failure was “wrong file uploaded.” That’s a deeply mundane way to blow up the world.

You want multiple layers of defense before anything reaches endpoints:

• Schema and type validation of any config or content updates.

• Digital signatures and checksums: endpoints must refuse any file that doesn’t match what the server expects.

• Format and sanity checks on the client: if the file looks weird (size, structure, version mismatch), don’t apply it.

• Slow promotion: even if something bad slips through validation, your ringed rollout catches it before it hits everyone.

You cannot rely on “the right file will always be uploaded.” Assume the opposite.

6. Observe your release like it’s a production incident

Every deployment is a small incident you hope ends well.

So you want:

• Real‑time metrics for the new version: crash rate, launch time, key errors, support tickets per minute.

• Per‑version and per‑ring dashboards: “How’s 3.2.5 performing on ring 1 vs 3.2.4?”

• Alerting with clear runbooks: “If crash rate > X% for new version, stop rollout and trigger rollback.”

Don’t just log things. Tie them to automated decisions: pause, roll forward, roll back.

Breaking changes: ship them in rollback‑friendly phases

People love asking: “How do we release breaking server changes with zero downtime?” The desktop equivalent is: “How do we change protocols, storage formats, APIs, without bricking old clients?”

The answer is the same: you don’t do one big jump; you do several compatible steps:

• Phase 1 – Expand: add new fields / endpoints / paths, but keep old behavior working. The server understands both old and new formats.

• Phase 2 – Dual‑write / dual‑read: clients can talk via both old and new paths. You can roll back either side because both still work.

• Phase 3 – Migrate: move data/users gradually, monitor.

• Phase 4 – Contract: only after you are absolutely sure, remove old code paths.

This “expand and contract” pattern makes every step reversible. If something goes wrong in phase 3, you can still fall back to the old behavior because you haven’t yet burned the bridge.

For desktop specifically:

• Don’t couple “new binary” + “irreversible data migration” in one shot.

• Let the app upgrade data in a way that’s reversible or at least survivable by the previous version (e.g., additive schema changes, versioned formats).

• Only remove legacy paths once you’ve lived with the new path in production for a while.

A practical checklist for your desktop release pipeline

If you’re a tech lead or CTO designing this from scratch, this is the minimum you want:

• You never ship to 100% of users first. Always rings/waves.

• Your updater:

  • Keeps at least one previous stable version locally.

  • Can downgrade itself without manual steps.

  • Does health checks after update and auto‑revert if needed.

• Your backend:

  • Knows which machine is on which version and ring.

  • Can remotely disable specific versions or features.

  • Has dashboards per version with error/crash metrics.

• Your process:

  • Treats “rollback” as a first‑class step in every release runbook.

  • Rehearses rollback in staging, not just forward deploys.

  • Defines clear thresholds: when do we stop rollout, when do we roll back?

Because in the end, we’re just engineers. We don’t control the OS, the drivers, the networks, or everything our users install. We don’t see every edge case. And with every bit of complexity we add, the space of “weird things that can go wrong” explodes.

What we do control is our ability to make safe mistakes: deploy small, observe quickly, and roll back instantly and automatically when reality doesn’t match our expectations.

• Scan emails for invoices and save them to the correct Google Drive folder (by year, month, and vendor)

• Generate client invoices from developer timesheets and email them automatically

• Remind developers to submit timesheets on time

• Handle edge cases and conditions around all of the above

This is the kind of “small” back‑office work that quietly eats evenings

The No‑Code Promise (And Where It Broke)

If you scroll LinkedIn long enough, the conclusion is always the same:
“Use a no‑code platform. You don’t need technical people anymore. Old‑school CTOs bring no value.”

Founders proudly share how they built full products on tools like N8N in a week or two, without a single developer. So I followed the hype and started with a no‑code automation platform.

Almost immediately, I hit three walls.

First, I had to learn the platform’s entire mini‑universe: concepts, terminology, UI, how they think about flows, triggers, and blocks. Instead of focusing on my domain (emails, invoices, vendors, months, timesheets), I had to first understand their domain.

Second, the platform wrapped Gmail, Drive, and everything else behind its own abstractions. I know roughly how Google’s APIs are structured, but inside the tool the mapping wasn’t intuitive. The real power of the APIs was there, but half‑hidden and renamed.

Third, debugging was painful. To test whether a tiny part of the logic worked, I had to run the whole flow manually and step through it. As a CTO I’ve spent years teaching teams to move from “click‑debugging” to proper testing. Here I was, back to clicking, waiting, and hoping.

Fourth, ai chat inside or around the platform didn’t save me either. The UI changes fast, documentation is incomplete, and anything slightly non‑standard (“detect invoice, route to vendor folder, use timesheets to generate invoices”) often falls between the cracks.

After 1–2 weeks, the automation mostly worked. But it took way more effort than it should have. I even started considering hiring a no‑code specialist to handle it for me — which is a funny twist on “you don’t need technical people anymore.”

Switching To Vibe Coding With AI

At that point I asked a different question:

What if I stop fighting the no‑code tool and instead use AI to help me write small, focused pieces of real code? So I moved the whole thing to Google Apps Script, but with AI as my pair‑programmer.

I described what I needed in natural language:
how to scan emails, detect invoices, route them into folders by year/month/vendor, process timesheets, generate invoices, send them out, and ping developers for reminders.

AI helped me draft the scripts, structure the modules, and wire them into Gmail and Drive. I then iterated: added tests, refined the logic, and used the real API docs whenever something subtle was needed.

In about two days, I had:

• Scripts that inspect emails and attachments for invoices.

• Logic that saves files into year/month/vendor folders automatically.

• Workflows to process developers’ timesheets, generate invoices, and email them to clients.

• Reminders to developers to fill or verify their timesheets.

• Tests around the critical paths, so changes don’t break everything.

No visual flows, no hidden abstractions — just code I understand and own.

Why AI Coding Won

For me, vibe coding with AI beat no‑code on three key axes.

Control: I can open any script, see exactly what’s happening, and change it. If the workflow grows, I’m not stuck waiting for a vendor to add just‑one‑more‑block.

Testing: I can write small tests around essential behavior instead of manually replaying whole flows, again and again, for every small change.

Reality: I work directly with real APIs and documentation. AI helps me bridge the gaps, but the underlying model is transparent and durable.

The Industry Shift (And Where I’m Betting)

To be fair, no‑code platforms are also moving toward AI. Some now let you describe a flow in natural language and they generate it for you. That’s a healthy direction and I might test it again in the future.

But the larger shift, which I wrote about in more detail in:
“SaaS Without AI Integration Will Die — Here’s Why” on Maks Notes, is this:

The core skill isn’t “dragging blocks” or even “writing code by hand.”
It’s being able to express intent clearly and let AI translate that into something executable — ideally on a platform you truly control.

For my business, that currently means AI‑assisted coding beats no‑code.

If You’re On The AI Coding Path

If you’re already leaning into AI coding, you can push it even further.

At Clear Solutions, we’re building tools exactly for that:

• AI Commit by Mavka helps you write clean, professional commit messages without wasting brainpower on wording.[link]

• AI Test by Mavka helps you automate test creation, so you don’t slide back into manual debugging when your scripts grow.[link]

If you’re interested in trying them, contact me — I’m happy to share a free license so you can feel what happens when AI is paired with real code, proper testing, and full control, not just another visual layer on top.

For years, this worked. But something changed.

The Productivity Crisis I Didn’t See Coming

A few months ago, I needed to create mockups for a new site. I had a similar design from before—shouldn’t take long, right?

I was wrong.

Using traditional wireframe tools, I spent hours just trying to recall how to use the interface. Creating buttons, adjusting spacing, organizing layers. After a full day of work, I had maybe 20% of what I needed. My estimate? A full week to finish.

That’s not productivity. I just wasted my time for nothing.

I realized the problem wasn’t the tool’s simplicity—it was that the tool required me to be both a tool specialist AND a person with an idea. I had to learn its UI tools before I could express my ideas.

The AI Integration Breakthrough

Then I discovered Frame0.

Frame0 is the same app, with the same functionality. UI/UX is pretty similar. Instead of forcing me to learn their interface, they built an API and AI integration that understood my intent. I could describe what I wanted in natural language, and the AI would translate that into actions within the tool.

Fifteen minutes. That’s all it took.

I went from frustrated to focused. From “how do I create this button?” to “what should this design actually communicate?”

My productivity increased 5x.

But here’s what really mattered: I had energy left for the details. For the design thinking. For the strategy. The tool stopped being an obstacle and became an extension of my thinking.

Small demo, just to illustrate how it was:

The Human-AI Collaboration Model

This isn’t about replacing humans with AI. It’s about amplifying human capability.

When Frame0 added AI integration, they didn’t remove the design interface. They added a layer that lets humans focus on strategy while AI handles execution. The result? Better designs, faster delivery, happier users.

This is the model that wins in 2025:

• Humans provide intent, strategy, and judgment

• AI handles execution, optimization, and pattern recognition

• The tool becomes invisible—just a means to an end
  

Users Don’t Want to Learn Your Interface—They Want Results

Your users are developers, product managers, engineers. They’re busy. They don’t want to spend time mastering your tool’s quirks. They want to accomplish their goal through your tool, not despite it.

When you add AI integration—especially through APIs and MCP servers—you let users interact with your product in their language, not yours. They describe what they need. The AI handles the translation.

This is the difference between a tool and a friction point.

The Tools That Get It Right

At Clear Solutions, we’ve been building AI-enhanced products that understand this shift:

AI Commit by Mavka — Automates commit message generation and code organization. Developers spend less time on documentation, more time on logic.

AI Tests by Mavka — Generates unit test cases and tests automatically. Development teams move faster. Coverage improves. Bugs decrease.

AI Code Review by Mavka — Provides intelligent code review feedback in real-time. Engineers focus on architecture decisions, not style guides.

These aren’t tools that force you to learn a new interface. They’re tools that integrate into your existing workflow and make you more productive.

Want to see the difference? Try them. If you’re interested in a demo, reach out to me directly via LinkedIn. We’ll show you what 5x productivity looks like.

Today, platforms powered by AI make it possible for engineers to share their experiences and insights at a professional level—just like professional bloggers and journalists. Our stories and ideas can now reach a much wider audience, and we’re able to join the bigger conversation about where technology is headed.

Here’s my own example: I recently wrote my first post for the AI Commit tool, powered by Mavka. I tried to answer the big question—will AI replace developers? Writing that post felt like a turning point. Suddenly, I wasn’t just a silent contributor. I was part of a public dialogue, sharing my perspective and connecting with other professionals.

AI Commit doesn’t just automate tasks. It empowers developers to write more clearly and consistently commit messages.

Right now, AI is bringing me a voice. It’s giving all of us—engineers, coders, architects—the chance to express ourselves, to share our expertise, and to shape the future of our industry. Whether you’re writing about the impact of AI on software development or sharing best practices for using new tools, AI is making it easier than ever to be heard. And that, in my view, is one of the most exciting changes happening in tech today.