Forem: Aral Roca

I Built a Free Invoice Generator, Resume Builder, and Cover Letter Generator That Don't Require Signup

Aral Roca — Sat, 02 May 2026 19:51:53 +0000

A friend asked me to recommend a free invoice generator yesterday. I opened the first ten results on Google and they all did the same thing: signup wall, email capture, or a watermark across the PDF unless you pay $12/month. Generating a PDF from form fields is a solved problem that somehow became a SaaS category.

So I built three of them in a day. Invoice generator, resume builder, cover letter generator. No signup, no watermark, no data leaving your browser. Fill in the fields, see a live preview, download a clean PDF. Done.

The three tools are an Invoice Generator, a Resume Builder, and a Cover Letter Generator. All three run entirely in your browser. No data leaves your device. No account needed. No watermarks.

Why I built these instead of recommending existing ones

I tried to find free invoice generators for a freelancer friend last month. Every single one either required signup, limited you to one template, added their branding to the PDF, or was clearly a funnel for their SaaS product. Same story with resume builders: the free tier gives you one basic template, and the moment you want something that looks professional, you're staring at a paywall.

The thing is, generating a PDF from form data is not a hard problem. The browser has everything it needs. pdf-lib is an excellent open-source library that creates PDFs entirely in JavaScript. There is genuinely no reason your invoice data needs to touch someone else's server.

So I built these tools with a shared PDF rendering layer and a template system inspired by PptPresentationMaker, which was already the most complex tool on Kitmul. The architecture is straightforward: React state for the form, an HTML/CSS live preview that updates on every keystroke, and a pdf-lib PDF that generates when you click download.

The Invoice Generator: six templates and real math

The Invoice Generator was the most technically interesting of the three. It has six templates (Clean, Modern, Classic, Bold, Minimal, Corporate), each with distinct header layouts and color schemes. You can upload your company logo, and the tool resizes it client-side using a canvas element before embedding it in the PDF with embedPng().

The auto-calculations handle subtotals, percentage or fixed-amount discounts, and tax rates. Everything updates live in the preview. The currency selector supports twelve currencies with locale-aware formatting via Intl.NumberFormat; the same $1,234.56 displays correctly whether you pick USD, EUR, or JPY.

The table rendering was the hardest part. pdf-lib doesn't have a table concept; you're positioning rectangles and text with pixel coordinates. I wrote a shared drawTable helper that computes row heights based on text wrapping, handles alternating row backgrounds, and automatically breaks to a new page if the table overflows. That helper is now reusable across all three tools.

One thing that surprised me: the header layout calculation. Templates with colored backgrounds need to know the exact height of the header content (logo height + business info lines + invoice details) before drawing the background rectangle. I ended up computing it dynamically based on which fields are filled in, so the header shrinks if you leave fields empty and expands if you add a logo.

The Resume Builder: five templates, all ATS-friendly

The Resume Builder is the most complex tool at around 900 lines. It has five templates: Classic (single column, maximum ATS compatibility), Modern (with a colored sidebar for contact info and skills), Professional (two-column header), Minimal (lots of whitespace), and Executive (bold accent underlines).

I made a deliberate choice to use only StandardFonts from pdf-lib (Helvetica and Helvetica-Bold). Custom fonts look nicer, but they break Applicant Tracking Systems. ATS parsers expect standard fonts and simple text positioning. Every template outputs real, selectable text drawn top-to-bottom, never images of text. Even the Modern template with its sidebar draws the main content first in the reading order, so an ATS reads your experience before your contact details.

Sections are reorderable. You can drag Experience above Education or add Certifications, Languages, and Projects sections. Each experience entry supports multiple bullet points with add/remove controls. The whole thing generates multi-page PDFs when your resume is longer than one page, with proper page breaks that never split a section header from its content.

The Cover Letter Generator: the simple one done right

The Cover Letter Generator is the simplest of the three, but that's the point. A cover letter is a formatted business letter, and getting the formatting wrong makes you look sloppy. The tool handles four templates (Traditional, Modern, Professional, Simple) with proper business letter conventions: sender info placement, date formatting, greeting, body paragraphs, and sign-off.

The Traditional template puts your contact info top-right (the formal standard). The Modern template uses a large name with a horizontal accent line. The Professional template has a colored header block. You can add as many body paragraphs as you need.

No AI writes your letter. You write it, the tool formats it. I think that matters. A hiring manager who has read a hundred AI-generated cover letters can spot them instantly. Your words in a clean layout will stand out more than a GPT-generated letter in a fancy design.

The privacy argument is real

These three tools handle sensitive information. Your invoice has your business details, client names, and financial data. Your resume has your employment history, email, phone number. Your cover letter names specific companies you're applying to.

Every alternative I tested sends this data to a server. Zoho, Canva, Resume.io, Zety; they all require accounts, and once you've created an account, your data lives on their servers under their privacy policies. Some of them explicitly state they use your data for "service improvement," which is a polite way of saying they train models on your resume.

With browser-based tools, the architecture makes privacy the default. There's no server to send data to. The pdf-lib library generates the PDF in a Web Worker, the browser creates a Blob URL, and the download happens through a local anchor click. Your data exists in browser memory until you close the tab.

What I'd build next

Receipt Generator (the mirror of invoices, for the receiving side), NDA Generator (simple template-based legal documents), and Meeting Minutes Generator (structured notes to PDF). They all follow the same pattern: form data, live preview, clean PDF. The shared layout helpers make each new tool faster to build than the last.

If you're a freelancer creating invoices, a job seeker polishing your resume, or anyone who needs a professional document without the signup dance, give these a try. They're at kitmul.com alongside 400+ other free browser-based tools.

Related tools: PPT Presentation Maker · Text to PDF · PDF Merger · Budget Planner · Image to PDF

References:

The O(n^2) Bug That Looked Like Clean Code

Aral Roca — Fri, 01 May 2026 20:30:09 +0000

We shipped a feature on a Tuesday. By Thursday the API was timing out. The monitoring dashboard showed p99 latency climbing from 80ms to 14 seconds over 48 hours. Nothing had changed except the number of users.

The culprit was three lines of code that looked completely reasonable during review:

const results = users.map(user => {
  const match = permissions.find(p => p.userId === user.id);
  return { ...user, role: match?.role ?? 'viewer' };
});

Clean. Readable. Functional style. Also O(n * m), which in our case was O(n^2) because users and permissions grew at the same rate. At 200 users, 40,000 comparisons. At 2,000 users, 4,000,000. At 20,000 users, 400,000,000. The fix was a one-liner; build a Map first:

const permMap = new Map(permissions.map(p => [p.userId, p.role]));
const results = users.map(user => ({
  ...user,
  role: permMap.get(user.id) ?? 'viewer',
}));

O(n + m) instead of O(n * m). Problem solved. But the real question is: why did nobody catch it?

The O(n^2) trap hides in plain sight

Quadratic complexity is the most dangerous performance class in production software. Not because it's the slowest; O(2^n) and O(n!) are far worse. But because it looks fine. It passes code review. It works in development. It even works in staging if your test dataset is small enough. Then it hits production with real data volumes and everything falls apart.

The pattern is almost always the same: a lookup operation nested inside an iteration. Array.prototype.find(), Array.prototype.includes(), Array.prototype.indexOf(); these are all O(n) operations. Put them inside a loop and you've got O(n^2). Put them inside two nested loops and you've got O(n^3). JavaScript's expressive array methods make this especially easy to miss because the code reads like English instead of looking like nested for loops.

Here are five real patterns I've seen break production systems.

Pattern 1: The innocent `.includes()` inside `.filter()`

// Looks clean, but O(n * m)
const activeUsers = allUsers.filter(u => activeIds.includes(u.id));

If activeIds is an array with 10,000 entries and allUsers has 50,000 entries, you're doing 500,000,000 comparisons. Convert activeIds to a Set and it drops to 50,000:

const activeSet = new Set(activeIds);
const activeUsers = allUsers.filter(u => activeSet.has(u.id));

Set.has() is O(1). That one change takes you from O(n * m) to O(n + m).

Pattern 2: Deduplication by comparison

// O(n^2) deduplication
const unique = items.filter((item, i) => 
  items.findIndex(x => x.id === item.id) === i
);

I see this pattern weekly in code reviews. The findIndex scans from the start for every element. For 10,000 items, that's up to 100 million comparisons. The fix:

const seen = new Set();
const unique = items.filter(item => {
  if (seen.has(item.id)) return false;
  seen.add(item.id);
  return true;
});

Or even simpler with a Map if you need the full objects:

const unique = [...new Map(items.map(i => [i.id, i])).values()];

Pattern 3: The cascading `.map().filter().map()`

This one is subtle. Each individual method is O(n), and chaining three O(n) operations is still O(n); 3n is just n with a constant factor. But it becomes O(n^2) when one of those operations hides a lookup:

const enriched = orders
  .map(order => ({
    ...order,
    customer: customers.find(c => c.id === order.customerId), // O(n) inside O(n)
  }))
  .filter(order => order.customer?.active)
  .map(order => formatForDisplay(order));

The functional pipeline looks elegant. The nested .find() makes it quadratic. A pre-built lookup table fixes it with zero loss of readability.

Pattern 4: The recursive tree flattener

function flattenComments(comments) {
  return comments.reduce((flat, comment) => {
    flat.push(comment);
    if (comment.replies) {
      flat.push(...flattenComments(comment.replies));
    }
    return flat;
  }, []);
}

The spread operator inside reduce creates a new array on every recursive call. For a balanced tree with n nodes, this is O(n^2) due to array copying. The fix is flat.push(...result) or passing the accumulator through:

function flattenComments(comments, result = []) {
  for (const comment of comments) {
    result.push(comment);
    if (comment.replies) flattenComments(comment.replies, result);
  }
  return result;
}

Pattern 5: The SQL query in a loop (the N+1 problem)

This one isn't JavaScript-specific. It's the most common performance antipattern in web applications:

const orders = await db.query('SELECT * FROM orders WHERE status = ?', ['active']);
for (const order of orders) {
  order.items = await db.query('SELECT * FROM order_items WHERE order_id = ?', [order.id]);
}

1 query for orders + n queries for items = n+1 queries total. With 1,000 orders, that's 1,001 database round trips. The N+1 query problem is well-documented, but it keeps showing up because ORMs make it easy to trigger accidentally through lazy loading.

The fix is a JOIN or a batch query:

const orders = await db.query('SELECT * FROM orders WHERE status = ?', ['active']);
const orderIds = orders.map(o => o.id);
const items = await db.query('SELECT * FROM order_items WHERE order_id IN (?)', [orderIds]);

How to catch quadratic complexity before production does

1. Profile with realistic data sizes. If your test suite runs with 10 records and production has 100,000, your tests are measuring nothing useful. Create benchmark fixtures that match production cardinality. The difference between O(n) and O(n^2) is invisible at n=10 and catastrophic at n=10,000.

2. Grep for .find(), .includes(), .indexOf() inside .map(), .filter(), .reduce(). This mechanical check catches the majority of accidental quadratic patterns in JavaScript codebases. If you want to see how dramatically different complexity classes scale, plug the numbers into a Big O Complexity Comparator; it plots every class from O(1) to O(n!) on the same chart.

3. Add complexity annotations to code reviews. When reviewing code, ask: what is n? How big can it get? What's the complexity of the inner operation? Making this explicit prevents the "it works fine in dev" surprise.

4. Set latency budgets with alerts. If an endpoint's p95 latency crosses 500ms, page someone. Quadratic complexity typically manifests as a gradual degradation, not a sudden failure; perfect for latency-based alerts that catch the trend before users notice.

5. Know your standard library. Array.sort() is O(n log n). Set.has() is O(1). Array.includes() is O(n). Map.get() is O(1). The difference between reaching for an Array method and a Map/Set method is often the difference between O(n^2) and O(n). The MDN Web Docs on Keyed Collections cover when to use each.

The real lesson

The dangerous thing about O(n^2) isn't that it's slow. It's that it's invisible until it isn't. Every one of the patterns above passed code review because the code was readable, idiomatic, and correct. It just didn't scale.

Performance complexity isn't something you optimize for later. It's a design decision you make at the time you write the code. The question isn't "does this work?" but "does this work when n is 100x what I'm testing with?"

Research from Google consistently shows that every 100ms of added latency costs measurable business metrics. A quadratic algorithm that adds 50ms at your current scale and 5,000ms at next year's scale is a ticking time bomb.

Build the habit of reaching for Map and Set by default. Question every .find() and .includes() inside a loop. Profile with production-sized data. The code that kills your app won't look dangerous; that's exactly what makes it dangerous.

Dive deeper

For a complete reference on all eight complexity classes with interactive charts, runnable code, and interview patterns, read the Complete Guide to Big O Complexity.

The Shift from Determinism to Probabilism Is Bigger Than Analog to Digital

Aral Roca — Thu, 30 Apr 2026 19:23:37 +0000

The other day I had a bug in production. Something was rendering wrong in the UI and I couldn't figure out where it was coming from. I gave Claude the URL, it opened Chrome, inspected the HTML in the browser, cross-referenced what it saw in the DOM with my source code, and found the exact line where the error was. Not the file; the line. It navigated between the rendered output and the codebase, matched what was broken on screen to the component that produced it, and pointed me to the fix.

That moment stuck with me. Not because AI saved me time (it does that daily), but because of what it revealed about the nature of the answer. The model didn't know where the bug was. It inferred it. It observed the rendered HTML, estimated which parts of the code could produce that output, and surfaced the most probable origin. That probabilistic inference across two different representations of the same system; browser and codebase; was more effective than my deterministic debugging would have been.

We're living through something bigger than most people realize. The shift from deterministic to probabilistic computing isn't just a technical upgrade. It's a change in how knowledge gets created.

The first paradigm shift: analog to digital

The move from analog to digital was the defining technology transition of the late 20th century. It converted continuous signals into discrete data. Suddenly you could copy information without degradation. Transmit it globally. Store it efficiently. The internet, distributed systems, modern software; all of it descends from that single insight: continuous signals can be represented as sequences of ones and zeros.

But there was something that transition left untouched: the process of creation itself.

Digital software is deterministic. Given the same input, it produces the same output. Every line of code, every system, every product had to be explicitly designed, written, and maintained by a human. The computer executed instructions. It didn't generate anything it hadn't been told to generate. A SQL formatter formats SQL because someone wrote exact rules for how SQL should be formatted. A password generator produces random strings because someone implemented CSPRNG algorithms that define precisely how randomness gets produced.

Deterministic systems are predictable, testable, and reliable. They're also fundamentally limited: they can only do what someone has already imagined and coded.

The second paradigm shift: deterministic to probabilistic

With large language models and deep learning, we entered a new phase. Systems that don't execute rigid instructions but generate results based on probability distributions.

The difference is structural:

We no longer describe exactly what to do. We train models to learn how to do it.
We don't generate information manually. We infer it.
We produce answers, content, and decisions that were never explicitly programmed.

Think about what an AI content detector does. It doesn't have a list of "AI-written sentences" to match against. It computes statistical properties of text; Zipf's law conformity, punctuation entropy, sentence length distributions; and estimates a probability that the text was machine-generated. The detector itself is a probabilistic system analyzing the output of another probabilistic system. That's a sentence that would have been meaningless ten years ago.

Or consider automatic subtitle generation. OpenAI's Whisper model doesn't follow if-then rules to transcribe speech. It processes audio spectrograms and predicts the most probable sequence of tokens that corresponds to what was said. It gets it right most of the time. Not all of the time. That "most of the time" is the defining characteristic of probabilistic systems.

This shift has a direct impact on the most valuable resource that exists: time. AI reduces the effort required to create, analyze, and predict by orders of magnitude.

Knowledge generation without precedent

The key difference is that probabilistic systems can work with the unknown. From learned patterns, they can:

Generate text, images, or code that has never existed before.
Predict future outcomes from incomplete data.
Find relationships that were never explicitly defined.

This breaks a historical constraint: we no longer need to write every possible case. The system can generalize.

Consider the Monte Carlo forecaster. Classical project management asked teams to estimate how long tasks would take and then added the numbers up. Monte Carlo simulation does something smarter: it runs thousands of scenarios using historical data and gives you a probability distribution of delivery dates. "There's an 85% chance you'll finish by March 15" is more useful than "the estimate is March 10." But here's a nuance that matters: Monte Carlo is deterministic code. Statistical formulas executed with perfect precision. There's no inference; there's simulation. It's probabilistic thinking implemented on deterministic infrastructure. Today an LLM could make the same prediction without any of that code; you pass it the team's historical data and it gives you a reasonable estimate. But "reasonable" isn't "reliable." Until models reach 99.99% accuracy, hand-coded statistical simulations remain the safe bet. Monte Carlo is exactly the kind of tool that marks the transition: probabilistic thinking that still needs deterministic crutches.

The same principle applies everywhere. A background remover running a neural network in the browser doesn't have rules about what counts as "background." It has learned probability distributions over millions of segmented images and applies those distributions to your photo. A prompt generator doesn't store pre-written prompts; it structures natural language patterns that probabilistically produce better model outputs.

Even tools that seem purely deterministic are being reshaped. HTML to Markdown conversion is deterministic; the same HTML always produces the same Markdown. But the reason that tool exists is probabilistic: people need clean Markdown because feeding raw HTML to an LLM wastes 60-80% of tokens on structural noise. A deterministic tool serving a probabilistic ecosystem.

The current limitations: why it's not perfect yet

Despite the potential, current AI has real constraints:

Inference time. Generating responses means processing enormous quantities of tokens. A complex reasoning chain in a frontier model can take 30-60 seconds. That's fast compared to human analysis, but slow compared to a database query. The latency gap between "compute a hash" (nanoseconds) and "reason about a bug" (seconds) is six orders of magnitude.

Probabilistic errors. Models don't "know" in the classical sense. They estimate. As of April 2026, GPT-5.5, Claude Opus 4.7, and Gemini 3.1 Pro score between 89% and 92% on MMLU-Pro; the harder benchmark replacing the original MMLU. Each generation climbs a few points, but the numbers are still statistical. A graph traversal animator will always find the shortest path because BFS is deterministic. An LLM asked to find the shortest path will probably find it, but it might hallucinate an edge that doesn't exist.

Classical infrastructure. These models run on hardware designed for deterministic computation: CPUs, GPUs, TPUs. NVIDIA's H100 is optimized for parallel matrix multiplication, which is what transformers need, but the underlying architecture is still classical. We're solving probabilistic problems with deterministic machines.

The trajectory: approaching 100% accuracy

The trend line is clear. Each new model generation improves on benchmarks, reduces error rates, and expands generalization capacity. Google's Gemini, Anthropic's Claude, and OpenAI's GPT families are converging toward accuracy levels that make the distinction between "correct" and "highly probable" practically meaningless for many tasks.

When models reach 99.99% accuracy on routine cognitive tasks:

Trust in AI systems will match or exceed trust in human judgment.
Most intellectual tasks that follow learnable patterns will be delegated entirely.
The marginal cost of generating knowledge will approach zero.

We're not there yet. But the distance is shrinking with every model release.

The bottleneck: classical compute vs. quantum compute

Here's an idea worth sitting with: we're solving a fundamentally probabilistic problem using deterministic tools.

GPUs and TPUs parallelize massive calculations, but they operate under classical principles. This creates real constraints:

High energy consumption. Training GPT-5 class models required tens of thousands of NVIDIA H100 GPUs for months, at costs exceeding $100 million.
Expensive scaling. More parameters means more hardware, more cooling, more electricity.
Significant latency on large models.

The theoretical alternative is quantum computing.

Companies like IBM, Google, and D-Wave Systems are exploring QPUs (Quantum Processing Units) that work directly with probabilistic states through superposition and entanglement.

In theory, this would allow:

Solving certain calculations exponentially faster.
Modeling probabilistic systems natively instead of simulating them on deterministic hardware.
Drastically reducing the computational cost of AI inference.

If you want to see what quantum circuits actually look like, the Quantum Circuit Simulator lets you build and run circuits in the browser. Two lines of code create a Bell State; a maximally entangled pair of qubits where measurement of one instantly determines the other. That kind of native probabilistic behavior is exactly what current AI infrastructure lacks.

The hard problem: quantum error correction

Quantum computing isn't ready for this role yet. The main obstacle is Quantum Error Correction.

Quantum systems are extremely sensitive to noise and interference. Every interaction with the environment can collapse a qubit's superposition, corrupting the computation. Current quantum processors have error rates that make them impractical for the sustained, reliable computation that AI inference requires.

For a QPU to be viable at scale, three things need to happen:

Error rates must drop dramatically. Current physical qubits have error rates around 0.1-1%. Useful quantum computation needs rates below 0.0001%.
Stable qubit counts must scale. IBM's current roadmap targets 100,000 qubits by 2033. That's ambitious, but the engineering challenges at each step are enormous.
Fault-tolerant architectures must mature. Surface codes and other error correction schemes work in principle but require thousands of physical qubits per logical qubit. The overhead is still prohibitive.

What's at stake isn't just speed. It's energy.

Data centers consumed around 415 TWh in 2024; 1.5% of global electricity. The IEA estimates they'll exceed 1,000 TWh by 2026, with AI as the main growth driver. Training a frontier model consumes the electricity equivalent of thousands of households for a year. Every inference query burns over 33 Wh on long prompts; ten times what a Google search uses. And this scales. More models, more agents, more robotics with embedded AI; every layer adds energy demand.

The day quantum error correction gets solved, that equation changes radically. Current QPUs consume around 25 kW, most of it on cryogenic cooling; not computation. But quantum computing works with the probabilistic problem natively instead of simulating it with trillions of matrix multiplications. Quantum compression algorithms already demonstrate 84% energy efficiency gains on specific AI tasks. And partial error correction is enabling quantum models to maintain high accuracy with thousands of qubits instead of millions.

When quantum error correction matures, we won't just have faster AI. We'll have AI that consumes orders of magnitude less energy per inference. That's what turns quantum computing from a lab curiosity into viable infrastructure for the billions of agents the future requires.

Until that happens, we'll continue running probabilistic AI on deterministic hardware. Which, honestly, works remarkably well for how fundamentally mismatched the paradigms are.

What this means practically

This isn't abstract philosophy. The shift from determinism to probabilism changes how you build, how you work, and how you think about tools.

A binary search tree lab teaches deterministic algorithms. Insert a node, traverse the tree, get the same result every time. That kind of certainty is still valuable. Databases still need B-trees. Routing still needs Dijkstra. Blue noise generators still need deterministic sampling algorithms to produce well-distributed random points.

But the layer above those deterministic primitives is increasingly probabilistic. The database query is deterministic; the AI agent that decides which query to run is probabilistic. The algorithm is deterministic; the model that selects which algorithm fits the problem is probabilistic. The text is deterministic once written; the system that extracts text from images using OCR neural networks is probabilistic.

We're building a stack where deterministic systems execute and probabilistic systems decide. That's new. And it's only going to accelerate.

The next step isn't better AI; it's a composable compute stack

What comes next doesn't replace one paradigm with another. It composes them.

Think about how modern infrastructure already works. CPUs execute deterministic logic; database transactions, cryptographic verification, your operating system's kernel. GPUs and TPUs solve probabilistic problems; they train models, run inference, process distributions across millions of parameters. Each layer does what the other can't. Nobody suggests replacing CPUs with GPUs. You combine them.

QPUs complete the third layer. They solve a class of problems that classical hardware simulates poorly: combinatorial optimization, high-dimensional distribution sampling, search across exponential spaces. AI inference doesn't just get faster; it becomes viable at scales that are currently intractable.

The stack looks like this: deterministic systems execute and verify. Probabilistic systems propose and generate. Quantum systems optimize what neither of the other two can touch.

But there's a piece almost nobody is talking about yet.

Models talking to machines talking to models

So far we think of AI as something that receives a prompt and returns text. That's like thinking the internet is email. The next layer is communication between probabilistic models; and between those models and the deterministic hardware they control.

A language model analyzes sensor data and decides it needs more information from a specific area. It communicates that decision to a vision model controlling a drone. The drone moves, collects data, processes it through another specialized model, and returns the results to the first one. No human intervened in the cycle. No human decided that area was interesting. The system inferred it.

That's not automation. Automation executes what a human designed. This is different: probabilistic systems deciding what data to collect, how to collect it, and what to do with what they find. Robots with AI models that choose to explore information sources that wouldn't have occurred to us.

Think about a marine drone with chemical sensors and a model trained on oceanic biodiversity. It doesn't follow a preprogrammed route. It detects an anomaly in water composition, infers it could indicate an unknown microbial community, adjusts its trajectory, and takes samples. It finds something no marine biologist would have looked for because none would have predicted it would be there. Another model analyzes the samples, identifies compounds with pharmaceutical potential, and asks the drone to return to the same zone with different sensors.

That's genuinely new knowledge. Not extracted from existing data or inferred from human text. Generated by a system that decided to go look for it.

When prediction takes nanoseconds

The current limitations are real. Inference takes seconds. Accuracy hovers around 86-95% depending on the benchmark. But those are the limitations of the first generation of a paradigm that's barely getting started. The trajectory points toward models with 99.99% accuracy and nanosecond response times.

When that happens, the world reorganizes in ways that are hard to imagine from where we stand now.

A self-driving car that takes 30 milliseconds to decide is a car that brakes late. One that decides in nanoseconds reacts before the obstacle finishes appearing. A network of medical models with 99.99% accuracy doesn't assist the doctor; it diagnoses with a reliability no human can match. A supply chain where every node has a predictive model communicating with all the others doesn't need quarterly planning; it reoptimizes in real time, every millisecond.

But the really important thing is what happens when probabilistic inference becomes so fast and accurate that it's functionally indistinguishable from deterministic certainty. The distinction between "computing" and "inferring" disappears. Your operating system doesn't need to distinguish between an arithmetic operation and a prediction. The compiler doesn't need to know if the result comes from formal logic or a 400B parameter model. It's all computation; part rule-based, part distribution-based, part quantum-optimized. Seamlessly integrated.

AI stops being a tool you open and becomes an infrastructure layer you don't even notice. Like electricity. Like TCP/IP. It's everywhere and you don't think about it.

Knowledge beyond the human

Robots with AI models don't just automate what we used to do. They perceive what we can't.

An ultrasonic sensor coupled with a materials model detects microfractures in a wind turbine that no visual inspection would find. A portable spectrometer with a chemical model identifies contaminants at concentrations human protocols don't measure. A hydrophone array with an acoustic model classifies marine species by sound patterns no biologist has cataloged yet.

These aren't incremental efficiency improvements. They're new sources of knowledge. Data that existed in the physical world but was invisible to us because we didn't have the right sensors coupled with the right intelligence to interpret them.

And here's where the loop closes. Those robots don't just collect data; the models inside them decide what data is worth collecting. But the cycle goes further than that. An AI analyzing ocean temperature anomalies determines that the existing sensor grid is too coarse; it needs readings at depths and frequencies no current instrument covers. So it designs a new sensor specification. A manufacturing robot builds it. A deployment robot installs it on a fleet of underwater drones. Those drones collect data that no previous system could capture, and that data trains a better model, which identifies the next gap in sensing capability, and the cycle begins again.

No human decided what to measure. No human designed the sensor. No human chose where to deploy it. The entire chain; from identifying a knowledge gap to filling it with new physical hardware; was driven by probabilistic inference.

When millions of such systems operate simultaneously, each one designing sensors for the others, deploying instruments that didn't exist a cycle ago, and feeding the results back into shared models, humanity gains access to a layer of reality it literally couldn't perceive before. It's not an improvement on what we already knew. It's access to what we didn't know we didn't know.

The full stack

Thirty years ago the question was "can you code?". Ten years ago it was "can you use APIs?". Today it's "can you direct models?". Tomorrow it'll be irrelevant; models will direct each other.

Deterministic systems execute and verify. Probabilistic systems propose, generate, and decide. Quantum systems optimize the intractable. Sensors and robots extend all of this into the physical world. And communication between models closes the loop: systems that discover what they don't know, decide how to find out, and act to get it. Without human intervention. Without anyone telling them where to look.

If the analog-to-digital shift redefined how we store information, and the deterministic-to-probabilistic shift is redefining how we generate knowledge, the full integration; models, hardware, sensors, robots, quantum computing; redefines the limits of what's possible to perceive and understand.

We won't be using better tools. We'll be surrounded by an intelligence that sees what we don't see, seeks what we don't seek, and finds what we didn't know existed.

I Hid a Secret Message in a Cat Photo and Nobody Noticed for Six Months

Aral Roca — Wed, 29 Apr 2026 19:07:14 +0000

Note: dev.to modifies the image, the original image with the secret is the original post 🤘

I found a steganography challenge in a CTF last year that had me staring at a picture of a cat for two hours. The image looked completely normal; 800x600 pixels of an orange tabby sitting on a keyboard. No metadata anomalies, no appended ZIP files, no obvious artifacts. The flag was hiding in the least significant bits of the blue channel. Once I extracted it, the message was 43 characters long. The cat hadn't changed at all.

That experience sent me down a rabbit hole. Steganography is one of those topics that sounds like movie-hacker fiction until you actually try it. Then you realize it's just math; and surprisingly simple math at that.

What steganography actually is

Steganography is the practice of hiding data inside other data so that nobody knows the hidden data exists. This is fundamentally different from cryptography. Encryption scrambles a message so it can't be read; steganography hides the message so nobody even looks for it.

The distinction matters. An encrypted file screams "I have secrets." A stego image says nothing. It's a photo of a cat. Or a sunset. Or your company logo. The best steganography produces carrier files that are statistically indistinguishable from unmodified originals.

The word itself comes from Greek: steganos (covered) + graphein (writing). It's been around since ancient Greece; Herodotus wrote about a guy who shaved a slave's head, tattooed a message on the scalp, waited for the hair to grow back, and sent the slave to deliver the message. We've upgraded to pixels since then.

How LSB encoding works

The most common image steganography technique is Least Significant Bit (LSB) encoding. Here's why it works.

A pixel in a 24-bit RGB image has three color channels, each stored as an 8-bit value (0-255). The last bit of each byte; the least significant bit; contributes the smallest possible change to the color value. Flipping it changes the channel value by exactly 1. The difference between RGB(142, 87, 203) and RGB(143, 87, 202) is invisible to the human eye.

So you take your secret message, convert it to binary, and replace the LSBs of the image pixels with your message bits. Each pixel gives you 3 bits of storage (one per channel). A 1920x1080 image has 2,073,600 pixels; that's 6,220,800 bits of storage, or roughly 760 KB of hidden data. In practice you'd use far less to avoid detection, but the theoretical capacity is enormous.

Here's a minimal Python implementation to make this concrete:

from PIL import Image
import numpy as np

def text_to_bits(text):
    """Convert text to a binary string with a null terminator."""
    bits = ''.join(format(ord(c), '08b') for c in text)
    bits += '00000000'  # null terminator to mark end of message
    return bits

def hide_message(image_path, message, output_path):
    """Hide a message in the LSBs of an image."""
    img = Image.open(image_path).convert('RGB')
    pixels = np.array(img)
    flat = pixels.flatten()

    bits = text_to_bits(message)
    if len(bits) > len(flat):
        raise ValueError(f"Message too long: need {len(bits)} bits, have {len(flat)}")

    for i, bit in enumerate(bits):
        # Clear the LSB, then set it to our message bit
        flat[i] = (flat[i] & 0xFE) | int(bit)

    stego = flat.reshape(pixels.shape)
    Image.fromarray(stego.astype('uint8')).save(output_path, 'PNG')
    print(f"Hidden {len(message)} chars in {len(bits)} bits ({len(bits)/len(flat)*100:.4f}% of capacity)")

def extract_message(image_path):
    """Extract a hidden message from the LSBs of an image."""
    img = Image.open(image_path).convert('RGB')
    flat = np.array(img).flatten()

    bits = ''.join(str(b & 1) for b in flat)
    chars = []
    for i in range(0, len(bits), 8):
        byte = bits[i:i+8]
        if byte == '00000000':
            break
        chars.append(chr(int(byte, 2)))
    return ''.join(chars)

# Usage
hide_message('cat.png', 'The flag is CTF{hidden_in_plain_sight}', 'stego_cat.png')
print(extract_message('stego_cat.png'))

The key operation is on line 18: (flat[i] & 0xFE) | int(bit). The bitwise AND with 0xFE (11111110 in binary) clears the LSB, and the OR sets it to whatever our message bit is. That's the entire trick. Everything else is just converting text to bits and iterating over pixels.

Hiding a message step by step

If you don't want to write Python; or you're on a machine where you can't install PIL; the Steganography Tool on Kitmul does the same thing in your browser. No uploads, no server processing. The image never leaves your device.

Here's the workflow:

Upload a carrier image. PNG works best because it's lossless. JPEG compression will destroy your hidden bits; more on that later.
Type your secret message. The tool shows you the available capacity based on your image dimensions.
Download the stego image. It looks identical to the original. Pixel-for-pixel, the differences are imperceptible.

To extract, switch to Reveal mode, upload the stego image, and the hidden text appears.

The entire operation runs client-side using the Canvas API and typed arrays. Your secret message never touches a network connection. This matters; if you're hiding sensitive information, sending it to a third-party server rather defeats the purpose.

Detection and steganalysis; how to NOT get caught

Steganalysis is the art of detecting steganography, and it's more sophisticated than you might think.

Visual inspection won't catch LSB encoding. But statistical analysis will. The simplest test is a chi-squared analysis of pixel value distributions. In a natural image, pixel values have a characteristic distribution. LSB embedding flattens pairs of values (e.g., 142 and 143 become equally probable), which shows up as an anomaly in the histogram.

Tools like StegExpose and OpenStego include detection modules. In competitive CTF environments, zsteg and steghide are the go-to extraction tools.

Here are practical tips if you want your stego image to survive scrutiny:

Use less capacity. Embedding data in only 10-20% of available pixels makes statistical detection much harder. Using 100% of capacity is a forensic red flag.
Randomize pixel selection. Instead of writing sequentially from pixel 0, use a pseudorandom sequence seeded by a password to select which pixels carry data. This distributes the modifications uniformly.
Choose busy images. Photos with lots of texture, noise, and color variation hide LSB changes better than smooth gradients or solid blocks. A photo of a forest floor beats a photo of a white wall.
Never use JPEG as a carrier. JPEG's lossy compression modifies pixel values during encoding. Your hidden bits will be destroyed when the image is saved. Always use PNG, BMP, or TIFF for LSB steganography.
Strip metadata before sharing. EXIF data showing the image was processed by a steganography tool is an obvious giveaway.

When to combine steganography with encryption

Steganography and encryption solve different problems, and the strongest approach uses both. Here's why.

If an attacker suspects your image contains hidden data and successfully extracts the LSBs, they'll see your plaintext message. Game over. But if you encrypt the message first; using AES-256, for example; the extracted bits look like random noise. The attacker can't tell whether they found a message or just normal image data.

The practical workflow:

Encrypt your message with a strong symmetric cipher.
Hide the ciphertext in the image using LSB encoding.
Share the stego image publicly.
Share the decryption key through a separate channel.

This gives you two layers of protection: the message is both hidden (steganography) and unreadable (encryption). An attacker would need to both detect the hidden data and crack the encryption; a significantly harder problem than either alone.

Kitmul's Security and Cryptography tools include AES encryption, hash generators, and other utilities that complement the steganography tool for this exact workflow.

Real-world use cases

Steganography isn't just a CTF party trick. It has legitimate and important applications.

Digital watermarking. Publishers, photographers, and media companies embed invisible watermarks in images to track unauthorized distribution. If a leaked image surfaces, the embedded watermark identifies which recipient leaked it. This is how several major movie studios track screener copies.

Whistleblowing and censorship resistance. In countries with heavy internet surveillance, steganography allows activists to share information through innocent-looking images posted on social media. The image passes inspection by automated content filters; the hidden message reaches its intended audience.

Covert communication. Intelligence agencies have used steganography since at least the early 2000s. The FBI's 2010 arrest of Russian spies (the "Illegals Program") revealed they were embedding encrypted messages in images posted to public websites.

CTF challenges. Capture The Flag competitions love steganography because it tests a different skill set than standard crypto challenges. You need to identify that steganography was used at all before you can begin extraction. Common CTF stego techniques include LSB encoding, appended data, palette manipulation in GIF files, and audio spectrum hiding.

Proof of ownership. Artists and content creators can embed copyright information or ownership proofs directly into their work. Unlike visible watermarks, these don't degrade the visual quality of the piece.

The limits of pixel encoding

LSB steganography has real constraints worth understanding. The carrier image must be lossless; any lossy compression step (JPEG, WebP lossy) will corrupt embedded data. The message capacity scales with image dimensions, but using more than about 15-20% of capacity makes the image vulnerable to statistical detection. And the technique only hides data; it doesn't protect it from extraction by someone who knows what to look for.

For most practical purposes, image steganography works best as one layer in a defense-in-depth strategy. Hide the message, encrypt the content, and use a secure channel to share the key. No single technique is bulletproof, but the combination raises the bar significantly.

Try it yourself

The Steganography Tool on Kitmul lets you hide and reveal messages in PNG images directly in your browser. Everything runs client-side; no data is uploaded, no accounts required, no limits. Upload an image, type a message, download the result. Then try extracting it to verify the round trip.

If you're interested in security and privacy tools, the Security and Cryptography collection includes hash generators, encryption tools, password generators, and more; all running locally in your browser.

All processing runs locally in your browser. No images or messages are sent to any server. The tool is free, open, and has no accounts or limits.

I Stopped Paying for Subtitle Services After Running Whisper in a Browser Tab

Aral Roca — Tue, 28 Apr 2026 17:05:00 +0000

Last Tuesday I needed subtitles for a 12-minute product demo. The video was in English, the audience was international, and the deadline was two hours away.

My first instinct was the usual cloud suspects. Rev quoted me $1.50 per minute with a 24-hour turnaround. Descript wanted a subscription. Happy Scribe's free tier maxed out at one minute. Even YouTube's auto-captions required uploading, waiting for processing, then manually downloading the .srt file from Studio; a workflow designed for YouTube, not for the rest of the internet.

Then I thought: OpenAI released Whisper as open source in 2022. It's been ported to ONNX, to Core ML, to WebAssembly. If someone can run Stable Diffusion in a browser tab, running a speech-to-text model shouldn't be harder.

So I built one. The Automatic Subtitle Generator on Kitmul runs Whisper entirely in your browser. No upload, no account, no subscription. Drop a video, get a .vtt or .srt file.

Here's how it works under the hood and why the privacy angle matters more than most people realize.

How Whisper works (the short version)

Whisper is an encoder-decoder transformer trained on 680,000 hours of multilingual audio. The encoder converts a log-mel spectrogram of the audio into a sequence of embeddings. The decoder autoregressively generates text tokens, predicting each word based on the audio context and all previous tokens.

The clever part is the training data. Instead of curating a clean dataset, OpenAI scraped the internet for audio paired with existing transcripts; YouTube videos with community captions, podcast show notes, audiobooks with their text counterparts. The sheer volume of noisy, real-world data is what gives Whisper its robustness. It handles accents, background music, and cross-talk far better than older models that were trained on read speech in quiet rooms.

The model comes in sizes from tiny (39M parameters) to large-v3 (1.5B parameters). The browser version uses a quantized variant that balances accuracy with the memory constraints of running inside a Web Worker.

The browser pipeline

When you drop a video into the subtitle generator, this is what happens:

Audio extraction. The video's audio track is separated using FFmpeg compiled to WebAssembly. No server round-trip; the demuxing happens in your browser's memory.
Resampling. Whisper expects 16kHz mono audio. If the source is 44.1kHz stereo (most videos), an OfflineAudioContext handles the conversion via the Web Audio API.
Chunked inference. The audio is split into 30-second chunks (Whisper's attention window) and fed through the ONNX model inside a Web Worker. This keeps the main thread responsive; you can scroll the page while transcription runs.
Timestamp alignment. Whisper produces word-level timestamps. The tool merges these into subtitle segments of 1-3 lines, keeping each segment under 42 characters wide (the BBC subtitle guidelines standard for readability).
Format export. You choose WebVTT or SRT. Both are plain text. Both work everywhere.

The first run downloads the model weights (~40-80MB depending on language). After that, your browser caches them. Subsequent runs start almost instantly.

Why client-side subtitles matter

The privacy argument is straightforward, but people underestimate how many scenarios it covers.

Legal depositions. Law firms transcribe testimony recordings. Uploading those to Rev or Otter.ai means a third party now has access to privileged communications. Every cloud transcription service's terms of service includes some version of "we may use your content to improve our models." Even if they don't today, you've already uploaded.

Pre-release content. Marketing teams subtitle product demos before launch. Internal training videos contain unreleased features. If your competitor's PR team is monitoring cloud transcription APIs (and some do; it's surprisingly cheap to scrape aggregated anonymized data), you've just leaked your roadmap.

Medical and therapeutic contexts. Therapists recording sessions for supervision. Doctors dictating notes. HIPAA doesn't care that the transcription service promises encryption; if PHI leaves your device, you need a BAA in place. Running locally sidesteps the entire compliance question.

Journalism. Source protection is sacred. Uploading an interview with a whistleblower to any cloud service, no matter how reputable, creates a copy outside your control.

The Kitmul approach to privacy applies the same principle across all its tools: if the computation can run locally, it should.

The accuracy question

Let's be honest. Whisper in a browser is not going to match a dedicated GPU running the full large-v3 model. But the gap is smaller than you'd expect.

For clear, single-speaker English audio (the most common use case for product demos, tutorials, and course videos), the browser version produces usable subtitles roughly 93-95% of the time. Most errors are homophones ("their" vs "there") or uncommon proper nouns.

Where it struggles:

Heavy accents + background noise. A speaker with a strong regional accent in a noisy cafe will produce more errors than the same speaker in a quiet room.
Multiple overlapping speakers. Whisper was trained primarily on single-speaker audio. Crosstalk confuses the decoder.
Domain-specific jargon. Medical terminology, legal Latin, or niche technical vocabulary that didn't appear frequently enough in the training data.
Very long silent gaps. Extended silence can cause the model to hallucinate repeated phrases; a known Whisper behavior documented in the OpenAI research paper.

For professional broadcast work, you'll still want human review. But for social media, internal videos, educational content, and quick drafts, browser-based Whisper is genuinely good enough.

85% of social media videos play on mute

This statistic from Digiday keeps getting cited because it keeps being true. On Instagram, TikTok, LinkedIn, and Twitter/X, the default playback is muted. If your video doesn't have burned-in captions, most viewers will scroll past it.

The subtitle generator doesn't just export .srt files. It can burn subtitles directly into the video using FFmpeg.wasm, with customizable font size, color, and background opacity. The output is a new MP4 with permanent, embedded captions; no player support needed, no separate file to upload.

For content creators who post across multiple platforms, this is the fastest workflow I've found: drop video, wait 2-3 minutes, customize caption style, download captioned video. One tool, zero context switches.

Subtitle formats: VTT vs SRT

If you're not sure which format to use, here's the practical difference:

Feature	WebVTT (.vtt)	SubRip (.srt)
Styling	Supports CSS-like styling, positioning	Plain text only
Web players	Native HTML5 `<track>` support	Requires parser
YouTube	Accepted	Accepted
Social media	Varies	Widely supported
Metadata	Headers, comments, notes	Sequence numbers only
Spec	W3C standard	De facto standard

Rule of thumb: use VTT for web-based players and HTML5 video, SRT for everything else. Both are editable in any text editor, so converting between them is trivial.

The accessibility angle nobody talks about

Subtitles aren't just a growth hack. Under the Americans with Disabilities Act and the European Accessibility Act (which took full effect in June 2025), video content published by businesses must be accessible to people who are deaf or hard of hearing. This applies to websites, apps, and social media.

Most small businesses and solo creators don't subtitle their videos because the cost and friction are too high. A free, instant, no-upload tool removes that excuse entirely.

If accessibility is part of your workflow, the Accessibility Tree Visualizer on Kitmul can help you audit your web content's ARIA structure alongside your captioning efforts.

Complementary workflow tools

Subtitles are one step in a content pipeline. Here's how other Kitmul tools fit:

Extract Audio from Video — Pull the audio track from any video before processing. Useful if you want to run Speech to Text separately for a full transcript.
Video Trimmer — Cut your video to the relevant segment before generating subtitles. Processing a 2-minute clip is faster than a 30-minute recording.
Audio Stem Splitter — Isolate vocals from background music before transcription. Cleaner audio input produces more accurate subtitles.
Text Readability Scorer — Paste your subtitle text to check if the language is appropriate for your audience's reading level.
Keyword Extractor — Pull keywords from your transcript for SEO metadata, video tags, and content optimization.

All of these run in your browser. No uploads. No accounts. They compose well because they all operate on the same principle: your data stays on your device.

Try it

The Automatic Subtitle Generator is free. Drop an MP4, WebM, MOV, or MKV file. Choose your language (or let the AI auto-detect from 90+ supported languages). Wait a couple of minutes. Download your subtitles or your captioned video.

No account. No upload. No watermark. No daily limit.

If you're building content at scale and want the transcript as raw text instead of timed subtitles, the Speech to Text tool handles that use case with the same Whisper model.

Three Ways to Convert JSON to TypeScript. Only One Is Deterministic.

Aral Roca — Mon, 27 Apr 2026 21:55:12 +0000

There are three ways to turn a JSON response into TypeScript interfaces. You can write them by hand, you can ask an LLM, or you can run the JSON through a deterministic converter. I've used all three. Two of them have failure modes that most people don't think about until they ship a bug.

The manual approach: slow and accurate until it isn't

Writing interfaces by hand works when you have three fields. It stops working around field fifteen. A Stripe charge object has 40+ properties. A GitHub pull request response is over 100 fields deep once you count nested objects. Nobody types those by hand without making mistakes.

The failure mode is subtle. You open the API docs, you start writing, and by field twenty you're skimming. Was merged_at a string or a Date? Is labels an array of objects or an array of strings? You guess, you move on, and TypeScript's compiler trusts whatever you wrote. The type system only catches errors if the types are correct in the first place.

The TypeScript documentation puts it plainly: any disables type checking for that value. But a wrong interface is arguably worse than any, because it gives you false confidence. Your IDE autocompletes fields that don't exist. Your code compiles. The crash happens at runtime.

The LLM approach: fast and probabilistic

Pasting a JSON blob into ChatGPT or Claude and asking for TypeScript interfaces is tempting. It's fast. It handles nesting. It even names interfaces in reasonable ways most of the time.

The problem is that LLMs are probabilistic. Give the same JSON to the same model twice and you might get different output. Sometimes it adds ? to fields that aren't optional. Sometimes it invents a union type that doesn't match the data. Sometimes it decides id should be string when the value is clearly 1. I've seen models produce Date for ISO timestamp strings; technically aspirational, but wrong if you're not parsing the string into a Date object first.

These aren't bugs in the model. It's the nature of the tool. An LLM generates plausible text based on patterns. It doesn't parse your JSON the way a type system does. It reads it, approximates what the types should be, and writes something that looks right. Mostly it is right. But "mostly right" and "deterministically correct" are different things when your type definitions guard runtime behavior.

There's also the privacy angle. Pasting a production API response into a third-party LLM means sending your data to someone else's server. If that response contains user PII, internal endpoints, or auth tokens that leaked into the payload, you've just shared them with an external service. For side projects, nobody cares. For production codebases with compliance requirements, that's a conversation with your security team you don't want to have.

The deterministic approach: same input, same output, every time

A deterministic JSON-to-TypeScript converter doesn't guess. It parses. The algorithm walks the JSON tree, inspects each value's JavaScript type, and maps it to the corresponding TypeScript type. There's no randomness, no temperature parameter, no model that might behave differently on Thursday.

The rules are mechanical:

"hello" is always string. Not sometimes string, not occasionally "hello" as a literal type.
42 is always number. Not int, not float, not number | string.
[1, 2, 3] is always number[]. Not Array<number>, not number[] | undefined.
{"a": 1} always generates a separate named interface with a: number.
null is always null. Not undefined, not omitted.

Same JSON in, same TypeScript out. Run it a hundred times and you get a hundred identical results. That's the property you want from a tool that generates type definitions your compiler will trust.

What the algorithm actually does

Under the hood, the converter does a recursive descent through your JSON structure. For every value it encounters, it calls inferType(), which returns the TypeScript type string. Objects produce new interface entries in a Map. Arrays inspect their elements and produce either a uniform type (string[]) or a union type ((string | number)[]). Empty arrays become unknown[] because there's no element to infer from.

Property names get converted to PascalCase for interface names. Keys that aren't valid JavaScript identifiers (hyphens, spaces, leading digits) get quoted automatically. The output can be toggled between interface and type declarations.

Here's a concrete example. This JSON:

{
  "id": 1,
  "name": "Aral Roca",
  "email": "aral@example.com",
  "active": true,
  "roles": ["admin", "editor"],
  "profile": {
    "bio": "Full-stack developer",
    "avatar": "https://example.com/avatar.png",
    "social": {
      "github": "aralroca",
      "twitter": "aralroca"
    }
  },
  "posts": [
    {
      "id": 101,
      "title": "Understanding TypeScript Interfaces",
      "published": true,
      "tags": ["typescript", "tutorial"]
    }
  ],
  "createdAt": "2026-04-27T10:00:00Z"
}

Produces exactly this:

interface Root {
  id: number;
  name: string;
  email: string;
  active: boolean;
  roles: string[];
  profile: Profile;
  posts: PostsItem[];
  createdAt: string;
}

interface Profile {
  bio: string;
  avatar: string;
  social: Social;
}

interface Social {
  github: string;
  twitter: string;
}

interface PostsItem {
  id: number;
  title: string;
  published: boolean;
  tags: string[];
}

Four interfaces. Every field typed correctly. Every nested object extracted into its own named interface. No randomness involved.

Interface vs. type: when the toggle matters

The converter offers both interface and type output. The choice isn't cosmetic.

Interfaces support declaration merging; if two interfaces share the same name in the same scope, TypeScript merges their properties. Types don't. For library authors who want consumers to extend types, interfaces are the better pick.

Types handle unions, intersections, and mapped types more naturally. If you need type Result = Success | Error or compose shapes with &, the type output saves a conversion step.

For API response typing, it rarely matters. Pick whichever your team's linting rules enforce and move on.

Where deterministic inference still needs human review

The converter infers types from values, not from schemas. That's a feature; it works with any JSON without requiring an OpenAPI spec or JSON Schema. But it means there are edges where you'll want to adjust:

Optional fields. The converter only sees the sample you provide. If a field is sometimes absent from the response, add ? manually.

String enums. "status": "active" becomes string, not "active" | "inactive" | "suspended". Narrow it yourself.

Date strings. ISO 8601 timestamps like "2026-04-27T10:00:00Z" are string to the converter. If you're parsing them with date-fns or dayjs, you'll want to change those to Date in your final types.

Pagination wrappers. A response like { data: [...], meta: { page: 1, total: 100 } } generates a Root interface with both. Rename it to PaginatedResponse<T> and extract Meta as a generic.

These adjustments take seconds. The point is that the deterministic converter gives you a correct baseline; the parts that need human judgment are the parts a machine genuinely can't infer from a single sample. An LLM would also get these wrong; the difference is the LLM might also get the easy parts wrong.

Privacy as a feature, not a marketing line

The converter runs entirely client-side. The JSON never leaves your browser. No server call, no analytics on your input, no account.

This isn't an abstract benefit. Plenty of teams have security policies that prohibit uploading source code or API responses to third-party services. That rules out most online tools. It rules out pasting production responses into LLM chatbots. A client-side converter that processes everything in a JavaScript function on your machine has zero compliance surface.

Open your browser's network tab while using it. You'll see nothing sent.

A practical workflow

1. Get a real response. Use curl, Postman, or your browser's network tab to capture an actual API response.

2. Paste and convert. Open the JSON to TypeScript converter, paste the JSON, copy the output.

3. Rename and refine. Change Root to UserResponse. Add ? where needed. Narrow string unions.

4. Co-locate with your API client. I put types in a types.ts next to whatever file makes the fetch or axios call.

5. Add runtime validation. Use Zod or Valibot to validate that the API actually sends what your types describe. The converter gives you structure; a schema library gives you runtime guarantees.

The whole thing takes under a minute per endpoint.

Beyond API responses

The converter handles any valid JSON:

Config files. Paste tsconfig.json or package.json for type-safe config loading.
Database exports. A MongoDB document or PostgreSQL row as JSON becomes your ORM layer types.
Test fixtures. If you write tests with Jest or Vitest, converting fixture files ensures your mocks match production shapes.
CMS content. Headless CMS responses from Strapi, Sanity, or Contentful are deeply nested. Type them once; let the compiler catch template bugs.

For formatting JSON before converting, the JSON Formatter handles pretty-printing and validation. For the opposite direction; stripping HTML into something an LLM can process efficiently; there's the HTML to Markdown converter.

The tradeoff matrix

	Manual	LLM	Deterministic
Speed	Slow	Fast	Fast
Correctness	Depends on you	Mostly correct	Always correct for the sample
Consistency	Varies	Non-deterministic	Identical every run
Privacy	N/A	Data sent to server	Client-side only
Optional fields	You decide	Sometimes guesses	You decide
String narrowing	You decide	Sometimes guesses	You decide

The deterministic converter handles the mechanical part; mapping values to types; perfectly. The parts it can't handle (optionality, string enums, date parsing) are the same parts the other approaches also can't handle reliably. The difference is it doesn't introduce new errors on the parts it can handle.

The bottom line

Type safety isn't a spectrum. Your types are either correct or they're not. Manual typing is slow and error-prone at scale. LLM typing is fast but probabilistic. Deterministic conversion is fast and correct; within the bounds of what any tool can infer from a single JSON sample.

Use the JSON to TypeScript converter for the mechanical work. Spend your judgment on optional fields, string unions, and interface naming; the decisions that require context no tool has.

Zero signup. Zero upload. Same input, same output. Part of the Developer & Programming Utilities on Kitmul.

Photo by Florian Olivo on Unsplash.

My Friends Spent 14 Minutes Deciding Where to Go Train. A Wheel Spinner Fixed It in 3 Seconds.

Aral Roca — Mon, 27 Apr 2026 16:12:25 +0000

Last Tuesday my friends spent 14 minutes deciding where to go train. Fourteen minutes. Four of us, three opinions about that rooftop downtown, one person who wanted the park with the low walls, and nobody willing to commit because nobody wanted to be the one who picked wrong.

I opened a browser tab, typed six parkour spots into a spin the wheel tool, and hit spin. The wheel landed on the bridge underpass. Everyone shrugged. We went. The session was solid. Nobody complained.

That 14-minute argument wasn't about training spots. It was about decision fatigue; the slow erosion of your ability to make good choices after making too many mediocre ones. And it happens constantly in contexts far more consequential than where to practice your kongs.

Why humans are terrible at random selection

We think we're good at picking things randomly. We're not. Ask someone to pick a random number between 1 and 10, and they'll disproportionately choose 7. Ask a teacher to cold-call students "randomly" during class, and they'll unconsciously favor the kids who make eye contact, sit up front, or haven't been called recently. The bias is invisible to the person doing the picking.

This isn't a character flaw. It's architecture. Human brains evolved to find patterns, not to generate randomness. A study published in PLOS ONE showed that when people try to produce random sequences, they systematically avoid repeats and clusters; the exact features that genuine randomness produces. We're so bad at it that researchers use human-generated "random" sequences as a test for cognitive bias.

Barry Schwartz documented the downstream effect in The Paradox of Choice: when people face too many options, they either freeze (analysis paralysis) or choose and then ruminate about whether they chose wrong. His research at Swarthmore found that "maximizers"; people who need to evaluate every option before committing; report significantly less satisfaction with their decisions than "satisficers" who pick something good enough and move on.

A random picker wheel is a satisficer machine. It removes the emotional weight from low-stakes decisions and hands it to probability.

Where a random wheel actually solves real problems

I assumed spin-the-wheel tools were novelty toys until I started paying attention to how people actually use them. The use cases fall into three categories that are surprisingly distinct.

Classrooms

Teachers have known for decades that cold-calling students improves engagement. The problem is that human-selected cold calls are biased. Teachers call on students who sit in a T-shape (front row plus center column) at roughly 3x the rate of students in the back corners. They call on boys more than girls. They avoid students who look anxious, which means the students who most need practice speaking never get it.

A random name picker fixes this mechanically. Put 30 names on the wheel, spin it, and whoever it lands on answers. The randomness is visible to the entire class; nobody can accuse the teacher of favoritism. Students in my network who teach middle school report that visible randomness ("the wheel picked you, not me") reduces pushback from students who don't want to be called on. The accountability shifts from the teacher to the mechanism.

Team decisions and retrospectives

Sprint retrospectives generate action items. Someone has to own each one. The politeness problem kicks in: nobody volunteers for the annoying tasks, and the same responsible people end up with disproportionate load. A wheel spin assigns ownership without the social dynamics.

I've seen this work in standup meetings too. Instead of going in the same clockwise order every day (which means the same person always goes first while still waking up, and the same person always goes last when everyone is checked out), spin the wheel for speaking order. Random order keeps people alert because you don't know when your turn is coming.

Pair programming rotations, code review assignments, who presents the demo to stakeholders; all of these benefit from randomization that a team generator or a random choice picker handles in seconds.

Giveaways and content creation

If you've ever run a social media giveaway, you know the anxiety. Pick a winner manually and someone will accuse you of favoritism. Use a random picker on camera and the audience trusts the result because they watched the process. The wheel is theatrical in a way that a random number generator isn't. Nobody wants to watch someone click "generate" and read a number. People do want to watch a wheel spin and slow down to a dramatic stop.

Streamers, YouTubers, and event organizers use wheel spinners for this exact reason. The visual feedback is the product. A coin flipper works for binary choices, and a dice roller works for numbered outcomes, but for named options with more than six entries, the wheel is the right interface.

How Math.random() actually works under the hood

Since the tool runs entirely in your browser, the randomness comes from JavaScript's Math.random(). That function has an interesting history.

Until 2015, Chrome's V8 engine used an algorithm called MWC1616 (multiply with carry) that was, frankly, terrible. It had only 2^32 possible states and failed multiple statistical randomness tests. The V8 team documented the replacement in detail: they switched to xorshift128+, an algorithm with 2^128 - 1 possible states that passes every test in the TestU01 suite. Firefox and Safari adopted the same algorithm.

Is it cryptographically secure? No. Math.random() is a pseudorandom number generator, not a cryptographic one. If you're generating encryption keys, use crypto.getRandomValues(). But for picking a training spot or selecting a student to answer a question? xorshift128+ is more than sufficient. The distribution is uniform, the period is astronomically long, and no human will ever detect a pattern in the output.

The wheel animation itself uses the Canvas API to draw colored slices and an easing function for the spin deceleration. The result is determined before the animation starts; the wheel is rendering a predetermined outcome with dramatic timing, not simulating physics. This means the visual experience is satisfying but the randomness is decided instantly.

The privacy argument

Most spin-the-wheel tools online upload your entries to a server. Some of them store your data indefinitely. A few of the popular ones set tracking cookies from five different ad networks before you've even typed your first option.

The Kitmul spin the wheel runs entirely in your browser. No entries leave your device. No server sees your student names, your team members' names, or your list of training spots. For teachers using student names; which are protected under FERPA in the US and similar regulations elsewhere; this isn't a nice-to-have. It's a compliance requirement that most online tools silently violate.

The URL state persistence means you can bookmark a wheel configuration or share it as a link without any server-side storage. The options are encoded in the URL itself. Close the tab, open the bookmark, and your wheel is back.

When not to use a wheel

Random selection is wrong when the decision actually has stakes. Don't use a wheel to decide which database migration to run first. Don't use it to pick which candidate to interview. Don't use it to allocate budget.

The wheel works when the options are roughly equivalent in value and the cost of choosing "wrong" is near zero. Training spots. Speaking order. Homework review partners. Game night picks. Giveaway winners from a pre-qualified pool.

If you catch yourself putting items on a wheel and hoping it doesn't land on one of them, that's your brain telling you the decision isn't actually random-appropriate. You have a preference. Honor it.

The 14-minute rule

After the training spot incident, I started timing how long group decisions take when everyone has veto power and nobody has a mechanism. The median for a group of 4+ people choosing from 5+ options: 14 minutes. The median for the same group using a random picker: 30 seconds, including the argument about whether the result is "really random."

That's 13.5 minutes saved. Multiply that by the number of low-stakes group decisions your team makes per week. For us it was about 6. That's 81 minutes per week; an entire Pomodoro block plus change; spent on decisions where the outcome genuinely didn't matter.

The spin the wheel is free, runs in your browser, and doesn't touch a server. Type your options, spin, and move on to the work that actually matters.

Spin the Wheel is part of the Random Generators toolkit on Kitmul. See also: Random Number Generator, Rock Paper Scissors, and Spaced Repetition Flashcards.

How to Create 360 Panoramas with GPT Image 2 and View Them Interactively

Aral Roca — Sat, 25 Apr 2026 22:19:50 +0000

What you will learn

This tutorial covers how to generate 360-degree equirectangular panorama images using GPT Image 2 (the image generation model inside ChatGPT) and how to view them in an interactive 360 viewer that runs entirely in your browser.

By the end you will know:

What an equirectangular image is and why the format matters
How to write prompts that produce usable 360 panoramas
How to load the result into the viewer and explore it
How to embed the viewer on your own website with a pre-loaded image

What is an equirectangular image

A 360 panorama is stored as an equirectangular projection; a flat rectangle that maps the full sphere of vision onto a 2:1 aspect ratio image. Think of it like a Mercator world map, but for a room instead of the Earth.

The horizontal axis covers 360 degrees of longitude
The vertical axis covers 180 degrees of latitude
The left and right edges must stitch seamlessly; they represent the same point in space

When a 360 viewer loads this image, it wraps it onto the inside of a sphere using Three.js and places the camera at the center. You drag to rotate, scroll to zoom, and the flat image becomes an immersive scene.

Professional cameras like the Ricoh Theta Z1 or Insta360 X4 handle stitching automatically. When generating with AI, the model needs to produce that seamless wrap in a single pass.

Step 1: Open ChatGPT with GPT Image 2

Go to ChatGPT and make sure you are using a model that supports GPT Image 2 (GPT-4o with image generation enabled). GPT Image 2 is available on ChatGPT Plus, Team, and Enterprise plans.

GPT Image 2 does not produce equirectangular projections by default. You need to be explicit about the format, the aspect ratio, and the seamless stitching requirement in every prompt.

Step 2: Write the prompt

The prompt structure has three critical parts:

Scene description: what you want to see
Format specification: equirectangular projection, 2:1 aspect ratio
Seamless constraint: left and right edges must stitch when wrapped onto a sphere

Base prompt template

Generate a 360-degree equirectangular panorama image of [SCENE DESCRIPTION].
The image must use equirectangular projection with a 2:1 aspect ratio.
The left and right edges must stitch seamlessly when wrapped onto a sphere.
Photorealistic style. High detail. Even lighting across the full 360 degrees.

Example prompt: Gothic cathedral interior

Generate a 360-degree equirectangular panorama image of the interior of a
gothic cathedral inspired by Sagrada Familia in Barcelona. Tall columns
branching into tree-like structures supporting the ceiling. Stained glass
windows casting colored light across stone surfaces. Warm afternoon light
filtering through the nave. The image must use equirectangular projection
with a 2:1 aspect ratio. The left and right edges must stitch seamlessly
when wrapped onto a sphere. Photorealistic style.

Example prompt: Modern apartment

Generate a 360-degree equirectangular panorama image of a modern minimalist
apartment living room. White walls, large floor-to-ceiling windows with
city skyline view, a gray sectional sofa, wooden coffee table, indoor
plants, and warm pendant lighting. Scandinavian design. The image must use
equirectangular projection with a 2:1 aspect ratio. The left and right
edges must stitch seamlessly when wrapped onto a sphere.

Example prompt: Tropical beach

Generate a 360-degree equirectangular panorama image of a tropical beach
at sunset. Crystal clear turquoise water, white sand, palm trees swaying,
a wooden pier extending into the ocean, dramatic orange and pink sky. The
image must use equirectangular projection with a 2:1 aspect ratio. The
left and right edges must stitch seamlessly when wrapped onto a sphere.

Step 3: Download the image

After ChatGPT generates the image:

Click on the generated image to open it full size
Click the download button (arrow pointing down)
Save it as JPEG or PNG; always grab the highest resolution available

GPT Image 2 outputs images at around 2048x1024 pixels. Higher resolution means more detail when the image is stretched across the full 360-degree sphere.

Step 4: Load it into the interactive viewer

Open the Interactive 360 Photo Viewer and drag your downloaded image onto the upload area. The viewer will:

Download and decode the image
Map it onto a 3D sphere using WebGL
Let you drag to look around, scroll to zoom, and toggle auto-rotate

Everything runs locally in your browser. The image never leaves your device.

Here is a live example; drag around to explore:

Tips for better results

1. Always specify the 2:1 aspect ratio. Without it, the model defaults to square or 16:9. These break the projection math when loaded into a viewer.

2. Describe the full 360-degree scene. Instead of "a room with a window", describe all four walls: "large windows on the north wall, a bookshelf on the east wall, a fireplace on the south wall, and a door on the west wall." The model produces better wraps when it understands the complete environment.

3. Request even lighting. The most common failure is a visible seam where the left and right edges meet. This happens when the lighting differs drastically across the scene. Specifying "even lighting" or "diffuse ambient light" reduces seam artifacts.

4. Interiors work better than open landscapes. Enclosed spaces (rooms, cathedrals, caves, studios) produce more consistent equirectangular results. Walls and ceilings anchor the perspective and reduce geometric warping.

5. Iterate with follow-up prompts. If the result has a visible seam or distorted geometry, tell ChatGPT exactly what went wrong: "The left and right edges don't match; there's a visible break in the wall texture. Regenerate with seamless horizontal stitching." GPT Image 2 responds well to specific corrections.

6. Download at full resolution. Lower resolution images lose detail when stretched across a sphere. Every pixel counts in equirectangular projection.

How to embed the viewer on your own site

The 360 viewer can be embedded on any website using an iframe. The src query parameter pre-loads a specific image:

<iframe
  src="https://kitmul.com/en/embed/image-design/interactive-360-photo-viewer?src=YOUR_IMAGE_URL"
  width="100%"
  height="500"
  frameborder="0"
  allowfullscreen
  loading="lazy"
></iframe>

Replace YOUR_IMAGE_URL with the public URL of your equirectangular image. The image must be publicly accessible and serve appropriate CORS headers. For images on the same domain, use a relative path: ?src=/images/my-panorama.jpg.

Limitations to keep in mind

GPT Image 2 is not a 360 camera. The images are impressive but imperfect:

Limitation	Details
Seam artifacts	About 30% of generations show a visible seam. Fix with follow-up prompts or GIMP's offset filter
Geometric inconsistency	Straight lines sometimes curve or warp, especially in architectural scenes
Resolution ceiling	Max ~2048x1024. Professional 360 cameras shoot at 5.7K+
No depth data	AI panoramas are flat projections; you can rotate but not move through the space

AI-generated vs. professional 360 photos

Aspect	GPT Image 2	Professional 360 camera
Cost per image	Free (ChatGPT subscription)	$200-800+ per session
Time to produce	30-60 seconds	Hours (setup + shooting + stitching)
Resolution	~2048x1024	5760x2880+
Geometric accuracy	Approximate	Photogrammetric precision
Customization	Unlimited; describe any scene	Limited to physical locations
Seam quality	~70% seamless	Always seamless
Best for	Concepts, prototypes, education	Listings, documentation, VR

Use cases

Real estate virtual staging: generate 360 views of unfurnished spaces with different interior styles before the property is decorated
Architecture concept presentations: show clients what a planned interior will feel like before construction begins
Educational content: create 360 views of historical interiors for classroom use; Roman villas, medieval castles, Renaissance chapels
Game and VR prototyping: test spatial feel of environments before committing to full 3D modeling
E-commerce showrooms: generate 360 product display rooms and embed the viewer on product pages

Summary

Open ChatGPT with GPT Image 2
Use the prompt template with explicit equirectangular projection, 2:1 ratio, and seamless edges
Download the image at full resolution
Load it into the Interactive 360 Photo Viewer
Drag to explore, zoom in, toggle auto-rotate, go fullscreen

The entire workflow takes under two minutes and runs entirely in your browser.

The Interactive 360 Photo Viewer is free, private, and processes everything locally. No signup, no server uploads. Part of the Image & Design Tools collection on Kitmul.

I Ran a Neural Network in a Browser Tab to Split a Song into Stems

Aral Roca — Fri, 24 Apr 2026 20:17:22 +0000

Last week a friend sent me a voice memo. "I found this incredible bass line in an old soul track," he said, "but I can't isolate it without paying $30/month for some cloud service that wants my email, my credit card, and probably my firstborn."

He's not wrong. The audio stem separation landscape in 2026 is a mess of subscription walls and cloud uploads. Most tools send your audio to a remote GPU, process it, and send back the stems. You get results in minutes, sure, but your unreleased remix idea now lives on someone else's server.

I wanted to see if the entire pipeline could run locally, in a browser tab, with zero network requests after the initial page load.

Turns out it can.

What stem separation actually is

For those unfamiliar: source separation (also called demixing or unmixing) is the process of decomposing a mixed audio signal into its constituent sources. A typical pop track is a sum of vocals, drums, bass, and everything else (guitars, synths, keys, strings). The AI's job is to reverse that sum.

The state of the art traces back to Meta's Demucs, a hybrid model that operates in both time domain and frequency domain simultaneously. It was trained on thousands of multitrack recordings where the individual stems are known, so it learned the spectral fingerprints that distinguish a kick drum from a bass guitar from a human voice.

The interesting bit is that Demucs v4 (htdemucs) uses a transformer architecture fused with a convolutional U-Net. The transformer handles long-range dependencies (like a sustained vocal note over a drum fill), while the U-Net captures local spectral patterns. The result is significantly less "bleeding" between stems compared to older approaches.

Running it in the browser with ONNX + WebAssembly

The Audio Stem Splitter on Kitmul loads an ONNX-exported version of the Demucs model and runs inference entirely via ONNX Runtime Web backed by WebAssembly. No server. No upload. The audio bytes never leave your machine.

Here's what happens when you drop an audio file:

The file is decoded to raw PCM using the Web Audio API's decodeAudioData
If the sample rate isn't 44100 Hz, it gets resampled via an OfflineAudioContext
The audio is chunked and fed through the ONNX model in a Web Worker to avoid blocking the UI thread
The model outputs four spectral masks (vocals, drums, bass, other)
Each mask is applied to the original spectrogram to produce isolated stems
The stems are encoded back to WAV for download

The whole pipeline is embarrassingly parallel in theory, but in practice you're bounded by the single WASM thread and available RAM. A 4-minute song takes roughly 3-5 minutes on a modern laptop. Not fast, but not bad for running a neural network in a browser tab.

The privacy argument nobody is making

Every time you upload a track to LALAL.AI, Moises, or Stem Roller, you're sending potentially copyrighted audio (or your own unreleased work) to a third-party server. Their privacy policies usually say they "don't store your files permanently," but the operative word is "permanently."

With client-side processing, the question of data retention is moot. There's nothing to retain. Your browser downloads the model weights once (cached for future visits), runs the math locally, and produces output files that exist only in your device's memory until you explicitly save them.

This matters especially for:

Producers working with unreleased material
DJs preparing sets with copyrighted tracks
Music teachers creating practice tracks for students
Forensic audio analysts working with sensitive recordings

Practical use cases I didn't expect

The obvious use case is karaoke (remove vocals, sing along). But I've seen people use stem separation for things I hadn't considered:

Transcription aid. A jazz pianist told me she splits out the piano stem from classic recordings to transcribe voicings more accurately. When you can hear the piano in isolation, you catch harmonic details that get buried in the full mix.

Sample archaeology. Hip-hop producers dig through vinyl rips looking for loops. Isolating the drum break from a 1970s funk track gives you a clean sample without having to EQ out the horns by hand.

Accessibility. Someone who is hard of hearing mentioned that boosting the vocal stem and attenuating the instrumental makes dialogue-heavy content (podcasts with music beds, film scenes) significantly clearer.

A/B testing mixes. If you're learning to mix, splitting a professional track into stems lets you rebuild the mix from scratch in your DAW and compare your choices against the original balance.

The model's limitations (honest take)

The separation isn't perfect. Here's where the model struggles:

Heavily compressed or low-bitrate audio produces more artifacts. Start with 320kbps MP3 or WAV if you can.
Dense arrangements with many layered instruments bleed more into the "other" stem. A solo guitar-and-voice track separates beautifully; a wall-of-sound Phil Spector production, not so much.
Mono recordings lose the spatial cues that help the model distinguish sources. Stereo is always better.
Very long files (>10 minutes) will challenge your device's RAM. The 50MB file size limit is there for a reason.

If you need studio-grade results for a commercial release, you probably want iZotope RX or the full Demucs CLI on a GPU. But for quick workflows, creative exploration, or situations where privacy matters more than perfection, browser-based separation is genuinely useful.

How it compares to the competition

Feature	Kitmul Stem Splitter	LALAL.AI	Moises	Demucs CLI
Processing	100% local (browser)	Cloud GPU	Cloud GPU	Local GPU/CPU
Price	Free	$15-30/mo	$4-17/mo	Free (OSS)
Privacy	No upload	Upload required	Upload required	No upload
Setup	Zero	Account + payment	Account + payment	Python + ffmpeg
Quality	Good (ONNX htdemucs)	Very good	Very good	Best (full model)
Speed	3-5 min/song	~30 sec	~1 min	~30 sec (GPU)

The tradeoff is clear: you sacrifice some speed and marginal quality for zero setup, zero cost, and complete privacy. For most non-professional workflows, that's the right call.

The Web Audio API is more capable than you think

Building this reinforced something I keep discovering: the browser audio stack is seriously underrated. Between AudioContext for real-time processing, OfflineAudioContext for offline rendering, AudioWorklet for custom DSP on a dedicated thread, and now ONNX Runtime Web for running neural networks, you can build legitimate audio production tools that would have required native apps five years ago.

If you're a developer interested in this space, the combination of Web Workers for heavy computation + SharedArrayBuffer for zero-copy data transfer + WASM for near-native math performance is the stack to bet on.

Try it

The Audio Stem Splitter is free, works in any modern browser, and processes everything locally. Drop an MP3 or WAV, wait a few minutes, and download your isolated vocals, drums, bass, and instrumental tracks.

If you're into music production, the Loop Music Creator (browser-based DAW) and the YouTube Loop Mix (dual-deck DJ tool) pair well with separated stems for remixing workflows.

All three tools run in your browser. No accounts. No uploads. No subscriptions.

One PR to a parser unlocked prerendering in Brisa

Aral Roca — Thu, 23 Apr 2026 20:30:35 +0000

I built a JavaScript framework called Brisa. The kind of framework that needs to parse every single source file your app contains; analyze imports, detect server vs. client components, inject macros, transform JSX. All of that happens at the AST level.

Before Brisa, I was already maintaining next-translate, an i18n library for Next.js. For the plugin that auto-injects locale loaders into pages, I used the TypeScript compiler API. It worked. It was also painfully slow; ts.createProgram() for every page file at build time, full type-checker instantiation, lib resolution. We had to add noResolve: true and noLib: true just to make it bearable. The parser was doing ten times more work than we needed because all we wanted was the AST, not the types.

When I started building Brisa, I knew I needed something faster. Something that gave me an ESTree-compliant AST without the overhead of a full compiler. That's how I found Meriyah.

Why I chose Meriyah over everything else

Meriyah is written entirely in JavaScript. No native bindings. No WASM loading step. No compilation step. Just parseScript(code, { jsx: true, module: true, next: true }) and you get back an ESTree AST in microseconds.

For Brisa's build pipeline, that speed difference compounds. Every source file in a Brisa project passes through Meriyah. The parser runs inside AST().parseCodeToAST(), which first transpiles via Bun's transpiler and then feeds the result to Meriyah. The output is a standard ESTree Program node that I can traverse, modify, and regenerate with astring.

But here's where it got interesting. Brisa has a feature called renderOn that lets you prerender components at build time. You write this in your page:

<SomeComponent renderOn="build" foo="bar" />

And at build time, the AST transform detects renderOn="build", replaces the JSX with a __prerender__macro() call, and injects this import at the top of the file:

import { __prerender__macro } from 'brisa/macros' with { type: 'macro' };

That with { type: 'macro' } is an import attribute that tells Bun's bundler to resolve the import at compile time. The component gets rendered during the build, and the result is injected as static HTML. The user writes renderOn="build", but under the hood the framework constructs ImportDeclaration and ImportAttribute AST nodes by hand and regenerates the code.

The problem: Meriyah didn't support import attributes when I started using it. So I contributed a PR to add the feature. That PR landed, and Brisa's entire prerender pipeline could work end to end.

Going from "the parser can't handle my syntax" to "I'll fix the parser itself" is the kind of thing that only happens when you deeply understand how ASTs work.

The inspiration

AST Explorer exists, and it's great. I use it regularly. It's the reference tool for exploring ASTs. I wanted to build something similar as part of Kitmul; my own version of an AST visualizer with parser selection, interactive tree view, and support for the parsers I use daily.

The AST Visualizer does exactly this. Paste JavaScript, pick your parser (Acorn, Meriyah, or SWC), and get an interactive tree or raw JSON. Everything runs locally in your browser.

The parser choice matters because each one produces a slightly different AST:

Acorn follows the ESTree spec strictly. It's the parser that ESLint uses internally. If you're writing ESLint rules, this is the tree your rule will traverse.
Meriyah also follows ESTree, but adds JSX support and bleeding-edge features via the next: true flag. It's the parser I chose for Brisa because it's fast, lightweight, and written in pure JS.
SWC is a Rust-based compiler that runs via WASM in the browser. Its AST uses a different structure; Module instead of Program, span objects instead of start/end positions. If you're working with Next.js or Turbopack internals, this is the AST you're dealing with.

Switching between parsers and seeing how the same code produces different trees is one of the fastest ways to understand parser differences. Try parsing const x = 42; with all three and compare the node types.

Three things the tree teaches you that docs don't

1. Expressions vs. statements are visible.

Every JavaScript developer hears "expression vs. statement" at some point. Few can articulate the difference until they see it in a tree. Consider:

x = 5;

The AST shows an ExpressionStatement wrapping an AssignmentExpression. The expression is the x = 5 part. The statement is the semicolon-terminated wrapper that makes it a standalone line. This distinction is why if (x = 5) is legal JavaScript; the assignment is an expression, and expressions are valid inside conditions.

2. Operator precedence becomes structural.

Parse 2 + 3 * 4 and you'll see:

BinaryExpression (operator: "+")
  ├─ left: Literal (2)
  └─ right: BinaryExpression (operator: "*")
           ├─ left: Literal (3)
           └─ right: Literal (4)

The multiplication is nested inside the addition's right operand. That's not a formatting choice; that's the parser encoding precedence into structure. The deeper node evaluates first. Parentheses change the tree structure, not some invisible priority flag.

3. Import attributes reveal how renderOn="build" works.

Parse this with Meriyah:

import { __prerender__macro } from 'brisa/macros' with { type: 'macro' };

The ImportDeclaration node gets an attributes array containing ImportAttribute nodes. Each attribute has a key and a value, both Literal nodes. This is the import that Brisa's build pipeline injects when it finds renderOn="build" on a component. The with { type: 'macro' } tells Bun to resolve the function at compile time. Without seeing the tree, you'd never guess that with { type: 'macro' } becomes a nested array of attribute objects.

Real use cases from building frameworks

I keep hearing "ASTs are for compiler people." No. ASTs are for anyone who writes tools that operate on code. Here's where I've actually used AST knowledge:

Framework build pipelines. In Brisa, every source file is parsed to an AST, analyzed for imports, transformed (macro injection, server/client separation, i18n processing), and regenerated as code. The central function is AST('tsx').parseCodeToAST(code), which returns an ESTree Program node. Without understanding the tree, I couldn't write a single one of those transforms.

Prerender macro injection via renderOn="build". When Brisa encounters <Foo renderOn="build" />, the AST transform constructs ImportAttribute nodes by hand to inject import {__prerender__macro} from 'brisa/macros' with { type: "macro" }. There's a quirk: Meriyah uses value on Literal nodes where astring expects name. That's an actual comment in the Brisa source code: // This astring is looking for "name", but meriyah "value". You only discover that kind of thing by staring at trees.

i18n loader injection. In next-translate-plugin, the Webpack loader uses ts.createProgram() to parse each page and detect its exports. It needs to know whether the page has getStaticProps, getServerSideProps, or a default export, so it can inject the right locale loader. The TypeScript AST uses SyntaxKind enums instead of string-based types, which is a different mental model from ESTree. Seeing both trees side by side clarifies the difference instantly.

Import path resolution. Brisa resolves relative imports to absolute paths at build time. The transform walks ImportDeclaration nodes, reads the source.value string, resolves it against the file system, and replaces it. This is 30 lines of code once you understand that ImportDeclaration.source is a Literal node with a value property.

The search feature saves more time than you'd expect

The visualizer includes a search bar that filters nodes by type, name, or value. Type "Identifier" and every identifier in the tree highlights. Type "import" and you find every import-related node instantly.

This sounds trivial until you're debugging a framework transform and you need to find every ImportDeclaration in a 200-line file. Scrolling through an expanded tree is slow. Searching for ImportDeclaration and seeing exactly where they sit in the hierarchy is fast.

Comparing parsers side by side

Feature	Acorn	Meriyah	SWC
Language	JavaScript	JavaScript	Rust (WASM in browser)
Spec	ESTree	ESTree	SWC AST
JSX support	No	Yes	Yes
Import attributes	No	Yes	Yes
Speed	Fast	Very fast	Fast (after WASM load)
Bundle size	~120KB	~320KB	~14MB (WASM)
Used by	ESLint	Brisa	Next.js, Turbopack

The point isn't that one parser is better. Each one has trade-offs. Acorn is the standard. Meriyah is the fast, feature-rich option. SWC is the heavyweight that handles everything but requires loading 14MB of WASM. The AST Visualizer lets you switch between all three and see the differences.

Five code snippets worth exploring

Paste these into the AST Visualizer and try each parser:

1. Arrow function with implicit return:

const add = (a, b) => a + b;

Notice how the ArrowFunctionExpression has expression: true and the body is a BinaryExpression, not a BlockStatement. That boolean flag is how tools distinguish => x from => { return x; }.

2. Import attributes (use Meriyah or SWC):

import { __prerender__macro } from 'brisa/macros' with { type: 'macro' };

With Meriyah, the ImportDeclaration gets an attributes array with ImportAttribute nodes. With Acorn, this syntax will throw a parse error. That's exactly the kind of parser difference that matters in practice; Brisa's build pipeline depends on it.

3. Optional chaining:

const value = obj?.nested?.deep?.property;

Each ?. creates a ChainExpression wrapping MemberExpression nodes with optional: true. The chain itself is a single node, not nested optionals.

4. Async/await:

async function fetchData() {
  const response = await fetch('/api/data');
  return response.json();
}

The FunctionDeclaration has async: true. The await keyword creates an AwaitExpression wrapping the CallExpression. This is why you can't use await outside an async function; the parser enforces the nesting.

5. Destructuring with defaults:

const { a = 1, b: { c = 2 } = {} } = config;

This generates a deeply nested tree. The defaults create AssignmentPattern nodes. The nested destructuring puts an ObjectPattern inside a Property value. This is the kind of structure where a tree view is worth a thousand words.

Privacy

All three parsers run entirely in your browser. Acorn and Meriyah are JavaScript libraries that execute client-side. SWC loads a WASM binary from a local file. No code is transmitted to any server. No analytics track what you paste. If you're parsing proprietary source code, nothing leaves your device.

If you're working with code that needs other kinds of analysis, the Visualizers & Logic Tools collection includes graph visualizers, truth table generators, and regex tools that pair well with AST work. For tracking your learning sessions, the Pomodoro Timer with built-in focus music is surprisingly effective for problem sets.

The actual takeaway

ASTs aren't magic. They're trees. Every piece of code you've ever written has a tree representation that a parser produces in milliseconds. The gap between "I've heard of ASTs" and "I can build a framework's compiler pipeline" is mostly about seeing enough trees that the patterns become obvious.

I went from struggling with the TypeScript compiler API in next-translate to contributing parser features to Meriyah for Brisa. The turning point wasn't reading more documentation. It was seeing enough ASTs that the node types became second nature.

The AST Visualizer won't teach you compiler theory. It'll teach you what the parser sees when it reads your code. For writing framework internals, build tools, codemods, and ESLint rules, that's the only thing that matters.

The AST Visualizer 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.

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.

Forem: Aral Roca

I Built a Free Invoice Generator, Resume Builder, and Cover Letter Generator That Don't Require Signup

Why I built these instead of recommending existing ones

The Invoice Generator: six templates and real math

The Resume Builder: five templates, all ATS-friendly

The Cover Letter Generator: the simple one done right

The privacy argument is real

What I'd build next

The O(n^2) Bug That Looked Like Clean Code

The O(n^2) trap hides in plain sight

Pattern 1: The innocent .includes() inside .filter()

Pattern 2: Deduplication by comparison

Pattern 3: The cascading .map().filter().map()

Pattern 4: The recursive tree flattener

Pattern 5: The SQL query in a loop (the N+1 problem)

How to catch quadratic complexity before production does

The real lesson

Dive deeper

The Shift from Determinism to Probabilism Is Bigger Than Analog to Digital

The first paradigm shift: analog to digital

The second paradigm shift: deterministic to probabilistic

Knowledge generation without precedent

The current limitations: why it's not perfect yet

The trajectory: approaching 100% accuracy

The bottleneck: classical compute vs. quantum compute

The hard problem: quantum error correction

What this means practically

The next step isn't better AI; it's a composable compute stack

Models talking to machines talking to models

When prediction takes nanoseconds

Knowledge beyond the human

The full stack

I Hid a Secret Message in a Cat Photo and Nobody Noticed for Six Months

What steganography actually is

How LSB encoding works

Hiding a message step by step

Detection and steganalysis; how to NOT get caught

When to combine steganography with encryption

Real-world use cases

The limits of pixel encoding

Try it yourself

I Stopped Paying for Subtitle Services After Running Whisper in a Browser Tab

How Whisper works (the short version)

The browser pipeline

Why client-side subtitles matter

The accuracy question

85% of social media videos play on mute

Subtitle formats: VTT vs SRT

The accessibility angle nobody talks about

Complementary workflow tools

Try it

Three Ways to Convert JSON to TypeScript. Only One Is Deterministic.

The manual approach: slow and accurate until it isn't

The LLM approach: fast and probabilistic

The deterministic approach: same input, same output, every time

What the algorithm actually does

Interface vs. type: when the toggle matters

Where deterministic inference still needs human review

Privacy as a feature, not a marketing line

A practical workflow

Beyond API responses

The tradeoff matrix

The bottom line

My Friends Spent 14 Minutes Deciding Where to Go Train. A Wheel Spinner Fixed It in 3 Seconds.

Why humans are terrible at random selection

Where a random wheel actually solves real problems

Classrooms

Team decisions and retrospectives

Giveaways and content creation

How Math.random() actually works under the hood

The privacy argument

When not to use a wheel

The 14-minute rule

How to Create 360 Panoramas with GPT Image 2 and View Them Interactively

What you will learn

What is an equirectangular image

Step 1: Open ChatGPT with GPT Image 2

Step 2: Write the prompt

Base prompt template

Example prompt: Gothic cathedral interior

Pattern 1: The innocent `.includes()` inside `.filter()`

Pattern 3: The cascading `.map().filter().map()`