Forem: Aral Roca

SAP Hybris Impex When None of Us on the Team Can Read It

Aral Roca — Sat, 18 Apr 2026 15:31:01 +0000

I'm currently embedded as an external on a team that uses the Hybris Management Console — HMC for short — to administer a SAP Commerce environment. Every few days the shared environment gets refreshed from production, which is exactly what you want for most of the data, and exactly what you don't want for half-finished configuration that hasn't made it to prod yet. A content type you registered on Tuesday, a workflow tweak from Wednesday, a test user you needed for a demo — gone by Friday morning. Everyone on the team has been through this loop enough times that they've stopped being surprised.

Impex is the natural answer. If you can describe a configuration change as an Impex file, you can replay it after every refresh, commit it to the repo, code-review it, and treat it like the rest of the platform. That is the official playbook and it is the right one.

The problem is more human than technical. Nobody on the team reads Impex fluently. The format predates most of the languages the team writes every day, the tooling around it is sparse, and a pull request that is sixty lines of semicolon-separated text doesn't exactly invite careful review. So people would rather click through the HMC, accept that the work will evaporate in a few days, and move on. Knowing this fixes itself with tooling, not with a training session, I spent a week building the eight browser tools this post is about.

What Impex is, in one paragraph

Impex is a plain-text scripting format SAP Commerce uses to insert, update, or remove rows in the platform's type system. Every Hybris object — Product, Catalog, Category, PriceRow, User, Customer, Order — is a Java-defined type, and Impex is how you push data at those types without writing Java. A file is a sequence of "blocks," each with a header line declaring a mode and type (INSERT_UPDATE Product;code[unique=true];name) followed by semicolon-separated data rows (;P-0001;My Product). Comments start with #. Macros start with $. Qualifier paths go inside parentheses: catalogVersion(catalog(id),version). The official Impex interpreter reference is the authoritative spec.

That is the entire language. It is genuinely small. What makes it hard to read is not the grammar; it's that it's a tabular format displayed in a text editor, without column alignment, without syntax highlighting, without any of the affordances you'd want for reviewing a spreadsheet.

Why HMC plus a periodic refresh forces this conversation

There is a recurring pattern in SAP Commerce projects: you have one production-like environment shared across product, QA, and engineering. To keep it close to reality, someone runs a refresh from production on a schedule — weekly, bi-weekly, overnight. That refresh is non-negotiable; it's how bugs get reproduced. But it means every configuration change that lives only in HMC has a half-life.

There are three ways out and only one of them scales.

Option one: stop doing the refresh. You immediately drift from production, QA starts missing real bugs, the refresh comes back, and you've lost a month.

Option two: ask people not to click in HMC. This is a social contract that lasts about a sprint. The tool is there, it works, deadlines exist.

Option three: every change goes into version control as an Impex file and is replayed after each refresh. This is the answer the platform has always wanted you to pick. It's also the one that requires your team to be comfortable reading and writing Impex, which brings me back to the opening of this post.

The eight tools

Everything below runs locally in your browser. Nothing is uploaded. The parser is a ~550-line TypeScript module that handles quoted fields, escaped semicolons, line continuations, macros, modifier blocks, and multi-block files. If you find real-world Impex this parser can't handle, I'd like to see it.

Impex Table Editor

This is the one that does the heavy lifting on my team. Paste a block, get a spreadsheet-style grid, edit cells inline, add or remove rows, copy the regenerated Impex back out. When the person writing the change doesn't read Impex but does read Excel, this is the bridge. It is also the tool I reach for first when I need to make a ten-row change without scrolling through semicolons.

If nothing else in this post sticks, the table editor is the one to bookmark.

Impex to CSV Converter

Turns any Impex block into CSV, one header per column. Useful when someone from content wants to see the current state of a catalog section in a spreadsheet without waiting for an engineer.

CSV to Impex Converter

The reverse: a CSV (often pasted from Google Sheets) becomes an Impex script, with the type name and unique column selected explicitly. Product people can draft the change in Sheets, the engineer converts it and commits. The review diff stays reviewable.

Impex to JSON and JSON to Impex

JSON is the lingua franca of everything that isn't Impex. If you're scripting a migration, generating Impex from a source of truth, or diffing two versions, a structured representation is easier than regexing semicolons. Each block becomes {mode, type, headers, rows}, macros are first-class, and the two tools round-trip so you can edit the JSON and convert back. A swap button at the top of each page flips the direction.

Impex Validator / Linter

Reports missing type names, unknown modifiers, duplicate unique keys across data rows, undefined macros, and column-count mismatches. None of these are exotic errors — they are all things SAP's interpreter will accept and then silently produce a bad import for. Adding this as a CI check on .impex files is the single highest-leverage change a team using Impex in version control can make.

Impex Macro Expander

Given an Impex file with $macros, produces the same file with every reference inlined. Fixed-point expansion, so macros that reference macros resolve cleanly. This is what you commit into an audit artefact. Auditors are not going to chase $macros through your repo.

Impex to SQL (Approximate)

Hybris abstracts over the database. Sometimes that abstraction leaks — a DBA asks what's actually being written, or you're reasoning about performance. This tool flattens Impex into approximate INSERT / UPDATE / DELETE in Postgres, MySQL, or ANSI-standard SQL, with INSERT_UPDATE rendered as ON CONFLICT / ON DUPLICATE KEY / MERGE depending on dialect. It is explicitly approximate; qualifier paths like catalogVersion(catalog(id),version) can't be rendered faithfully as joins without your items.xml. But for a mental model conversation, it's faster than spinning up a local Hybris and watching the query log.

The workflow I'm pushing on my team

Short version, ordered by ROI.

Impex goes both ways: dump what you did in HMC into a .impex file, or edit .impex and import to skip HMC entirely. HMC is slow for configuration — a twenty-field form is tedious the third time you touch it. For anything repetitive or bulk, writing the Impex directly and running the import is several times faster than clicking. And whatever you did have to do in HMC gets exported to .impex so it survives the next refresh.

Non-trivial edits happen in the Table Editor. Flat-editor Impex is fine for adding one column or flipping a flag. For anything with more than a handful of rows, the table editor is correct and the flat editor is not.

Run the Impex Validator before every import. This is 90% of the value of the tooling in this post. It catches duplicate unique keys, unknown modifiers, and undefined macros before SAP's interpreter silently accepts them and produces a bad import. Right now we pass it by hand over each .impex before running the import; not automated, but it catches most of the surprises.

Diffs are done on JSON. Convert both versions of a file to JSON via Impex to JSON and diff that. Row-level semicolon diffs are unreadable; structured diffs are not.

Macros are expanded in audit artefacts. Commit the compact form. When compliance asks what the deployment actually did, hand them the expanded version.

What still bites

Not every Impex problem has a browser-tool answer.

Type-system evolution is the big one. When somebody renames a field in items.xml, every Impex file referencing the old name silently starts writing to the wrong column or failing in confusing ways. No linter in the browser can catch this without access to your specific type definitions. A small project-local script that walks your .impex files and cross-references attributes against the current type system is worth a weekend. I haven't shipped one because every team has a different setup.

Performance is the other. Large Impex imports behave differently from bulk SQL loads — the interpreter validates every row, triggers platform events, and invalidates caches. If a million-row import takes six hours, the fix is almost never "tune the database." It's "split the file and import in parallel" or "disable cache eviction during the load." The SAP Commerce performance documentation covers this well.

Why I built this and not something else

The honest answer: my team (myself included) was not going to learn to read Impex by reading more Impex. Documentation didn't fix it. Pair programming didn't fix it. The bet was that handing someone a spreadsheet UI over an Impex block and saying "edit this like you'd edit anything else, the tool will write the Impex for you" might lower the barrier enough for Impex to become a format the team treats like CSV — a transport representation that happens to be how SAP Commerce wants the data, not a language they need to master.

Will this actually work? I don't know yet.

I want to be straight about where I am with this. These tools exist because my team is trying to answer a bigger question: can configuration-as-code via Impex replace clicking through HMC, long-term, for a team that isn't fluent in Impex? The tools are a bet on "yes." They are not proof.

There are a few ways this experiment could fall apart. Maybe the table editor is fine for 80% of edits but the remaining 20% — the ones involving nested qualifier paths, macros that reference other catalogs, modifier subtleties — still push people back to HMC and the discipline erodes. Maybe writing Impex is the easy part and the hard part is the CI pipeline that actually replays the scripts after a refresh, which is not what this post is about. Maybe the type system evolves faster than the tooling can keep up and the validator starts producing noise people learn to ignore. Any of these would mean "infrastructure-as-code in HMC via Impex" isn't really the right framing, and we need a different abstraction.

I'll write a follow-up in a few months once there's real data. Either these tools become the default path and configuration-as-code works the way SAP always wanted it to, or we learn something interesting about why it doesn't, and that's its own post. I don't have a strong prior either way.

If you're running SAP Commerce with the same HMC + refresh setup and you want to try something similar, the tools are free, local, and will keep working regardless of what I conclude. Bookmark the ones that fit your workflow. If you end up with your own data — positive or negative — I'd like to hear it.

For the ecosystem context: the SAP Help ImpEx documentation is the canonical reference, the SAP Commerce community forums are better than Stack Overflow for version-specific questions, and the Gartner Magic Quadrant for Digital Commerce covers where SAP Commerce sits in the broader enterprise ecommerce landscape.

I Was Paying Anthropic to Read CSS Class Names

Aral Roca — Fri, 17 Apr 2026 14:04:33 +0000

I burned through 176 million Anthropic tokens last Wednesday. You can see the spike in the screenshot further down. Most of that was productive Claude Code work, but when I tracked down the anomaly I found a batch job quietly shovelling raw HTML into Claude Sonnet 4.5 for summarization. The prompts worked; the token budget did not. When I finally looked at what my scraper was feeding the model, roughly 70% of every request was <div class="css-1f2x"> soup. The actual article, the part I cared about, was maybe 25% of the payload.

The fix was a five-line change: convert HTML to Markdown before sending it to the model. Token count dropped by 60%. Same output quality. I wish I had learned this sooner.

This post is about why that works, when it matters, and a few adjacent problems that same trick solves.

Why HTML is a token disaster

LLMs tokenize text. Anthropic exposes a token counting endpoint in the Claude API, and OpenAI's open-source tiktoken gives a similar view: most English prose splits into roughly one token per 3-4 characters. But HTML is not prose. It is a nested tree of tags, class names, inline styles, SVG attributes, and JSON blobs dumped into data-* attributes by every modern framework.

You can verify this yourself. Paste a paragraph of plain text into Anthropic's token counter and note the count. Then wrap it in a typical React-generated <div class="prose dark:prose-invert max-w-none sm:px-6 lg:px-8"> and count again. The wrapper alone, that one line, can cost you 30-40 tokens. Multiply that across a scraped page with 500 nested divs and you see where the money goes.

Markdown, by contrast, is nearly invisible to a tokenizer. A heading is two characters: #. A bold span is four: **x**. A link is [text](url), and the model handles it natively because its training corpus is saturated with Markdown from GitHub, Stack Overflow, and Reddit.

I ran a quick test on the Wikipedia article for the HTTP protocol:

Raw HTML (saved from browser): ~48,000 tokens
Cleaned HTML (boilerpipe style): ~22,000 tokens
Markdown conversion: ~8,900 tokens

That is an 81% reduction against raw, and 60% against even a cleaned HTML payload. On a model that charges per input token, this is not a micro-optimization. It is the difference between a viable product and a Stripe chargeback.

Here is a week of my actual Claude Code usage for reference. Four days, 433 million tokens, about $306 at list prices (I am on a Max subscription, but the equivalent pay-as-you-go cost makes the scale legible). Most of that is productive coding. Imagine what shaving 10-15% off by not shipping structural noise would buy you over a year.

The RAG pipeline case

If you are building retrieval-augmented generation, this matters even more. A RAG system typically:

Crawls or scrapes source documents
Chunks them into pieces that fit the embedding model's context window
Embeds each chunk into a vector database
At query time, retrieves the top-K chunks and injects them into the LLM prompt

Each of those steps gets worse with HTML in the loop. Embeddings drift because the model is trying to encode CSS class names alongside actual meaning. Chunking gets jagged; you either split mid-tag and confuse the retriever, or you use a naive character split that cuts a sentence in half. Retrieval latency grows because the vector space is polluted with structural noise.

Converting to Markdown before chunking solves all three. The excellent LangChain docs quietly recommend this: use MarkdownHeaderTextSplitter or RecursiveCharacterTextSplitter with Markdown separators. Their own examples strip HTML to Markdown first. There is a reason.

When you cannot run Python on a server

A lot of the HTML-to-Markdown literature assumes you have a backend with BeautifulSoup and markdownify installed. That is fine if you are building a pipeline. It is painful if you are a content writer, a journalist archiving sources, or a developer doing a one-off migration at 11pm.

I built Kitmul HTML to Markdown because I kept reaching for that exact workflow and hating every option. The tool runs in the browser. Paste the HTML source, get the Markdown. Nothing uploads, nothing phones home. The conversion happens with JavaScript on your machine, which means you can paste internal wiki exports, legal drafts, or client content without a second thought.

If you have never inspected the HTML behind a page, open any article, right-click, choose "View Page Source", and copy the article body. Feed that into the tool. What comes back is something you can actually put into a prompt, paste into Notion, or commit to a Git repository.

Seven places this actually helps

It took me a while to recognize how many of my problems reduce to "I have HTML and I wish it were Markdown". A partial list:

Feeding a long article to an LLM. The single largest wins happen when you are summarizing, extracting entities, or asking questions about a long web page. Markdown strips out the chrome and leaves the substance. Prompt cost drops, and ironically the model does better on the cleaner input because it stops getting distracted by CSS.

Migrating a blog off WordPress or Ghost. If you are moving to a static site generator like Astro, Hugo, or Jekyll, every post needs to be a .md file. Export your WordPress XML, feed each <content:encoded> block through the converter, drop the result into content/posts/. I moved 84 posts this way in an evening.

Archiving research. I keep a personal wiki of engineering articles I reference often. Pages disappear from the web all the time; the average web page lifespan is under 100 days. Markdown snapshots take milliseconds to read, diff cleanly in Git, and survive format churn in a way screenshots or PDFs do not.

Preparing training data or few-shot examples. If you are curating examples for fine-tuning or in-context learning, you want them consistent. Markdown is the consistent form. Every scraped source ends up the same shape, with the same heading hierarchy, and no random <span> wrappers confusing your template.

Cleaning up content after visual editors. Tools like Notion, Medium, or CKEditor export HTML that is technically correct but full of <p><strong><em><u> nesting nobody wants. Round-tripping through Markdown collapses that to the minimum semantic form, and you get a diffable, portable source of truth out of it.

Writing documentation from scraped API references. I have done this for three SDKs now. Grab the rendered HTML from the vendor's docs (many are built with MkDocs or Docusaurus and have no Markdown source available), convert it, and you have a starting point you can edit and commit. It is faster than copy-pasting each code block by hand.

Reducing costs on the Claude API and Gemini API. Every frontier model bills input tokens. Anthropic's prompt caching helps, but caching 48K of HTML is still worse than caching 9K of Markdown. Caches also evict. The cheapest token is the one you never send.

What gets lost in the conversion

Be honest about the trade-offs. A few things do not survive:

Visual styling. Colors, fonts, custom CSS. If the visual layout is the content (infographics, landing pages), Markdown is the wrong target.
Interactive components. Embedded forms, iframes, JavaScript widgets. These become either plain links or they disappear.
Exact table layouts. Markdown tables handle rows and columns, but merged cells, colspans, and nested tables simplify or break. For data-heavy tables, CSV export is usually a better path; our CSV to JSON tool covers the adjacent case.
Image positioning. Markdown images are inline, top-down. Float layouts do not translate.

For 90% of text-driven web pages, none of this matters. For the remaining 10%, you probably want the HTML anyway.

A concrete workflow

Here is the routine I have settled into for LLM work:

Scrape the page with fetch or Playwright and grab the innerHTML of the article body, not the full document. A decent CSS selector does half the cleanup for you.
If it is a one-off, paste into the HTML to Markdown converter. If it is a batch, use a library like turndown (on GitHub) or markdownify in Python.
Strip boilerplate (cookie banners, "related posts", newsletter CTAs). Markdown makes this easy: the noise tends to cluster at the top and bottom.
Feed to the model. For long documents, chunk along Markdown headings rather than character counts.
Cache the Markdown version locally. The next run should not repeat step 1.

The whole thing usually takes longer to describe than to run.

The broader point

Format conversion sounds boring. It is, until you watch your API bill shrink by 60% because you stopped sending structural ASCII noise to a trillion-parameter model. LLMs are expensive not in absolute terms but per million tokens, and the number of pipelines where someone is shipping raw HTML into a context window is genuinely embarrassing.

Markdown is the lingua franca of AI training data. That is a fact about the world, not an opinion. Working in Markdown aligns your inputs with what the model was trained to handle, and a plain-text intermediate form also gives you a version your Git history can meaningfully diff, which is something you will be grateful for in six months when you are trying to remember what the prompt looked like in Q3.

Try it

Open the HTML to Markdown converter, paste any HTML, and see the token count drop. Everything runs in your browser, which means your client drafts, scraped sources, and internal docs never leave your machine. The code is inspectable in the DevTools network tab; there are zero outbound requests during conversion.

If you want to publish the Markdown somewhere visual, the Markdown to Medium converter handles publication-ready output for Medium's editor.

Related tools: JSON Formatter · CSV to JSON · Word Counter · Text Diff Checker · Image Compressor

WSJF, Cost of Delay and Why Your Loudest Stakeholder Keeps Winning the Backlog Argument

Aral Roca — Thu, 16 Apr 2026 19:53:48 +0000

A few months ago I sat in a PI planning session where a team of twelve argued for forty minutes about whether a "see product alternatives" button was more important than a "notify me" button for out-of-stock items. Both PMs had slide decks. Both had data. Both were convinced. The conversation ended the way those conversations always end; the loudest person in the room won, and everyone else went back to their laptops with a quiet grudge.

That meeting is why I rebuilt our WSJF Calculator. Not because the world needed yet another backlog prioritization tool, but because I kept watching smart teams flush an entire quarter down the drain arguing about feelings when the math has existed since the 1980s.

The trick nobody tells you about prioritization

Most people think prioritization is about picking the most valuable thing. It isn't. It's about picking the thing where value divided by size is highest. That distinction sounds pedantic until you realize it's the difference between shipping eight small wins in a quarter and shipping one lumbering "strategic initiative" that nobody really wanted.

That's the whole thesis behind Weighted Shortest Job First. You score each backlog item on two things; how expensive it is to delay, and how big the job is. Then you divide. The highest score wins. That's it. No story point debates at 9am on a Monday, no "is login page a 3 or a 5", no pretending your gut feeling is a methodology.

WSJF = Cost of Delay / Job Size

Don Reinertsen popularized this in The Principles of Product Development Flow, which I'd call the best agile book ever written if the phrase "agile book" didn't immediately make most engineers reach for the nearest window. It's actually a queueing theory book dressed up as a management book, which is why it's so good.

Cost of Delay is three things, not one

Here's where most WSJF spreadsheets get it wrong. Cost of Delay isn't a single number. It's the sum of three very different questions:

Business Value. If we shipped this tomorrow, how much would users or the business care? Revenue, retention, a specific OKR. Concrete when you can, relative when you can't.
Time Criticality. Does the value decay over time? A Black Friday feature shipped in December is worth approximately zero. A compliance deadline you miss is worth less than zero.
Risk Reduction / Opportunity Enablement. Does this unlock something else, or take uncertainty off the table? Boring infrastructure work lives here and that's usually where it gets buried.

Add those three together. That's Cost of Delay. Divide by Job Size. That's WSJF. The reason this works isn't because the numbers are accurate; it's because the conversation is accurate. You can't pretend a risk-reduction spike is a revenue feature anymore. Every item has to justify itself on three axes before it gets a score.

Why relative sizing beats hours every single time

The other trap is how you size. People want to estimate in days. Don't. Human beings are terrible at estimating duration and we have decades of behavioral research showing it; Parkinson's law alone should be enough to scare you off. What humans are actually okay at is comparing two things and saying "that one's bigger."

So score in Fibonacci (1, 2, 3, 5, 8, 13, 20) or T-shirt sizes (XS, S, M, L, XL, XXL). The gaps matter; a jump from 5 to 8 forces a conversation that "4 days vs 5 days" doesn't. Our tool supports both because teams argue about this, and the argument is not worth having. Pick one. Move on.

What the tool actually does

The WSJF Calculator runs in your browser. Nothing leaves your machine. I'm obsessive about this for product-management tools specifically; your roadmap is the kind of thing you really don't want sitting on someone else's server.

Here's what we built into it after watching teams actually use it:

Templates for common domains. E-commerce, SaaS, internal platform, regulated industry. Start from something that already makes sense.
What-if analysis. Inflate the top task's size by 25%. Does the ranking flip? If yes, your top priority is fragile; re-estimate before you commit.
Robustness indicator. If the top three WSJF scores are within 10% of each other, treat them as equal and let team capacity decide. The tool shows you this in real time so you stop pretending 4.20 is meaningfully bigger than 4.10.
Share links. Copy a URL, paste it in PI planning notes, everyone loads the same backlog state. No Jira exports, no CSVs floating around Slack.
CSV + PDF export. Because some stakeholders only trust a PDF.

When WSJF is the wrong answer

I'll save you a mistake I've made. WSJF is not a universal prioritization framework. It's the right tool when:

You have 15 or more roughly comparable backlog items.
Your team is doing continuous delivery with short cycles.
Cost of delay is actually variable across items (some are time-sensitive, some aren't).

It's the wrong tool when:

You have a single strategic bet and three support tickets. Just do the strategic bet.
Everything is equally urgent. Then nothing is, and you have a management problem, not a prioritization problem.
You're trying to decide between two products. That's a Kano or portfolio question.

For binary in/out decisions, reach for MoSCoW or the Eisenhower matrix instead. For consumer-product feature ranking where you want a simpler formula, RICE is friendlier. I built versions of all three; they each solve a slightly different shape of problem.

The meeting ritual that actually works

WSJF breaks down when it becomes a ritual. The calculator does the math; the humans have to do the talking. Here's the loop I've seen work:

Score Cost of Delay first, together. Use planning poker to surface disagreement. If two people scored a 3 and a 13, that's interesting; dig in.
Score Job Size last. If you know the size first, it anchors the value estimate. Humans are lazy that way.
Read the top three out loud. If anyone flinches, re-score.
Lock and ship. Don't re-score mid-sprint. The whole point is that yesterday-you and today-you had different gut feelings but the math didn't move.

For longer-horizon commitments, pair WSJF with probabilistic forecasting. I wrote a whole piece on Monte Carlo delivery forecasting that pairs nicely with this; one tool tells you what to do next, the other tells you when you'll realistically be done.

The part that surprised me

When I first shipped the calculator, I expected engineers to use it. It turned out product managers are the heaviest users, and the thing they love most isn't the score. It's the audit trail. Every ranking has the three sub-scores visible; when a stakeholder asks "why isn't my feature at the top", the PM can point at a number and say "because your Time Criticality is S and your Job Size is XL." The conversation ends in a minute, not a week.

That's the real point of any prioritization tool. Not to replace judgment. To make judgment visible enough that the loudest person in the room can't overwrite everyone else.

Try it here: kitmul.com/en/agile-project-management/wsjf-calculator. It's free, it's in your browser, and your backlog is still yours.

AVIF in 2026: The Complete Guide to the Image Format That Beat JPEG, PNG, and WebP

Aral Roca — Tue, 14 Apr 2026 19:41:39 +0000

AVIF landed quietly in 2019 and spent years as the format nobody used. Then Chrome shipped native support. Then Firefox. Then Safari 16. By 2024, Can I Use reported 93% global browser coverage. And suddenly the question flipped from "can I use AVIF?" to "why aren't I using AVIF?"

If you're still serving JPEG and PNG on the web in 2026, you're leaving performance on the table. Here's what you need to know.

What AVIF actually is

AVIF (AV1 Image File Format) is a still-image format derived from the AV1 video codec, developed by the Alliance for Open Media; a consortium that includes Google, Apple, Microsoft, Mozilla, Netflix, and Amazon. It's royalty-free, open-source, and designed to replace JPEG, PNG, and even WebP.

The key technical facts:

Lossy and lossless compression in a single format
10-bit and 12-bit color depth (vs JPEG's 8-bit)
HDR and wide color gamut (BT.2020, PQ, HLG)
Alpha transparency (like PNG, unlike JPEG)
Film grain synthesis (stores grain parameters instead of actual noise)
Based on the HEIF container (ISO/IEC 23008-12)

The compression comes from AV1's intra-frame coding tools: directional prediction, recursive partitioning (up to 128x128 superblocks), and the CDEF (Constrained Directional Enhancement Filter). These tools were designed for video but work remarkably well for still images.

The compression numbers

Let's be specific. In independent tests by Netflix, Cloudflare, and Google, AVIF consistently outperforms:

Comparison	File size reduction
AVIF vs JPEG	30-50% smaller at same quality
AVIF vs PNG	50-70% smaller (lossy mode)
AVIF vs WebP	15-25% smaller at same quality

For a concrete example: a 500KB JPEG photograph typically compresses to ~250KB as AVIF with no visible quality difference. A 2MB PNG screenshot drops to ~400KB. These are not edge cases; they're typical results across diverse image types.

Why AVIF matters for web performance

Images account for roughly 50% of the average web page's total weight, according to HTTP Archive data. Cutting that by 30-50% has real consequences:

Core Web Vitals: Smaller images directly improve LCP (Largest Contentful Paint). Google has confirmed LCP is a ranking signal.
Bandwidth costs: A site serving 1 million page views/month with 500KB of images per page transfers ~500GB. Switching to AVIF cuts that to ~300GB. At CDN rates, that's real money.
Mobile experience: On 3G connections (still common in emerging markets), a 500KB image takes ~4 seconds to load. A 250KB AVIF takes ~2 seconds. That's the difference between a bounce and a conversion.
Carbon footprint: Less data transferred means less energy consumed. The Green Web Foundation estimates that data transfer accounts for ~0.06g CO2 per MB.

AVIF vs WebP vs JPEG vs PNG: when to use each

The format landscape isn't "use AVIF for everything." Each format still has its place:

Use case	Best format	Why
Photographs for the web	AVIF	Best compression, no visible quality loss
Transparent graphics	AVIF or WebP	Both support alpha; AVIF is smaller
Pixel-perfect screenshots	PNG	Lossless, universal compatibility
Email attachments	JPEG	Universal; every client supports it
Legacy system input	BMP/JPEG	Some systems can't decode modern formats
Favicons	ICO	Required by browsers for tab icons
Scalable logos	SVG	Vector; infinitely scalable
HDR photography	AVIF	Only modern format with full HDR support

The practical advice: serve AVIF as your primary web format with JPEG/PNG fallbacks using the <picture> element or CDN-based content negotiation.

How to convert images to and from AVIF

You don't need to install command-line tools or pay for cloud services. Kitmul provides free, browser-based AVIF converters that process everything locally; your images never leave your device.

Converting TO AVIF (reduce file sizes)

JPEG to AVIF Converter: The most common conversion. Shrink your photo library by 30-50%.
PNG to AVIF Converter: Perfect for screenshots and graphics with transparency.
WebP to AVIF Converter: Upgrade from WebP to the next generation; another 20% savings.
SVG to AVIF Converter: Rasterize vector graphics into compact AVIF files.
BMP to AVIF Converter: Compress raw bitmaps from legacy systems; 95%+ reduction.
PDF to AVIF Converter: Extract PDF pages as lightweight AVIF images.
ICO to AVIF Converter: Convert icon files for web galleries.

Converting FROM AVIF (for compatibility)

AVIF to JPEG Converter: When you need universal compatibility for email or print.
AVIF to PNG Converter: Lossless output with transparency for editing workflows.
AVIF to WebP Converter: WebP fallback for CDN pipelines.
AVIF to PDF Converter: Embed images in professional documents.
AVIF to GIF Converter: For email signatures and legacy platforms.
AVIF to BMP Converter: Raw pixel data for industrial systems.
AVIF to ICO Converter: Create favicons from AVIF source images.

The `<picture>` element: serving AVIF with fallbacks

The standard pattern for progressive format delivery on the web:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description" loading="lazy">
</picture>

The browser picks the first format it supports. AVIF-capable browsers (93%+) get the smallest file. WebP serves as a fallback for the remaining ~7%. JPEG is the universal safety net.

For responsive images, combine with srcset:

<picture>
  <source
    srcset="photo-400.avif 400w, photo-800.avif 800w, photo-1200.avif 1200w"
    type="image/avif"
    sizes="(max-width: 800px) 100vw, 800px">
  <source
    srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w"
    type="image/webp"
    sizes="(max-width: 800px) 100vw, 800px">
  <img
    src="photo-800.jpg"
    alt="Description"
    loading="lazy"
    width="800"
    height="600">
</picture>

CDN and build-tool support

Most modern infrastructure handles AVIF natively:

Cloudflare Image Resizing: Auto-converts to AVIF via Polish or Image Resizing
Vercel/Next.js: next/image supports AVIF via formats: ['image/avif', 'image/webp'] in next.config.js
Netlify: Automatic AVIF via Image CDN
Sharp (Node.js): Full AVIF encode/decode since v0.29
Squoosh: Google's browser-based encoder supports AVIF
libavif: The reference implementation by the AOM

Known limitations

AVIF isn't perfect. Be aware of these trade-offs:

Encoding speed: AVIF encodes 5-10x slower than JPEG. This matters for real-time processing but not for batch/build-time conversion.
Maximum dimensions: The AV1 spec limits individual tiles to 8192x4320 pixels. Larger images require tiling, which some tools don't support.
Animation support: AVIF supports animated sequences (AVIS), but tooling is immature compared to GIF/WebP animation.
Older browsers: IE11 and pre-2020 browsers don't support AVIF. Always include fallbacks.
Email clients: Most email clients don't render AVIF. Use AVIF to JPEG for email content.
Print workflows: Print shops typically expect TIFF, PDF, or high-quality JPEG. Convert with AVIF to PDF before sending to print.

The bottom line

AVIF is the best general-purpose image format available in 2026. It delivers smaller files than any alternative at equivalent quality, supports features no other format offers (HDR, wide gamut, film grain synthesis), and has near-universal browser support.

The migration path is straightforward:

Convert your existing images to AVIF (use our free converters)
Serve AVIF with <picture> fallbacks
Keep JPEG/PNG originals for compatibility workflows

Every kilobyte you save loads faster, ranks better, and costs less. The format war is over. AVIF won.

Your Last Coffee Isn’t the Problem; the First Three Are Still in Your System

Aral Roca — Mon, 13 Apr 2026 19:37:09 +0000

A friend of mine was averaging 4 cups of coffee a day. Morning espresso at 7. Drip coffee at 10. Post-lunch lungo at 14:00. And an afternoon ristretto around 16:00 "just to push through." He wasn't sleeping well, but blamed stress, screens, the usual suspects.

I told him to do the math.

The exponential decay you're ignoring

Caffeine follows first-order elimination kinetics with a half-life of approximately 5 hours in healthy adults. The formula is simple:

remaining = dose * 0.5 ^ (elapsed_hours / 5)

A single 95mg drip coffee at 10:00 AM leaves ~47mg by 3 PM and ~24mg by 8 PM. Sounds harmless. But most of us don't drink a single cup.

When you stack multiple intakes, the decay curves overlap. That 63mg espresso at 7 AM is almost gone by evening, but the 80mg lungo at 2 PM still has 40mg in your system at 9 PM. Add the 40mg ristretto at 4 PM and you're sitting at 64mg of caffeine at bedtime; well above the 50mg sleep disruption threshold identified in clinical research.

The problem isn't any single cup. It's the superposition of all of them.

Why I built a multi-intake caffeine tracker

Most caffeine calculators I found online only handle one beverage. You enter "95mg at 8 AM" and get a decay curve. Useless if you're a multi-cup person; which is most of us, according to the FDA's average of 3-4 cups per day in the U.S.

So I built one that handles the actual workflow: add as many beverages as you want, each with its own type and time, and see the combined decay curve.

The Caffeine Half-Life Calculator supports 11 beverage presets:

Beverage	Caffeine (mg)
Ristretto	40
Espresso	63
Lungo	80
Drip Coffee	95
Cold Brew	200
Matcha	70
Energy Drink	80
Black Tea	47
Green Tea	28
Cola	34
Decaf	7

You can also enter custom amounts. Everything runs client-side in the browser; no data leaves your machine.

The math behind the combined curve

For N intakes, the total caffeine at time T is:

total(T) = sum(dose_i * 0.5 ^ ((T - t_i) / 5)) for all i where T >= t_i

Each intake only contributes to the total after its consumption time. The resulting curve isn't a simple exponential; it's a sum of shifted exponentials, which can produce surprising plateaus when intakes are spaced closely.

This is why eyeballing it doesn't work. A 3 PM coffee "doesn't seem like much," but combined with the residual caffeine from morning drinks, it can push your bedtime levels past the threshold.

What we learned about his consumption

After plugging in his actual daily routine:

7:00 AM Espresso (63mg) ; mostly gone by evening; only 5mg left at 11 PM
10:00 AM Drip Coffee (95mg) ; still 17mg at 11 PM
2:00 PM Lungo (80mg) ; 28mg at 11 PM
4:00 PM Ristretto (40mg) ; 18mg at 11 PM

Total at 11 PM: 68mg. That's 36% above the sleep threshold.

Dropping the 4 PM ristretto brought him to 50mg; right at the edge. Moving the lungo to 1 PM dropped it to 43mg. That single hour shift made the difference.

The developer who also drinks cold brew

If you're a developer reading this; and statistically you probably are, given where I'm posting this; cold brew is particularly dangerous. At 200mg per serving, a single cold brew at 2 PM leaves 71mg in your system at 11 PM. By itself.

Add that to a morning coffee and you're looking at 80+ mg at bedtime. No wonder you're staring at the ceiling at 1 AM wondering if it's the code review or the caffeine.

Technical details

The tool is built with React, runs entirely in the browser (no backend), and uses URL state for shareability. The decay chart uses a simple bar visualization with color coding:

Amber/dark: high caffeine (>50% of peak)
Amber/light: moderate (below 50% of peak, above sleep threshold)
Green: safe for sleep (below 50mg)

The source is part of Kitmul, a collection of 300+ free browser-based tools. If you're into health tracking, you might also find the BMI Calculator, BMR Calculator, or Water Intake Calculator useful; staying hydrated actually helps your body process caffeine more efficiently.

Practical takeaways

Track all your intakes, not just the last one. Cumulative caffeine is what matters for sleep.
The cutoff time depends on how many cups you've already had. A 2 PM coffee is fine after one morning cup, but not after three.
Cold brew is not just "strong coffee." At 200mg it's in a different category entirely.
Ristretto < Espresso < Lungo. Shorter extraction = less caffeine. If you want an afternoon coffee, go short.
The 50mg threshold is a population average. If you're a slow metabolizer (CYP1A2 gene variant), your half-life could be 7+ hours. Adjust accordingly.

Try the Caffeine Half-Life Calculator with your actual daily intake. You might be surprised how much caffeine is still in your system at bedtime.

All calculations run locally in your browser. No data is sent anywhere. The tool is free, open, and has no accounts or limits.

6 Agile Tools I Built Because Jira Dashboards Aren't Enough

Aral Roca — Sun, 12 Apr 2026 19:01:19 +0000

I've been doing agile coaching and engineering management for long enough to know that most teams measure the wrong things. Or, more commonly, they measure nothing at all and just vibes-check their way through sprint planning. "How's the sprint going?" "Fine." "Are we on track?" "I think so." Cool. That's not data. That's horoscopes.

The tools I'm about to walk through exist because I kept building the same spreadsheets over and over for different teams. WIP aging charts in Google Sheets. Capability matrices in Notion that nobody updated. Capacity plans in Excel that broke every time someone went on vacation. At some point I snapped and just built them properly — browser-based, no accounts, no servers, data stays on your machine.

Here are six agile tools I shipped this week, what problems they solve, and why I think you might actually use them.

Your WIP is lying to you

Every kanban board shows you how many items are in progress. Three items in dev, two in review, one in testing. Great. But that number is almost useless by itself.

What matters isn't how many items are in progress — it's how long they've been there. A column with three items where each one arrived yesterday is fine. A column with three items where one has been sitting there for 22 days is a disaster hiding in plain sight.

This is the core insight behind WIP aging, and it comes directly from Little's Law: average cycle time equals work in progress divided by throughput. If your WIP includes ancient items, your average cycle time is being dragged up and your flow metrics are lying to you. ActionableAgile made this concept popular in the kanban world, and it's genuinely one of the most underrated agile metrics out there.

The WIP Age Chart I built lets you visualize this instantly. Drop in your items, their start dates, and their current column — you get a scatter plot showing age by stage with configurable thresholds. Items aging past your 85th percentile cycle time get flagged red. No more "oh I didn't realize that ticket had been in code review for three weeks."

Six dimensions, one radar

Here's a question that should be easy but never is: "Is the team healthy?"

Not "are they delivering stuff" — that's one dimension. I mean the full picture. Are they delivering the right stuff? Is their flow smooth or choppy? Can they make commitments and keep them? Is quality holding up or are they shipping fast and breaking things?

Inspired by Daniel Vacanti's work on kanban flow metrics, I built a Six Dimensions Radar that scores teams across six axes: Quality, Responsiveness, Predictability, Productivity, Flow, and Value. You input your metrics, it renders a radar chart, and suddenly you can see that your team is crushing it on productivity but their predictability is garbage. That's a conversation starter. That's the kind of team performance visibility that turns a retrospective from "what went well / what didn't" into something with actual teeth.

The bus factor spreadsheet nobody maintains

Every engineering org I've worked with has had some version of a skills matrix. Usually it's a Google Sheet that someone created during an offsite, got populated once with enthusiasm, and has been slowly rotting ever since. Meanwhile, the actual bus factor keeps getting worse and nobody notices until Sarah goes on maternity leave and suddenly nobody knows how the payment gateway works.

T-shaped skills sound great in theory. In practice, nobody tracks them. The Capability Gap Analyzer makes it trivially easy: list your team members, list your capabilities, rate proficiency on a simple scale, and it immediately shows you where the gaps are. Single points of failure light up. Skills that only one person has get flagged. You can export the whole thing as JSON and actually keep it updated because it takes thirty seconds instead of an afternoon.

Stop forming teams by accident

Most teams aren't designed. They're accidents. Someone gets hired, they join whichever team has capacity, and three months later you have a team of four backend engineers and zero frontend people trying to deliver a user-facing feature. Conway's Law predicts exactly what happens next: the architecture mirrors the team structure, and you end up with a beautiful API that nobody can actually use because the UI is an afterthought.

Team Topologies by Matthew Skelton and Manuel Pais made a compelling case that team design is system design. I agree completely. The Team Formation Optimizer takes your people, their skills, and your constraints (who works well together, who needs mentoring, what capabilities each team needs) and helps you explore formations that actually make sense. It won't replace human judgment — nothing should — but it surfaces combinations you wouldn't have thought of and highlights obvious imbalances before they bite you.

"How much work is coming?" is a forecasting problem

Sprint planning usually focuses on what's already in the backlog. But the backlog isn't static. New items arrive constantly — bugs, feature requests, tech debt, that thing the CEO saw at a conference and now considers urgent. If you don't model the arrival rate, your capacity planning is fiction.

This is a classic time series decomposition problem. The Backlog Arrival Rate Forecaster uses multiplicative seasonal decomposition to break your historical backlog arrivals into trend, seasonal, and residual components. Feed it six months of data and it'll tell you that yes, backlog arrivals spike 40% every January (post-holiday feature requests) and drop 25% in August (everyone's on vacation). The approach follows the same principles outlined in Hyndman & Athanasopoulos's forecasting textbook — not because I'm trying to be academic, but because the methods work and they're well-understood.

Knowing your delivery forecasting numbers means nothing if you don't also know what's coming in. Inflow matters as much as throughput.

Capacity planning that accounts for reality

The most common capacity planning I see is: "We have 5 devs × 10 points each = 50 points per sprint." This is wrong in so many ways I don't even know where to start. People take vacation. People get sick. People get pulled into incidents. New hires ramp up slowly. Seasonal factors affect availability — good luck staffing a full team between Christmas and New Year's.

The Seasonal Capacity Planner accounts for all of this. You input your team composition, planned absences, hiring timeline, and seasonal adjustment factors. It produces a realistic capacity forecast that doesn't pretend everyone is available 100% of the time. This is basically the Theory of Constraints applied to team capacity — your actual throughput is determined by your bottleneck, not your theoretical maximum. Sprint planning with realistic capacity numbers is a different experience entirely.

All of this runs in your browser

I'm going to keep hammering this point because it matters: none of these free agile tools send your data anywhere. No servers. No accounts. No analytics tracking your team's performance data. Everything runs client-side in JavaScript. Your data lives in localStorage. You can export and import JSON files to move data between machines or share configurations with teammates.

Most of the tools also support URL state — meaning you can configure a view and share the URL directly. Someone clicks it and sees exactly what you see. No login required.

These are browser-based tools built for people who want to understand their teams better without handing their data to yet another SaaS vendor. If you're doing kanban flow analysis or trying to improve your agile metrics visibility, I think they'll save you time.

I ship tools weekly. If there's something missing or broken, open an issue or just tell me on Twitter. I read everything.

How to Detect AI-Generated Content Using Perplexity and Burstiness

Aral Roca — Thu, 09 Apr 2026 13:24:42 +0000

A friend of mine who runs a content agency told me over coffee last week: "we've tried every AI detector out there and they're all snake oil." I told him I thought I could build a better one. He laughed. Fair enough.

The AI Content Detector I built runs entirely in the browser. No uploads, no subscriptions, no cloud API charging you per scan. It uses ten statistical metrics and eighteen sentence-level signals to figure out whether text was written by a human or generated by ChatGPT, Claude, Gemini, or whatever LLM people are using this week. I want to explain how it actually works, because most "AI detector" marketing pages are deliberately vague about their methodology.

Why perplexity and burstiness alone don't cut it

Every blog post about AI detection mentions perplexity and burstiness. They're real metrics, they do measure something useful, but here's the uncomfortable truth I discovered after weeks of testing: modern AI models like GPT-4 and Claude produce text with high perplexity and high burstiness. They've been trained to sound human. Relying on these two metrics alone is like trying to catch a burglar by checking if they used the front door.

Perplexity measures how predictable word sequences are (low = robotic, high = creative). Burstiness measures sentence length variation (low = uniform, high = varied). Old-school AI from 2022 failed both tests spectacularly. But 2025-2026 models? They pass with flying colors.

So what actually works?

The ten metrics that matter

After benchmarking against articles I knew were AI-generated and articles I knew were human (I used a set of ten real URLs ranging from MIT Technology Review to generic SEO coffee blogs), I found that these signals, combined, produce results that are actually useful:

Zipf's Law conformity turned out to be the single most reliable metric. Every natural language follows Zipf's law: the second most common word appears half as often as the first, the third appears a third as often, and so on. Human text deviates from this curve because we get fixated on certain words, go on tangents, make weird word choices. AI text follows Zipf's law almost perfectly because it's sampling from probability distributions that inherently produce Zipfian outputs. I compute R-squared of log-rank vs log-frequency and anything above 0.96 is suspicious.

Repeated sentence starters is embarrassingly simple but catches a ton of AI. Count what percentage of sentences start with the same word. AI loves starting sentences with "The", "This", "It", "In". I've seen AI blog posts where 70%+ of sentences start with one of four words. Humans are messier about it without even trying.

Punctuation entropy measures the Shannon entropy of distances between punctuation marks. AI places commas and periods at remarkably regular intervals. Humans are chaotic; sometimes we write three short sentences in a row, then a long one with five commas, then a fragment.

Sentence length skewness captures the shape of the sentence length distribution. AI produces near-symmetrical distributions (bell curve). Humans write with positive skew: many short sentences, some medium ones, and the occasional monster sentence that runs away from you.

Hapax legomena ratio counts what percentage of words appear only once in the text. Human text has more one-time words because we use specific, contextual vocabulary. AI reuses words more evenly across the text.

Paragraph uniformity is the coefficient of variation of paragraph lengths. AI produces remarkably uniform paragraphs. Humans write a two-sentence paragraph followed by a twelve-sentence one without thinking about it.

The remaining four metrics (perplexity, burstiness, vocabulary richness, word length standard deviation) contribute smaller weights. They help break ties but they're not the heavy hitters anymore.

The real trick: multiplicative signal scoring

Here's where it gets interesting. Individual signals overlap between AI and human text all the time. A human might use dashes (AI signal) or have uniform paragraphs (AI signal). But humans almost never have dashes AND uniform paragraphs AND transition words AND no contractions AND formulaic structure AND repeated starters all in the same sentence.

AI text has clusters of co-occurring signals. When three or more AI signals appear in the same sentence, the score doesn't just add up; it multiplies. A sentence with two AI signals scores normally. Three signals? Score multiplied by 1.5x. Four or more? Multiplied by 2x. This multiplicative approach captures something that linear scoring misses: the difference between "occasionally looks AI-ish" and "this is obviously a pattern."

The sentence-level classifier tracks eighteen separate signals per sentence: length uniformity, dash usage, transition words, filler phrases ("it is important to note", "plays a crucial role"), overused vocabulary ("leverage", "comprehensive", "facilitate"), bold-then-explain patterns, "Here's what/why/how" hooks, proper noun density, contractions, parenthetical asides, questions, informal language, passive voice, starter repetition, colon endings, semicolons, numbered lists, and conclusion patterns.

URL mode and content extraction

You can paste text directly or enter a URL. In URL mode, the tool fetches the HTML, strips out navigation, sidebars, footers, images, scripts, and all non-text elements, then converts the remaining content to Markdown using Turndown. You can expand the extracted content below the results to verify what the tool actually analyzed. Some sites load content via JavaScript (client-side rendering), which the fetcher can't capture; for those, the text tab works better.

The URL fetch tries your browser first (no server involved). If CORS blocks it, a lightweight Edge proxy kicks in with a rate limit of five requests per minute.

Where it falls short

I'm not going to pretend this is perfect.

The biggest weakness: well-written AI text that has been lightly edited by a human. If someone generates a draft with ChatGPT and then rewrites a third of the sentences, adds a personal anecdote, and removes the transition words, our detector (and every other detector) will struggle. That's a fundamental limitation of statistical approaches.

The second weakness: some human writing is genuinely formulaic. Corporate press releases, legal documents, academic abstracts. These trigger AI signals because they lack the messiness that statistical detectors look for. This isn't a bug exactly, but it does produce false positives on a category of text that nobody would call creative writing.

The third weakness: very short text. Below about 200 words, there isn't enough statistical signal for any of the metrics to be reliable.

Compared to GPTZero, Originality.ai, Copyleaks

Those services use trained ML classifiers (neural networks trained on millions of labeled AI/human samples). In theory, they should be more accurate than statistical heuristics like mine. In practice, the gap is smaller than you'd think, especially on longer texts. Their models were trained on specific AI outputs and struggle when new models appear; statistical patterns are more model-agnostic.

The real advantage of the browser-based approach: your text never leaves your device, it's free, and it's instant. If you're scanning a hundred blog posts for a content audit, that matters more than a few percentage points of accuracy.

Try it

The AI Content Detector is on Kitmul. Free, no signup, runs in your browser. Test it on something you know is AI-generated, test it on something you wrote yourself, and see if the results match your intuition.

Next up: a sitemap scanner that crawls every URL in your sitemap.xml and produces a report of which pages look AI-generated. That one should be fun.

References:

Resting heart rate 68 to 56: what changed in my dev work

Aral Roca — Sat, 04 Apr 2026 15:39:11 +0000

I normally write about web frameworks, WebAssembly, and JavaScript internals. And I normally don't publish on a Saturday. But I've been wanting to write this for a while and today I woke up inspired, so here it is.

This isn't a technical article. It's personal. But I genuinely believe it can help a lot of people, especially developers and founders who spend long hours in front of a screen and feel like their brain gives up before their schedule does.

I want to talk about the things that changed my daily performance more than any tool, framework, or productivity app ever did. Not hypothetical stuff I read on a blog. Things I've been doing for months (some for years) that produced measurable, repeatable differences in how I work.

Here are the numbers first:

Resting heart rate: 68 → 56 bpm
Breathing rate: 14-16 → 8-10 breaths/min
Deep work blocks: ~90 min max → 3-4 hours consistently
Post-meeting recovery: 20-30 min → basically instant

None of this came from a supplement, an app, or a course. It came from applying things I learned through competitive athletics to how I work as a developer.

Some context about me
The parkour connection
Hack #1: Intermittent hypoxia
- What it actually is
- What changed for me
- The science (briefly)
Hack #2: The Pomodoro technique, done right
- Why most people do it wrong
- The parkour parallel
- How I actually use it
Hack #3: Walking meetings
Hack #4: Strategic caffeine
Hack #5: Cold exposure
Hack #6: Power naps
What didn't work
The thing nobody talks about: Silicon Valley already does this
The physiological argument for founders
How to start
References

Some context about me

I've been in software development for over ten years. Most of that time I've been deep in open source. I created NextTranslate, Teaful, and more recently Brisa, a web framework built on web components. I also recently built Kitmul, which went from a testing ground for my libraries to 300+ browser-based tools in three weeks (I wrote about that here).

That's the professional side. But there's another side that's been part of my life for just as long: parkour.

The parkour connection

I started doing parkour in the mid-2000s. By 2011 I was competing in Red Bull events. Not casually. This was serious training, serious risk, serious discipline. I trained alongside people who are now elite athletes preparing for the Olympics. Parkour will officially be part of the Games, and some of the people I used to train with are on that path.

Red Bull Art of Motion, Santorini

In 2021 I had the worst accident of my life. I misjudged a jump from a rooftop to a fence, fell badly, and ended up in a coma for three days. When I woke up, my vestibular system was damaged. The apparatus that controls balance. For weeks I couldn't walk straight without the world spinning.

Most people would have quit parkour after that. I did the opposite. I used parkour as rehabilitation. I went back to basics. Simple movements, low risk, building balance from scratch. The mindset was the same one I apply to debugging: the jump wasn't the problem. My execution was. I analyzed what I did wrong, and I trained specifically to fix it.

It took years of patient work. But this year, I went back and completed that exact same jump. Rooftop to fence. Clean.

I'm telling this story because it's directly relevant to everything that follows. The accident taught me something I already knew intellectually but had never felt in my bones: your body is the foundation of everything you do. When it breaks, nothing else matters. Not your code, not your startup, not your deadlines. And when you rebuild it deliberately, with discipline, everything else gets better too.

These days I do parkour as a hobby to stay in shape. But the years of competitive training, the accident, the recovery, gave me something that no programming book or productivity course ever could: an intuitive understanding of how the body and brain actually perform under pressure. And how fragile that performance is if you don't take care of the hardware.

Training outdoors

Athletes know things about performance that knowledge workers generally ignore. How rest periods affect output quality. How breathing patterns change your nervous system state. How adrenaline management is a trainable skill, not a personality trait. How the difference between a good day and a bad day often comes down to physiology, not motivation. And how you recover from failure matters more than the failure itself.

Once I started applying these principles to my work as a developer, everything changed.

And exercise itself, just moving your body regularly, is the most underrated performance hack that exists. It increases BDNF (the protein that helps your brain form new connections), regulates cortisol, improves sleep, and directly enhances executive function. Everything else I'm about to describe works better on top of a foundation of consistent physical activity. Parkour is my thing, but any movement practice works.

Hack #1: Intermittent hypoxia

This is the one that surprised me the most.

What it actually is

Intermittent hypoxia training (IHT) is simple: you alternate short periods of reduced oxygen breathing with normal recovery. It's the same principle behind altitude training, the thing that endurance athletes have been doing for decades to improve oxygen efficiency, except you can do it at sea level, sitting at your desk, in 15-30 minutes.

The protocol: controlled breathing cycles that temporarily reduce your blood oxygen saturation, followed by recovery breathing. Repeat for several rounds. That's it.

I started doing this to improve my breath-hold times and cardiovascular performance for parkour. The results in training were immediate. Longer runs, faster recovery between sequences, and much better composure during high-risk movements. When you're mid-air in a precision jump, the ability to manage your adrenaline response is not optional. IHT gave me noticeably more control over that.

What changed for me

But the real surprise came outside of training sessions. And this is the part that I think matters for anyone who works with their brain.

After about two weeks of consistent IHT practice, I noticed something: I was breathing more slowly throughout the entire day. Not because I was trying to. My body had simply recalibrated. Where I used to take 14-16 breaths per minute sitting at my desk, I dropped to 8-10.

This sounds minor. It's not.

Patrick McKeown, author of The Oxygen Advantage, has documented extensively how slower, lighter nasal breathing improves CO2 tolerance. Higher CO2 tolerance means better oxygen delivery to tissues, including your brain. It's counterintuitive (more CO2 = better oxygenation?), but the physiology is well-established: CO2 is what triggers hemoglobin to release oxygen to cells (the Bohr effect). If you breathe fast and shallow, you actually reduce oxygen delivery despite taking in more air.

Here's what I noticed in my daily work after my breathing shifted:

Sustained focus got dramatically easier. I used to hit a wall at about 90 minutes of deep work. That wall moved to 3-4 hours. Not through willpower or discipline. I just didn't get tired as quickly. Better brain oxygenation, fewer stress hormones circulating, more stable energy.

Adrenaline management at work. This was the one I didn't expect. Running a startup (or even just being a senior developer) means constant high-stakes moments. A production incident at 2am. A hard conversation with a coworker. An investor call where you have 20 minutes to make your case. Before IHT, these situations would leave me wired for hours afterward. Now the recovery is almost instant. The same nervous system control that helps me stay calm mid-air during parkour helps me stay clear-headed during a crisis at work.

Faster cognitive recovery. After an intense 3-hour coding session or a difficult meeting, I used to need a significant break before I could do anything useful again. Now I bounce back in minutes. It's like my brain's recovery time dropped from "restart the computer" to "close the tab and open a new one."

The simplest performance intervention: breathe less

The science (briefly)

I'll keep this short because I'm a developer, not a scientist, but I did go down the rabbit hole on the research:

A 2022 study in Frontiers in Neuroscience found that IHT causes "proadaptive modifications" in the brain, stimulating BDNF (brain-derived neurotrophic factor) and increasing what they called "the adaptive potential, endurance, and working capacity of the brain" [1]. Another study showed significant gains in memory recall and attention in participants following IHT protocols [2].

The mechanism is called hormesis. Controlled, small doses of stress that make the body more resilient. Same principle as cold exposure, sauna, or fasting. The difference is that hypoxia specifically targets oxygen efficiency and neural adaptation.

A study published in Physiology documented that intermittent hypoxia upregulates three growth factors (EPO, BDNF, and VEGF) all directly linked to enhanced neural function and cellular resilience [10]. This isn't about feeling zen. It's about building a more capable brain at the physiological level.

Andrew Huberman, a Stanford neuroscientist, has documented how breathing protocols shift autonomic nervous system state, reducing cortisol, increasing parasympathetic tone, and enhancing executive function [4]. IHT is essentially a more intense version of breathwork: it doesn't just teach you to breathe better in the moment. It permanently upgrades your baseline respiratory efficiency.

My resting heart rate went from 68 to 56 bpm. That's not a small change.

Hack #2: The Pomodoro technique, done right

I know, I know. Everyone's heard of Pomodoro. "25 minutes of work, 5 minutes of break, revolutionary." Most people try it for a week and drop it because it feels artificial.

I did the same thing years ago. Then parkour taught me something that made me come back to it with a completely different understanding.

Why most people do it wrong

The issue isn't the timer. It's what people do during the "break."

Most developers hit the 5-minute break and immediately check Slack, scroll Twitter, read email, or look at their phone. That's not rest. That's a different kind of cognitive load. Your prefrontal cortex doesn't get to discharge. It just switches to a different task. When the timer starts again, you're not fresh. You're fragmented.

The parkour parallel

Here's what parkour taught me about rest, and it took me years to really internalize this:

You need rest to improve. The gains happen during recovery, not during effort.

In a parkour training session, you give 100% on a sequence. A run, a series of jumps, a technical combination. Then you walk back. You breathe. You shake out your arms. You stand there for a minute doing literally nothing. And then you go again at 100%.

If you skip that recovery and try to chain explosive movements back-to-back, two things happen: your performance degrades fast, and you get injured. Every serious practitioner learns this the hard way.

Your brain works exactly the same.

When you try to code for four straight hours without structured breaks, the last two hours are objectively worse. Your attention drifts. Your error rate climbs. You make architectural decisions you'll regret tomorrow. But you don't notice it in the moment because cognitive degradation is invisible from the inside.

How I actually use it

25 minutes of this, then 5 minutes of not-this

Once I understood that the 5-minute break is not a concession to weakness but the actual mechanism that makes high performance sustainable, Pomodoro clicked for me.

25 minutes of full-intensity focus. One task. No Slack. No email. No "quick check" on anything. If something pops into my head, I write it on a sticky note and go back to what I'm doing. The goal is to create a state of total immersion, the same mental state I'm in during a parkour sequence where I literally can't afford to think about anything else.

5 minutes of real rest. Stand up. Look out the window. Walk to the kitchen. Breathe. The key word is "real." Your eyes need to leave the screen. Your working memory needs to flush. If you don't do this, you're just doing 4 hours of gradually degrading work with arbitrary timer interruptions.

The parallel to parkour is direct: train hard in bursts, rest completely between sets. The rest is what lets you sustain 100% intensity. Without it, by the third round you're operating at 60% and making mistakes. Except at your desk, the "injury" is a bug you'll spend two days debugging.

Here's a trick I use that combines both hacks: during some Pomodoro breaks, I do a quick round of breath-hold exercises. Five minutes of controlled breathing resets my autonomic nervous system and primes me for the next focus block. It's like a mini-reboot. When the timer starts again, I'm genuinely fresh, not just "took a break" fresh.

After four Pomodoro cycles, I take a longer break of 15-20 minutes. Go outside if possible. Move. The compounding effect across a full day is dramatic. Hour six feels like hour one.

Hack #3: Walking meetings

This one is simple but I almost never see people talk about it.

Many meetings don't require you to be sitting at a desk staring at slides. Status updates, brainstorming sessions, 1-on-1s, planning discussions. For all of these, you can be walking.

I use a walking treadmill at my desk during meetings. Slow pace, 3-4 km/h, just enough to keep blood flowing. The effects are immediate: better attention, less fidgeting, fewer distractions. There's something about low-intensity movement that keeps the brain engaged without consuming cognitive resources. Research backs this up: walking improves creative thinking and sustained attention.

My walking treadmill setup. Most meetings don't require sitting.

But here's the part nobody mentions: what happens after the meeting. When you've been sitting for an hour-long call, you finish drained. You need a transition period before you can do real work again. When you've been walking during that same call, you finish energized. You sit down at your desk and you're immediately ready to work. The meeting didn't drain your battery. It charged it.

This has been particularly useful for me during weeks with heavy meeting loads. The meetings themselves become light exercise, and the transitions between meetings and deep work become seamless.

Obviously this doesn't work for every meeting. If you're pair programming, sharing your screen, or doing a code review where you need to type, sit down. But for the 60-70% of meetings that are primarily conversation, walking is strictly better than sitting.

Hack #4: Strategic caffeine

I've never been a big coffee drinker. But I noticed that the few times I did have coffee, the effect was massive. That got me thinking about why.

The answer is simple: most people drink coffee every day, and daily caffeine consumption builds tolerance fast. After a couple of weeks, your morning coffee doesn't enhance your performance. It gets you back to your baseline. You're not getting a boost. You're paying a tax (dependency, sleep disruption, afternoon crashes) to feel normal. That's a bad trade.

Because I don't have that daily habit, I can treat caffeine purely as a tool.

What if the daily coffee ritual is actually costing you more than it gives?

Most days I drink water. Just water. This means my caffeine tolerance stays low. Then, when I actually need it (I slept poorly and have a big day ahead, there's a product launch, I'm doing a full day of complex pair programming) a single coffee delivers a genuine cognitive boost. Alertness, processing speed, working memory, all measurably better because my body isn't habituated.

Think of it like a power-up in a game. If you use it on every level, it stops being special. If you save it for the boss fight, it actually matters.

The transition period when you stop daily coffee is about a week of mild headaches and low energy. After that, you reach a new normal where you feel fine without it, and caffeine becomes something you choose to deploy strategically rather than something you depend on to function.

I know this one is controversial. Coffee culture is deeply embedded in developer identity. All I can say is: try it for two weeks and see what happens. The worst that can happen is you go back to your regular habit.

Hack #5: Cold exposure

This is a quick one. A cold shower at the end of my normal shower, 60-90 seconds of cold water, produces a norepinephrine spike that improves alertness and mood for hours. This is well-documented by Huberman and others [4].

I'm not doing ice baths or any extreme Wim Hof protocol. Just cold water at the end. The cost is minimal (it's uncomfortable for about 30 seconds, then you adapt). The effect on morning focus is noticeable and consistent.

Wim Hof's method (breathing + cold + meditation) was actually validated in a Radboud University study that showed trained participants could voluntarily influence their sympathetic nervous system and innate immune response [8]. That's remarkable. But you don't need the full method to get the basic alertness benefit. Just turn the handle to cold for a minute at the end of your shower.

Hack #6: Power naps

When I hit a wall after lunch or after a heavy morning, a 20-30 minute nap resets me completely. Not a "nice to have." A genuine cognitive reboot.

The key is keeping it under 30 minutes. Go longer and you enter deep sleep, which means you wake up groggy and worse than before. But a short nap, 20 minutes is the sweet spot, clears the mental fog and gives you what feels like a second morning. I've had some of my most productive afternoons right after a power nap.

I don't schedule them. I just listen to my body. If I'm not tired, napping is pointless. But when the signal is there, fighting it with coffee or willpower is a losing strategy. The nap is faster, free, and has no side effects.

What didn't work

I think it's important to mention what I tried that either didn't stick or didn't produce noticeable results. Not everything works for everyone, and I don't want to give the impression that I just tried five things and all five were magic.

Meditation apps. I tried Headspace and Calm for a few months each. They're well-made products, but guided meditation didn't produce the same physiological changes as breathwork and IHT. My suspicion is that meditation works better as a long-term practice (years, not months) while breathing protocols produce measurable changes in weeks. Your mileage may vary.

Strict time-blocking the entire day. I tried scheduling every 30-minute slot for a few weeks. It created more anxiety than productivity. Pomodoro works for me because it structures intensity and rest, not content. I decide what to work on, then I decide how intensely to focus on it. Scheduling every minute took away the flexibility that makes creative work possible.

The thing nobody talks about: Silicon Valley already does this

Behind the clean offices, a quiet obsession with physiological optimization

Here's what I find interesting. These aren't fringe biohacking experiments. Breathwork and oxygen manipulation have been quietly adopted across the tech industry for years. Not as a trend, but as a serious performance tool.

Bryan Johnson, the founder of Braintree (sold to PayPal for $800M), spends roughly $2M per year on biohacking protocols. The man literally moved his office into a hyperbaric chamber [5]. Now, $2M/year is absurd and not what I'm suggesting. But the underlying logic, that physiological optimization directly translates to cognitive performance, is sound.

Jack Dorsey, co-founder of Twitter and Block, has practiced meditation and controlled breathing for over 20 years [6]. Tim Ferriss has dedicated entire podcast episodes to breathing protocols for performance, hosting James Nestor (author of the NYT bestseller Breath: The New Science of a Lost Art) to discuss how subtle breathing adjustments transform cognitive output [7].

Dave Asprey, founder of Bulletproof, has worked extensively with Wim Hof. Patrick McKeown's Oxygen Advantage method, which is essentially breath-hold training that simulates altitude, has been adopted by athletes, military operators, and increasingly, tech executives [3].

Longevity Technology reported that biohacking has become "a major trend among Silicon Valley executives seeking to optimize health and performance," with breathwork, cryotherapy, and oxygen manipulation among the most commonly adopted protocols [9].

What's telling is why these people gravitate toward physiological hacks rather than (or in addition to) productivity software. When you're building something that demands 12-16 hours of sustained cognitive output per day, across months and years, the bottleneck is not your task manager. It's not your team structure. It's not your tech stack. The bottleneck is your brain's ability to maintain quality output under sustained pressure. That's a physiology problem, not a tooling problem.

And marginal gains in oxygen efficiency and stress resilience compound dramatically over time.

The physiological argument for founders

The startup world glorifies hustle but ignores the hardware it runs on. You can optimize your deployment pipeline, your sprint process, your hiring funnel. But if your brain is running on shallow breathing and chronic cortisol, none of it matters. You're making your worst decisions at the end of the day, exactly when they matter most.

Consider what changes when your baseline physiology is different:

Your resting heart rate drops. Mine went from 68 to 56 bpm. A lower resting heart rate correlates with better cardiovascular efficiency, better stress recovery, and better autonomic regulation. You're literally running calmer all day.

Your breathing rate drops. 8 breaths per minute instead of 15. Fewer breaths means less sympathetic nervous system activation throughout the day. Less fight-or-flight. Less background anxiety. Less cortisol.

Your work is structured around recovery. Pomodoro ensures that hour six of your day is as sharp as hour one. You don't gradually degrade. You stay at peak performance in short bursts and actively recover between them.

Your oxygen utilization improves. The same blood volume delivers more oxygen to your prefrontal cortex, the part of your brain that handles planning, decision-making, and impulse control. The exact functions you need most as a founder.

Your stress recovery accelerates. The interval between "something went wrong" and "here's what we're going to do about it" shrinks from minutes to seconds. This is probably the most practically valuable change. In a startup, the speed at which you can move from panic to plan is everything.

None of this is woo. James Nestor's research, documented across multiple peer-reviewed collaborations, shows that breathing efficiency is one of the single highest-leverage interventions for cognitive performance [7]. And a study published in Physiology documented that intermittent hypoxia upregulates EPO, BDNF, and VEGF, three growth factors directly linked to neural function and cellular resilience [10].

How to start

None of this requires expensive equipment or complicated protocols.

Intermittent hypoxia, the 5-minute version:

Breathe normally through your nose for 2 minutes. Just calm, quiet nasal breathing.
Take a normal breath in, exhale gently, and hold your breath.
Walk slowly while holding. When you feel a moderate urge to breathe, stop.
Resume nasal breathing and recover for 1-2 minutes.
Repeat for 6-8 rounds.

This is a simplified version of Patrick McKeown's Oxygen Advantage method [3]. It works by increasing your CO2 tolerance and training your body to do more with less oxygen, exactly what altitude training does, but at sea level.

For more structured sessions with timed rounds and progressive difficulty, I built an intermittent hypoxia breathing timer as one of the tools on Kitmul.

Pomodoro, the non-negotiable version:

Pick one task. Not "a few things." One.
Set a timer for 25 minutes.
Work at full focus. No Slack, no email, no phone.
When the timer rings, stop. Stand up. Walk away from your screen for 5 minutes.
Repeat. After 4 cycles, take a 15-20 minute break.

The discipline is in the rest, not the work. Anyone can focus for 25 minutes. The hard part is actually stopping and actually resting. If you want a good timer, there's a Pomodoro timer on Kitmul too.

Caffeine reset:

Stop drinking coffee for one week. Push through the headaches (they peak at day 2-3 and disappear by day 5). Then only use caffeine on days when you genuinely need a boost. You'll be amazed at how much more effective a single cup becomes.

Cold exposure:

At the end of your normal shower, turn the water to cold for 60-90 seconds. That's it. The first week is uncomfortable. After that, it becomes almost pleasant, and the alertness benefit is consistent.

Walking meetings:

Buy a cheap walking treadmill. Use it during any meeting where you don't need to type. You'll finish meetings energized instead of drained.

I started all of this because of parkour. The breathing work, the structured rest, the body awareness. It all came from athletic training, not from reading productivity blogs. But the transfer to knowledge work was immediate and dramatic.

The best productivity hack I've found in over ten years of professional software development isn't a tool, a framework, or an AI agent. It's optimizing the machine that runs all the other machines: your body.

Oxygen and well-timed rest. That's it.

References

Rybnikova, E. & Nalivaeva, N. (2022). "Intermittent Hypoxic Training as an Effective Tool for Increasing the Adaptive Potential, Endurance and Working Capacity of the Brain." Frontiers in Neuroscience. Read study
Schega, L. et al. (2013). "Effects of Intermittent Hypoxia on Cognitive Performance and Quality of Life in Elderly Adults." Gerontology. Read on PubMed
McKeown, P. The Oxygen Advantage. Breath-hold exercises that simulate altitude training at sea level. Official site
Huberman, A. "Breathwork Protocols for Health, Focus & Stress." Huberman Lab. Read article
Johnson, B. Braintree founder, $2M/year biohacking protocol including hyperbaric oxygen. Source
Dorsey, J. 20+ years of meditation and breathwork practice. Source
Nestor, J. Breath: The New Science of a Lost Art. NYT bestseller on breathing science. Official site
Wim Hof Method. Radboud University study on voluntary influence over sympathetic nervous system. Read more
"Silicon Valley's biohacking obsession: Why tech executives are hooked." Longevity Technology. Read article
Dale, E. et al. (2014). "Unexpected Benefits of Intermittent Hypoxia: Enhanced Respiratory and Nonrespiratory Motor Function." Physiology. Read study
Intermittent Hypoxia Breathing Timer. Free guided tool for structured IHT sessions.
Pomodoro Timer. Free focus timer with structured work/rest cycles.

AI agents shouldn't control your apps; they should be the app

Aral Roca — Tue, 31 Mar 2026 14:44:02 +0000

Kitmul started as something far more modest than what it is today. I maintain two open source libraries: NextTranslate and Teaful. I needed a real Next.js project where I could iterate on them. Not artificial demos or example repositories; a live product where bugs surface naturally and limitations become obvious.

That was the only goal.

The AI multiplier effect

To speed up development, I started using AI coding agents: Claude Code, Gemini, and Codex. Not just for productivity. I wanted to understand firsthand how these agents behave in a real development workflow. What they're good at, where they break, and how they change the way you think about building software.

What I didn't expect was the effect on scope. When you can implement an idea in minutes instead of hours, you stop triaging ideas. You just build them. I went from "let me maintain these two libraries" to "let me build 300+ tools" in just 3 weeks.

Currently I'm on Claude Code 20x. The combination of an agent that understands your codebase deeply and can execute multi-step tasks autonomously has been the biggest development velocity multiplier I've experienced.

From dev tools to tools for everyone

As an open source developer, I've always built for other developers. Libraries, CLI tools, build utilities. Limited audience, limited impact.

With Kitmul I flipped the question. Instead of "what tool does a dev need," I asked: "what tool do people search for on Google and end up on a website that charges them or uploads their files to a server."

The answer: hundreds of tools. Remove image backgrounds, separate audio tracks, convert formats, compress PDFs, generate QR codes. Tools people use daily, and for which many sites charge €10-20/month.

Today Kitmul has over 300. And they're not trivial wrappers.

The architecture: everything on the user's device

Kitmul's fundamental technical decision is that everything runs on the client. No exceptions whenever possible.

The stack is straightforward: if native JavaScript is enough, use JavaScript. If the operation is intensive (audio processing, heavy image manipulation, track separation) compile to WebAssembly. For performance-critical parts, Rust compiled to WASM.

For example, here's how we merge PDFs entirely in the browser:

import { PDFDocument } from 'pdf-lib';

export async function mergePDFs(files) {
  const merged = await PDFDocument.create();

  for (const file of files) {
    const bytes = await file.arrayBuffer();
    const pdf = await PDFDocument.load(bytes);
    const pages = await merged.copyPages(pdf, pdf.getPageIndices());
    pages.forEach((page) => merged.addPage(page));
  }

  return merged.save(); // Returns Uint8Array, never leaves the browser
}

Zero network calls. The file goes from File API → pdf-lib → download.

Why Rust + WASM: the prime number checker

For heavier computation, JavaScript hits a wall. A real example from Kitmul: our Prime Number Checker. JavaScript can check primality for small numbers, but try testing a number with more than 1,200 digits and the browser will choke. BigInt simply can't handle it.

Here's the JavaScript approach, which works fine for numbers up to ~13 digits:

function isPrime(n) {
  if (n <= 1) return false;
  if (n <= 3) return true;
  if (n % 2 === 0 || n % 3 === 0) return false;
  for (let i = 5; i * i <= n; i += 6) {
    if (n % i === 0 || n % (i + 2) === 0) return false;
  }
  return true;
}

// Works for small numbers, but for a 1200+ digit number?
// BigInt arithmetic becomes so slow the tab freezes.

The solution: we compiled a Rust crate that uses num-bigint with a Miller-Rabin primality test to WASM. The Rust side receives the number as a string (because it can be thousands of digits long) and returns whether it's prime:

use num_bigint::BigUint;
use num_traits::{One, Zero};

#[no_mangle]
pub extern "C" fn is_number_prime(ptr: *const u8, len: usize) -> i32 {
    let bytes = unsafe { std::slice::from_raw_parts(ptr, len) };
    let num_str = std::str::from_utf8(bytes).unwrap_or("0");
    let n = num_str.parse::<BigUint>().unwrap_or_else(|_| BigUint::zero());

    if n <= BigUint::one() { return 0; }

    if miller_rabin(&n) { 1 } else { 0 }
}

Then from JavaScript, we load the WASM module and pass the number as bytes:

// Load WASM and check a 1200+ digit number
const { instance } = await WebAssembly.instantiate(wasmBuffer, {});
const exports = instance.exports;

const numStr = "12345..."; // 1200+ digit number
const bytes = new TextEncoder().encode(numStr);
const ptr = exports.wasm_alloc(bytes.length);
new Uint8Array(exports.memory.buffer).set(bytes, ptr);

const result = exports.is_number_prime(ptr, bytes.length);
exports.wasm_dealloc(ptr, bytes.length);
// result: 1 = prime, 0 = not prime

JavaScript with BigInt can't handle numbers above ~1,200 digits. The Rust WASM module handles numbers of any size; we've tested it with numbers over 3,000 digits. Same browser, same device, but Rust's num-bigint crate uses optimized limb arithmetic that JavaScript simply can't match.

The implications of this architecture:

Near-zero infrastructure cost: no servers processing files.
Real privacy, not promised: data literally never leaves the device.
Scalability without provisioning: each user brings their own compute.

The thesis: AI agents shouldn't control your apps. They should BE the app.

This is where I think the current industry is getting it wrong.

OpenAI with Operator, Anthropic with Computer Use, Google with Project Mariner: the big players are all building AI agents that control existing applications. They take screenshots of your screen, move your mouse, click buttons, fill forms. Essentially they're building really sophisticated RPA bots.

I think this approach is fundamentally flawed. Here's why:

1. You're building on top of interfaces designed for humans, not machines. When an AI agent navigates a website, it's fighting against dropdowns, modals, cookie banners, CAPTCHAs, and layout changes. Every website redesign can break the agent. This is fragile by design.

2. You still depend on third-party services. The AI agent might be smart, but it's still uploading your PDF to iLovePDF, still sending your images to Canva's servers, still giving your data to someone else. The privacy problem doesn't go away just because a robot is clicking the buttons.

3. It's slow. Screenshot → analyze → click → wait for page load → screenshot again. This loop takes seconds per action. Meanwhile, a direct function call takes milliseconds.

The alternative: what I'm building with Kitmul is radically different.

The AI agent doesn't control apps. The AI agent IS the app.

Instead of navigating to SmallPDF to merge files, the agent calls mergePDFs() directly. Instead of opening Canva to remove a background, it runs a WASM model in-browser. No screenshots, no mouse movements, no waiting for page loads. Direct function calls, direct results.

// The "screenshot and click" approach (Operator, Computer Use):
// 1. Navigate to smallpdf.com          (~3s)
// 2. Find upload button                 (~1s)
// 3. Upload file                        (~5s)
// 4. Wait for processing                (~3s)
// 5. Click download                     (~2s)
// 6. Wait for download                  (~3s)
// Total: ~17 seconds + your files on someone else's server

// The Kitmul approach:
const merged = await mergePDFs(files);  // ~300ms, never leaves your device

This is a 30-50x speed difference, with the added benefit that your files never touch a remote server.

Orchestration in practice

Kitmul already has a built-in chat where the AI acts as an orchestrator. The user describes what they want in natural language. The AI selects tools from the catalog, executes them in sequence, and chains outputs.

A concrete example: you upload an audio file. The AI separates it into tracks using a WASM source separation model. Then applies noise reduction to the vocal track. Converts the result to MP3. All chained, all in the browser, all without the file leaving your device.

The orchestrator uses a tool registry that maps natural language intents to concrete functions:

// Simplified version of how the orchestrator works
const toolRegistry = {
  'merge_pdf': { fn: mergePDFs, input: 'file[]', output: 'file' },
  'split_audio': { fn: splitAudio, input: 'file', output: 'file[]' },
  'compress_image': { fn: compressImage, input: 'file', output: 'file' },
  // ... 300+ more tools
};

// The AI decides the execution plan, then runs it:
const plan = await ai.plan("Split this song and remove noise from vocals");
// → [{ tool: 'split_audio', input: userFile },
//    { tool: 'noise_reduction', input: '$prev.vocals' },
//    { tool: 'convert_to_mp3', input: '$prev' }]

for (const step of plan) {
  step.result = await toolRegistry[step.tool].fn(resolve(step.input));
}

It's not a concept. It works today.

The part that gets really interesting: self-building tools

Here's where Kitmul diverges from everything else.

With 300+ tools, we cover a lot of use cases. But when a user asks for something we don't have, instead of saying "sorry, we can't do that," the system should be able to create the tool on the fly with AI; and then, critically, have a human-in-the-loop verify that the generated tool actually works correctly before it becomes part of the permanent catalog.

Think about it:

User asks: "I need a tool that converts MIDI files to sheet music."
The AI generates the tool: a client-side implementation using WebAssembly.
A human reviewer (me, or eventually a community of contributors) verifies the tool works, handles edge cases, and meets Kitmul's quality standards.
Once approved, the tool is permanently added to the catalog.
The next user who asks for the same thing gets the verified, production-quality tool instantly.

The system literally builds itself based on what users need. Every unanswered request becomes a signal. Every verified tool makes the platform more capable. It's a flywheel where AI generates, humans verify, and the catalog grows organically.

This is fundamentally different from the "generate code at runtime" approach that some AI companies are pursuing. Generated code running without verification is a liability: it might have bugs, security holes, or simply not work for edge cases. The human-in-the-loop step is not a limitation; it's a feature. It ensures every tool in the catalog is production-quality.

See it in action

Here's a quick demo of how Kitmul works:

The goal: 4,000 tools in a year

I have a backlog with over 4,000 tool ideas. It's not an arbitrary number: it's the actual size of the list after analyzing what people search for and what currently requires uploading files to a server or paying a subscription.

With Claude Code 20x and the self-building approach, this is not a moonshot. Many tools are built in a single session. The more complex ones (those requiring custom WASM or signal processing) take longer, but they're still orders of magnitude faster than without AI.

What's next

The orchestration works for simple flows, but complex workflows with branching, conditionals, and feedback loops still need work. The self-building pipeline is being designed right now.

The long-term vision: a system where any task you do today with fragmented software (uploading files here, paying a subscription there, installing an app for something else) can be resolved within a single interface, executed locally, orchestrated by AI, and constantly expanding based on what users actually need.

The question I want to leave you with: Do we really need AI agents that puppet our existing apps? Or do we need to rethink what the app itself should be?

I think the answer is the latter. And I think the browser is the right runtime to prove it.

I Built a 100% Private, On-Device AI Audio Stem Splitter (No Servers!)

Aral Roca — Tue, 17 Mar 2026 19:02:18 +0000

Most "AI" tools these days are just wrappers around an API. You upload your
file, wait for a server to process it, and hope your data isn't being used to
train the next big model.

When I decided to add an Audio Stem Splitter to
Kitmul, I had one
non-negotiable rule: Zero server uploads.

The result is a tool that can take any song and split it into Vocals, Drums,
Bass, and Instruments entirely within your browser.

The Problem with Traditional Audio Splitting

If you've ever used tools like PhonicMind or LALAL.AI, you know the drill:

Upload your MP3.
Wait in a queue.
Pay for "credits" or high-quality downloads.
Your file sits on someone else's server.

For musicians, producers, or just karaoke fans, this is slow and
privacy-invasive. I wanted to see if we could bring the power of models like
Demucs
directly to the user's hardware using WebAssembly and Web Workers.

How it Works: AI in the Browser

The magic happens thanks to a few modern web technologies:

WebAssembly (WASM): We run the heavy lifting—the actual neural network inference—using a specialized AI model optimized for the browser.
Web Workers: Splitting audio is CPU-intensive. By offloading the process to a background thread, the UI remains snappy. You can still navigate the site while the "AI chef" is in the kitchen.
Local Processing: When you drag a file into the splitter, the browser reads the raw bytes, processes them locally, and generates the stems. Your audio never leaves your computer.

Why Use an On-Device Splitter?

Privacy First: Your unfinished demos or private recordings stay private.
No Subscriptions: Since it uses your CPU/GPU, there's no server cost for me to pass on to you. It's free.
High Fidelity: We export the results in high-quality WAV format, not compressed MP3s.
No Limits: Split as many songs as you want without worrying about "minutes remaining."

Beyond Karaoke: Practical Use Cases

While removing vocals for karaoke is the most obvious use, I've seen some great
creative ways to use it:

Sampling for Producers: Isolate a clean drum break or a bassline for your own tracks.
Instrument Practice: Remove the guitar track so you can be the lead guitarist for your favorite band.
Mixing Reference: Listen only to the vocal harmonies to study how a professional track was layered.

Try it Out

The Audio Stem Splitter is now live on Kitmul. It's best used on desktop
(Chrome or Edge handle the AI models particularly well).

👉 Try the Audio Stem Splitter on Kitmul

I'm constantly adding more tools to Kitmul (we're at over 150 now!), but this
one feels special because it pushes the boundaries of what the browser can do
without relying on the cloud.

If you are a developer interested in on-device AI or a musician looking for a
private way to split tracks, let me know what you think in the comments!

Don't Fall Into the CDN Trap! 🪤

Aral Roca — Thu, 19 Dec 2024 00:43:24 +0000

This blog post’ll explore how Brisa's HTML Streaming feature can help you avoid the CDN trap and improve your app’s performance. We’ll also compare Brisa with other popular tools like HTMX and React to highlight the benefits of using Brisa for server-side rendering.

Why HTML Streaming is Important

HTML Streaming is a powerful technique that allows you to send HTML incrementally from the server to the client, improving performance and reducing latency. With Brisa, you can stream HTML content directly to the client, not only for the initial render but also for subsequent updates and server actions.

If your app needs just 1 request to fetch server data, you’re stuck in the CDN trap. Add more requests, and you’re in a cascading nightmare. CDNs are fine for assets—nothing more. Your website is an asset only if it doesn’t rely on server data.

Rendering the Components on the server with streaming is the best way to avoid the CDN trap. Brisa not only uses HTML Streaming for the first render but also as a response to Server Actions after rendering a component on the server.

You may wonder, but many components are static and I don't want to render them always on the server. Well, Brisa allows you to pre-render them at build-time with just one attribute, so that only dynamic components are rendered on the server.

<StaticComponent renderOn="build" />

Do dynamic imports solve the CDN trap?

No. Using HTML Streaming on Server Actions have exactly the same benefits as using it on the first render.

Imagine managing the opening and rendering of a dialog with a dynamic import:

Only if the dialog needs server data, we are in the same problem.

Code example: Quiz with HTML Streaming

As an example, we are going to make a quiz of questions in Brisa using HTML Streaming through Server Actions, and you will see how easy it is to do it, apart from its benefits.

In order to make the quiz, we are going to create a component that will be rendered on the server and will be responsible for managing the questions and answers. The questions will be sent to the client through HTML Streaming, and the answers will be processed on the server.

import { renderComponent } from 'brisa/server';

// Define the type for questions to ensure type safety.
type Question = {
  answer: string; // The correct answer for the question ('yes' or 'no').
  question: string; // The text of the question to be displayed.
  id: number; // Unique identifier for each question.
};

// All this code is server-code. It ensures that the user cannot infer the correct
// answers by inspecting the page source or the network.
const questions: Question[] = [
  { id: 1, answer: 'no', question: 'Is the Earth flat? ' },
  { id: 2, answer: 'yes', question: 'Is the Earth round? ' },
  { id: 3, answer: 'no', question: 'Can giraffes lay eggs?' },
  { id: 4, answer: 'yes', question: 'Can penguins fly?' },
  { id: 5, answer: 'no', question: 'Can a cow jump over the moon?' },
  { id: 6, answer: 'yes', question: 'Is water wet by definition?' },
  { id: 7, answer: 'yes', question: 'Is the sky blue?' },
  { id: 8, answer: 'yes', question: 'Do fish sleep with their eyes open?' },
  { id: 9, answer: 'no', question: 'Can a cow fly?' },
];

// Function to open the modal with a random question.
function openModal() {
  const randomIndex = Math.floor(Math.random() * questions.length);

  renderComponent({
    element: <Modal {...questions[randomIndex]} />,
    target: '#content', // Specify the DOM element where the modal should render.
  });
}

// Function to process the user’s answer and display the result.
function processAnswer(e: ClickEvent, value = 'yes') {
  // We have the event on the server, so we can access the target and the dataset!
  const id = (e.target as HTMLButtonElement).dataset.id;

  // Check if the user's answer matches the correct answer.
  const isCorrect = questions.find((q) => q.id === Number(id)).answer === value;

  // Render feedback based on the correctness of the answer.
  renderComponent({
    element: isCorrect ? (
      <p id="content" class="correct">
        Correct!
      </p>
    ) : (
      <p id="content" class="incorrect">
        Incorrect!
      </p>
    ),
    target: 'dialog',
  });
}

// Main homepage component.
export default function Homepage() {
  return (
    <>
      <div class="hero">
        <h1>
          <span class="h1_addition">Welcome to </span>Brisa
        </h1>
        <p class="edit-note">✏️ SSR Modal example</p>
        <code>src/pages/index.tsx</code>
      </div>

      <form onSubmit={openModal}>
        <button>Open modal</button>
        <div id="content" /> {/* Container for rendering dynamic content */}
      </form>
    </>
  );
}

// Modal component to display a question and answer options.
function Modal({ question, answer, id }: Question) {
  return (
    <dialog open>
      <form method="dialog">
        <h2>{question}</h2>
        {/* Button for "Yes" answer */}
        <button data-id={id} onClick={(e) => processAnswer(e, 'yes')}>
          Yes
        </button>
        {/* Button for "No" answer */}
        <button data-id={id} onClick={(e) => processAnswer(e, 'no')}>
          No
        </button>
      </form>
    </dialog>
  );
}

🔗 Code example here

One of the advantages of using server-side logic for rendering and controlling a dialog is the enhanced security and simplicity it offers. With Brisa, you can offload both the rendering and logic processing to the server, ensuring that critical data remains inaccessible to the client and maintaining a clean separation of concerns.

In this example, a modal dialog is used to present random quiz questions to the user. The logic for selecting the question, validating the answer, and rendering the UI is entirely managed on the server. This approach eliminates the risk of exposing sensitive data, such as the correct answer, to the client.

Normally we load modals on the client with a dynamic import to avoid loading them at the start, requesting the CDN, and then if the modal needs server data, once rendered it has to make a cascade of calls to the server. With Brisa, we can load the modal directly from the server, avoiding the need to make additional calls and keeping the modal logic on the server.

With this approach, we get the following benefits:

Enhanced Security: Sensitive data, such as correct answers, remain on the server, preventing unauthorized access or manipulation.
Improve UX: By rendering the modal directly on the server with streaming, we can avoid additional network requests and improve the user experience thanks to streaming.
Simplified State Management: By centralizing logic on the server, the client remains lightweight and focuses only on rendering and user interaction.
Reduced Client-Side Complexity and Size: No need for complex state management libraries or additional client-side logic to handle the modal. The server manages everything and you can do an SPA without increasing the client bundle size.

SPA without Client-Side JavaScript?

Yes, you can! Although we support writing Web Components with JSX and Signals with very little code (3kb), we want you to use them only for pure client interactions. Our goal is to make it possible to create SPAs without the need for client-side JavaScript.

Imagine that your e-commerce site, instead of having a cascade of requests and a lot of client-side JavaScript code that harms performance and user experience, becomes a SPA without client-side JavaScript, since most interactions that require server data can be managed directly on the server.

Rendering on the server is very cheap and fast (~10ms)!

Cheap and fast

Control stream chunks with Async Generators

Brisa allows you to control the stream chunks with Async Generators. This way, you can stream the HTML in chunks and control the flow of the stream.

import { Database } from "bun:sqlite";
import { renderComponent } from "brisa/server";

export default function LoadMovies() {
  function streamMovies() {
    renderComponent({
      element: <MovieItems />,
      target: "ul",
      placement: "append",
    });
  }

  return (
    <>
      <button id="movies" onClick={streamMovies}>
        Click here to stream movies from a Server Action
      </button>
      <ul />
    </>
  )
}

const db = new Database("db.sqlite");

async function* MovieItems() {
  for (const movie of db.query("SELECT title, year FROM movies")) {
    yield (
      <li>
        {movie.title} ({movie.year})
      </li>
    );
  }
}

In this example, we are using an Async Generator to stream the movies from a SQLite database. Any yield is a chunk of the stream that will be sent to the client.

🔗 Code example Streaming HTML from SQLite

What is `renderComponent`?

Brisa’s renderComponent allows developers to:

Re-render components dynamically on server actions.
Render specific components to specific locations in the DOM.
Choose how and where to place them (e.g., replace, append, prepend, after & before).
Enhance transitions with the View Transition API.
Stream JSX components incrementally from the server.

Here’s a quick look:

export default function MyComponent({ text = "foo" }: { text: string }) {
  function handleClick() {
    // Re-render the same component
    renderComponent();

    // Re-render with new props
    renderComponent({ element: <MyComponent text="bar" /> });

    // Render another Component to a specific location
    renderComponent({
      element: <AnotherComponent />,
      target: "#target-id",
      placement: "append",
      withTransition: true, // Enhance transitions with the View Transition API
    });
  }

  return (
    <div>
      <button onClick={handleClick}>{text}</button>
    </div>
  );
}

All this code is server-side code. In Brisa, all the events from server components are Server Actions.

Why is This a Game-Changer?

Brisa’s approach to server actions is inspired by React’s model and HTMX concepts but is designed to be simpler and inherently safer.

Brisa vs. HTMX

HTMX allows developers to dynamically update portions of the DOM via server responses. But it lacks:

Component-level granularity: HTMX relies on server-generated HTML partials without the concept of components.
Streaming support: HTMX does not natively support streaming updates to the client.
Bundle size: HTMX is a 14KB library, while Brisa is only 2KB.

With renderComponent, you get:

Component reuse: Brisa components are re-rendered seamlessly, leveraging JSX and React-like composition.
Dynamic placement: Update or append components where in the DOM.
Streaming support: Send and render data incrementally using server-side streams.

Brisa vs. React

In React, implementing server actions often involves using "use server" and "use client" directives. This dual model introduces the potential for human error and can unintentionally expose components to the client.

Key differentiators include:

Streaming HTML support: React communicates between the server and client by sending JavaScript, which can add significant overhead. Conversely, Brisa streams HTML directly to the client, reducing complexity and improving performance.
Signals - fine-grained reactivity: Brisa’s client-side signals automatically react to server-side changes by updating Web Components, avoiding the need for a complete re-render.
Bundle size: React-DOM v.19 weighs around 200KB, while Brisa maintains an ultra-lightweight footprint of just 2KB.
Selective updates: Brisa allows you to update specific components on the server, reducing the need for full-page reloads.

Conclusion

Brisa’s HTML Streaming avoids the CDN trap and improves your app’s performance. You can stream HTML content directly to the client for the initial render, subsequent updates, and Server Actions. This approach improves security, and user experience, and simplifies state management, making it an ideal choice for server-side rendering.

If you’re looking to build fast, secure, and scalable web applications, give Brisa a try today!

Support Us: Visit our shop for Brisa swag! 🛍️

Brisa 0.2.0 Release Notes

Aral Roca — Sun, 08 Dec 2024 22:03:06 +0000

We’re thrilled to announce Brisa 0.2.0, a minor milestone in Brisa's journey. This release introduces official support for Deno, alongside multiple performance optimizations and important fixes. Let's dive into the highlights!

🦕 Deno Support

Brisa now officially supports Deno as an output target. Here’s what’s new:

Output Configuration: Use output: 'deno' in your brisa.config.ts to build for Deno.
Deno-Specific Configurations: Brisa leverages deno.json for custom setups, automatically placed in your build directory.
CLI Integration: Running brisa start detects the Deno output and uses Deno.serve for serving your application.

Brisa every time is more JS runtime agnostic, and we are excited to see how you will use it with Deno!

🚀 Key Fixes and Improvements

Performance Optimizations: Client builds have been further optimized, enhancing build times and overall performance.

Improved Compatibility:
- Added a polyfill for Promise.try to ensure working in Node.js and Deno.
- Fixed HTTP response issues with uncoded ReadableStream.
- Resolved locale-changing issues in navigation for i18n.
CLI Improvements:
- Fixed brisa start to correctly load brisa.config.ts for all outputs.
- Enhanced build consistency across output types.

🛠️ Recap: Key Features from 0.1.x Releases

Development Tools

PandaCSS Integration (0.1.1): Seamlessly use PandaCSS within Brisa for robust styling options.
Hot Reload Enhancements (0.1.6, 0.1.7): Improved hot-reload for multi-save scenarios, making your development workflows faster and more reliable.
idleTimeout Configuration (0.1.2): Fine-tune connection handling with the idleTimeout property for more predictable server behavior.

Routing & Middleware

Route Rewrite Support (0.1.3): Dynamically rewrite routes with middleware, enabling flexible routing scenarios.
Improved SPA Middleware (0.1.3): Added support for transforming hard redirects into soft redirects in SPA navigation, streamlining client-side transitions.

Server-Side Rendering

SSR Support for Web Components (0.1.5): Extended support for self in Web Components during SSR, enabling advanced interactions with attributes, styles, and events at the server level.

API Utilities

getServer API (0.1.3): Access the Brisa server instance directly to extend its functionality or introspect runtime details.
Streaming HTML from Async Generators (0.1.2): Combine SQLite queries with async generators for streaming HTML content directly to the client, unlocking performance benefits for large datasets.

What's Changed

fix(example): update wc external dep to fix warning – @aralroca in #653
perf: optimize client builds – @aralroca in #643
fix(node): add Promise.try polyfill to fix error with Node – @aralroca in #656
feat: add output: 'deno' – @aralroca in #657
feat: use deno.json and move it inside build – @aralroca in #658
feat(cli): run Deno on brisa start when output is 'deno' – @aralroca in #660
fix(cli): fix brisa start to load correct brisa.config – @aralroca in #662
docs(www): add Deno to the home – @aralroca in #663
fix(build): co-relate details with the correct output – @aralroca in #666
fix(render): fix uncoded ReadableStream in HTTP responses – @aralroca in #668
fix(i18n): fix change locale from navigate – @aralroca in #669
feat(deno): use Deno.serve – @aralroca in #659

Full Changelog: https://github.com/brisa-build/brisa/compare/0.1.7...0.2.0

Visit our shop to get your Brisa swag and show your support!

Forem: Aral Roca

SAP Hybris Impex When None of Us on the Team Can Read It

What Impex is, in one paragraph

Why HMC plus a periodic refresh forces this conversation

The eight tools

Impex Table Editor

Impex to CSV Converter

CSV to Impex Converter

Impex to JSON and JSON to Impex

Impex Validator / Linter

Impex Macro Expander

Impex to SQL (Approximate)

The workflow I'm pushing on my team

What still bites

Why I built this and not something else

Will this actually work? I don't know yet.

I Was Paying Anthropic to Read CSS Class Names

Why HTML is a token disaster

The RAG pipeline case

When you cannot run Python on a server

Seven places this actually helps

What gets lost in the conversion

A concrete workflow

The broader point

Try it

WSJF, Cost of Delay and Why Your Loudest Stakeholder Keeps Winning the Backlog Argument

The trick nobody tells you about prioritization

Cost of Delay is three things, not one

Why relative sizing beats hours every single time

What the tool actually does

When WSJF is the wrong answer

The meeting ritual that actually works

The part that surprised me

AVIF in 2026: The Complete Guide to the Image Format That Beat JPEG, PNG, and WebP

What AVIF actually is

The compression numbers

Why AVIF matters for web performance

AVIF vs WebP vs JPEG vs PNG: when to use each

How to convert images to and from AVIF

Converting TO AVIF (reduce file sizes)

Converting FROM AVIF (for compatibility)

The <picture> element: serving AVIF with fallbacks

CDN and build-tool support

Known limitations

The bottom line

Your Last Coffee Isn’t the Problem; the First Three Are Still in Your System

The exponential decay you're ignoring

Why I built a multi-intake caffeine tracker

The math behind the combined curve

What we learned about his consumption

The developer who also drinks cold brew

Technical details

Practical takeaways

6 Agile Tools I Built Because Jira Dashboards Aren't Enough

Your WIP is lying to you

Six dimensions, one radar

The bus factor spreadsheet nobody maintains

Stop forming teams by accident

"How much work is coming?" is a forecasting problem

Capacity planning that accounts for reality

All of this runs in your browser

How to Detect AI-Generated Content Using Perplexity and Burstiness

Why perplexity and burstiness alone don't cut it

The ten metrics that matter

The real trick: multiplicative signal scoring

URL mode and content extraction

Where it falls short

Compared to GPTZero, Originality.ai, Copyleaks

Try it

Resting heart rate 68 to 56: what changed in my dev work

Some context about me

The parkour connection

Hack #1: Intermittent hypoxia

What it actually is

What changed for me

The science (briefly)

Hack #2: The Pomodoro technique, done right

Why most people do it wrong

The parkour parallel

How I actually use it

The `<picture>` element: serving AVIF with fallbacks

What is `renderComponent`?