DEV Community: Khaja Hussain

Playwright Test Agents: Can AI Really Write and Fix Your Tests?

Khaja Hussain — Fri, 23 Oct 2026 19:52:21 +0000

A few years ago, automating a login page was fairly straightforward.

You would open the application, inspect the HTML elements, write a Playwright or Selenium script, and run it.

Everything worked fine until someone changed the UI.

Maybe the login button was renamed. Maybe a form field moved. Or perhaps a developer replaced an ordinary HTML input with a custom Angular component.

Suddenly, a test that had been working for months started failing.

The application itself might be perfectly fine. But the automation script no longer knows how to interact with it.

If you've worked with UI automation, you've probably come across situations like this.

Now imagine having an assistant that can explore your application, suggest what should be tested, write the test scripts, and help investigate failures.

That's the idea behind Playwright Test Agents.

Let's understand how they work, using a simple example.

First, what is Playwright?

Before getting into AI agents, let's understand Playwright itself.

Playwright is an open-source browser automation framework developed by Microsoft.

It allows developers and QA engineers to automatically test web applications.

For example, instead of manually opening a website and checking whether login works, you can write a test that:

Opens the login page.
Enters an email address.
Enters a password.
Clicks the Sign In button.
Checks whether the application displays the expected result.

The browser performs these actions automatically.

Playwright supports Chromium, Firefox, and WebKit, so the same test can be executed across different browser engines.

But there's one challenge.

Someone still needs to decide what to test, write the automation scripts, and maintain them when the application changes.

This is where AI agents become interesting.

What are Playwright Test Agents?

Playwright introduced Test Agents in version 1.56.

Instead of relying entirely on manually written test scripts, these agents help with different stages of the testing process.

There are three main agents:

1. Planner — Decides what to test

The Planner explores your application and prepares a test plan.

2. Generator — Writes the tests

The Generator takes that plan and creates Playwright test scripts.

3. Healer — Helps fix failing tests

The Healer runs tests, investigates failures, and attempts to repair issues in the automation code.

Think of them as three members of a QA team.

One prepares the scenarios, another writes the automation, and the third investigates why something failed.

Of course, they're AI agents, not actual team members. Their output still needs to be reviewed.

Let's take a real-world example

Imagine we're building a customer portal using Angular for the frontend and ASP.NET Core for the backend.

The application has a signup page with four fields:

Full Name
Email
Password
Confirm Password

There's also a Create Account button.

As a developer, you might test it once with valid information, see that the account was created successfully, and move on.

But what else could go wrong?

What happens if someone enters an invalid email address?

What if the password and confirmation password don't match?

What if the user tries to register with an email address that already exists?

What if someone clicks Create Account without entering anything?

These are basic scenarios, but it's surprisingly easy to miss one when you're focused on delivering a feature.

Let's see how the agents could help.

Step 1: Planner — Let AI prepare the test scenarios

We start by giving the Planner a simple instruction.

For example:

Explore the signup page of my application and create a test plan. Include successful registration, invalid email addresses, empty fields, password mismatch, and duplicate email registration.

The Planner can inspect the application and prepare a Markdown file containing the proposed scenarios.

An example plan might look like this:

Scenario	Expected result
Valid signup details	Account is created
Empty email address	Required-field validation appears
Invalid email format	Email validation error appears
Password mismatch	Password mismatch message appears
Duplicate email	Appropriate error message appears

The actual plan will depend on the application's behaviour and requirements.

Notice something important here.

We didn't start by writing TypeScript code.

We started by explaining what the application should do.

This is useful for beginners because it encourages thinking about test scenarios before automation scripts.

However, the Planner cannot automatically know every business rule. For example, it may not know whether your application requires a minimum password length of 8 or 12 characters unless that information is available.

So review the plan before generating tests.

Step 2: Generator — Turn the plan into Playwright tests

Once the test plan is ready, the Generator can use it to create executable test scripts.

For example, consider this scenario:

A user should not be able to register with an invalid email address.

A Playwright test for that scenario might look like this:

import { test, expect } from '@playwright/test';

test('Invalid email should show an error', async ({ page }) => {

  await page.goto('http://localhost:4200/signup');

  await page.getByLabel('Full Name').fill('John');

  await page.getByLabel('Email').fill('invalid-email');

  await page.getByLabel('Password').fill('Password@123');

  await page.getByLabel('Confirm Password').fill('Password@123');

  await page.getByRole('button', { name: 'Create Account' }).click();

  await expect(
    page.getByText('Please enter a valid email')
  ).toBeVisible();

});

This is an illustrative test. The field labels, page URL, and validation message would need to match your actual application.

If you're new to Playwright, here's what the important lines do.

page.goto() opens a webpage.

getByLabel() finds an input field using its visible label.

fill() enters a value into that field.

getByRole() locates the button.

click() simulates a user clicking it.

expect() checks whether the expected result appears.

In this example, we're checking that the application displays an email validation message.

Without AI, we could write this script manually.

With the Generator, we can ask an agent to create similar scripts based on our test plan.

That doesn't mean we should accept every generated test without checking it. An AI agent could write an assertion that doesn't reflect the intended business behaviour.

Step 3: Healer — What happens when a test breaks?

Now let's imagine something changes in our Angular application.

Originally, our signup button was called:

Create Account

A few weeks later, the design team changes the text to:

Sign Up

The application continues to work for normal users.

But our automated test still searches for a button called Create Account.

await page.getByRole('button', { name: 'Create Account' }).click();

Because the button name has changed, the test may fail.

This is where the Healer becomes useful.

The Healer can execute the failing test, inspect the page, and attempt to identify what changed.

If it determines that the Sign Up button is the correct replacement, it may suggest updating the locator to:

await page.getByRole('button', { name: 'Sign Up' }).click();

It can then rerun the test to check whether the change resolves the failure.

That's a relatively simple example, but it shows why test maintenance is such an important part of automation.

There's an important catch, though.

Suppose registration itself has stopped working because the ASP.NET Core API is returning an HTTP 500 error.

That's a genuine application defect.

We don't want an AI agent to simply remove the failing assertion so that the test passes.

A passing test is only valuable when it's checking the correct behaviour.

The Healer may also skip a test if it believes the functionality is broken, so those outcomes need human review.

How can you try Playwright Test Agents?

If you're a developer working with Angular, React, or ASP.NET Core, you can experiment with these agents using a local web application.

You'll need Node.js, a supported AI coding assistant, and a Playwright project.

First, initialize Playwright if it isn't already installed:

npm init playwright@latest

Follow the installation prompts to configure your test project and install the required browsers.

Next, initialize the Playwright Test Agents.

For VS Code:

npx playwright init-agents --loop=vscode

For Claude Code:

npx playwright init-agents --loop=claude

For Codex:

npx playwright init-agents --loop=codex

These commands add agent definitions to your project. You'll still need a supported AI coding environment to use them.

Now run your web application locally.

For example, an Angular development server commonly runs at:

http://localhost:4200

Open your supported AI agent interface and ask the Planner to create test scenarios for your signup page.

Then use the Generator to create tests from the plan.

To execute the tests, run:

npx playwright test

If something fails, the Healer can help investigate.

A useful detail from the official documentation is that the Planner can use a seed test to understand the application's setup, dependencies, and authentication requirements.

This becomes important when testing applications that require login or special test data.

For the complete setup and agent workflow, see the official Playwright Test Agents documentation.

Does this mean we no longer need QA engineers?

I don't think so.

AI can help reduce repetitive work, but software testing involves much more than clicking buttons and checking messages.

Consider a payment application.

An AI agent might verify that clicking Pay Now displays a success message.

But what if the customer was charged twice?

What if the payment succeeded but the database transaction failed?

What if the request was retried after a network timeout?

These are the kinds of situations where domain knowledge and engineering experience matter.

AI may help generate scenarios, but someone still needs to understand the system, identify risks, validate assumptions, and decide whether the results are meaningful.

For me, the interesting part isn't that AI can write a few lines of Playwright code.

It's that AI agents can help with the broader testing workflow, from planning to maintenance.

That's a more meaningful improvement than simply generating scripts.

A few things I'd keep in mind

If you're planning to introduce AI agents into an existing project, I'd start small.

Choose one feature, perhaps login or signup, and see how the agents behave.

Review the generated scenarios before running them.

Run tests against a development or dedicated test environment, not production.

Make sure you control the test data. Registration tests can easily create dozens of unwanted accounts if you're not careful.

And most importantly, never assume that a green test result automatically means the feature is working correctly.

Final thoughts

Playwright Test Agents are an interesting step forward for browser automation.

The Planner helps organize what needs testing. The Generator turns those scenarios into code. The Healer helps investigate and repair failing tests.

For beginners, they can make test automation more approachable.

For experienced developers and QA engineers, they offer another way to reduce repetitive work and spend more time understanding application behaviour.

But the fundamentals haven't changed.

A good automated test should verify something meaningful, be repeatable, and fail when the application behaves incorrectly.

AI can help us build those tests. It shouldn't replace our understanding of what we're testing.

One small practical tip: If you're testing a signup flow that requires email verification, you don't always need to use your personal email address. For manual testing, you can use any online temporary email generator such as Temp email to create a disposable inbox and check whether registration or verification emails arrive correctly. For repeatable automated tests, a controlled test inbox or email-testing service is usually a better choice.

.NET Native AOT vs Traditional ASP.NET Core: What Developers Should Know

Khaja Hussain — Wed, 21 Oct 2026 20:41:02 +0000

Khaja Hussain

Oct 21

.NET Native AOT vs Traditional ASP.NET Core: What Developers Should Know

#backend #csharp #dotnet #performance

7 min read

.NET Native AOT vs Traditional ASP.NET Core: What Developers Should Know

Khaja Hussain — Wed, 21 Oct 2026 19:44:04 +0000

Recently, I was checking the memory usage of a server running several ASP.NET Core applications.

Nothing had crashed. The applications were running fine. But memory utilization was higher than I would have liked, and it got me thinking about whether I could make better use of the server's resources.

I've been working with C# and ASP.NET for years, mostly building APIs, database-driven applications, and Angular frontends. My usual stack is ASP.NET Core, SQL Server, and Entity Framework Core.

So naturally, I started looking at .NET Native AOT.

I'd heard about the smaller executables, faster startup times, and lower memory requirements. All of that sounded promising.

But I had a more practical question:

Could I take an existing ASP.NET Core application, enable Native AOT, and get the same functionality while using fewer resources?

The more I looked into it, the more I realized that the answer depends heavily on how the application is built.

First, what actually changes with Native AOT?

In a traditional ASP.NET Core application, our C# code is compiled into Intermediate Language (IL).

When the application runs, the .NET runtime uses Just-in-Time (JIT) compilation to turn that IL into native machine code as needed.

Native AOT changes when that compilation happens.

Instead of waiting until runtime, the application is compiled into native machine code during publishing.

That means the deployed application doesn't need a JIT compiler to execute its code.

It can also run without a separately installed .NET runtime because the necessary runtime components are included in the published application.

For certain workloads, especially small services that start frequently, this can make a noticeable difference.

But there's something worth understanding here.

Native AOT doesn't remove garbage collection from .NET.

We're still writing managed C#. Objects still get allocated, and the garbage collector still manages memory.

So if an application is holding a large collection in memory, caching too much data, or loading unnecessary records from SQL Server, Native AOT isn't going to magically fix that.

This was an important distinction for me because memory usage was what got me interested in AOT in the first place.

Where Native AOT starts getting complicated

Creating a new Minimal API with Native AOT support is fairly straightforward.

The interesting part is what happens when we try to apply the same approach to an existing business application.

Consider a typical ASP.NET Core project.

It probably has controllers, services, dependency injection, Entity Framework Core, authentication, logging, and a few third-party packages.

For a traditional ASP.NET Core application, that's a completely normal setup.

For Native AOT, some of those choices become important.

1. What about my existing controllers?

This was the first major limitation that caught my attention.

As of .NET 10, ASP.NET Core MVC controllers aren't supported by Native AOT.

Minimal APIs are supported, although there are still compatibility limitations.

If your application has dozens of controllers, you can't simply add PublishAot to the project file and expect everything to work.

You may have to restructure parts of the application.

That isn't necessarily a bad thing for a new microservice, but it's a different conversation when you're maintaining an existing enterprise application.

2. Entity Framework Core is another consideration

I use Entity Framework Core extensively, especially with SQL Server.

It's convenient for filtering, pagination, relationships, and working with database entities.

However, Native AOT support in EF Core is still experimental according to Microsoft's documentation.

One of the challenges is query generation.

In a traditional EF Core application, queries can be built dynamically at runtime.

For example:

var query = dbContext.Products.AsQueryable();

if (!string.IsNullOrEmpty(search))
{
    query = query.Where(x => x.Name.Contains(search));
}

if (categoryId.HasValue)
{
    query = query.Where(x => x.CategoryId == categoryId.Value);
}

var products = await query
    .OrderBy(x => x.Id)
    .Skip(pageIndex * pageSize)
    .Take(pageSize)
    .ToListAsync();

This is a common pattern in business applications.

Filtering and pagination requirements change constantly, and developers need the flexibility to construct queries based on user input.

EF Core's experimental Native AOT support uses query precompilation, which has limitations with dynamically composed queries like this.

You can sometimes rewrite queries into shapes that can be precompiled, but that adds design constraints.

For a small API with a handful of predictable queries, that might be manageable.

For a large application with complicated search screens and reporting requirements, it's worth thinking carefully before committing to that approach.

Trying Native AOT with a small API

If you're curious about Native AOT, I wouldn't recommend starting by converting a large existing application.

I'd start with a small API.

With the .NET 10 SDK installed, you can create a project using Microsoft's AOT template:

dotnet new webapiaot -n AotDemo
cd AotDemo

The template is already configured for Native AOT and uses Minimal APIs.

One difference you'll notice is the way JSON serialization is configured.

Let's say we have a simple endpoint returning orders.

using System.Text.Json.Serialization;

var builder = WebApplication.CreateSlimBuilder(args);

builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.TypeInfoResolverChain.Insert(
        0, AppJsonSerializerContext.Default);
});

var app = builder.Build();

app.MapGet("/orders", () => new[]
{
    new OrderDto(101, "Paid", 49.99m),
    new OrderDto(102, "Pending", 19.50m)
});

app.Run();

public record OrderDto(int Id, string Status, decimal Total);

[JsonSerializable(typeof(OrderDto[]))]
internal partial class AppJsonSerializerContext : JsonSerializerContext
{
}

Notice the JsonSerializable attribute.

In a regular ASP.NET Core application, JSON serialization often relies on runtime reflection to discover the properties of objects.

Native AOT works better when that information is generated during compilation.

That's why System.Text.Json source generation is important.

The API response itself is ordinary JSON:

[
  {
    "id": 101,
    "status": "Paid",
    "total": 49.99
  },
  {
    "id": 102,
    "status": "Pending",
    "total": 19.50
  }
]

While experimenting with different API implementations, I would also compare their actual responses.

It's easy to focus on startup time or memory usage and overlook whether a change to serialization has affected the response structure.

For larger sample responses, especially arrays containing nested objects, a table view can help. Tools like JSON Parser make it easier to inspect JSON responses and understand their structure in a more readable format.

Of course, I would only use sample or non-sensitive data with an online tool. For actual validation, automated tests should compare the expected response structure and values.

Once the application is ready, you can publish it with Native AOT.

For example, on a properly configured Windows development machine:

dotnet publish -c Release -r win-x64

Native AOT publishing requires platform-specific build tools, including the appropriate C++ compiler toolchain.

Also, remember that running the project with dotnet run doesn't test the final Native AOT executable. The real test is the published binary.

Would Native AOT make every API faster?

Not necessarily.

This is where I think developers need to separate startup performance from request-processing performance.

Native AOT can significantly improve startup time and reduce application footprint.

But that doesn't automatically mean an API processing thousands of requests will have better throughput.

Suppose an endpoint spends most of its time executing a SQL Server query.

If that query takes 300 milliseconds, switching from JIT to AOT won't suddenly make the database return results in 30 milliseconds.

Database indexes, query execution plans, network latency, caching, and application logic still matter.

Also, the traditional .NET JIT compiler is highly optimized. Once an application has warmed up, it can deliver excellent performance.

So I wouldn't make a migration decision based only on a comparison of two empty API templates.

I'd want to see how my actual application behaves.

How I would compare the two approaches

Before considering Native AOT for production, I'd build a small service that represents part of my existing workload.

Ideally, I'd publish the same functionality with both JIT and Native AOT, using comparable deployment configurations.

I'd measure:

Startup time: How quickly can the application begin serving requests?
Memory usage: What is the process memory consumption when idle and under a representative workload?
API latency: How do average and p95/p99 response times compare?
Throughput: How many requests can each version handle before latency starts increasing?
Deployment size: How much space does each published application require?
Compatibility: Did I have to rewrite code or replace any libraries?

I'd also run the tests multiple times on the same hardware and check the published AOT application's behavior, not just its build output.

If the API works with both approaches and AOT gives me a measurable benefit, great.

But if I have to spend days rewriting controllers or working around library limitations to save a small amount of memory, I would question whether the trade-off makes sense.

Where I think Native AOT fits best

For me, Native AOT is particularly interesting for small, focused services.

A background worker, a lightweight API, or a service that needs to start quickly could be a good candidate.

An application with hundreds of controllers, extensive EF Core usage, and several reflection-heavy libraries is a different story.

In that situation, I'd first look at the existing application's memory allocations, database queries, caching strategy, and hosting configuration.

Sometimes the most effective optimization isn't changing the compilation model. It's fixing an inefficient query or reducing the amount of data the application keeps in memory.

Final thoughts

I started looking into Native AOT because I wanted to understand whether it could help reduce the resources consumed by my ASP.NET Core applications.

I haven't migrated those applications to Native AOT, and I don't have production benchmarks to share yet.

What I've learned so far is that Native AOT is worth exploring, but it shouldn't be treated as an automatic upgrade for every existing .NET application.

If I were starting a small, independent API today, I would seriously consider testing Native AOT from the beginning.

For an established ASP.NET Core application built around controllers and Entity Framework Core, I would be more cautious.

The deciding factor shouldn't be which approach looks faster in a benchmark screenshot.

It should be whether the performance improvement justifies the architectural and maintenance cost.

I'm curious how other .NET developers are approaching this. Have you used Native AOT in production, or are you still sticking with traditional ASP.NET Core for your APIs?

References

What Switching From C# to Rust Actually Taught Me

Khaja Hussain — Sat, 11 Jul 2026 09:01:28 +0000

I've spent most of my career writing C#. ASP.NET Core, EF Core, the whole ecosystem — it's productive, well-documented, and I've never had a real complaint about it. This isn't a "C# vs Rust, one wins" post. C# remains one of my favorite languages to build with. This is just about why I got curious about Rust, and what I noticed when I actually rewrote something instead of just reading takes about it.

Why I got curious in the first place

Three things kept pulling my attention:

No GC pauses. C#'s garbage collector is well-engineered, but it still pauses your program at moments it chooses, not you. For latency-sensitive work, that unpredictability is worth understanding better.
Compile-time memory safety. Rust catches null references and data races at compile time instead of at runtime. A different tradeoff, not a "fix" for something broken in C#.
Ownership. People kept describing it as a big deal. I wanted to actually understand why instead of nodding along.

The first two weeks were genuinely hard — I fought the borrow checker constantly, rewriting the same function three times before it compiled. It clicked faster than I expected though, and it left me with a better mental model for shared state in general, one that's helped me even back in C#. I ended up collecting everything I wish someone had told me going in over at Rust Tutorial — more on that at the end, if ownership is the part that's holding you back.

The project: a real-time order tracker

To compare the two properly, I built a small dummy project — a real-time order tracking service. Incoming order events update in-memory state, and connected dashboards get live updates over a WebSocket. It's a common shape: inventory systems, delivery tracking, live ops dashboards.

C# version: ASP.NET Core minimal API, SignalR for the WebSocket push, a ConcurrentDictionary for state.
Rust version: axum for HTTP/WebSockets, tokio as the runtime, state behind an Arc<Mutex<HashMap>>.

Both versions expose API endpoints that return JSON responses. To test them, you can send a few sample requests and use an online JSON parser to inspect the responses, especially when dealing with nested order data. This also makes it easier to verify that both implementations return the same structure.

Nothing production-grade — just enough of a real workload to notice actual differences instead of comparing "Hello World" benchmarks, which don't tell you much.

What felt different, not better or worse

The frameworks themselves were both pleasant to use. What changed was how explicit I had to be:

Shared state. C#'s ConcurrentDictionary just worked — I trusted the library and moved on. Rust made me spell out the Arc<Mutex<...>> at every point it was touched. More typing, but I came away understanding my own concurrency model better.
Errors. A malformed event in the C# version could throw from a background task and, if I'd missed a try/catch, fail quietly. Rust's Result made every fallible step something I had to explicitly acknowledge.
Nulls. "Order not found yet" was a null check I could forget in C#. In Rust it's Option, and the compiler won't let it slide.

None of this means Rust is "better" — it just made assumptions in my C# code more visible, which was uncomfortable at first and useful by the end.

Quick, informal numbers (not a real benchmark)

Full transparency: this was a five-minute wrk run on my own laptop, not a controlled test environment. Don't read too much into the exact figures — but the general pattern lined up with what's commonly reported elsewhere too.

	C# (ASP.NET Core)	Rust (axum)
Idle memory footprint	~110 MB	~9 MB
Cold start time	~1.2s	~40ms
Requests/sec (simple load test)	~9,000	~34,000
p99 latency	~42ms	~6ms
Deploy artifact	App + .NET runtime	Single ~6MB binary

The gap narrowed once .NET's JIT fully warmed up under sustained load — it's genuinely competitive once hot. Rust's edge was most consistent in memory footprint and tail latency, which tracks: no GC means no surprise pause landing in your worst-case requests.

Where Rust felt rougher

To keep this balanced:

Compile times grew noticeably slower than C#'s as the project did.
Ecosystem gaps — some things .NET gives you out of the box (certain auth patterns, mature ORMs) took more assembly in Rust's crates.
The learning curve is real. Not the right moment to introduce it if your team is shipping next week.

When I'd reach for which

Situation	I'd reach for
Typical CRUD app / internal business tool	C# — EF Core and the .NET ecosystem get you there faster
Team is already deep in .NET, tight deadline	C# — the right call, no reason to add a learning curve under pressure
Real-time systems where latency predictability matters	Rust — no GC pause means a flatter tail latency
Memory-constrained environments (containers, edge, embedded)	Rust — the footprint difference is real and adds up at scale
Need a small, dependency-free deployable binary	Rust — one binary, nothing else to ship
Rich enterprise integrations (auth providers, ORMs, admin tooling)	C# — still the deeper batteries-included ecosystem
Want to learn something that reshapes how you think about memory and concurrency	Rust — worth the rough two weeks even if you never ship it

So, am I dropping C#?

Not even close. For CRUD apps and business logic, C# is still one of the most productive languages I know, and that hasn't changed. What changed is that I now have another tool for the specific cases where predictable latency and a small footprint actually matter — and Rust earned that spot honestly.

If you're curious about Rust coming from C

If you want the official deep reference, The Rust Book is where most of the Rust community points beginners first. Alongside that, I also put together a helpful website while working through ownership and borrowing myself — plain explanations, runnable examples, nothing assumed: Rust Tutorial.

If you're a C#/.NET dev thinking about giving Rust a try, either one is a solid place to start.

Have you made a similar jump — from C#, Java, Go, or anywhere else? Curious what surprised you.

I Compared TOON vs Minified JSON Using OpenAI’s Tokenizer

Khaja Hussain — Tue, 12 May 2026 00:29:29 +0000

Recently I noticed a lot of developers talking about TOON:

TOON GitHub repository

The idea behind TOON is interesting. Instead of sending traditional JSON, TOON tries to reduce token usage and make data more compact for LLMs.

Since token costs are becoming a real concern for AI products, I wanted to test it myself.

Not theoretically.
Not with benchmarks from slides.
Just a simple real-world comparison.

I used OpenAI’s tokenizer tool and compared:

TOON format
Minified JSON

For the conversion process, I used:

JSON to TOON Converter
JSON Parser
JSON formatter
Compare Text

Minified JSON:

{"user":{"id":1001,"name":"Khaja","email":"khaja@example.com","roles":["admin","developer"],"settings":{"theme":"dark","notifications":true}}}

TOON version:

user:
id: 1001
name: Khaja
email: khaja@example.com
roles[2]: admin,developer
settings:
theme: dark
notifications: true
`

TOON Result: Tokens: 37
Minified JSON Result: Tokens: 38

That means TOON saved only 1 token in this example.

Honestly, that surprised me.

So… Is TOON Useful?

I think the answer is: yes, but with nuance.

TOON is not “bad.”
In fact, I actually like the direction.

It makes developers think seriously about:

token efficiency
AI-friendly data formats
prompt optimization
serialization overhead

Those are important conversations.

But after testing it, I’m not convinced that TOON alone will dramatically reduce costs for most companies.

In many cases:

removing whitespace already gives huge savings
gzip/brotli compression already works extremely well
AI models are already heavily trained on JSON structures

So the practical gains may be smaller than the hype suggests.

But Small Savings Can Still Matter at Scale

Here’s the interesting part.

Even tiny optimizations matter when companies process millions of requests.

Imagine:

10 million API calls
large AI prompts
multiple agents
long conversation histories

Saving even 1–2% tokens at scale could potentially save hundreds or thousands of dollars over time.

So I do understand why people are excited about TOON.

The Bigger Challenge: Ecosystem

Personally, I think TOON’s biggest challenge is not token count.

It’s ecosystem adoption.

JSON already has:

mature tooling
validators
parsers
database support
IDE integrations
API ecosystem dominance

Replacing that is extremely difficult.

In real production systems, compatibility usually matters more than tiny syntax improvements.

My Take

After testing both formats, my conclusion is:

TOON introduces interesting ideas
token savings appear modest in smaller examples
the ecosystem challenge is massive
but the conversation around AI-native serialization formats is valuable

I don’t think JSON is disappearing anytime soon.

But I do think experiments like TOON push the industry forward.

And honestly, that’s a good thing.

Would love to hear what other developers think or any suggestion what to compare next.

A free, high-performance backend for small projects — Cloudflare Workers in 10 minutes

Khaja Hussain — Sun, 03 May 2026 11:00:22 +0000

Every developer wants the same thing: a free way to run small backend tasks. A webhook for a side project. A contact form handler. An OG image generator. A small proxy to hide an API key. Things that handle a few hundred requests a week. They do not need a $20/month server, an Azure Function App you will forget about next month, or a new Lambda that takes an hour to set up.

I have had this problem for years. Most of my work is in .NET shops — AWS for production, Azure for clients on the Microsoft stack. Both are great for real workloads. Both feel like overkill when the actual task is "send me an email when a Stripe customer pays."

Last weekend I needed exactly that webhook. Spinning up a new Function App for one endpoint felt silly. Adding it to an existing production API would mix two unrelated things — the next person reading the code would wonder why a billing handler was sitting inside the customer-facing app. Every option I knew was way too much setup for one tiny task.

So I finally tried something I had been avoiding for three years: Cloudflare Workers. It solved the problem in ten minutes. Free, no credit card, deployed to 300+ data centres. Here is how it went, and why I should have tried it sooner.

Why I had been ignoring Cloudflare Workers

Three reasons:

No .NET story. I work in C#. Writing JavaScript at the edge felt like a whole new world just to deploy one small function.
The marketing made it look like big-company infra. Every Workers post I had read mentioned Durable Objects, R2, KV, Queues, AI bindings. It looked like a big platform you commit to, not a tool you grab for one task.
I thought the free tier was a trick. "100,000 requests per day" sounded like a number with hidden conditions and a credit-card requirement.

None of those were true.

The 10 minutes

Install Wrangler, the Cloudflare CLI:

npm install -g wrangler
wrangler login

The login opens a browser. Click approve and you are done. No credit card asked. I checked twice — I have been burned before.

Scaffold a project:

npm create cloudflare@latest stripe-webhook
cd stripe-webhook

Pick "Hello World" Worker, JavaScript, skip the deploy step. The generator puts everything in one folder. Open src/index.js and replace the default code with this:

export default {
  async fetch(request, env) {
    if (request.method !== 'POST') {
      return new Response('POST only', { status: 405 });
    }

    let event;
    try {
      event = await request.json();
    } catch {
      return new Response('Invalid JSON', { status: 400 });
    }

    if (event.type === 'checkout.session.completed') {
      const amount = event.data.object.amount_total / 100;
      const email = event.data.object.customer_email;

      await fetch('https://api.resend.com/emails', {
        method: 'POST',
        headers: {
          'Authorization': `Bearer ${env.RESEND_KEY}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          from: 'alerts@mydomain.com',
          to: 'me@mydomain.com',
          subject: `New payment: $${amount}`,
          text: `${email} just paid $${amount}.`,
        }),
      });
    }

    return new Response('ok', { status: 200 });
  },
};

Run it locally:

npm run dev
# Ready on http://localhost:8787

Send a fake Stripe payload with curl. Worked on the first try.

Deploy it:

npx wrangler deploy

Eight seconds later it printed a *.workers.dev URL. Total bundle size: 1.2 KB. I pointed Stripe's webhook config at that URL, sent a test event from the Stripe dashboard, and the email arrived in my inbox before the dashboard finished refreshing.

The part that surprised me

The free tier really is 100,000 requests a day. No credit card. The Worker runs in 300+ Cloudflare data centres at the same time. A Stripe webhook from San Francisco hits the San Jose data centre, my email goes out from Resend's nearest server, and the whole round trip takes under 200ms. No cold start. No Function App I have to remember to delete next month before it starts billing me.

If you store a webhook secret with wrangler secret put STRIPE_WEBHOOK_SECRET and verify the signature (you should — Stripe sends a Stripe-Signature header for this), the whole thing is still about 60 lines of code.

One gotcha worth knowing

If the request body is invalid JSON, request.json() throws a SyntaxError and Cloudflare returns a generic 500. That is bad for any user-facing endpoint, and it is worse for Stripe — Stripe retries on 5xx errors, so a broken parser quietly turns into duplicate retries while your dashboard looks fine. Wrap the parse in a try/catch and return a 400 with a clear message. Stripe webhook payloads are also big and hard to read; pretty-printing them with a JSON formatter and JSON viewer makes debugging much faster. I learned the try/catch lesson the hard way — one panicked late-night Stripe dashboard refresh.

What I would do differently next time

Use Workers first for any small task that needs an HTTP endpoint. That is a much bigger category than just "webhook" — link shorteners, OG image generators, form handlers, edge auth, JSON proxies, internal Slack bots. Trying it is one npm create command away.

I feel a bit silly for waiting three years. The mental model is one sentence: a Worker is a function that takes a Request and returns a Response. That is the whole platform. Everything else (KV, Durable Objects, AI bindings) is optional. If you want the full step-by-step instead of the highlights here, this Cloudflare Workers deploy guide covers the whole setup with a real validating endpoint, the free-tier limits in detail, and a few more gotchas to know before you ship.

If you have been avoiding Workers like I was, try it on the next small task you hit. Fifteen minutes will tell you if it fits how you think. For me, it did.

Understanding Protocol Buffers: A Fast Alternative to JSON

Khaja Hussain — Sun, 15 Dec 2024 20:36:23 +0000

In the world of data interchange, JSON (JavaScript Object Notation) has been a long-standing favourite. It’s simple, human-readable, and works seamlessly across platforms. For many use cases, JSON is “good enough.” But as systems scale, and the need for speed and efficiency increases, JSON’s text-based format can become a bottleneck.

That’s where Protocol Buffers (Protobuf) come in. Developed by Google, Protobuf is a powerful, compact, and lightning-fast data serialization format that has become a popular choice for modern applications.

Why Consider Protocol Buffers Over JSON?
Compactness: JSON’s text-based format can result in larger payloads. Protobuf, on the other hand, uses a binary format, which dramatically reduces the size of the data.

Speed: Protobuf’s binary format is faster to serialize (convert data to a transferable format) and deserialize (convert back to usable data).

Schema Evolution: Protobuf includes a schema that defines the structure of your data, making it easier to evolve your APIs without breaking backward compatibility.

Efficiency at Scale: For applications with high traffic or limited bandwidth (e.g., mobile apps, IoT devices), Protobuf’s efficiency can result in lower latency and better performance.

Protocol Buffers: A Smarter Way to Handle Data
In the world of data interchange, JSON (JavaScript Object Notation) has been a long-standing favorite. It’s simple, human-readable, and works seamlessly across platforms. For many use cases, JSON is “good enough.” But as systems scale, and the need for speed and efficiency increases, JSON’s text-based format can become a bottleneck.

Why Consider Protocol Buffers Over JSON?
Compactness: JSON’s text-based format can result in larger payloads. Protobuf, on the other hand, uses a binary format, which dramatically reduces the size of the data.

Speed: Protobuf’s binary format is faster to serialize (convert data to a transferable format) and deserialize (convert back to usable data).

Schema Evolution: Protobuf includes a schema that defines the structure of your data, making it easier to evolve your APIs without breaking backward compatibility.

Efficiency at Scale: For applications with high traffic or limited bandwidth (e.g., mobile apps, IoT devices), Protobuf’s efficiency can result in lower latency and better performance.

A Quick Comparison: JSON vs. Protobuf
Let’s take a simple example. Imagine you’re sending information about a user:

Using JSON:

{
  "id": 123,
  "name": "John Doe",
  "email": "john.doe@example.com"
}

This is straightforward and human-readable. But it’s also relatively large because of all the extra characters like {}, :, and the field names.

Using Protobuf:
First, you define a schema (usually in a .proto file):

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

When serialized to binary format, this same data is compacted into a tiny, efficient payload—unreadable to humans but incredibly fast for computers to process.

When to Stick with JSON
JSON is still a fantastic choice for many use cases:

If human-readability is a priority (e.g., logging or configuration files).
For simple, low-traffic systems where performance isn’t critical.

When to Use Protobuf
If your application needs to:

Handle large-scale data exchange (e.g., microservices, real-time APIs).
Operate under bandwidth constraints (e.g., mobile or IoT devices).
Ensure compatibility while evolving the API schema.

JSON is like the comfortable, everyday car you drive around town—reliable and easy to use. Protobuf, on the other hand, is a sleek sports car—designed for speed, efficiency, and high performance. While JSON is great for most day-to-day tasks, Protobuf shines when you need to go the extra mile.

So, whether you stick with JSON or make the leap to Protobuf depends on your needs. But if you’re building for the future and performance is key, Protobuf is a solid choice to keep things running smoothly.

Some helpful links to understand Protobuf and Json:

Protocol Buffers Documentation
protobuf
Json
JSON in API Development