DEV Community: Aral Roca

I Stopped Installing Qiskit to Understand Hadamard Gates

Aral Roca — Wed, 22 Apr 2026 18:53:44 +0000

I spent six years working adjacent to quantum computing research. Not building qubits; building the classical software that talks to the hardware. The thing that surprised me most wasn't the physics. It was how bad the tooling was for anyone trying to learn.

The education gap is the real bottleneck

The hardware is advancing. IBM's 1,121-qubit Condor processor exists. Google's Willow chip hit a below-threshold error correction milestone in late 2024. But ask a CS undergrad to explain what a Hadamard gate actually does to a qubit's state vector, and you'll get a blank stare followed by a memorized sentence from a textbook.

The problem isn't intelligence. The problem is that every learning path for quantum circuits funnels you into one of two dead ends:

1. Pen-and-paper linear algebra. You compute tensor products by hand. You multiply 8x8 matrices. By the time you've verified that your CNOT gate works correctly, you've spent 40 minutes and lost all intuition for what the circuit does.

2. Full SDK installations. Qiskit, Cirq, PennyLane. These are serious tools for serious work. They're also 200MB+ installs with Python dependency chains, Jupyter notebooks, and a learning curve that assumes you already understand what you're trying to learn. That's backwards.

There's a gap between "read the textbook" and "install Qiskit." That gap is where most people give up.

What I actually wanted

A textarea where I type H 0 and immediately see the state vector change. No install. No signup. No notebook server. Just a browser tab. And if I don't remember the syntax, a row of clickable buttons that writes the gate for me.

That's what the Quantum Circuit Simulator is. Up to 16 qubits, nine gates (H, X, Y, Z, S, T, CX, SWAP, CCX), a gate toolbar for quick insertion, real-time probability bars, complex amplitudes, and an interactive 3D Bloch sphere that shows each qubit's state on the unit sphere.

The syntax is one gate per line:

H 0
CX 0 1

That's a Bell State. Two lines. The output shows |00> at 50.00% and |11> at 50.00%, with amplitudes of 0.707 + 0.000i each. If you've read Nielsen & Chuang, you recognize this as (1/sqrt(2))(|00> + |11>); the maximally entangled two-qubit state that Einstein called "spooky action at a distance."

You didn't need to install anything to see that.

Why browser-based matters for quantum education

There's a pedagogical argument here that goes beyond convenience. When the feedback loop between "write circuit" and "see result" drops to zero seconds, something changes in how you learn.

You start experimenting. You add a Z gate after the Hadamard and watch the probabilities shift. You swap the control and target qubits on the CNOT and see what breaks. You build a GHZ state with three qubits:

H 0
CX 0 1
CX 1 2

And you see |000> at 50% and |111> at 50%; all three qubits entangled, no intermediate states. The 0.707 amplitude on both basis states confirms the math. You didn't need to set up a virtual environment to get there.

This is how people actually learn. Not by reading about superposition in a PDF; by breaking circuits and watching what happens.

The technical implementation

The simulator runs entirely in JavaScript. No backend. No WebAssembly. No WASM-compiled Qiskit. Just matrix multiplication on complex numbers in the browser.

The state vector starts as |000...0> (all qubits in the |0> state). Each gate applies a unitary transformation:

Hadamard (H): Creates superposition. Transforms |0> into (|0> + |1>)/sqrt(2).
Pauli-X: Quantum NOT gate. Flips |0> to |1> and vice versa.
Pauli-Y: Rotation around the Y-axis with a phase factor of i.
Pauli-Z: Phase flip. Leaves |0> unchanged but maps |1> to -|1>.
CX (CNOT): Controlled-NOT. Flips the target qubit if and only if the control qubit is |1>. This is the gate that creates entanglement.
Phase (S): Rotates by π/2 around the Z-axis. Maps |1⟩ to i|1⟩. The square root of Z.
T (π/8 gate): Rotates by π/4 around the Z-axis. Key building block for universal quantum computation. The square root of S.
SWAP: Exchanges the states of two qubits. Syntax: SWAP q1 q2.
CCX (Toffoli): Controlled-controlled-NOT. Flips the target qubit only when both control qubits are |1⟩. Universal for classical reversible computation. Syntax: CCX c1 c2 target.

For a 3-qubit system, the state vector has 2^3 = 8 complex amplitudes. The simulator tracks all of them and displays both the raw amplitudes and the measurement probabilities (|amplitude|^2) in real time.

The circuit state is encoded into the URL. Every change you make; every gate you add, every qubit count adjustment; updates the URL parameters automatically. Copy the URL, send it to a colleague, and they see your exact circuit. No accounts. No save buttons. No cloud storage. The URL is the save file.

The gate toolbar and Bloch sphere

Two things kept bugging me about text-only circuit input. First, beginners don't know the syntax. Second, numbers alone don't build geometric intuition about qubit states.

The gate toolbar sits above the textarea: nine buttons grouped by type (single-qubit: H, X, Y, Z, S, T; two-qubit: CX, SWAP; three-qubit: CCX). Click a button and the gate line gets appended to your circuit. You can still type manually if you prefer, but the buttons remove the "what was the syntax for a Toffoli gate again?" friction.

The Bloch sphere renders below the results panel. It computes the reduced density matrix for each qubit via partial trace, then extracts the Bloch coordinates (x = 2Re(rho01), y = 2Im(rho01), z = rho00 - rho11). For a single qubit in |0>, the vector points to the north pole. Apply a Hadamard and it moves to the equator. Create a Bell state and both vectors collapse to the origin, because the reduced state of each qubit in a maximally entangled pair is the maximally mixed state. You can drag the sphere to rotate it, which helps when multiple qubit vectors overlap.

For circuits with 1 to 4 qubits, all vectors show on the same sphere with different colors. Beyond 4 qubits, a dropdown lets you pick which qubit to visualize.

Comparing to the alternatives

Feature	Kitmul Simulator	Qiskit	Cirq	IBM Quantum Composer
Setup time	0 seconds	10-30 min	10-30 min	Account required
Install size	0 MB	~500 MB	~300 MB	Cloud-based
Max qubits	16	30+	30+	127 (hardware)
Sharing	URL copy	Export notebook	Export script	Account link
Privacy	100% local	Local	Local	IBM cloud
Cost	Free	Free	Free	Free tier limited

The trade-off is obvious. The Kitmul simulator handles up to 16 qubits. Qiskit handles 30. If you're implementing Shor's algorithm or running variational quantum eigensolvers, you need the full SDK. If you're trying to understand what a Hadamard gate does before committing to a 500MB install, you don't.

Eight circuits worth trying

Here are eight circuits you can paste directly into the simulator (or build them by clicking the gate buttons):

1. Superposition on a single qubit (set qubits to 1):

H 0

Result: |0> and |1> each at 50%. This is the quantum coin flip.

2. Bell State (set qubits to 2):

H 0
CX 0 1

Result: |00> and |11> each at 50%. Maximal entanglement.

3. GHZ State (set qubits to 3):

H 0
CX 0 1
CX 1 2

Result: |000> and |111> each at 50%. Three-qubit entanglement.

4. Phase kickback (set qubits to 2):

X 1
H 0
CX 0 1
H 0

Result: The Hadamard-CNOT-Hadamard sandwich. Watch how the phase of the target qubit kicks back to the control. This is the core mechanism behind Deutsch's algorithm.

5. Quantum NOT with Hadamard (set qubits to 1):

H 0
Z 0
H 0

Result: |1> at 100%. The H-Z-H sequence is equivalent to a Pauli-X gate. This identity (HZH = X) shows up everywhere in quantum error correction.

6. Phase gate demo (set qubits to 1):

X 0
S 0

Result: |1> at 100%, but the amplitude is now 0.000 + 1.000i. The S gate adds a π/2 phase rotation. Compare with Z (which maps |1⟩ to -|1⟩).

7. Toffoli gate — quantum AND (set qubits to 3):

X 0
X 1
CCX 0 1 2

Result: |111> at 100%. The Toffoli gate flips qubit 2 only when both qubits 0 and 1 are |1>. This is the reversible equivalent of a classical AND gate.

8. SWAP circuit (set qubits to 2):

X 0
SWAP 0 1

Result: |01> at 100%. The state that was on qubit 0 has been transferred to qubit 1.

Who this is for

CS students taking their first quantum computing course. The simulator covers exactly what shows up in chapters 1-4 of Nielsen & Chuang; single-qubit gates, multi-qubit gates, entanglement, and measurement probabilities. The gate toolbar means you don't need to memorize syntax on day one, and the Bloch sphere gives you the geometric picture that textbooks struggle to convey in static figures.

Software engineers curious about quantum computing but not ready to commit to a full SDK installation. You can verify your intuition in 30 seconds and then decide if it's worth going deeper with Qiskit or Cirq.

Physics students who understand the math but want to quickly prototype small circuits without booting up Jupyter.

Teachers who need a zero-friction demo tool for lectures. Share a URL; students see the circuit on their own devices. No lab setup. No installation instructions. No "my Python version is different" support tickets.

Privacy

The entire simulation runs in your browser's JavaScript engine. No circuit data is transmitted to any server. No analytics track which gates you use. The URL encoding uses base64, which is decoded client-side. If you're working with proprietary circuit designs (up to 16 qubits), nothing leaves your device.

If you want to explore other tools in the same category, the Visualizers & Logic Tools collection includes graph visualizers, truth tables, and logic gate simulators that pair well with quantum circuit work. For tracking your study sessions, the Pomodoro Timer with built-in focus music works surprisingly well for problem sets.

The point

Quantum computing doesn't need to be gatekept by tooling complexity. The fundamental operations; Hadamard, Pauli gates, CNOT; are matrix multiplications. A browser can do matrix multiplication. So a browser can simulate small quantum circuits. And with a clickable gate toolbar and an interactive Bloch sphere, the barrier to entry drops even further.

The Quantum Circuit Simulator won't replace Qiskit for research. It replaces the 30 minutes between "I wonder what happens if I apply H then CX" and actually seeing the answer. For learning, that's everything.

The Quantum Circuit Simulator is free, private, and runs entirely in your browser. No signup, no install, no data leaves your device. Part of the Visualizers & Logic Tools collection on Kitmul. Photos by Alex Shuper and Dynamic Wang on Unsplash.

I Tracked My To-Do List for 30 Days. 73% of My 'Urgent' Work Was Someone Else's Emergency.

Aral Roca — Tue, 21 Apr 2026 19:22:47 +0000

I tracked every task I touched for 30 days. Not in a project management tool; in a spreadsheet with three columns: task, time spent, and whether it actually mattered a week later.

The results were embarrassing. 73% of the tasks I labeled "urgent" on Monday were irrelevant by Friday. Most of them were other people's priorities that I adopted because they arrived with exclamation marks in the subject line. The remaining 27%; the things that actually moved my projects forward; had been sitting in my backlog for weeks, quietly aging while I answered Teams threads.

That spreadsheet is why I stopped using to-do lists and started using the Eisenhower Matrix. Not because I read a productivity book. Because the data made it impossible to keep pretending that busy equals productive.

The urgent-important confusion

Most people use the words "urgent" and "important" interchangeably. They're not. Dwight Eisenhower understood this distinction better than anyone in the 20th century. The man commanded D-Day, served as NATO's first Supreme Commander, and ran the United States for eight years. His productivity wasn't a lifestyle hack; it was a survival requirement.

His insight was simple: urgent means it demands attention now. Important means it contributes to your long-term goals. These two axes are independent. A task can be both, either, or neither.

The problem is that urgency hijacks your attention. A ringing phone feels more important than a strategic plan because your brain evolved to respond to immediate stimuli. Daniel Kahneman calls this System 1 thinking; fast, automatic, and terrible at prioritization. Every time you react to an urgent-but-unimportant task, you're letting your amygdala run your calendar.

The four quadrants

The Eisenhower Matrix sorts every task into one of four quadrants:

Q1: Urgent + Important (Do First)
Deadlines, crises, client emergencies. A production server is down. A contract expires tomorrow. These need immediate action and actually matter. The trap: if Q1 is always full, you're not prioritizing; you're firefighting. That means your Q2 is neglected.

Q2: Not Urgent + Important (Schedule)
Strategic planning. Skill development. Relationship building. Exercise. Writing documentation. These tasks never scream at you, which is exactly why most people ignore them until they become Q1 crises. Stephen Covey argued that Q2 is where your career lives. He was right.

Q3: Urgent + Not Important (Delegate)
Most meetings. Most emails. Someone else's deadline that landed in your inbox. These feel urgent because another human being is waiting, but they don't move your goals forward. Delegate them, batch them, or set boundaries. If you can't delegate, timebox them aggressively; 15 minutes for email twice a day, not 15 checks per hour.

Q4: Not Urgent + Not Important (Eliminate)
Excessive social media scrolling. Unnecessary meetings where you're CC'd "just in case." Reorganizing your desktop icons for the third time this week. Delete these from your day. They produce nothing and they consume the time you need for Q2 work.

Why Q2 is where your career actually lives

Here's the pattern I noticed in my 30-day audit. Every task that moved my career forward; shipping a feature, learning a new technology, writing a blog post, having a meaningful 1-on-1; was Q2. None of them were urgent when I started them. All of them were important.

The tasks that consumed most of my time; answering Teams messages, attending status meetings, reviewing documents I wasn't the decision-maker on; were Q3. Urgent because someone was waiting. Unimportant because my absence wouldn't have changed the outcome.

Research backs this up. A McKinsey study found that executives spend 28% of their day on email and another 19% on "gathering information." That's nearly half the workday on Q3 activities. The executives who outperform spend disproportionately more time on Q2: coaching, strategy, and capability building.

Cal Newport calls Q2 work "deep work" and argues it's the skill that separates people who build things from people who just stay busy. His framing is right: Q2 tasks require focused, uninterrupted blocks. You can't do strategic planning in the 4 minutes between Teams notifications.

The daily ritual I actually use

After the 30-day audit, I settled on a system that takes about 5 minutes each morning:

Brain dump. Write every task floating in your head into the Eisenhower Matrix tool. Don't categorize yet; just get them out.
Sort by asking two questions. For each task: "Does this have a real deadline?" (urgency) and "Will this matter in 30 days?" (importance). Drag it into the right quadrant.
Do Q1 first. These are non-negotiable. But if Q1 has more than 3 items, something is wrong with your planning.
Block time for Q2. I use the Pomodoro Timer for this; 25-minute focus blocks with no Teams, no email, no notifications. Two Pomodoro blocks per morning on Q2 work changed my output more than any other habit.
Batch Q3. Answer emails twice a day. Attend meetings only if you're the decision-maker. For recurring meetings, use the Meeting Cost Calculator once; when your team sees that the weekly sync costs $1,400 per session, they suddenly find ways to make it shorter.
Kill Q4. If it's not urgent and not important, why is it on your list?

The whole process takes 5 minutes. The return is measured in hours.

Eisenhower vs other prioritization frameworks

The matrix isn't the only prioritization tool. Here's when to use what:

Framework	Best for	Weakness
Eisenhower Matrix	Daily/weekly personal task sorting	Doesn't handle dependencies or team capacity
WSJF	Backlog prioritization with 15+ items	Overkill for personal task lists
MoSCoW	Scope negotiations with stakeholders	Binary in/out; no nuance on ordering
RICE	Product feature ranking	Requires reach/impact data you might not have
Kano Model	Understanding customer delight vs basics	Research-heavy; not for daily planning

The Eisenhower Matrix works best for individual contributors and managers sorting their own week. If you need to prioritize a product backlog across a team, reach for WSJF. If you need to negotiate scope with a stakeholder, MoSCoW gives you a shared language. The tools solve different shapes of the same problem.

Common mistakes I see

Putting everything in Q1. If everything is urgent and important, nothing is. You have a boundary problem, not a prioritization problem. Learn to say "I can do this Thursday" to things that arrive as "ASAP."

Ignoring Q2 because nothing is on fire. Q2 tasks become Q1 tasks when you neglect them long enough. That "eventually upgrade the database" task? It's Q2 until the database crashes at 3 AM. Then it's Q1, it's expensive, and you're doing it under pressure.

Treating Q3 as Q1. Just because someone sent you an urgent email doesn't make the task important to your goals. Other people's urgency is not your emergency. The fact that your boss asked for something today doesn't automatically make it important; it makes it urgent. These are different concepts, and confusing them is the single most common time management failure.

Never reviewing the matrix. Priorities change. A task that was Q2 on Monday might be Q1 by Wednesday because a deadline moved. Check your matrix every morning. It takes 2 minutes.

The part nobody tells you about Eisenhower

The popular version of the Eisenhower Matrix comes from Stephen Covey's The 7 Habits of Highly Effective People, published in 1989. But the idea predates the book. Eisenhower himself reportedly said: "What is important is seldom urgent and what is urgent is seldom important." The Eisenhower Presidential Library attributes this to a 1954 speech, though the exact wording is debated.

What's not debated is the principle. Eisenhower managed the complexity of the Cold War, the Interstate Highway System, and the creation of NASA while reportedly maintaining a calm, structured approach to his days. He wasn't productive because he worked more hours. He was productive because he worked on the right things.

The matrix is his most lasting contribution to productivity thinking, and unlike most productivity frameworks from that era, it scales perfectly to modern work. Swap "phone calls" for "Teams messages" and "memos" for "emails"; the quadrants haven't changed in 70 years because the human tendency to confuse urgency with importance hasn't changed either.

Pair it with the right tools

The Eisenhower Matrix handles the "what should I work on?" question. For the rest, pair it with:

Pomodoro Timer for executing Q1 and Q2 work in focused blocks
Standup Timer to keep daily standups short and Q3-efficient
OKR Tracker to define what "important" means at the quarterly level
Sprint Capacity Calculator to prevent overloading Q1 with more than your team can handle
Scrum Poker to size tasks before categorizing them

Try it

The Eisenhower Matrix runs in your browser. Drag tasks between quadrants. No account, no sync service, no data uploaded. Your task list stays on your device.

Start with tomorrow morning. Write down every task. Sort them into four boxes. Then watch how much of your "urgent" work turns out to be noise.

The Eisenhower Matrix tool is free, private, and runs entirely in your browser. Part of the Agile & Project Management toolkit on Kitmul.

I Stopped Using YouTube for Focus Music and My Pomodoro Sessions Got 10x Better

Aral Roca — Mon, 20 Apr 2026 18:58:46 +0000

I run a Pomodoro timer every working day. Not because I read a productivity book. Because I kept losing 25-minute focus blocks to a YouTube ad for meal kits.

The ad problem nobody talks about

The Pomodoro Technique is simple: 25 minutes of focused work, 5-minute break, repeat. Francesco Cirillo designed it in the late 1980s with a tomato-shaped kitchen timer. No WiFi. No subscription. No interruptions from the tool itself.

Fast forward to 2026. Most people who use background music during focus sessions stream it from YouTube, Spotify free tier, or some "lofi beats" livestream. The problem is obvious once you notice it: these platforms interrupt you with ads at random intervals. You're 18 minutes into a deep focus block, your brain has finally loaded the entire problem into working memory, and then a 15-second ad for car insurance yanks you out of flow state.

The irony is brutal. You opened the music to help you focus. The platform's business model requires breaking your focus. These two goals are structurally incompatible unless you pay.

And paying doesn't fully solve it either. Spotify's free tier has ads every few songs. YouTube Premium removes ads but still shows notification popups, recommendation sidebars, and autoplay previews that pull your eyes away from the code editor. The cognitive cost of even seeing a notification is measurable; a University of California, Irvine study found it takes an average of 23 minutes to return to a task after an interruption.

Why I built music into the timer

The Pomodoro Timer on Kitmul ships with three built-in audio tracks:

Lofi Hip-Hop (Work) ; 90 minutes of continuous, uninterrupted audio
Jazz (Read / Rest) ; 90 minutes, zero ads, zero interruptions
Beethoven (Writing) ; 24 minutes of classical, perfect for a single Pomodoro cycle

The tracks are served as static MP3 files from the same domain. No third-party player. No streaming SDK. No analytics pixel tracking what you listen to. Hit play, the audio starts, and it loops seamlessly until you stop the timer.

Each mode (Focus, Short Break, Long Break) can have a different track assigned. I use Lofi for coding, Jazz for reading pull requests during breaks, and Beethoven when I'm writing documentation or blog posts like this one. The volume slider and track selection persist in localStorage, so your setup survives page refreshes.

The audio starts at a random position in the track each session. This matters more than it sounds; if you hear the same opening bars 8 times a day, your brain stops treating it as background and starts listening to it. Random start position keeps it ambient.

My daily setup

I work in 4-Pomodoro blocks. Each block is roughly 2 hours: four 25-minute focus sessions with three 5-minute short breaks and one 15-minute long break at the end.

A typical morning:

Open the Pomodoro Timer in a pinned tab
Set Focus to Lofi Hip-Hop, Short Break to Jazz
Press play
The browser tab title updates to show the countdown (18:42 - Focus | Kitmul)
The favicon turns red during focus, green during breaks
When the timer hits zero, a browser notification fires and the alarm sounds

No context switch. No reaching for my phone. No opening another tab to find music. The entire workflow lives in one browser tab.

The science behind music and focus

Not all background audio helps concentration. Research from the Journal of the Acoustical Society of America shows that music with lyrics competes for the same cognitive resources as reading and writing. Instrumental music, particularly with consistent tempo and low complexity, actually reduces perceived effort on repetitive tasks.

The three tracks in the timer were chosen for this reason:

Lofi: steady beat, no vocals, 70-90 BPM ; sits in the sweet spot for sustained attention
Jazz: slightly higher complexity, good for tasks that need creative lateral thinking
Beethoven: longer melodic phrases, works well for writing where you need sustained chains of thought

This isn't random. A meta-analysis published in Psychology of Music found that self-selected instrumental music at moderate volume improves performance on tasks requiring sustained attention by 5-15% compared to silence. The key word is self-selected; the music works because you chose it, not because an algorithm decided it was time for a crypto ad.

What the Pomodoro Technique actually fixes

The technique isn't really about tomatoes or 25-minute intervals. It's about two things:

1. Time boxing. You commit to working on one thing for a defined period. This kills the "I'll just check Slack" impulse. If the timer is running, you're in focus mode. Period.

2. Forced breaks. Most people skip breaks when they're "in the zone." This feels productive but leads to diminishing returns after 90 minutes. The Pomodoro break forces you to step back, which paradoxically keeps output higher across the full day.

The original technique recommends tracking completed Pomodoros to estimate future work. Our timer doesn't force this; it's a timer, not a project management tool. If you need sprint-level tracking, pair it with the WIP Aging Chart or the Monte Carlo Forecasting tool to get statistical delivery predictions.

Comparing to alternatives

Feature	Kitmul Pomodoro	YouTube + Timer App	Spotify + Timer App
Built-in music	3 curated tracks	Requires separate tab	Requires separate app
Ads during focus	None, ever	Every 5-15 min (free)	Every 3-6 songs (free)
Privacy	No data sent anywhere	Google tracking	Spotify tracking
Works offline	Yes (PWA)	No	Partial
Tab title countdown	Yes	No	No
Favicon changes by mode	Yes	No	No
Cost	Free	Free with ads / $14/mo	Free with ads / $11/mo

The "free with ads" model makes sense for entertainment. It makes zero sense for a productivity tool. An ad during a movie is annoying. An ad during a focus session is destructive. The interruption cost far exceeds the 15 seconds the ad occupies.

Tips for getting the most out of it

Pin the tab. A pinned tab shows only the favicon, which changes color by mode (red = focus, green = short break, blue = long break). You get a visual status indicator without dedicating screen space.

Enable browser notifications. The timer fires a desktop notification when each session ends. This means you can work in your IDE or terminal without watching the timer tab. Request notification permission once and forget about it.

Adjust durations. The default 25/5/15 works for most people, but some tasks need longer focus blocks. The sliders let you set Focus anywhere from 1 to 60 minutes. I use 45-minute blocks for writing and 25-minute blocks for coding.

Use the Countdown Timer for non-Pomodoro time boxing. Not everything fits the Pomodoro structure. If you need a one-off 12-minute timer for a standup or a meeting agenda, the countdown timer is simpler.

Pair with the Caffeine Calculator. If you're stacking Pomodoro blocks through the afternoon, know when to stop drinking coffee. Caffeine has a half-life of about 5 hours; a 3 PM espresso is still half-present at 8 PM.

It runs in your browser. That's the point.

No download. No Electron app eating 400MB of RAM. No account. No sync service. No "upgrade to Pro for custom sounds."

The Pomodoro Timer is a single browser tab that does one thing well: it counts down, plays music, and stays out of your way. Everything runs client-side. Your timer settings, music preferences, and volume level stay in localStorage on your device.

If you're currently using YouTube or Spotify as your focus music source, try switching to built-in audio for one day. Count how many times you get interrupted. The number will probably be zero. That's the point.

The Pomodoro Timer is free, private, and works offline as a PWA. No signup, no ads, no data leaves your browser. Part of the Agile & Project Management toolkit on Kitmul.

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.

DEV Community: Aral Roca

I Stopped Installing Qiskit to Understand Hadamard Gates

The education gap is the real bottleneck

What I actually wanted

Why browser-based matters for quantum education

The technical implementation

The gate toolbar and Bloch sphere

Comparing to the alternatives

Eight circuits worth trying

Who this is for

Privacy

The point

I Tracked My To-Do List for 30 Days. 73% of My 'Urgent' Work Was Someone Else's Emergency.

The urgent-important confusion

The four quadrants

Why Q2 is where your career actually lives

The daily ritual I actually use

Eisenhower vs other prioritization frameworks

Common mistakes I see

The part nobody tells you about Eisenhower

Pair it with the right tools

Try it

I Stopped Using YouTube for Focus Music and My Pomodoro Sessions Got 10x Better

The ad problem nobody talks about

Why I built music into the timer

My daily setup

The science behind music and focus

What the Pomodoro Technique actually fixes

Comparing to alternatives

Tips for getting the most out of it

It runs in your browser. That's the point.

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 `<picture>` element: serving AVIF with fallbacks