LLBBL Blog

AI-Assisted vs AI-Agentic Coding

Sun, 19 Apr 2026 10:00:00 -0500

There are two ways to work (c0de) with AI tools right now. I think most people know the other one exists, but they haven’t taken the time to try it. You should know how to do both. And when to do both.

Assisted Mode

Everybody knows this one. You write some code, you get stuck, you ask a question.

How does date parsing work in Python? What’s this function do? Haven’t we built this already? I need some fucking Regex again.

The AI answers. You copy-paste or accept the suggestion. You keep going. You’re driving. The AI is in the passenger seat reading the map.

I mean, this is really useful. I’m not going to pretend it isn’t. It’s also just autocomplete with opinions. Fancy autocomplete. Smart autocomplete.

Great. You’re doing the thinking. You’re deciding what gets built and how to structure it and what order to do things in. You’re just asking for help on some of the blanks. That’s assisted mode.

Agentic Mode

This is different.

You describe what you want. You need to know how to describe what you want.

That is extremely important. Let me say that again. You need to know how to describe what you want.

You need to build an agent that understands how to interpret your description as what you want.

Sometimes it’s going to get it correct and sometimes it’s not. It’s going to go in a different direction than you wanted and you’re going to have to correct it. That’s the job now. You’re reviewing the output, the code, and how it’s producing the code. What are the gaps? You have to find the gaps and improve the agent so that it understands you better.

When I Use Which

I wish I had a clean rule for this. I don’t. That’s the vibes part.

Small or specific things can be assisted. Quick answers. Great. Easy. Move on.

Once you start wanting to touch multiple files, agentic. Major features like commands or parser changes or handler rewrites, recipes or tests. I’m not writing all that by hand. I can describe what I want way better than I can autocomplete it.

Bug fixes? Depends. If I already know where the bug is, assisted. If I don’t, agentic. Let the agent grep around and figure it out. It’s better at reading a whole codebase quickly than I am. Not better at understanding it. Better at reading it.

New features? Almost always agentic. I describe the feature, point it at similar code in the repo, and let it go.

Again, review is super important. Sometimes you have to send it back or start over or change major portions of it. And if you build a system that learns, it’ll get better along the way.

The Review Problem

Switching to agentic mode, your entire job is code review. All day, all the time, constant. That’s the human’s job. Code review.

Are you good at code review? You should get better at it. You need to get better at it.

This is not whether or not the tests pass. You need to identify possible issues and then describe tests that can check for those issues.

The nuanced bugs are the worst. And if those make it to production, you’re going to have problems.

Don’t skim the diff.

That should be the new motto. Read the code. Get better at code comprehension. It’s extremely important. You may be writing less code but you need to sure as shit understand what the code is doing and how it can be bad.

The Hybrid Reality

It’s totally fine to switch between modes depending on what you’re doing or your work session. Agentic can be way more impactful, but assisted mode is way better at helping you understand what the code is doing because you can select code blocks and easily ask questions about it.

So it’s not a toggle, it’s a spectrum. Now isn’t that funny? I’m on the spectrum of agentic development.

Where are you on the spectrum of agentic development?

So Which Is Better?

Neither. Both. It depends. Whatever, just build stuff.

Is assisted mode safer? Really? Like, does the human actually write better code this way? I don’t know. Agentic mode can be faster and you need to be super careful that it’s not gaslighting you into thinking it knows what it’s doing.

Build software for you. And when it makes sense, help out with the community stuff. Support open source.

If you’re a developer, I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week. Or you can find me on Mastodon at @logan@llbbl.blog.

Most Dev Blogs Die

Sat, 18 Apr 2026 14:00:00 -0500

#MDBD

Most developers have started a blog at some point. Almost none of them are still writing.

Don’t start a blog. You already know the reasons why you should.

It’s good for your career,
it helps you learn,
it builds an audience,
whatever.

Maybe the interesting question isn’t “why should I blog” but “why did I stop.”

The Work Nobody Talks About

Writing at 30% the effort. NO wait. I mean Writing is just a small part of it. Yea, right.

You might, have you considered, possibly, that you perhaps, need a topic.

You need to know what you are talking about, you need to research it.

Truth matters, I guess, probably still right?

I mean, certainly add to the conversation, that that matters.

Publishing is the easy part. Maintaining a unique presence on multiple platforms is not.

What started as “I should write about this thing I learned” quickly turns into a quarter-day or half-day ordeal.

And that’s one post. Now there is tomorrow. And after that, another day.

You need a topic. You need a topic. You need a topic. You need a topic.

It Becomes Work

At some point, blogging stops being fun and interesting and becomes something you have to do. It feels like an obligation. You’re forcing yourself to sit down and write.

This matters to me because I’m currently on a daily publishing streak. Every day is a struggle on what to talk about.

You know what’s fun? Side projects. Building things. Tinkering with a new language on a Monday morning because you saw someone post about it. Writing about that? Easy. Staring at a blank editor trying to come up with something insightful about React server components? Sometimes fun.

Write about the fun stuff. The rest will follow. Or it won’t. That’s fine too.

What Actually Keeps One Going

I don’t have all the answers. I barely have some of the answers. But here’s what I’m doing.

I built a system. A whole content pipeline. CLI tools. Posts go through a lifecycle: draft, schedule, push. The system is not responsible for inspiration. It just managed those things. Markdown.

I lowered the bar. Way down. Not everything has to be a certain number of words. I don’t even know what my best-performing posts are. Isn’t that crazy? I have no idea. I don’t check. I’ll care later, maybe.

I write about what I’m already doing. What are you working on right now? That’s your next post. What are you interested in? What are you using that could be better? There. Done. You have a topic.

No wait, nevermind. Ah crap, I need another topic.

I stopped optimizing. You don’t have to figure out all the things you should be doing. Keywords. Thumbnails. Social media strategy. Just get the words out. The words are the hard part. Everything else is a distraction disguised as productivity.

The Commitment Problem

Blogging is a commitment. That’s the whole problem. Nobody is going to fire you for not posting this week. Nobody is likley two notice. :D

Streaks work for some people and not others. I’m on day 102 of one. Don’t ask me why I doing this to myself.

If you’re a developer, I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week. Or you can find me on Mastodon at @logan@llbbl.blog.

Sat, 18 Apr 2026 11:58:17 -0500

reply to this with blog post ideas. your neighborhood tech blogger thanks you.

Claude Opus 4.7 Is Here

Fri, 17 Apr 2026 10:00:00 -0500

Anthropic just announced Claude Opus 4.7 yesterday, and here is my take on the new model after reading the blog post and doing a bit of research on their rollout plans from previous models.

What’s New

The headline is a 13% improvement on a 93-task coding benchmark over Opus 4.6. Rakuten’s SWE-Bench saw 3x more production tasks resolved, which is the kind of real-world metric that actually matters. Benchmarks are one thing, but “can it handle my actual codebase” is another.

The big quality-of-life improvement is that Opus 4.7 is better at verifying its own output before telling you it’s done. If you’ve ever had a model confidently hand you broken code and say “there you go,” you know why this matters. It handles long-running tasks with more precision, and the instruction following is noticeably tighter.

There’s also a major vision upgrade. The new model accepts images up to 2,576 pixels on the long edge, which is more than 3x the resolution of previous Claude models. If you’re working with technical diagrams, architecture charts, or screenshots of code, that’s a real improvement.

When Can You Actually Use It?

For enterprise customers, Anthropic says Opus 4.7 is available from your cloud vendor: the API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. But most of us aren’t using the API directly.

As of right now, Opus 4.7 is not yet available in Claude Code or the desktop app. It’s also not showing up in the model picker on claude.ai for Pro plan users. Anthropic’s announcement says “available today across all Claude products,” but that doesn’t seem to have fully rolled out yet for consumer plans.

Looking at previous releases, Opus 4.6 launched on February 5th and was accessible on claude.ai and the API the same day. Historically, Anthropic hasn’t gated new Opus models behind higher tiers, so there’s no reason to think Pro, Max, Team, and Enterprise won’t all get access. The question is just when. If past patterns hold, it should show up within a few days. Keep checking your model picker.

Claude Code Users

As of today, Claude Code on the stable release is still on Opus 4.6. I’m not sure if it’s available on the bleeding edge builds, but for most people it’s not there yet.

The announcement mentions a few Claude Code features coming with 4.7:

/ultrareview is a new slash command for dedicated code review sessions. Pro and Max users get three free ultrareviews to try it out.
Auto mode has been extended to Max plan users, letting Claude make more decisions autonomously.
The default effort level is being bumped to xhigh (a new level between high and max), which means the model will spend more time reasoning through harder problems.

Once Opus 4.7 does show up in Claude Code, remember to check any custom agents or skills that have a model hardcoded in the frontmatter. If you’ve got claude-opus-4-6 specified in your .claude/commands/ directory or agent configurations, those will keep using the old model until you update them.

Anthropic also notes that Opus 4.7 follows instructions more literally than previous models. Prompts written for earlier models can sometimes produce unexpected results. So if something feels off after switching, it’s worth re-tuning your prompts.

The Tokenizer and Cost Changes

One thing to be aware of: the tokenizer has been updated. The same input text will produce 1.0 to 1.35x more tokens than before. That means your costs could go up slightly even at the same per-token pricing ($5/million input, $25/million output, unchanged from 4.6). Not a dealbreaker, but worth watching if you’re running high-volume workloads.

Pricing hasn’t changed, the coding improvements look useful, and important to know that the model ID is claude-opus-4-7. Keep an eye on your model picker over the next few days.

Agentic Development Trends: What's Changed in Early 2026

Thu, 16 Apr 2026 14:00:00 -0500

I’ve been following the agentic development space around Claude Code and similar tools and the last couple months have been interesting. Here’s what I’m seeing as we move through March and April 2026.

From Solo Agents to Coordinated Teams

The biggest shift is that more people are moving away from trying to build one agent that does everything. Instead, we’re seeing coordinated teams of specialized agents managed by an orchestrator, often running tasks in parallel. I think this is the more proper use of these systems, and it’s great to see the community arriving here.

If you’re curious about the different levels of working with agentic software development, I created an agentic maturity model on GitHub that goes into more detail on this progression.

Long-Running Autonomous Workflows

Early on, agents handled what were essentially one-shot tasks. Now in 2026, agents can be configured to work for days at a time, requiring only strategic oversight at key decision points. Doesn’t that sound fun? You’re still the bottleneck, but at least now you’re a strategic bottleneck.

Graph-Based Orchestration

Frameworks like LangGraph and AutoGen are converging on graph-based state management to handle the complex logic of multi-agent workflows. I think this makes sense when you consider the branching and conditional logic of real-world tasks could map naturally to graphs.

MCP Is Everywhere

MCP (Model Context Protocol) has become the industry standard for tool integration. All vendors fully support it, and there’s no sign of slowing down. Every week there are new MCP servers popping up for connecting agents to different services and tools.

Unified Agentic Stacks

The developer tooling is becoming more consistent. Cursor is becoming more like Claude Code, and Codex is becoming more like Claude Code. Maybe you see a pattern there… might tell you something about who’s setting the pace.

What is also noteable, people are experimenting with using different tools for different parts of the workflow. You might use Cursor to build the interface, Claude Code for the reasoning and main logic, and Codex for specific isolated tasks. Mix and match based on strengths.

Scheduled Agents and Routines

Claude Code recently released routines or scheduled or trigger-based automations that can run 24/7 on cloud infrastructure without needing your laptop. Microsoft with GitHub Copilot are working on similar capabilities? Cursor had something like this a while back too.

Security Gets Serious

Two things happening here. First, people are getting better at leveraging agents for security reviews and monitoring. Tasks that previously required highly specialized InfoSec expertise. You no longer need to be a hacker to find vulnerabilities; you can let your AI try to hack you.

However, the same capabilities that harden defenses can also be used for offensive attacks. We’re seeing a major push for security-first architecture as a requirement for all new applications, specifically to defend against the rise of agentic offensive attacks. Red team and blue team are both getting AI-pilled.

FinOps: Watching the Bill

Last on the list is financial operations. Inference costs now account for over half of AI cloud spending according to recent estimates. Organizations are prioritizing frameworks that offer explicit cost monitoring and cost-per-task alerts. Getting granular about how much you’re spending to solve specific problems and optimizing at the task level. I think that’s pretty interesting and something we’ll see a lot more tooling around.

The common thread across all of these trends is maturity. We’re past the “wow, an AI wrote code” phase and into “how do we make this reliable, secure, and cost-effective at scale.” That’s a good place to be.

Why javascript:void(0) Needs to Stay in the Past

Wed, 15 Apr 2026 22:35:00 -0500

A few months ago, I ran across a javascript:void(0) in the wild. I’m not going to get into the specific context because it doesn’t really matter, also it gets a bit too personal for this blog post. But I took a screenshot, thought “huh, that’s weird,” and promptly forgot about it.

Then I was scrolling back through my screenshots and found it again. So here we are. Let’s talk about javascript:void(0) and why you shouldn’t be using it in 2026.

Here’s the screenshot that started this:

What Does It Actually Do?

If you’ve never encountered this pattern before, here’s the quick version. void is a JavaScript operator, so not a function, and its only job is to evaluate the expression next to it, throw away the result, and return undefined. That’s it. That’s the whole job.

When a browser receives undefined from clicking a link, it does nothing. No navigation, no page refresh. It’s a way to override the browser’s default behavior for an anchor tag.

In practice, it looked like this:

<a href="javascript:void(0);" onclick="openModal()">Click Me</a>

The href prevents the browser from doing anything, and the onclick fires whatever JavaScript you actually wanted to run. Clever? Sure. A good idea today? No.

Why Did We Use It?

Back in the day, we wanted to stop the browser from doing its default thing, following a link, so we could trigger events and make web pages more interactive. This was typically done on anchor tags because, well, that’s what we had. JavaScript didn’t give us a better way to handle it at the time, so javascript:void(0) became the go-to pattern.

It worked. But “it works” and “it’s a good idea” are two very different things.

Three Reasons to Stop Using It

1. It Breaks the Anchor Tag’s Purpose

The biggest issue is that javascript:void(0) completely overrides what an anchor tag is supposed to do. An <a> tag exists to link to things. When you stuff JavaScript into the href, you’re hijacking the element’s entire reason for existing.

We’ve moved on from needing to do this. If you want something clickable that triggers behavior, use a <button>. If you want a link that also has JavaScript behavior, give it a real URL as a fallback.

2. Separation of Concerns

Modern best practices tell us that HTML should define the structure of the page, and JavaScript should define the behavior. When you’ve got JavaScript living inside an href attribute or relying on inline onclick handlers, you’re mixing the two in ways that make code harder to maintain and reason about.

The better approach? Use event.preventDefault() in your JavaScript:

<a href="/fallback-page" id="myLink">Click Me</a>

document.getElementById('myLink').addEventListener('click', function(event) {
  event.preventDefault();
  openModal();
});

This way, if JavaScript is disabled or fails to load, the link still works. There’s a fallback behavior, which matters for accessibility and backwards compatibility. The HTML stays clean, and the behavior lives where it belongs, in your JavaScript files.

Now, I will say that plenty of modern front-end frameworks add their own semantic patterns and play pretty loosey-goosey with this separation of concerns rule. But even React’s onClick handlers and Vue’s @click directives are compiled and managed in a way that’s fundamentally different from jamming raw JavaScript into an HTML attribute.

3. Content Security Policy Will Block It

I’d like to believe Security still matters in 2026 so lets talk about the Content Security Policy (CSP).

CSP is a set of rules that a web server sends to the browser via HTTP headers, telling the browser what resources the page is allowed to load or execute. Before CSP, browsers just assumed that if code was in the HTML document, it was meant to be there. Web pages were incredibly vulnerable to cross-site scripting (XSS) attacks.

With CSP, the server tells the browser: “Only execute JavaScript if it comes from my own domain. Do not execute any code written directly inside the HTML file.”

A proper CSP header looks something like this:

Content-Security-Policy: default-src 'self'; script-src 'self';

This is great for security. But guess what javascript:void(0) is? Inline JavaScript. A strict CSP will block it.

So if you see a site still using javascript:void(0), check the response headers. Chances are you’ll find something like:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline';

See that 'unsafe-inline' addition? That’s the security risk. By adding unsafe-inline, the developer is telling the browser to trust all inline scripts. Every single one. So if an attacker manages to inject JavaScript onto the page, the browser will execute it without hesitation.

You’re weakening your entire site’s security posture just to keep a legacy pattern alive. That’s not a tradeoff worth making.

You Probably Don’t Even Need to Think About This

If you’re working with any modern JavaScript framework, this problem is already solved for you.

React, Svelte, Vue, Solid, whatever you’re using, they all ship components that handle default browser behavior the right way. Take forms as an example. The raw HTML <form> element will, by default, submit and trigger a full page navigation. That’s why developers used to manually call event.preventDefault() everywhere. But now, frameworks like Next.js, Remix, and SvelteKit give you a <Form> component (or equivalent) that overrides that default behavior for you. No page reload. No manual prevention.

The same applies to links, buttons, and pretty much any interactive element. The framework’s component handles the wiring so you don’t have to remember the low-level browser quirks. You import the component, use it, and move on.

That’s the real reason javascript:void(0) feels so out of place in 2026. It’s not just that we have better patterns available, but the tooling has abstracted the problem away entirely. The history is worth knowing, because understanding why things work the way they do makes you a better developer!

The Human's Guide to the Command Line: From Script to System

Wed, 15 Apr 2026 10:00:00 -0500

This is Part 3 of The Human’s Guide to the Command Line. If you missed Part 1 or Part 2, go check those out first, you’ll need the setup from both.

In Part 2, we built a note-taking app. It works. But running it looks like this:

uv run ~/code/note/note.py add "call the dentist"

That’s… not great. Real command-line tools don’t make you remember where a Python file lives. You just type the name and it works. By the end of this post, you’ll be able to type:

note add "call the dentist"

From anywhere on your computer. Let’s make that happen.

Why Can’t I Just Type `note`?

When you type a command like ls or brew, your shell doesn’t search your entire computer for it. It checks a specific list of directories, one by one, looking for a program with that name. That list is called your PATH.

You can see yours right now:

echo $PATH

You’ll get a long string of directories separated by colons. Something like /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin. When you type brew, the shell checks each of those directories until it finds a match.

Right now, note.py is sitting in ~/code/note/. That folder isn’t in your PATH, so the shell has no idea it exists. We need to turn our script into something installable, and put it somewhere the shell knows to look.

Restructuring Your Project

Python has specific expectations about how a project needs to be organized before it can be installed as a tool. Right now your project looks like this:

note/
  pyproject.toml
  note.py

We need to reorganize it into a package. Here’s what we’re aiming for:

note/
  pyproject.toml
  src/
    note/
      __init__.py
      cli.py

Let’s do it step by step. Open Ghostty and navigate to your project:

cd ~/code/note

Create the new directories

mkdir -p src/note

The -p flag means “create parent directories too.” This creates both src/ and note/ inside it in one shot.

Move your script

mv note.py src/note/cli.py

Your note-taking code now lives at src/note/cli.py instead of note.py.

Create the package marker

touch src/note/__init__.py

This creates an empty file. Python uses __init__.py to recognize a folder as a package — it can be completely empty, it just needs to exist.

Update pyproject.toml

Open your project in Zed:

zed .

Find pyproject.toml in the sidebar and open it. You need to add two things. First, tell uv where your code lives by adding this section:

[tool.uv]
package = true

Then add this section to define your command:

[project.scripts]
note = "note.cli:main"

That line is doing something specific: it’s saying “when someone types note, find the note package, go into the cli module, and call the main function.” That’s the same main() function at the bottom of the code we wrote in Part 2.

Your full pyproject.toml should look something like this (the exact version numbers may differ):

[project]
name = "note"
version = "0.1.0"
description = "A simple command-line note taker"
requires-python = ">=3.12"
dependencies = []

[tool.uv]
package = true

[project.scripts]
note = "note.cli:main"

Verify the structure

Run this in Ghostty to make sure everything looks right:

ls -R src/

You should see:

src/note:
__init__.py  cli.py

Installing It For Real

Here’s the moment. From your project directory (~/code/note), run:

uv tool install .

That . means “install the project in the current folder” — same dot from Part 2 when we ran zed . to mean “open this folder.”

What just happened? uv created an isolated environment for your tool and dropped a link to it in ~/.local/bin/. That directory is on your PATH (or should be), which means your shell can now find it.

Try it:

note list

You should see your notes from Part 2 (or “No notes yet” if you cleared them). Try adding one:

note add "I installed my first CLI tool"
note list

That works from anywhere. Open a new terminal tab, navigate to your home directory, your Desktop, wherever… note just works now.

If you get “command not found”: Run uv tool update-shell and then restart your terminal. This adds ~/.local/bin to your PATH in .zshrc so your shell knows where to find tools installed by uv.

One thing to know about editing

When you ran uv tool install ., uv copied your code into its own isolated environment. That means if you go back and edit src/note/cli.py, your changes won’t show up until you reinstall:

uv tool install --force .

The --force flag tells uv to overwrite the existing installation. During development, you could also use uv tool install -e . (the -e is for “editable”) which keeps a live link to your source code so changes show up immediately without reinstalling.

You went from a Python script you had to run with uv run note.py to a real command that works from anywhere on your machine.

Welcome to your first CLI!

How Active Noise Canceling Actually Works

Tue, 14 Apr 2026 10:00:00 -0500

I’ve been thinking about how headphones work. What’s actually happening in there? Let me try and break down how active noise canceling (ANC) works, and how pass-through mode decides what sounds to let in.

It’s All About Destructive Interference

Sound is a pressure wave moving through air. And here’s the thing about waves: if you produce an identical wave that’s perfectly inverted, 180 degrees out of phase, the wo cancel each other out. That’s the entire principle behind ANC.

Modern headphones have multiple external microphones on each ear cup that are continuously sampling ambient noise in real time. Those audio signals get fed into a digital signal processor (DSP) chip, which analyzes the waveforms and generates an inverted version. The inverted signal is then played through the drivers into your ear at the same time the real-world sound arrives.

So the noise gets canceled before it hits your eardrum. Simple concept, incredibly complex the more you learn about it.

Speed Is Everything

The entire chain, from the mic capture to waveform inversion to playback has to happen in microseconds in order to beat the incoming sound wave. This is why ANC works best on predictable, steady sounds like airplane engines, road rumble, or HVAC hum. Those low-frequency drones are easy to predict and easy to invert.

Higher-frequency or more modulated sounds, like human voices, are harder to predict. The waveforms change too quickly and irregularly for the DSP to perfectly cancel them out. That’s why you can still hear someone talking to you even with ANC cranked up. The algorithm just can’t keep up with the complexity of speech.

Hybrid ANC: The Second Pass

Modern headphones use what’s called hybrid ANC, which adds microphones on the inside of the ear cups in addition to the external ones. This gives the DSP a second correction pass. The external mics handle the initial cancellation, and the internal mics pick up whatever noise leaked through the ear cups and apply another round of inversion.

It’s basically error correction for sound. Pretty clever.

How Pass-Through Mode Works

Pass-through (or transparency mode, or ambient sound, every brand calls it something different) is essentially ANC running in reverse. Instead of canceling out the world, you’re selectively letting it in.

The external microphones are still sampling ambient audio and the DSP is still processing it. But now the headphones are reproducing a version of the outside world through the drivers, as you would have heard it without headphones on.

The DSP can selectively boost certain frequency ranges, like the range where human speech commonly occurs, while reducing others like wind noise or low-frequency rumble. So pass-through mode isn’t just “turning off” noise canceling. It’s actively shaping what you hear.

In transparency mode, ANC is still running. It’s just operating at a reduced level. The system is always actively managing your audio environment.

Now how much of the outside world you are letting in is maybe a different topic for another day.

What Would Minimum Wage Be If It Kept Up With Housing?

Mon, 13 Apr 2026 14:00:00 -0500

I pulled the data and verified the math. The answer is… not great.

The Numbers We’re Working With

In 1950, the federal minimum wage was $0.75 per hour. A median owner-occupied single-family home cost $7,354.

In 2026, the federal minimum wage is $7.25 per hour — unchanged since 2009. The median U.S. family home price is $429,129.

These numbers come from multiple independent sources. Let’s see what happens when we put them side by side.

The Home-Labor Index

I’m using a simple metric here: how many hours of minimum-wage work does it take to buy a median home? No mortgages, no interest rates, no down payments; just raw labor hours versus home price.

1950:

$7,354 ÷ $0.75/hr = 9,805 hours
At 40 hrs/wk × 52 wks = 2,080 hrs/yr
That’s 4.71 years of full-time minimum-wage work

2026:

$429,129 ÷ $7.25/hr = 59,191 hours
Same 2,080 hrs/yr
That’s 28.46 years of full-time minimum-wage work

In 1950, a minimum-wage worker needed under 5 years of gross income to cover a median home. In 2026, that same worker needs over 28 years. The ratio has gotten roughly six times worse.

So What Should Minimum Wage Be?

If we wanted to preserve the same home-purchasing power that a minimum-wage worker had in 1950, we can work backwards:

2026 Median Home Price ÷ 1950 Home-Labor Index
$429,129 ÷ 9,805 hours = $43.77 per hour

We can verify this another way. The 1950 ratio was 4.714 years of income to buy a home. To maintain that ratio in 2026:

$429,129 ÷ 4.714 = $91,029/yr required income
$91,029 ÷ 2,080 hours = $43.76/hr

Both methods land in the same place. To have the same relationship between minimum wage and housing that existed in 1950, the federal minimum wage would need to be roughly $43.77 per hour

You don’t need a PhD to look at these numbers and see the wage gap disparity. The gap between wages at the bottom and the cost of the most basic economic asset, a home, has grown dramatically. That the gap exists isn’t debatable.

The federal minimum wage has been $7.25 since 2009. That’s 17 years without an increase. Meanwhile, median home prices have roughly doubled in that same period.

If we cared about the citizens, we’d need to 6x the minmum wage while also working at more affordable housing for the middle class.

Mon, 13 Apr 2026 11:55:50 -0500

Time-Series PostgreSQL at Petabyte Scale

From the creators of TimescaleDB — the PostgreSQL platform trusted by enterprises processing trillions of metrics daily. Start a free trial or get a demo.

Mon, 13 Apr 2026 11:55:32 -0500

Ghost — The first database designed for agents

Postgres databases for agents. Unlimited forks. Hard caps. No surprise bills.

What Is an AI Agent, Actually?

Mon, 13 Apr 2026 10:00:00 -0500

We need some actual definitions. The word “agent” is getting slapped onto every product and service, and marketers aren’t doing anybody favors as they SEO-optimize for the new agentic world we live in. There’s a huge range in what these things can actually do. Here is my attempt at clarity.

The Spectrum of AI Capabilities

Chatbot / Assistant — This is a single conversation with no persistent goals and no tool use. You ask it questions, it answers from a knowledge base. Think of the little chat widget on a product page that helps you find pricing info or troubleshoot a common issue. It talks with you, and that’s about it.

LLM with Tool Use — This is what you get when you open “agent mode” in your IDE. Your LLM can read files, run commands, edit code. A lot of IDE vendors call this an agent, but it’s not really one. It’s a language model that can use tools when you ask it to. The key difference: you are still driving. You give it a task, it does that task, you give it the next one.

Agent — Given a goal, it can plan and execute multi-step workflows autonomously. By “workflow” I mean a sequence of actions that depend on each other: read a file, decide what to change, make the edit, run the tests, fix what broke, repeat. It has reasoning, memory, and some degree of autonomy in completing an objective. You don’t hand it step-by-step instructions. You describe what you want done, and it figures out how to get there.

Sub-Agent — An agent that gets dispatched by another agent to handle a specific piece of a larger task. If you’ve used Claude Code or Cursor, you know what I’m talking about. The main agent kicks off a sub-agent to go research something, review code, or run tests in parallel while it keeps working on the bigger picture. The sub-agent has its own context and tools, but it reports back to the parent. It’s not a separate autonomous agent with its own goals. It’s more like delegating a subtask.

Multi-Agent System — Multiple independent agents coordinating together, either directly or through an orchestrator. The key difference from sub-agents: these agents have their own goals and specialties. They negotiate, hand off work, and make decisions independently. Think of a system where one agent monitors your infrastructure, another handles incident response, and a third writes the postmortem. Each Agent is operating autonomously but aware of the others.

So How Is Something Like OpenClaw Different From a Chatbot?

A chatbot is designed to talk with you, similar to how you’d just talk with an LLM directly. OpenClaw is designed to work for you. It has agency. It can take actions. It’s more than just a conversation.

Obviously, how much it can do depends on what skills and plugins you enable, and what degree of risk you’re comfortable with. But here’s the interesting part: it’s proactive. It has a heartbeat mechanism that keeps it running continuously in the background. It’ll automatically check on things or take action on a schedule you specify, without you having to prompt it.

A Few Misconceptions Worth Clearing Up

OpenClaw is just one specific framework for building and orchestrating agents, but the misconceptions around it apply broadly.

“Agents have to run locally." That’s how OpenClaw works, sure. But in reality, the enterprise agents are running invisibly in the background all the time. Your agent doesn’t need to live on your laptop.

“Agents need a chat interface." Because you can talk to an agent, people assume you must have a chat interface for it to be an agent. But by definition, agents don’t require a conversation. They can just run in the background doing things. No chat window needed.

“Sub-agents are just function calls." This one trips up developers. When your agent spawns a sub-agent, it’s not the same as calling a function. The sub-agent gets its own context window, its own reasoning loop, its own tool access. It can make judgment calls the parent didn’t anticipate. That’s fundamentally different from passing arguments to a function and getting a return value.

Why Write This Down

I mainly wrote this for myself. I keep running into these terms and needing a mental model to put them in context, so as I’m thinking about building agentic systems and trying to decide what level of capability I actually need for a given problem. The process of writing it down makes those decisions somewhat easier.

Mon, 13 Apr 2026 09:56:37 -0500

A Concrete Definition of an AI Agent

An AI agent pursues a goal by iteratively taking actions, evaluating progress, and deciding next steps. Useful agents must be reliable, adaptive, and accurate.

Sun, 12 Apr 2026 09:59:10 -0500

Card games today with BoardGame friend. Going to try Star Wars Unlimited and 5 minute dungeon. Have you tried either and what did you like about them?

SvelteKit Forms: Back to Basics (And Why That's a Good Thing)

Sat, 11 Apr 2026 10:00:00 -0500

Before we talk about SvelteKit, we should touch on how React form handling works. I’m writing this to remind myself of the modern way to do it…

You set up useState for every input field
Write onChange handlers to update state on every keystroke
Add an onSubmit handler to prevent the browser’s default behavior, construct a JSON payload, fire off a fetch request
Manage loading state to disable the submit button
Manually parse the response to show success or error messages.

That’s a lot jumps to be hooped.

Frameworks like Next.js have improved this with server actions, but the fundamental approach remains the same: a cage match with the browsers native form handling.

SvelteKit takes a completely different approach. It just uses regular HTML.

How SvelteKit Forms Work

In SvelteKit, you write a standard <form method="POST"> in your +page.svelte file. That’s your UI. Then, in a +page.server.ts file in the same directory, you export an actions object that handles the submission.

The server-side action receives a request object, extracts the form data, runs your logic, and returns either a redirect or a fail with validation errors. No client-side state management, no manual fetch calls, no JSON serialization.

// +page.server.ts
export const actions = {
  default: async ({ request }) => {
    const data = await request.formData();
    const email = data.get('email');
    const password = data.get('password');

    if (!email) {
      return fail(400, { email, missing: true });
    }

    // authenticate user...
    throw redirect(303, '/dashboard');
  }
};

If you’re a backend developer coming from Python or Ruby, this should feel familiar. The browser collects the data, posts it to a URL, and the server processes it. Stateless, reliable, and native.

Progressive Enhancement: The Best of Both Worlds

You might be thinking, “Okay, but I don’t want full page reloads every time someone submits a form.” Fair point. SvelteKit handles this with something called progressive enhancement. You add use:enhance to your form tag:

<form method="POST" use:enhance>
  <!-- your inputs -->
</form>

That single directive tells SvelteKit to automatically intercept the submission, prevent the page reload, submit the data via fetch under the hood, and update the form prop with any validation errors returned from the server.

But wait there’s more.

If JavaScript fails to load or the user is on a terrible connection, the form still works. It falls back to the browser’s native POST request.

Your form doesn’t break just because a script didn’t load. That’s how the web is supposed to work.

The React approach treats the browser as a rendering target and reimplements everything in JavaScript. SvelteKit treats the browser as a platform and builds on top of what’s already there.

Now, don’t get me wrong. I’ll write React code any day of the week at the ole w2, but I am really liking how Svelte and SvelteKit has decided to approach these sorts of features.

Routing in SvelteKit vs Next.js vs Astro

Fri, 10 Apr 2026 10:00:00 -0500

Continuing my series on Svelte, I want to dig into how SvelteKit handles routing and how it compares with Next.js and Astro. These are the frameworks I am most familiar with, so apologies if you wanted a different framework.

Let’s start with everybody’s favorite topic: routing. Okay, maybe I’m the only one excited about this, but stick with me.

Astro: The Traditional Approach

Astro’s routing feels the most traditional of the three. You have a src/pages/ directory, and the file name is the route. So src/pages/dashboard.astro maps to /dashboard. If you’ve worked with PHP or other languages with file-based routing, this will feel immediately familiar.

Inside the .astro file, you separate your backend logic at the top of the file with --- fences. That code runs entirely on the server, and everything below is your HTML template. Clean and straightforward.

Next.js: Folder-Based with the App Router

Next.js (the current versions, at least) uses the App Router. The structure is folder-based: app/dashboard/page.tsx maps to /dashboard. The key difference from Astro is that the folder name determines the route, but the file must always be called page.tsx.

By default, everything in the app directory is a server component, meaning it runs on the server. If you want client-side interactivity, you explicitly add "use client" at the top of the file. You can also set "use server" if you want to be explicit, but it’s the default. I think Next.js does a really good job of making it clear what runs where.

SvelteKit: Convention Over Configuration

SvelteKit also uses folder-based routing, similar to Next.js. The structure is src/routes/dashboard/, but instead of page.tsx, SvelteKit uses a reserved + prefix for its special files:

+page.svelte — Renders on the server, then hydrates on the client
+page.server.ts — Runs only on the server (data loading, form actions)
+server.ts — A raw API endpoint with no UI

There’s no "use client" or "use server" directive. The file naming convention itself tells SvelteKit what should run where. If you fetch a database record in +page.server.ts, that data is returned as an object, fully typed, and available in your +page.svelte via the $props rune. It just works.

The Case for Standard File Names

I can see if some people get annoyed that every route has files named +page.svelte and +page.server.ts. The files will all look the same in the IDE, but there’s a real advantage here: you can group all related components in the same route folder.

For example, if you’re building a dashboard, you can keep your DashboardChart.svelte, DashboardFilters.svelte, and other components right alongside your +page.svelte and +page.server.ts. You always know which file is the route entry point, which handles server logic, and which are supporting components. It encourages logical grouping instead of scattering related files across the project.

Quick Comparison

Feature	Astro	Next.js	SvelteKit
Route structure	File name = route	Folder + `page.tsx`	Folder + `+page.svelte`
Server/client split	`---` fences	`"use client"` directive	File naming convention
API routes	`src/pages/api/`	`app/api/route.ts`	`+server.ts`
Default rendering	Server	Server	Server + hydration

All three frameworks use file-based routing, but they each have a slightly different philosophy about how to organize and separate concerns. Astro keeps it simple with traditional file mapping. Next.js gives you explicit directives. SvelteKit leans on naming conventions to keep things clean.

I think I can get used to the + prefix convention in SvelteKit. The type safety between your server file and your page component is nice.

Next up in the series, I’ll dig into how each framework handles data loading and forms.

Thu, 09 Apr 2026 18:33:07 -0500

MergePHP: Stop Guessing, Start Verifying: A Modern API Documentation and Testing Toolkit. - www.youtube.com/watch Context7 Mentioned? We will see. 😶‍🌫️

Svelte 5 Runes: A React Developer's Guide to Reactivity

Thu, 09 Apr 2026 10:00:00 -0500

Continuing my series on Svelte topics, today we’re talking about runes. If you’re coming from React, this is is going to be a different way to work with reactivity in modern JavaScript.

These blog posts might be what is considered the basics, but it helps me learn and think through the topics if I work on blog posts around the important things that every developer needs to know.

What Are Runes?

In Svelte 5, runes are special symbols that start with the dollar sign ($). They look like regular JavaScript functions, but they’re actually compiler directives, reserved keywords that tell the Svelte compiler how to wire up reactivity during the build step.

If you’ve used decorators in Python or macros in other languages, runes fill a similar role. They look like standard JavaScript, but the compiler transforms them into something more powerful behind the scenes.

Let’s walk through the four runes you’ll use most.

`$state` — The Engine of Reactivity

$state is the foundation. It declares reactive state in your component.

<script>
  let count = $state(0);
</script>

<button onclick={() => count++}>{count}</button>

In React, useState returns an immutable value and a setter function, so you always need that setCount call. In Svelte, $state returns a deeply reactive proxy. You just mutate the value directly, and the compiler handles the rest. No setter function, no spread operators for nested objects. It just works.

`$derived` — Computed Values Without Dependency Arrays

In React, you’d reach for useMemo here, and you’d need to explicitly declare a dependency array so React knows when to recalculate.

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

Dependency arrays are prone to human error. We forget what depends on what, and that leads to stale data or unnecessary recalculations. $derived automatically tracks whatever state variables are used inside of it. No dependency array needed. It just reads what it reads, and recalculates when those values change.

`$effect` — Side Effects That Actually Make Sense

This is the equivalent of useEffect in React, which is notoriously tricky. Missing dependencies, stale closures, infinite loops… all the big gotchas are in useEffect calls.

In Svelte, $effect is used to synchronize state with external systems, like writing to local storage or updating a canvas:

<script>
  let theme = $state('dark');

  $effect(() => {
    localStorage.setItem('theme', theme);
  });
</script>

Just like $derived, it automatically tracks its dependencies and only runs when the state it reads actually changes. No dependency array, no cleanup function gotchas. It runs when it needs to run. That’s it.

`$props` — Clean Component Interfaces

Every framework needs a way to pass data into components. In Svelte 5, $props makes this look like standard JavaScript object destructuring:

<script>
  let { name, age, role = 'viewer' } = $props();
</script>

<p>{name} ({age}) - {role}</p>

Default values, rest parameters, renaming … it all works exactly how you’d expect from CommonJS. If you know destructuring, you already know $props. It’s readable, predictable, and there’s nothing new to learn.

Runes Me Over

You’ve probably noticed a theme. Svelte 5 runes eliminate a whole class of bugs that come from manually managing dependencies. React makes you think about when things should update. Svelte’s goal is to figure it out for you at compile time.

Svelte vs React: State Management Without the Ceremony

Wed, 08 Apr 2026 10:00:00 -0500

Continuing my Svelte deep-dive series, let’s talk about state management and reactivity. This is where the differences between React and Svelte can ‘feel’ much different.

React’s State Ceremony

In React, state requires a specific ritual. You declare state with useState, which gives you a getter and a setter:

const [count, setCount] = useState(0);

function increment() {
  setCount(count + 1);
}

Want to update a variable? You have to call a function. You can’t just reassign count. React won’t know anything changed. This is fine once you internalize it, but it adds ceremony to what should be a simple operation.

Then there’s useEffect, which is where things get tricky. You need to understand dependency arrays, and if you get them wrong, you’re looking at infinite loops or stale data:

useEffect(() => {
  document.title = `Count: ${count}`;
}, [count]); // forget this array and enjoy your infinite loop

Some of useEffect usage is actually unnecessary and likely using it wrong. If you’re using it for data transformations, derived values from state or props, or responding to user events, you’re probably reaching for the wrong tool.

The React docs themselves will tell you that you might not need an effect. It’s a common source of bugs and confusion, especially for developers who are still building their mental model of React’s render cycle.

Svelte: Reactivity Through the Language Itself

Svelte takes a fundamentally different approach. Reactivity is baked into the language semantics. Want to declare state? Just declare a variable:

<script>
  let count = $state(0);

  function increment() {
    count += 1;
  }
</script>

<button onclick={increment}>{count}</button>

That’s it. You assign a new value, and the DOM updates. The Svelte compiler sees your assignments and automatically generates the code to update exactly the parts of the DOM that depend on that variable. No virtual DOM diffing, no setter functions, no dependency arrays to manage.

Need a derived value? Svelte has you covered with $derived:

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

<p>{count} doubled is {doubled}</p>

In React, you’d either compute this inline, use useMemo with a dependency array, or… if you didn’t know better reach for useEffect and a second piece of state (please don’t do this).

Svelte’s $effect rune exists for side effects like updating document.title or logging, but you should reach for it far less often than useEffect in React. The compiler handles most of what useEffect gets used for automatically.

More Svelte comparisons coming as I keep digging in. Thanks for Svelting with me.

Svelte vs React: The Virtual DOM Tax You Might Not Need

Tue, 07 Apr 2026 14:00:00 -0500

I’m diving more into Svelte and SvelteKit lately, and I’m going to be writing a few posts about it as I learn. Fair warning: some of these will be general knowledge posts, but writing things out helps me internalize the details.

The Virtual DOM Question

It’s well known that React relies on a virtual DOM. The basic idea is that React maintains a copy of the DOM in memory, diffs it against the actual DOM, and then batches the changes to update the real thing. This works, but having to maintain this virtual DOM can lead to complications and confusion around what triggers a render or a re-render. If you’ve ever stared at a useEffect dependency array wondering why your component is re-rendering, you know what I mean.

Svelte takes a completely different approach. It’s not a library you ship to the browser, it’s a compiler step. You write Svelte code, and it compiles down to highly optimized vanilla JavaScript that surgically updates the DOM directly. No virtual DOM to maintain. No diffing algorithm running in the background. The framework essentially disappears at build time, and what you’re left with is just… JavaScript.

Templating That Feels Like the Web

I like how Svelte handles the relationship between HTML, CSS, and JavaScript. React forces you to write HTML inside JavaScript using JSX. You get used to it, sure, but it’s a specific way of thinking about your UI that can take some getting used to.

Svelte flips this around. Your .svelte files are structured more like traditional web pages — you’ve got <script> tags for your JavaScript, regular HTML for markup, and <style> tags for CSS. Everything lives in one file, but there’s a clear separation between the three concerns.

If you’ve ever worked with Django templates, Laravel Blade, or Ruby on Rails views, this will feel immediately familiar. It’s a lot closer to how the web actually works than JSX’s “everything is JavaScript” approach. For someone coming from those backgrounds, the learning curve is noticeably gentler.

More Svelte posts coming as I dig deeper. That’s all for now!

Lisette is a New Rust-to-Go Language, So I Built It a Test Library

Mon, 06 Apr 2026 14:00:00 -0500

This morning I dove into a new programming language called Lisette. I saw it from @lmika and had to take a look. It gives you Rust-like syntax but compiles down to Go, and you can import from the Go standard library directly.

It’s early in development, so a lot of things don’t exist yet. They have a roadmap posted with plans for third-party package support, a test runner, bitwise operators, and configurable diagnostics.

So Naturally, I Built a Test Library

Anyone who reads my blog knows I care a lot about testing. So when I saw “implement a test runner” sitting on the roadmap, I did what any reasonable person would do on a Monday morning. I built a testing library for Lisette called LisUnit.

I wanted something that felt familiar if you’ve used Jest or PHPUnit. Test cases are closures that return a result, and assertions work the same way. Here’s what it looks like:

lisunit.Suite.new("math")
  .case("add produces sum", || {
    lisunit.assert_eq_int(add(2, 3), 5)?
    Ok(())
  })
  .case("add is commutative", || {
    lisunit.assert_eq_int(add(2, 3), add(3, 2))?
    Ok(())
  })
  .run()

Define a suite, chain your test cases, run it.

Why Bother?

I don’t know exactly what direction the Lisette team is headed with their own test runner, so this is just a prototype. Building a test library turns out to fun way to try out a new language because you end up touching a lot of language constucts?

I’ll probably keep poking at it as Lisette evolves. Happy Monday.

Mon, 06 Apr 2026 08:57:33 -0500

emdash-cms/emdash: EmDash is a full-stack TypeScript CMS based on Astro; the spiritual successor to WordPress

EmDash is a full-stack TypeScript CMS based on Astro; the spiritual successor to WordPress - emdash-cms/emdash

Hiding Poems Inside Images

Sun, 05 Apr 2026 10:00:00 -0500

I built a tool that hides poems inside images. Not as metadata, not as a watermark. The actual text of the poem drives the visual pattern, and you can reconstruct the poem perfectly from the image alone.

How It Works

You give it a poem. It analyzes the syllable count, rhyme scheme, and stress patterns. Then it generates a visual pattern where those poetic features drive the aesthetics: spiral width, dot placement, block size, line weight.

The text itself is encoded into the pattern in a variety of ways. The pattern isn’t just inspired by the poem, it IS the poem. Run the decoder on the image and you get back the original text, character for character, including whitespace and punctuation.

Seven Renderers, Two Approaches

There are seven different visual styles, split into two categories.

The steganographic renderers (geometric, concentric, waveform) hide text invisibly in pixel color channels using LSB encoding. The visual pattern is purely decorative. This is a well-known technique. nothing new there.

I wanted to build something different, so I focused on visual encoding patterns. The encoding is the art, and the art is the encoding. Everything about how the image is constructed follows repeatable algorithms so it can be decoded back:

Nautilus draws a golden spiral where line width carries the data
Fibonacci uses a sunflower phyllotaxis dot pattern
Mosaic creates an adaptive block grid
Dotline connects dots with varying line weight

Each has different capacity. The nautilus spiral can hold about 2,200 characters, enough for a full Whitman poem. A fibonacci pattern holds about 1,600. Even the smallest renderer handles a haiku easily.

Right now I’m just having fun building different visuals, images that encode and decode. Eventually I might build an API around it, but for now it’s a side project…

A Basho’s haiku is here:

Sat, 04 Apr 2026 19:00:00 -0500

We can explain how dreams work but can an artificial system really ever understand them. What does being able to dream even mean to you the human?

Sat, 04 Apr 2026 11:02:10 -0500

The Highest Rated Episode In Dimension 20 History

This isn’t a joke, this is Katie’s life! 🚌🧝‍♀️ #shorts #dimension20 #dropoutTo watch EVERY season of Dimension 20, every live show, every Adventuring Party…