DEV Community: James Anderson

The Discerning Mind: What AI May Never Reach

James Anderson — Sun, 18 Oct 2026 09:15:08 +0000

You do it dozens of times a day, and you almost never notice.

You glance at a photo and something in you says that's beautiful — before you could tell anyone why. You read a sentence and feel, in an instant, that it's slightly off, a word out of place you haven't consciously identified yet. You walk into a room and sense it's almost right, that one thing could be moved and it would come together. You look at a design, a melody, a face, a line of code, and a judgment arrives — fast, certain, and ahead of any reasoning you could give for it.

We treat this as nothing. It's just taste, just an opinion, just a feeling. But it is one of the strangest and most quietly remarkable things a human being does — this instant, pre-rational knowing of what is good, what is wrong, what could be more. And it is precisely the thing that AI, for all its astonishing fluency, does not seem to have.

I want to sit with that, honestly, because I think the usual way we argue about it is wrong. The question everyone asks is "can AI be creative — can it make art, music, writing?" And the answer, increasingly, is yes, it can produce those things, impressively. But I don't think production was ever the point. I think the human thing — the thing that might be genuinely out of reach — is something else entirely. Not the making. The discerning.

The distinction almost everyone misses

Here is the move that the whole question turns on, and most of the debate skips right over it.

We lump two very different capacities together under the word "creativity," and they are not the same thing at all:

Generation is producing output — a poem, an image, a tune, a layout. And I'll say this plainly, because pretending otherwise would make me a liar and cost me your trust: AI is extraordinary at generation now. It can write a competent poem, render a striking image, compose a passable melody, draft a clean design. If your claim is "AI can't produce aesthetically pleasing things," you have already lost the argument, because everyone has seen that it can.

Discernment is judging that output — knowing which of two versions is better, sensing what's wrong, perceiving what could be improved, having taste. And this is a completely different faculty.

Here's why the distinction matters so much: generation was never the hard part of creativity. A random number generator generates. Throw enough paint at enough walls and you'll produce something. The miracle of the creative human was never that they could make marks — it was that they could look at the marks and know. Know which one was alive and which was dead. Know what to keep and what to throw away. Know, standing in front of the thing, that it wasn't finished yet, and feel in which direction "finished" lay.

The discerning mind, not the producing hand. We got so dazzled — or so threatened — by watching machines produce that we forgot the production was never where the magic lived.

What discernment actually is

So let's look closely at this strange faculty, because the closer you look, the stranger it gets.

Discernment isn't a rule you apply. You don't compute that a face is beautiful or a phrase is clumsy. You perceive it, the way you perceive a color — directly, immediately, often before a single word of justification is available to you. The reasons come after, if they come at all, and half the time they're reconstructions, stories we tell to explain a verdict we'd already reached.

And it's deeply embodied and personal. Your sense of what's beautiful is tangled up in a lifetime of sensory experience, of things you've seen and heard and touched, of memories, of emotions, of the particular person you happen to be. Two people with identical knowledge can have completely different taste, because taste isn't knowledge. It's a point of view. It's yours.

But here is the part I keep coming back to, the part that I think matters most: discernment comes from caring. You can only find something beautiful if things are capable of mattering to you. The whole faculty is downstream of being a creature that experiences, that prefers, that is moved, that has something at stake in how the world is. You judge beauty because beauty does something to you. Take away the one who can be moved, and I'm not sure "beautiful" means anything at all — it's just a word with no one behind it to feel its weight.

Which brings us to the machine.

Why AI may lack it, structurally

An AI that generates aesthetic output is doing something genuinely impressive, but notice what it's doing. It has learned, from an ocean of human-made examples, the statistical shape of what people have called good. When it produces something beautiful, it is, in effect, finding the center of mass of human aesthetic preference and generating toward it.

And here's the problem hiding in plain sight: real taste is almost the opposite of an average.

Taste is particular. It's a point of view, which by definition is not everyone's. The most interesting aesthetic judgments in history were often the ones that cut against the consensus — the thing nobody had learned to love yet, that one person saw and insisted was beautiful before the rest of us caught up. An average can tell you what people have found beautiful. It cannot want something to be beautiful in a way no one has wanted before, because wanting requires a wanter, and an average is nobody's.

But the deeper issue isn't statistical, it's this: there is no one home. The model has processed every description of awe ever written, every account of grief and longing and wonder and beauty — and it has never once been moved by anything. It knows, with superhuman thoroughness, what beauty is described as. It has never felt it. Not once. Not for a moment.

And so when it "judges" — when it tells you which image is better, or improves your paragraph — I think something is missing that we're too quick to overlook. A judgment with no subject behind it, no one who is moved by it, nothing at stake for anyone in the judging — is that judgment, or is it an extraordinarily good imitation of the residue that judgment leaves behind? The machine has the map of human taste, in staggering detail. But a map with no one reading it, no one caring where it leads, is just ink. The discerning mind might be the reader, not the map — and that's the part I'm not sure can be manufactured.

Now let me argue against myself

If I stopped here, I'd be doing the thing I dislike — telling you a comforting story about human specialness and calling it an argument. So let me give the other side its real strength, because it has some, and if you've been thinking skeptically this whole time, you're right to.

Maybe what we call "taste" is just extremely sophisticated pattern-matching on human preference — and the feeling that it's something more, something sacred, is simply human exceptionalism. We have an embarrassing track record here. We said machines could never play chess, then never play it creatively, then never master Go's intuition, then never use language — and each time, the thing we'd called uniquely human turned out to be a pattern a machine could learn. "Aesthetic judgment is special and unreachable" might just be the next item on that list, and I might be writing the same confident sentence people wrote right before they were proven wrong.

And maybe — this is the uncomfortable one — the "experiencing subject" I keep invoking is itself not what I think it is. Maybe we are also prediction machines, evolved to pattern-match on our environment, and the thing we call "being moved" is just what our pattern-matching feels like from the inside. If that's true, there's no magic line here at all. The machine does with silicon what we do with meat, and my insistence that ours has a someone behind it and theirs doesn't is just a bias I have because I happen to be one of the meat ones.

And purely practically: maybe AI doesn't need to feel beauty in order to reliably identify what humans will find beautiful — and if it can predict your aesthetic response perfectly, then for every practical purpose that touches your life, the difference between "real taste" and "flawless simulation of taste" may be a difference that makes no difference.

These are not weak arguments. I don't have a knockdown reply to any of them. Anyone who does is selling you something.

Where I land, held loosely

So, with all of that honestly on the table — here is what I still believe, offered as a suspicion and not a proof.

I think discernment is distinctly human not because the machine isn't powerful enough, but because aesthetic judgment may be inseparable from being a subject with stakes. Taste, real taste, isn't only identifying what people like. It's caring that something is beautiful. It's being changed by it. It's the whole circuit — being moved by something, and out of that being-moved, wanting to make something that moves someone else the way you were moved. That circuit runs, at every step, through an experiencing self. And a machine can reproduce the outputs of that circuit — the beautiful image, the confident judgment — without any of the circuit actually existing.

A judgment that nothing is at stake in, that no one is moved by, that doesn't matter to anyone doing it — I keep arriving at the same place: I don't think that's quite judgment. I think it's a very good imitation of what judgment leaves behind.

So will AI ever reach the discerning mind? My honest answer is: I suspect not — but not because it can't become more capable. Because the thing we're pointing at might not be a capability at all. It might be a property of being someone. You can't scale your way to a subject. And I hold even this loosely, because the truth is nobody knows, and the history of "machines will never" should make all of us humble, in both directions.

What we're left with

Whatever AI becomes, the discerning mind is, for now, still ours — that small daily miracle of looking at something and knowing, of being moved before you can explain why, of sensing that a thing could be more and feeling, dimly, in which direction.

It's easy to feel diminished watching machines generate in seconds what used to take us years. But maybe the quiet consolation in all of this is that generation was never where our worth lived. The seeing was. The being-moved was. The this could be better was. Those might turn out to be the last things to go — or they might be the things that were never really on the table at all, because they were never about output in the first place. They were about being alive to the world.

The machine makes. We discern. And discernment, when you follow it all the way down, might just be another name for caring that things are one way rather than another — for the world mattering to someone.

That's not a small thing to be left holding. It might be the whole thing.

Honest question, because I genuinely go back and forth and I'd rather hear real thinking than applause: is taste a skill that enough data could eventually teach — or is it inseparable from being a conscious, caring subject? And here's the one that keeps me up: if a machine could perfectly predict what you'd find beautiful, while feeling nothing at all — would that be taste, or a flawless imitation of it? And is there even a difference? I don't think I know.

AI Made Your Easy Work Free. That Made You More Valuable.

James Anderson — Sat, 17 Oct 2026 05:57:07 +0000

Let's start by admitting the scary part is true, because the whole argument falls apart if I pretend otherwise.

AI can build an enormous amount of software now, fast, for almost nothing. You can vibe-code a working app over a weekend. Clone a SaaS product's whole front end in an afternoon. Generate the CRUD endpoints, the forms, the standard UI, the glue code, the "make it look like this" — all of it, in minutes of prompting, at a quality that a few years ago would've been a week of a junior's time.

That's not hype. It's real, and if you've felt the floor shift under you because of it, you're not imagining things. So the fear makes sense: if building software is nearly free now, what's left for the people whose job was building software?

Here's the thing that question quietly assumes, though — and it's wrong. It assumes the building was where the value lived. It wasn't. And once you see what AI actually made free, and what it conspicuously didn't, the panic turns into something closer to a map.

What AI actually made free

Let me be specific and generous about how much AI really took, because downplaying it just sounds like denial.

It took the happy path. The first version. The part of the work that's been written down ten thousand times in tutorials, Stack Overflow answers, and open-source repos — which is exactly why the model learned it so well. The standard login flow, the typical dashboard, the ordinary API, the form that validates an email, the component that looks like every other component. The commodity layer of software engineering, the stuff that was technically "skilled work" but was really pattern-matching against a million prior examples.

That's maybe 90% of the volume of what gets typed in a day. And it genuinely did fall. A huge amount of what used to be billable, time-consuming, résumé-worthy engineering is now a prompt and a glance. Pretending that's not true helps no one, least of all you.

Concede the whole 90%. The argument doesn't need it.

What it conspicuously did not touch

Now the part nobody put in the demo.

AI did not learn how to make a webhook idempotent when Stripe times out mid-transaction and you have no idea whether the charge went through. It didn't learn to tune cgroup memory limits when a background worker quietly OOMs at 3am and takes the queue down with it. It has no feel for the passkey signCount desync that silently locks your paying customers out of their own accounts — the bug that generates zero errors and a pile of furious support tickets. It can't do the data migration that has to move fifteen years of real users' files without losing a single byte or breaking one weird edge case someone created in 2013.

Notice what all of those have in common: none of them show up in a demo, and none of them were written down anywhere for the model to learn from.

That's not a coincidence — it's the whole explanation. AI got extraordinary at the 90% because the 90% is the part that's documented everywhere, done the same way a million times, sitting in the training data in bulk. The 10% is hard precisely because it isn't written down. It's the failure modes, the edge cases, the what-happens-when-it-breaks-at-scale — knowledge that doesn't live in tutorials because it's only ever learned the expensive way: by getting burned, at 3am, on a real system, with real users yelling.

You can't prompt your way to that, because the thing you'd need to prompt doesn't exist in text. It exists in scar tissue.

The counterintuitive part: the 10% got more valuable

Here's the move most people miss while they're panicking.

When the easy 90% was expensive, its cost hid the value of the hard 10%. It was all bundled together and called "engineering," and the bill for the boilerplate and the bill for the 3am expertise came out looking like the same kind of money. The commodity work subsidized and camouflaged the rare work.

Now that the 90% is free, that camouflage is gone — and the 10% stands exposed as the only remaining scarcity. And value always concentrates wherever the scarcity is.

So AI didn't flatten the value of expertise. It flattened the value of the commodity part of expertise, and shoved all the remaining value into the rare part. The person who can do the 3am work didn't get less valuable when AI arrived — they got more valuable, because now everyone can do the easy part, and almost nobody can do theirs. The scarcity sharpened. The premium went up.

That's the whole reframe, and it's why the title isn't a motivational lie: AI making your easy work free is exactly what made your hard work worth more. It stopped being hidden inside the cost of the boilerplate.

The market is already proving it

You don't have to take the argument on faith — go look at the vibe-coded clone wave happening right now.

People are using AI to clone paid apps by the thousands: creative tools, CRMs, SaaS products, whole suites. The first versions appear fast and look impressive. And almost all of them die in alpha.

Why? Not because the code was bad. Because the makers could generate the 90% and either couldn't or wouldn't do the 10%. The clones that survive — the rare ones — are precisely the ones where somebody pushed through the unglamorous hard part: the maintenance, the edge cases, the reliability, the trust that gets built one answered support ticket at a time. "Cloning the surface of software is now free" is the exact reason depth became the moat. The market responded to free building with a graveyard of surfaces and a premium on substance. That's the thesis, already playing out, in public.

So what do you actually do with this?

Honest direction, no false comfort:

If you're early in your career and the 90% is most of what you can do right now — that's the part that got commoditized, so the move isn't "learn to prompt faster." It's to deliberately go after the 10%: debugging, systems thinking, how things fail, what happens at scale, reading code you didn't write, operating things in production. I'll be straight that this is genuinely harder than it used to be, because the easy work that used to teach you the hard stuff — the grunt tasks juniors cut their teeth on — is exactly what's being automated away. That's a real problem, and it deserves honesty rather than a slogan. But the direction is clear: chase the part that doesn't demo.

If you're experienced — your value didn't drop, it got concentrated. The years you spent getting burned are now the scarce thing, not the overhead. Stop apologizing for being "slow" at the boilerplate AI does instantly, and lean into the part it can't touch, because that part is now the whole job.

For everyone: stop competing on the layer AI does for free. There's no winning there — it's free, and you can't underbid free. Compete on the layer it can't reach.

The takeaway

"AI can build anything" is true and misleading in the same breath. It can build the 90% that was always the commodity. It can't build the 10% that was always the point.

The value didn't leave software. It moved — from the writing to the making-it-actually-work, from the demo to the dependability, from "can you build it?" to "can you keep it alive when it breaks at 3am?" For an engineer who can do the hard part, that's not a worse world. It might be the first time in a long while that the hard part is clearly, visibly the valuable part — instead of being quietly hidden inside the bill for the easy part.

Your easy work became free. That's not what makes you replaceable. That's what finally made the rest of you worth paying for.

A personal note, since this is the thing I've been chewing on the most: I've ended up building in this space myself — a workspace where the whole point is to put the real effort into the hard part (the reliability, the guardrails, the trust around what gets built), rather than just the fast generation everyone already has. It's called Xenition. I'm genuinely not pitching it here — this piece stands on its own and I'd have written it either way. But if any of this resonated and you're curious what "building for the hard 10%" looks like in practice, you're welcome to take a look. Mostly I just wanted to think the idea through out loud, and the comments are where I actually want to be.

So — the contestable version, and I want the real disagreement: do you think the hard 10% stays safe, or does AI eventually eat that too? And for the experienced folks: what's your 10% — the thing you do that no demo ever shows and no prompt ever quite gets right? I'll start: anything involving what happens after the happy path fails.

Git, Docker, and IPFS All Hide the Same Beautiful Idea

James Anderson — Wed, 14 Oct 2026 08:50:45 +0000

Let me make you a small promise, because it's worth your fifteen minutes.

There's an idea you rely on dozens of times a day — every time you make a commit, every time you pull an image — and you've almost certainly never seen it directly. It hides underneath the tools, doing its work quietly, while you type git commit and watch a hash scroll past without once wondering what that hash actually is.

It's one of the most elegant ideas in all of computing. Simple enough to explain in a single sentence. Powerful enough that git, Docker, and IPFS are all built on it — three very different tools, one shared foundation. And once you see it, something nice happens: a whole pile of "huh, why does it work like that?" questions about your daily tools quietly resolve into "oh, of course."

That's the promise. One idea, and by the end your tools make more sense than they did this morning. Let me show it to you.

First, the ordinary way — and its quiet flaw

Almost all the time, we find data by its location. A file path: /home/james/report.pdf. A URL: example.com/report.pdf. A database row by its ID. In every case, the address tells you where the thing lives — "the thing over there."

This feels so natural we never question it. But it has a quiet weakness, and the whole idea we're building to is a response to that weakness, so it's worth noticing.

The name tells you nothing about the content. The file at /home/james/report.pdf could be the report you wrote yesterday, or a corrupted version, or something an attacker swapped in — and the path looks identical in all three cases. The address is a promise that has to be trusted. You ask for a location, you get back whatever currently lives there, and you have no built-in way to know it's what you expected.

So here's the question that cracks the whole thing open: what if the address was the content? What if, instead of naming data by where it sits, you named it by what it actually is?

The idea, in one sentence

Here it is, the whole thing:

Instead of addressing data by its location, you address it by a cryptographic hash of its content — a short, unique fingerprint computed from the bytes themselves.

That's content-addressing. The "address" of a piece of data isn't a path or a name someone chose. It's a fingerprint derived from the data itself.

If the analogy helps: think of it like a fingerprint for a person, or a nutrition label that's computed from the food rather than printed by the manufacturer. It comes from the thing. Change the thing even slightly, and the fingerprint changes completely. Two identical things have identical fingerprints, always.

So the shift is small but total. "Give me the file at /report.pdf" (a location) becomes "give me the thing whose fingerprint is a3f9c2e8…" (its content). You no longer ask where — you ask what.

It sounds almost too simple to matter. Here's why it's beautiful: look at everything that falls out of it, for free.

The magic: four things you get for nothing

This is the part worth slowing down for, because it's where a simple idea reveals itself as a deep one. You don't add the following features to a content-addressed system. They're just consequences of the one idea. You get them whether you wanted them or not.

1. Integrity, for free. The address is a checksum. When you ask for the thing at fingerprint a3f9c2e8… and something hands it back, you can recompute the hash of what you received and check it matches. If even one byte was corrupted or tampered with in transit, the fingerprint won't match, and you'll know instantly. The name verifies the data. There's no separate "is this file corrupted?" step to bolt on — it's built into the very act of addressing.

2. Deduplication, for free. Identical content produces an identical hash. Always. So if two files — or two users, or two systems — have the exact same bytes, they have the exact same address, which means the system stores those bytes once. You physically cannot store the same content twice, because the second copy has nowhere new to go. Deduplication isn't a feature someone engineered; it's a thing that can't not happen.

3. Immutability, for free. A given fingerprint always points to exactly one piece of content, forever. Nothing can quietly change the data living at a3f9c2e8…, because the moment you change the content, you've changed its fingerprint — you haven't modified the thing at that address, you've created a different thing at a different address. The old address still points at the old content, unchanged. History can't be silently rewritten.

4. Caching, for free. If you already have the thing at a3f9c2e8…, you are done. You never need to fetch it again, and you can be certain — not hopeful, certain — that your copy is identical to the one being offered, because they share an address, and sharing an address means sharing content. "Do I already have this?" becomes a trivial lookup instead of a careful comparison.

Sit with that for a second. Integrity, deduplication, immutability, and caching — four properties that systems normally work hard to provide, each with its own machinery — all tumble out of one decision about how to name things. That's what "elegant" means in software: enormous consequence from minimal cause.

Now let me show you where you've been standing on this idea the whole time.

Where you've been using it all along

Git

Here's the one that tends to land hardest, because you use it constantly.

Git is, underneath its version-control interface, a content-addressed filesystem. Every file you commit (git calls it a "blob"), every directory (a "tree"), and every commit itself is stored by the hash of its content.

That commit hash you see — a3f9c2e8… — is not an ID that git assigned. It is a fingerprint of everything in that commit: the files, the directory structure, the author, the message, and the hash of the commit before it. It's computed from the content.

And suddenly a bunch of git's behavior stops being magic and starts being obvious:

Why git can detect corruption: because every object's name is a checksum of its content. (Property 1.)
Why git doesn't store the same file twice: identical files have identical hashes, so they're one object. (Property 2.)
Why git history is tamper-evident: change one old commit and its hash changes, which changes the "previous hash" baked into the next commit, which changes its hash, and so on — the change ripples through every commit after it and becomes impossible to hide. (Properties 1 and 3, working together.)

Git isn't doing anything mystical. It's content-addressing, wearing a version-control coat.

Docker

Docker image layers are content-addressed too, and the same reveals follow:

Why docker pull is often so fast: it skips the layers whose content hash you already have. (Caching — property 4.)
Why layers are shared across different images: two images built on the same base have layers with the same content, so the same hash, so they're stored once. (Dedup — property 2.)
Why a sha256: image digest means something: it guarantees you pulled exactly the image you meant, byte for byte, with no silent substitution. (Integrity — property 1.)

Every one of those conveniences you take for granted is the same idea quietly at work.

IPFS

IPFS makes content-addressing the entire premise, which is why it's the cleanest example. On the normal web, you fetch a file from a location — this server, that URL. On IPFS, you fetch a file by its content hash (called a CID). You're not asking "what's on this server?" — you're asking "who has the thing whose fingerprint is this?", and anyone on the network who has that content can serve it, because the same file produces the same address no matter where it lives. Location stops mattering; identity is everything.

But wait — what if two things have the same fingerprint?

If you’ve been reading closely, a question has probably been forming, and it’s the right one to ask — because the entire idea hinges on the answer.

Content-addressing assumes that no two different pieces of content ever produce the same hash. That event — two different inputs, one identical fingerprint — is called a collision, and if it could happen easily, the whole scheme would fall apart: two different files would share an address, and “same hash means same content” would become a lie.

So why do we trust it? Because with a good cryptographic hash, collisions are astronomically unlikely. Not “unlikely like winning the lottery” — unlikely like every person on Earth winning the lottery, on the same day, for a thousand years running. The space of possible hashes is so vast (for SHA-256, that’s 2²⁵⁶ values — a number larger than the count of atoms in the observable universe) that in practice you can treat “same hash = same content” as simply true, and build version control for the entire planet on top of that assumption.

But “in practice” is doing real work in that sentence, and here’s the concrete story that proves the point. Git originally used a hash called SHA-1. Over the years, SHA-1 weakened — researchers eventually managed to deliberately construct two different inputs with the same SHA-1 hash, which is exactly the collision the model depends on never happening. So git undertook a careful, years-long migration to SHA-256. Not because content-addressing was flawed, but because the whole thing rests on collisions being infeasible, and when the old hash got shaky, the one load-bearing assumption had to be shored up.

That’s the honest footnote to the beautiful idea: content-addressing is only ever as trustworthy as the hash underneath it. The elegance is real — but “which hash function” isn’t a minor detail, it’s the thing holding the entire structure up. The idea is beautiful; the hash is what makes it hold.

The takeaway

Here's the whole thing, one more time, so it sticks: if you name data by what it is instead of where it lives, you get integrity, deduplication, immutability, and caching as a free gift — which is exactly why the tools you trust most are quietly built on it.

It's a small idea with a very long reach. And now it's yours. You'll start noticing it everywhere — in a commit hash, a Docker digest, a CID, and places you haven't looked yet — and that noticing, that seeing of the idea beneath the tool, is the difference between using something and understanding it.

Fifteen minutes, one idea, and your tools make more sense than they did when you started. As promised.

Genuinely curious: what's a concept like this one for you — a single small idea you learned that suddenly explained a dozen tools at once? Content-addressing was one of mine; I remember the exact moment git stopped being magic. And now that you know git is content-addressed: what else about it just clicked into place?

People Are Vibe-Coding Clones of Every Paid App. What Actually Survives?

James Anderson — Tue, 13 Oct 2026 07:15:38 +0000

Earlier this month, a developer in Atlanta got fed up with Adobe's cancellation fees. So he used Claude to clone the entire Adobe Creative Suite — seven apps, Photoshop through After Effects — rebuilt them from scratch in Rust, dumped them on GitHub for free, and declared "software is over."

He's not alone. Vibe-coded clones of paid apps are showing up everywhere right now: creative tools, CRMs that "drop Salesforce," all sorts of commercial software being reverse-engineered and reimplemented by individuals pointing AI agents at a problem that used to require a company.

Now, the honest part: most of these specific clones are rough. Early alpha, buggy, missing the brutal last 10% of polish that makes software actually usable. The Adobe-clone creator said so himself — "not anywhere close to ready." If you're waiting for a free Photoshop that fully replaces Photoshop, you'll be waiting a while.

But if you're only looking at whether any individual clone is good yet, you're watching the wrong thing. Something bigger just happened, and it's worth sitting with — because the wall that protected a handful of giants for twenty years just got a lot easier to climb. Let's talk about what actually survives here, and why it might be one of the better things to happen to software in a long time.

The moat was never the code. It was the cost of building it.

For decades, the giants' real protection wasn't genius. It was expense.

Building something like Photoshop, or Salesforce, or a polished premium SaaS, took armies of engineers, years of work, and tens of millions of dollars. That was the moat. Not that the software was impossible to conceive of — plenty of people knew exactly what a photo editor should do — but that actually building one at that level was out of reach for anyone without a war chest and a hiring pipeline.

That barrier is the thing that let them behave the way they did. It's why they could charge subscription rent forever, raise prices whenever, lock you into their file formats and ecosystems, make cancellation deliberately painful, and treat users as a captive audience rather than customers who could walk. Where were you going to go? Building your own was impossible. GIMP existed, and the fact that "the free alternative" was a punchline for twenty years tells you everything about how secure that moat was.

AI didn't make the clones good. Let's be clear about that. What it did was make them cheap and fast — and that's the variable that actually mattered, because cheap-and-fast is exactly the barrier the whole monopoly structure was built on. One person with an AI agent can now attempt, in weeks, what used to need a funded team and years. The clone doesn't have to be finished to matter. The wall just has to become climbable, and it did.

What actually survives (because it isn't the clones)

Let me be straight, because it's the honest center of this: most of these clones will die. They'll stall in alpha, or the maintainer will lose interest, or they'll never close the last-10% gap that separates "impressive demo" from "thing I trust with my work." Free clone graveyards are a real thing, and AI makes it easier to start a project, not to finish and maintain one.

So the clones themselves, mostly, won't survive. Here's what does, permanently:

The giants can no longer assume they're the only option. For twenty years, "build your own" was not a sentence anyone finished. Now it is — credibly, cheaply, repeatedly. And you don't actually need the clone to be perfect for this to change everything. You need it to be possible. A monopoly's power comes from the absence of alternatives; the moment a credible alternative becomes cheap to mount, the monopoly has to start behaving like it has competition, whether or not any single competitor wins. Possibility is the product here, not polish.

That shift doesn't expire when the clones do. The cost wall fell, and it is not going back up.

Why this is genuinely good — and not just satisfying to say

It would be easy to make this purely about schadenfreude. I want to make the real argument instead, because it's stronger: this is good for reasons that have nothing to do with anyone's feelings about Big Tech.

Monopoly pricing dies when "build your own" becomes thinkable. You don't even need people to actually build the alternative — you need the giants to know they could. That alone caps what they can charge and how badly they can treat you, because the escape hatch is finally real. Prices, terms, and lock-in all have to get more honest when the door isn't locked anymore. Users win, directly.

Leverage returns to the small side for the first time in a generation. For two decades the relationship was entirely one-directional: accept the subscription, accept the price hike, tolerate the slow enshittification, or leave — to nothing. There was no "or else." Now there's a credible "or else," and leverage you can't negotiate from is the whole game. That's new, and it's healthy.

Innovation decentralizes. When building serious software required armies, only the well-funded could do it, which meant software got built to serve shareholders and quarterly targets. When it requires one motivated person and an AI, a thousand people can try — and some of them will build things the giants never would have, because they're scratching their own itch instead of optimizing a funnel. Not all of it will be good. But it'll be varied, and variety is where the genuinely new things come from.

And the companies most exposed are the ones who earned it. Notice why that developer built the Adobe clones: cancellation fees. Resentment. The feeling of being squeezed. The giants most vulnerable to this are precisely the ones who leaned hardest on their moat — aggressive pricing, hostile lock-in, treating loyal users like a billing relationship. The companies that actually treated people well have the least to fear. That's not revenge. That's the market finally doing the thing it's supposed to do.

The part that's hard to say politely

There's an irony here that's worth naming plainly, because it's real and it matters.

The giants pushed AI harder than anyone. They built it, embedded it in everything, sold it as the inevitable future — and, crucially, many of them cited AI-driven efficiency while laying off thousands of their own engineers. The message to workers was unmistakable: AI makes your expertise cheap, which makes you replaceable.

And now that same AI is making their moats cheap. The barrier that made them untouchable — the sheer cost of building software this good — is the exact thing AI is dissolving. The tool they wielded to cut their labor costs is the tool eroding the walls that let them charge rent.

This isn't childish "haha, suffer." It's something more structural, and harder to argue with: you cannot spend years telling the entire world that AI makes expertise cheap and replaceable, and then act shocked when AI makes your expertise — your product, your moat, your pricing power — cheap and replaceable too. The disruption they aimed at their own workforce turned around and pointed back at them. If you live by the AI-efficiency argument, you don't get to be surprised when you're disrupted by it. The symmetry is just honest.

The role AI is actually playing here

Strip away the drama and AI's specific role in all this is clear: it's the great equalizer.

It collapsed the one variable — build cost — that was holding the entire monopoly structure upright. For the first time, the ability to build serious, ambitious software isn't gated behind a company's balance sheet. It's in the hands of individuals. That's a genuine redistribution of a capability that was concentrated for decades, and it happened fast.

Now, the honest double-edge: the same AI that lets a solo dev clone Adobe also helps Adobe defend itself. The giants have more compute, more data, more distribution, more lawyers. AI arms both sides. But — and this is the whole point — it arms the small side far more, in relative terms, because the giants were already powerful and the little guy had essentially nothing. Handing a new weapon to someone who already has an army changes little; handing the same weapon to someone who had a stick changes everything. The uplift is asymmetric, and it favors the underdog. That asymmetry is why this is disruptive instead of just incremental.

Let's not kid ourselves, though

If I only told you the optimistic half, you'd be right not to trust me, so here's the honest counterweight.

The legal fights are coming, and they'll be ugly. "Clean-room reimplementation" — functional replication without copying code — is a real and defensible concept, but trade dress, trademarks, and the exact line between "inspired by" and "copy of" are not settled, and the giants have the lawyers to make that line expensive to approach. Some of these clones will get sued into oblivion regardless of their technical merits.

And "free clone" is not automatically a win for anyone. Software nobody maintains becomes a security liability. A clone without support, updates, and a community is a trap you walk into the day its single maintainer gets bored. The open-source graveyard is full of "free alternatives" that were genuinely better for about eight months. AI lowered the cost of starting; it did almost nothing for the cost of sustaining, which is where most of these die.

None of that undoes the core shift. But anyone selling you "software is free now, the giants are finished" is selling you the same overconfidence from the other direction. The wall fell. The giants will adapt, litigate, and survive. It's the uncontested part of their power that's gone.

What actually survives

So, back to the question in the title. What survives this wave of clones?

Not most of the clones. They'll do what early, unmaintained, one-person software usually does.

What survives is the end of an era — the one where a handful of companies could build an unbreakable wall out of engineering cost, sit behind it charging rent forever, and treat both users and workers as disposable, because there was genuinely nowhere else to go. AI knocked a hole in that wall. The giants aren't finished; they'll adapt and they'll endure. But they will never again have the uncontested dominance they had, because "build your own" stopped being impossible, and a threat that's cheap to mount is a threat that never fully goes away.

And for an industry that spent the last few years telling its own people they were replaceable by AI, there's a fitting symmetry in watching that same AI make monopoly itself a little more replaceable too.

That's not the end of software. It's a shift in who gets to make it — away from the few with the war chests, toward the many with an idea and an AI agent. Most of them will fail. That's fine. The point was never that everyone wins. The point is that, for the first time in a long time, the giants can lose. And a world where the giants can lose is a healthier one than the one we had.

Honest questions, and I want the real answers, not the comfortable ones: is AI collapsing the cost of cloning software actually good — the end of monopoly rent and lock-in — or does it just leave us a graveyard of abandoned clones and a decade of lawsuits? And the uncomfortable one: after years of "AI will replace you" pointed at engineers, is there genuine justice in AI coming for the giants' moats — or does it just feel good to say? I genuinely go back and forth.

Context & sources: this piece is anchored in the early-October 2026 release of ArtCraft — Atlanta developer Brandon Thomas's suite of seven open-source, AI-assisted "clean-room" reimplementations of Adobe's creative apps (Photocraft, Vectorcraft, Filmcraft, Lightcraft, Printcraft, Effectcraft, Designcraft), built with Claude Opus 5.5 in Rust and widely covered (Gizmodo, PetaPixel, KDnuggets, Phoronix, and others). The creator has described the apps as early alpha and "not anywhere close to ready." The broader "SaaSpocalypse" framing — the idea that AI-collapsed build costs threaten subscription software — and related clone projects (REA and others) are drawn from the same October 2026 reporting. Specifics are current-as-of-writing and moving fast; treat the trend as the story rather than any single clone's readiness.

Passkeys Can Lock You Out of Your Own Device. Here's How.

James Anderson — Mon, 12 Oct 2026 05:10:23 +0000

Let me say the reassuring part first, because this is not a "don't use passkeys" piece: passkeys are genuinely good, they're a real upgrade over passwords, and I use them. If you take nothing else from this, take that.

But there's a part of how passkeys work that the "add passkey auth in 10 minutes" tutorials never mention, and it's the one part actually worth understanding — because it's the part with teeth. Under the right (or wrong) conditions, the passkey system can let a website verify what device and software you're using and refuse to log you in if it doesn't approve. In principle, that can lock you out of your own account on your own device, for running the "wrong" operating system or browser.

That sounds alarming, and the mechanism is real, so I want to explain it honestly — both how it genuinely works and how worried you should actually be, because the answer to the second part is "less than the headline suggests, but not zero." This piece was sparked by a more alarmist article making the rounds ("passkeys are a trap"), and I wanted to write the fair, technical version: what's true, what's overblown, and — if you're the one building auth — the choice that quietly lands on your desk.

The feature is called attestation. Here's the whole story.

First, how passkeys actually work

Quick, because the rest depends on it.

A passkey is a public/private key pair, created by your authenticator — your phone, your laptop, or a hardware key like a YubiKey. When you register, the authenticator generates the pair, keeps the private key locked away (ideally in a secure chip it never leaves), and hands the website the public key. To log in, the site sends a challenge, your authenticator signs it with the private key, and the site verifies the signature with the public key it stored.

Why this is genuinely better than passwords: there's no shared secret to steal — the site never holds anything that logs you in, so a database breach leaks public keys, which are useless to an attacker. And it's phishing-resistant, because the key is bound to the real domain; a fake look-alike site can't trigger it. This part is great. No notes.

The standard underneath is WebAuthn (a W3C/FIDO standard), and "passkey" is just the friendly user-facing name for a WebAuthn credential. So far, so good.

"Passkey" is an umbrella, not one thing

Here's the first thing the marketing glosses over: "passkey" isn't a single thing. It's a spectrum of options. A passkey can be synced across your devices (the convenient kind, backed up to iCloud or Google) or device-bound (never leaves one piece of hardware). It can live on the device you're using (platform) or roam between devices over Bluetooth/NFC (roaming, like a YubiKey). Most of these distinctions are benign — they're just convenience-vs-control tradeoffs you'd reasonably want either way.

But one property is different in kind, because it's not about your convenience at all. It's about what the website gets to know and demand about your setup. That's attestation.

What attestation actually is

When you register a passkey, the authenticator can include a signed statement that proves what kind of authenticator created the key — its make and model — in a way that can't be faked, because it's signed using a key baked into the device's secure chip at manufacture.

That's the core idea: attestation attests to the provenance of the authenticator. Not who you are — what device you used.

There are levels of it, and the differences matter:

none — the default. No device info, or an anonymized version. The site gets your public key and nothing identifying about your hardware. This is what the overwhelming majority of sites use.
direct — the site receives the authenticator's make and model (e.g. "this is a YubiKey 5" or "this is an iOS platform authenticator").
enterprise — the strong one: the attestation can include uniquely identifying information, like a serial number. This is meant for controlled deployments where a company issues a known fleet of keys.

And here is the mechanism behind the scary headline: because an attested registration cryptographically proves what device and software stack produced the key, a website can decide to accept only certain ones. "We only accept hardware-backed, user-verified, attested passkeys from approved authenticators." If your setup can't produce that proof — because you're on Linux, or a de-Googled phone, or a custom browser, or an OS that's no longer getting the blessed updates — the site can notice, and refuse you. That's the lock-out. It's real, and that's genuinely how it would work.

So how worried should you actually be? (Honestly: watchful, not scared)

This is where the alarmist version stops and the honest version has to keep going, because the mechanism being possible is very different from it being likely to hit you today. Here's the real context, and most of it is reassuring.

Attestation defaults to none, and the professional consensus is to leave it there. The W3C spec defaults the attestation setting to none, and current (2026) guidance for developers is blunt about it: for almost all consumer and business sign-ins, you should not request attestation. It leaks platform information, reduces user choice, and adds friction for no benefit to a normal login. "Skip it" is the mainstream recommendation, not a fringe one.

The identifying kind needs your consent and specific configuration. Enterprise attestation — the type that can include serial numbers — can't just be silently switched on against a consumer. It requires the authenticator to support it, the platform/browser to be configured (typically by enterprise policy) to release it, and user consent. It's a managed-workplace tool, not something a random website can spring on you.

Privacy is built into the standard on purpose. To stop attestation from becoming a tracking identifier, FIDO guidance requires each attestation certificate to be shared across at least 100,000 devices in a batch. So "direct" attestation tells a site you're using, say, an iPhone 15 — not which iPhone 15. It identifies a model, not a person, by design.

And in practice, essentially no mainstream consumer site requires attestation today. The passkeys you actually use — from Apple, Google, or a password manager — are the benign, non-attested, user-friendly kind. The lock-you-out scenario is a capability sitting in the standard, not a wall you're hitting this week.

So the honest calibration: the mechanism is real and worth knowing about, because it's the point where authentication could quietly turn into a lever over what software you're allowed to run — and standards have a way of tightening over time. But it is not a trap that's currently sprung, and "passkeys are dangerous, don't use them" is an overreaction to a capability that today sits almost entirely unused against consumers. Watchful, not scared.

The part most articles skip: if you're the developer, this is your choice

Here's the angle I most wanted to write, because nearly every passkey piece is aimed at users and this one's aimed at you, the person implementing auth.

When you add passkeys to your app, attestation is a setting you choose, and the default — none — is almost certainly the right one. Requesting attestation means you receive platform/device information about your users, you add friction, and you risk excluding people on perfectly legitimate but non-mainstream setups. For a normal product, that's all cost and no benefit.

So the practical rule is easy: use none unless you have a specific, genuine regulatory or policy reason not to — a regulated workforce that must use issued hardware keys, a high-assurance fleet, a compliance mandate. Those are real and valid. "It felt more secure" is not one of them.

But I'd also frame it as more than a technical default, because it is: the moment you require attestation, you've become the one deciding which devices and software your users are allowed to use to reach their own accounts. That's a real power, and a real responsibility. The lock-out this article's title warns about isn't something passkeys do to people on their own — it's something a developer chooses to impose. Most of the time, you shouldn't. Reach for that lever only when you truly must, and know what you're doing to your users' autonomy when you do.

What to actually do

As a user: use passkeys. They're a big security upgrade and the versions you'll actually encounter are the friendly kind. Just know the word "attestation" and what it enables, so that if the norms ever shift, you'll recognize what's happening instead of being quietly funneled. And if you want maximum control with passkey-grade security, a hardware key like a YubiKey is self-contained and keeps the authority with you.

As a developer: default to attestation: none. Only request more when a real policy requires it. And when you do, remember you're not just tightening security — you're deciding what your users are permitted to run. Choose that deliberately.

The takeaway

Passkeys aren't a trap, and the title isn't a warning to avoid them — it's a warning to understand them. The lock-out is real as a mechanism and, today, almost entirely theoretical in practice, because the setting that enables it defaults off, needs consent in its strong form, and is deliberately privacy-limited.

But it's worth knowing, for one reason that runs deeper than passwords ever did: attestation is the point where "proving who you are" quietly gains the ability to enforce "what you're allowed to run." It's benign now. It's the dial to watch. And if you're the one building the login, it's a dial that's in your hand — so keep it set to "trust the user" unless you have a very good reason not to.

Two honest questions. As a user: does knowing about attestation change how you feel about passkeys — or is this a non-issue being blown out of proportion? And as a developer: has anyone here had a genuine, legitimate reason to require attestation beyond none? I'd like to hear the real use cases from people who've actually shipped it, because they're rarer than the fear implies.

Sources & further reading: WebAuthn is a W3C/FIDO Alliance standard (see the W3C Web Authentication spec and MDN's PublicKeyCredentialCreationOptions docs for the attestation conveyance options). The attestation member defaults to none per spec; current developer guidance (e.g. WebAuthn implementation guides, 2026) recommends none for virtually all consumer and B2B sign-ins and reserving direct/enterprise for regulated or managed-fleet cases. FIDO guidance recommends attestation certificates span ≥100,000 devices per batch to preserve privacy, and enterprise attestation requires authenticator support, platform configuration, and user consent. This piece was prompted by a more alarmist article ("Passkeys are a trap"); I've aimed to present the mechanism accurately and the risk proportionately — verify specifics against the primary WebAuthn spec, which is the authority here.

Tech Is Brutal Right Now. Stay or Go? Let's Think Clearly.

James Anderson — Sun, 11 Oct 2026 09:01:04 +0000

You sent 200 applications. You heard back from three. Two were rejections and one was a "we've moved forward with other candidates" that you're pretty sure was automated.

You did the thing. The degree, or the bootcamp, or the self-taught grind. You learned the stack, you built the projects, you ground the LeetCode. And the door that everyone promised would open is just… not opening. Meanwhile the news is a steady drip of layoffs, and every post about "breaking into tech" either tells you to never give up or tells you it's already over.

So somewhere underneath the exhaustion, there's a quiet, scary question you maybe haven't said out loud: is this even worth it anymore? Do I keep trying, or do I go do something else?

That's a completely reasonable question to be asking right now. It isn't weakness, it isn't impatience, and it isn't you being dramatic. And anyone who answers it for you with a slogan — "grind harder!" or "tech is dead, run!" — is wasting your time, because they're answering a question you didn't ask.

I'm not going to tell you to stay, and I'm not going to tell you to go. I don't know your life. What I can do is give you honest information and an honest way to think it through, so that whatever you decide is a decision and not a panic. Let's do that.

First, the honest reality — no sugar, no doom

You deserve the real picture before you decide anything, so here it is, both halves.

The brutal half is real, and it's not in your head. Entry-level hiring has genuinely collapsed. Depending on which report you read, junior developers have fallen from around 15% of tech hiring to about 7%, and entry-level postings sit something like 40% below where they were a few years ago. Layoffs have continued in waves, tens of thousands per quarter, with AI increasingly cited as a factor. And there's a genuinely cruel twist called the "experience paradox": companies cut their junior roles and say they want experienced people — which leaves beginners asking how you're supposed to get experience from a door that's closed. If you feel like the game got harder right as you showed up to play it: you're right. It did. This is not a personal failing, and I need you to actually believe that part before you make any decision, because deciding out of shame leads you somewhere different than deciding out of clarity.

But the other half is also real, and you need it to decide honestly. The market didn't die — it split. Overall tech employment is still projected to grow modestly. AI and ML roles are booming — some postings up 59%, 85%, even higher year over year. And the most important nuance, the one almost nobody says clearly: entry-level tech jobs didn't vanish so much as move and change shape. The specific tasks juniors used to be hired for — boilerplate, scripted testing, routine bug fixes — got automated. So companies stopped hiring for those, and the hiring shifted toward problem-solving, AI-augmented work, smaller companies, and specializations. One way people put it: the junior role isn't being eliminated, the entry bar is being raised. That's harder. It is not the same as "closed."

Hold both of those at once, because the decision you're about to make depends on seeing the whole board, not just the half that matches your current mood.

(All of these figures come from 2025–2026 industry and labor reports; treat them as directional and current-as-of-writing — they move. Sources at the end.)

The reframe: you're actually asking two different questions

Here's the thing that will make this decidable instead of just scary. "Should I give up on tech?" is really two questions wearing one coat, and people panic because they've mashed them together. Pull them apart and it gets a lot clearer.

Question one: is the path broken, or the field?

The old path in — grind the fundamentals, mass-apply to hundreds of listings, get hired — is genuinely broken right now. That spray-and-pray approach worked when companies were hiring aggressively and a warm body with the right keywords got interviews. It mostly doesn't work anymore. But "the path I was using stopped working" is a completely different statement from "the field is closed to me." One is an approach problem. The other is a field problem. People quit over the first thinking it's the second.

Question two: do you actually want this — or did you want what it promised?

Be honest with yourself here, because nobody's watching. A lot of people came into tech for the rewards — the salary, the stability, the status of a "safe, future-proof" career. There is nothing wrong with that; those are good reasons to pick a field. But when the rewards get shaky — when "safe" stops feeling safe — it's worth asking whether you actually like the work itself, separate from what it was supposed to pay and provide. Because the answer changes everything about what you should do next.

Most people never separate these two. They feel the pain, collapse it into "should I quit tech," and either grind blindly or bail in a panic. Separating them is where an actual decision becomes possible.

A framework for deciding — honestly, either way

So here are the questions to actually sit with. I've tried to write them so that both answers are respectable, because they are. There's no correct destination here; there's only the honest one for you.

1. Do you enjoy the actual work on a normal day — reward aside? Not the dream of the job. The doing of it: building the thing, chasing the bug, the moment it finally runs. If yes — if some part of you likes this even when nobody's paying you for it — that's a strong signal, because that motivation is exactly what survives a brutal market. If honestly no — if the work itself is a slog you tolerate for the paycheck — that's not a character flaw, it's extremely useful information.

2. Is your struggle an approach problem or a fit problem? Be precise. Two hundred applications into a void that aren't landing is an approach problem — the method is wrong, not you, and methods can change. Dreading every hour you actually spend coding is a fit problem — and no change of approach fixes a fit problem. These feel the same from the inside (both are "it's not working") and they have opposite solutions.

3. What did you actually want — the work, or the life it promised? And the follow-up: is that life still realistically on offer here, or is it more available somewhere else now? If what you wanted was stability and good pay, it's fair to ask honestly where those are most reachable for you in the next few years. That might be an adapted path in tech. It might not be. Both are legitimate answers to an honest question.

4. What's your actual runway and risk tolerance right now? This one isn't about passion, it's about reality, and it matters. Someone with a year of savings and no dependents can afford to keep pushing on a hard path. Someone supporting a family on a shrinking timeline is making a completely different, equally reasonable calculation. There is no brave answer and no cowardly answer here — there's only your real situation, which you're allowed to factor in without guilt.

Sit with those four. Where they point is different for different people, and that's the whole point — this isn't a test with a right answer.

If you're leaning stay: then change the path, because the old one broke

If those questions point you toward staying — you like the work, your struggle is an approach problem, the life you want is still reachable here — then the single most useful thing to internalize is this: the reason it's not working is probably the old approach, so adapt the approach.

Briefly, because this isn't a full guide: differentiate instead of mass-applying (a hundred tailored, targeted efforts beat a thousand sprayed ones now). Build a visible body of real work that proves you can do the job, since "I can build things" travels further than "I have a certificate." Learn to work with AI rather than pretending it isn't there — that's literally the raised bar now, and AI-fluent juniors are the ones commanding a premium. Look at smaller companies and adjacent or specialized roles, which is where a lot of the entry-level hiring actually still is, rather than only the big names everyone's spraying. And network into opportunities instead of applying cold, because referrals cut through a pile that algorithms are filtering ruthlessly.

The door isn't open the way it was. But it's a different door now, not a wall — and most people are still knocking on where the old one used to be.

If you're leaning go: that is not failure, and I mean that

If those questions point you the other way — the work itself doesn't move you, or it's a fit problem, or what you wanted is more reachable elsewhere, or your runway just doesn't allow the long grind — then hear this clearly, because a scared beginner rarely gets told it: choosing something else is not quitting, and it is not losing.

Sometimes a brutal market does you an actual favor. It forces a question you'd have spent years avoiding if things had been easy: is this really what I want? Plenty of people would have drifted into a tech career they didn't love simply because the money was good and the path was smooth — and a hard market shook them awake to go find something that fits them better. That's not defeat. That's clarity you got the hard way.

And it's rarely a total loss of what you've built. The problem-solving, the logical thinking, the comfort with tools and systems — those transfer. Into tech-adjacent roles, into other industries that badly need technically-literate people, into something entirely different you'd genuinely rather do. Leaving because you realized you want a different thing is one of the more mature moves a person can make. You're allowed to make it without calling it failure, because it isn't one.

The takeaway

You don't need me, or a motivational post, or a doom thread, to make this choice for you. You need honest information and permission to decide — so here's both.

The reality: it is genuinely hard right now, it is largely not your fault, and it is not hopeless — the field didn't close, it moved, and whether that move is one you want to follow is a real and personal question. Staying and adapting is a respectable answer. Leaving or pivoting is an equally respectable answer. The only bad outcome is letting fear quietly make the choice for you — drifting on in a panic, or bailing in one — instead of deciding on purpose.

So think clearly, be honest with yourself about the four questions, and then choose. Both doors are open. Both are allowed. Make it yours.

Honest question, and I'd genuinely like real answers rather than the motivational kind: if you're a beginner in this market, are you doubling down, pivoting, or genuinely not sure yet — and what's the thing that'll actually decide it for you? And if you're already in tech: what would you honestly tell someone starting out right now — not the LinkedIn version, the real one?

Sources & further reading: figures are drawn from 2025–2026 labor-market and industry reporting, including Stanford HAI's AI Index (entry-level developer employment down ~20% from its 2024 peak), SignalFire and ARDURA analyses (junior share of hiring falling from ~15% to ~7%), Ravio / Resume.org / CompTIA / Dice / Indeed Hiring Lab data (entry-level posting declines, AI-role growth of 59–134%, net tech employment still projected to grow modestly, AI-skill salary premiums), and Challenger, Gray & Christmas layoff tracking (AI cited as a rising share of tech cuts in 2026). These numbers vary by source and methodology and are moving quickly — treat them as directional and current-as-of-writing, and check the primary reports for the latest.

What a Multimodal AI Workspace Actually Looks Like When It's Built Right

James Anderson — Sat, 10 Oct 2026 06:37:37 +0000

Here's the shape of a normal hour of AI-assisted work right now.

You're in a chat tool, and it gives you some code. You copy it into your editor. Then you need a quick doc to explain it — different tool, paste the context back in, regenerate. Then someone wants a slide version — a third tool, paste it again. Then a spreadsheet to track the numbers — a fourth. Then a diagram — a fifth. Somewhere in there you also pulled data from an API and a file from Drive.

Notice what you are in that workflow: you're the integration layer. You are the thing manually carrying context between a dozen AI tools that have no idea the others exist. Every handoff is a copy-paste, a re-explanation, a loss of state. The AI is doing the easy parts, and you're doing the tedious glue work between the AI parts.

This is absurd, and we've mostly stopped noticing it because it crept up on us one tool at a time.

The obvious response is "someone should build one workspace that does all of this." And lots of people are claiming to — "all-in-one AI workspace" is on a hundred landing pages. But most of them are a chat box with a few features stapled on. So the interesting question isn't whether a multimodal AI workspace should exist. It's: what are the genuinely hard problems you have to solve for one to actually work — and what does "built right" look like for each?

That's what I want to break down. Not a tour of features; the actual design challenges, and the difference between a real answer and a fake one.

Hard problem 1: routing — knowing which surface the task needs

The naive version of a multimodal workspace is a dashboard with buttons: here's the code editor, here's the doc, here's the slide canvas, here's the spreadsheet. Pick one, then talk to the AI inside it.

That's not a workspace. That's a folder of separate tools wearing a shared skin, and it pushes the hardest cognitive work back onto you: deciding which surface this task needs. The whole promise of "multimodal" is that you shouldn't have to.

The genuinely hard problem is routing — taking a plain request ("turn these notes into a presentation," "clean up this data and chart it," "write and run a script to do X") and figuring out, without a menu, which surface or surfaces the task actually calls for, then summoning them. "Make me a pitch deck" should produce slides, not a markdown wall. "Why is this query slow?" should open a code/analysis context, not a doc.

Built right: the system infers the surface from intent, and gets it right often enough that you stop thinking about surfaces at all. Built wrong: you're back to picking from a menu, which means the "intelligence" is a chat box and everything else is manual.

Hard problem 2: context continuity across surfaces

This is the one that separates a real workspace from a bundle, and it's genuinely difficult.

The entire point of putting code, docs, slides, and sheets in one place is that they share an evolving context. You draft a plan, then build the thing the plan describes, then make slides about what you built, then a spreadsheet to track it — and at no point should you have to re-explain what "the thing" is. The context from step one should still be alive at step four.

Most "all-in-one" tools fail exactly here. Each surface is its own little island with its own conversation, so moving between them means re-establishing context by hand — which is the copy-paste problem again, just relocated inside one app. You've changed the logo on the tabs; you haven't removed the glue work.

Built right: state carries across modes. The doc knows what the code does. The slides know what the doc said. You add a column to the sheet and it understands which numbers you mean, because the context didn't reset when the surface changed. Built wrong: five surfaces, five amnesiac conversations, and you ferrying between them.

Hard problem 3: the right surface, not just a surface

It's not enough to have many surfaces. Each one has to actually be good at its job.

A spreadsheet task needs real spreadsheet affordances — formulas, cells, the ability to recompute — not a static markdown table that calls itself a spreadsheet. A slide deck needs to be a deck you can present and edit, not an image of slides. Code needs to actually run. The failure mode here is ten mediocre surfaces: a toy editor, a fake spreadsheet, slides you can't really use. That's worse than ten specialized tools, because now you've got breadth and no depth.

Built right: each surface is genuinely capable at the thing it's for, so you're not quietly downgrading your tools in exchange for having them in one place. Built wrong: you traded best-in-class tools for the convenience of mediocrity in a single tab.

Hard problem 4: letting it act — safely

A workspace that can only produce text is a document generator. A workspace that can do things — run the code, send the email, change the data, call the API — is far more useful and far more dangerous, and this is where the design gets serious.

The moment the workspace can take actions with real consequences, you're in agent-safety territory, and all the unglamorous guardrails apply: least privilege on what it can reach, human approval for consequential actions (gated by blast radius, not forty rubber-stamp prompts), an audit trail of what it actually did, and ideally a separate check — a reviewer or judge step — before anything irreversible fires. A multimodal workspace that can act without these isn't a productivity feature; it's an incident waiting for a date.

Built right: capability and controllability ship together — the workspace can act, and there are brakes designed in from the start. Built wrong: "look how much it can do!" with no answer for what happens the first time it does the wrong thing.

Hard problem 5: connectors without chaos

The last hard part is the outside world. A workspace that can't reach your real data — your Drive, your repos, your calendar, your database — is a sandbox. So integrations matter. But "100+ connectors" is easy to put on a slide and hard to make coherent.

The failure mode is a junk drawer: a long list of half-working integrations, each with its own auth quirks and inconsistent behavior, most of which nobody uses and several of which are quietly broken. Breadth as a marketing number, not a capability.

Built right: the connectors that exist actually work, behave consistently, and — critically — feed into the shared context and the permission model from problems 2 and 4, rather than being bolted on beside them. Built wrong: a wall of logos and a lot of "connection failed."

What this looks like in practice (with disclosure)

A disclosed note, because it's the honest thing to do: I work on Xenition, which is an attempt to build exactly the kind of workspace I've been describing — one chat that summons the right surface (code, docs, slides, spreadsheet, an image/design canvas), carries context across them, and can take actions through connectors with approval gates and an audit trail around the agent parts.

I'm not going to walk through it as a feature tour, because that's not the point of this piece and you'd rightly tune it out. I'll just say which of the hard problems above were the actually hard ones in practice, since that's the useful part: routing and context continuity (problems 1 and 2) are where almost all the real difficulty lives. Making a system reliably infer the right surface, and keeping one context alive as you move between a doc and code and a sheet, is a genuinely unsolved-feeling problem that you chip away at rather than "finish." The surfaces themselves (problem 3) are a lot of work but a known kind of work. And the acting-safely part (problem 4) is exactly the guardrails conversation — approval gates, audit, a judge agent — which is why I'd argue controllability has to be designed in from day one, not added after the first scary demo.

I mention all this not to pitch it but because the honest version of "here's what built-right looks like" includes "here's where it's still hard," and routing-plus-continuity is the part I'd tell anyone evaluating any tool in this space to poke at hardest. If a multimodal workspace nails the demo but makes you re-explain yourself every time you switch surfaces, it hasn't solved the problem that matters.

The honest counter: when fragmentation actually wins

Now the part that keeps this from being a sales pitch, because it's true and it matters: sometimes ten specialized tools beat one workspace, and you should know when.

If you need the absolute best-in-class tool for one specific thing — the deepest spreadsheet, the most powerful IDE, a design tool a dedicated team has polished for a decade — a general workspace will almost always be shallower at that one thing than the specialist. If you're wary of lock-in, putting everything in one vendor's workspace is a bigger bet than keeping your tools separate and swappable. And if your work is genuinely single-mode — you only ever write code, full stop — the "multi" in multimodal is overhead you don't need.

A multimodal workspace is a bet on integration over specialization: you accept that each surface might be slightly less deep than the best standalone tool, in exchange for the context continuity and the elimination of glue work. That's often a great trade. It is not always a great trade, and anyone telling you it always is, is selling something.

The takeaway

The future of AI tooling probably isn't more tools. We're already drowning — the fragmentation, the copy-pasting, the being-the-integration-layer-yourself. The direction that actually helps is fewer surfaces that adapt to the task, with one context flowing through them.

But "adaptive multimodal workspace" is only as good as how it answers the hard problems: can it route to the right surface without a menu, keep one context alive across modes, make each surface genuinely capable, act with real guardrails, and connect to the outside world coherently? Those five things are the whole game. The branding is noise; those are the questions.

So whether you adopt one of these workspaces, build your own, or decide your specialized stack is better for now — judge it on those five, not on the length of the feature list. "Built right" isn't about how much it can do. It's about whether it removed the glue work without quietly making you the glue in some new way.

Genuinely curious where people land on this: are you consolidating toward one AI workspace, or deliberately keeping a stack of specialized tools — and what's the thing that actually decided it for you? I suspect the answer is mostly "which pain hurt more: the switching, or the shallowness." But I'd like to hear the real ones.

I Think We're Forgetting How to Be Bored

James Anderson — Wed, 07 Oct 2026 06:59:26 +0000

You know the moment. You're waiting for the kettle, or the elevator, or a page to load, or a friend who's running late. There's a gap — thirty seconds, maybe three — of nothing to do.

And your hand is in your pocket before you've even decided to reach for it.

Not because you need anything. There's no message you're waiting on, nothing urgent. It's closer to a flinch — a small, automatic recoil from the empty moment, like the quiet is something to be escaped rather than simply stood in. I do it constantly. I'd guess you do too.

Here's what caught me up short recently: I tried to remember the last time I was genuinely bored. Not "between tasks," not "scrolling because I'm avoiding something" — actually bored. No screen, no input, no stream of someone else's thoughts pouring into mine. Just me, and an unfilled stretch of time, and nothing to fill it with.

I couldn't remember. It might have been years.

And for most of my life, I'd have called that a win. Boredom was the enemy, right? The thing to be solved, optimized away, never tolerated. We finally killed it. We have, in our pockets, an infinite supply of things to never be bored with again.

I'm starting to think we lost something, and I didn't notice it leaving.

Boredom was never empty

Here's the reframe that's been sitting with me. I always thought of boredom as empty time — dead air, wasted minutes, the absence of anything happening.

But that's not what it was. Boredom was the one mode where your mind got to wander with no destination. Where it drifted, made odd connections, chewed on things in the background, daydreamed its way into ideas you weren't trying to have. It looked like nothing was happening. Underneath, a lot was.

Think about where your actual good ideas come from. Not the ones you grind out at a desk — the real ones, the ones that arrive sideways. They come in the shower. On a walk with no podcast. Staring out a train window. In the drifting minutes before sleep. "Shower thought" is a cliché precisely because it's true: insight shows up in the gaps, not in the grind. The gaps were when your brain finally had room to connect the dots it had been quietly collecting all day.

Boredom was the soil those ideas grew in. We just called it wasted time, because it didn't look productive — and so, the moment we had a way to eliminate it, we did.

We filled every gap, and barely noticed

What's strange is that nobody chose this. There was no moment where you decided, "I will never again sit in an empty minute." It just happened, gradually, one filled gap at a time.

The commute got filled. The waiting room got filled. The queue at the shop, the ad break, the walk from the car, the thirty seconds for the kettle — all of it, filled. There is now no idle moment in a normal day that has to stay idle, because there's always something within reach to pour into it. And because the filler is so good — endlessly novel, perfectly tuned — the reaching became automatic. You don't decide to fill the gap. The gap appears and the hand moves.

It got paved over so quietly that the loss never registered as a loss. You don't miss the shower thoughts you didn't have. You don't notice the ideas that didn't connect because the dots never got their idle time together. The mental space didn't get taken from you in some dramatic way you'd resent. It got nibbled, a moment at a time, until there was none left and you'd forgotten it was ever there.

And now there's a new filler, and it's the most seductive one yet

The feed was one thing. At least with a feed you still had to do a little of the work — scroll, choose, react, think something.

But there's a newer gap we've started filling, and it's a quieter, deeper one: not knowing.

You used to be allowed to not know things for a while. You'd hit a question and have to sit with it — turn it over on the walk home, stay puzzled through dinner, wake up still chewing on it. That unresolved state was uncomfortable, and it was also doing something. Sitting with a question is how you actually think about it. The puzzlement was the processing.

Now the answer is instant. You wonder something, you ask, it's there. Which is genuinely wonderful, and I use it all day. But it means the puzzlement never gets to happen anymore. The question and the answer have collapsed into the same second, and the thinking that used to live in the space between them has nowhere to occur.

And I notice this is the same shape as something I wrote about before — the way the struggle of solving a hard problem yourself was where the satisfaction lived, and removing the struggle quietly removed the joy. This is the twin of that. First we optimized away the friction of struggling. Now we're optimizing away the friction of not knowing, and of being unoccupied. We keep finding the uncomfortable mental states and smoothing them out — and it keeps turning out that the discomfort was load-bearing. The friction was where the good stuff lived.

What I think we actually lost

It's easy to make this about "attention spans," but I don't think that's quite it, and that framing lets us off too easy. The loss is more specific, and more human.

We lost the ideas that only come in the gaps. If there's never an unfilled moment, there's never a shower thought. We may be quietly starving our own creativity — not because we got less creative, but because creativity needs idle, undirected time to do its work, and we deleted the idle time.

We lost being alone with our own minds. Boredom used to force a kind of self-contact — your own unmediated thoughts, with nothing in between. Fill every gap and you can get through an entire day without once being truly alone with your mind. There's a strange new loneliness in that: never lonely, because never without input, and also never actually with yourself.

We lost our tolerance for discomfort. The flinch toward the phone in the empty three seconds is really a shrinking ability to sit in any unstructured, uncomfortable moment. And that tolerance was quietly holding up a lot of other things — patience, deep focus, the capacity to stay with a hard problem long enough to crack it. You can't do deep work if you can't tolerate thirty seconds of nothing.

I don't have a fix, and I'm suspicious of anyone who does

This is the part where a post like this usually pivots to "so do a digital detox!" and gives you a five-step plan. I'm not going to, because I don't believe it, and I think you'd feel the hollowness of it.

The honest situation is harder than that. You can't really go back — the gaps are filled, the tools exist and they're genuinely useful, and "just be bored on purpose" turns out to be weirdly difficult, because you always know relief is one tap away. Boredom you could escape at any second isn't really boredom; it's a test of willpower, which is a different and more tiring thing. Manufactured idleness isn't the same as the real kind, the same way choosing a hard path when the easy one is right there isn't the same as having no choice.

And it isn't all bad. The filled commute, the instant answer, the never-dull waiting room — these are real conveniences, and I'm not going to pretend I'd hand them back. This isn't a lament for a better past.

It's just an honest noticing: we traded something we didn't know we needed for something obviously convenient, and we can't cleanly un-trade it. We got rid of boredom without ever asking what boredom was for.

So

Here's the only thing I'll offer, and it's small on purpose.

Next time you're waiting for the kettle, try not reaching. Just stand there in the empty thirty seconds and notice what your mind does when you take it off the leash. It'll feel uncomfortable — faintly itchy, like you're forgetting to do something. That discomfort is the thing. It's the muscle we stopped using, twitching because it hasn't been asked to work in years.

We didn't lose boredom. We evicted it — quietly, conveniently, one filled moment at a time. And it's only now, in the rare second the room goes quiet, that some of us are realizing boredom had been paying rent all along, on something we actually miss: the wandering, the connecting, the just-being-with-ourselves. We filled the room with noise and only noticed the furniture was gone once it got quiet enough to look.

I don't know how to get it back. But I think I want to try to be bored again, at least sometimes. On purpose. Badly. Starting with the kettle.

Honest question, and I'd love real answers: when's the last time you were truly bored — no phone, no screen, no AI, just an empty moment you didn't fill? I struggled to remember mine, and I don't think I'm the only one. What did you used to think about, back when there were still gaps to think in?

Your AI Agent Will Do Something Terrible. Here's How to Survive It.

James Anderson — Tue, 06 Oct 2026 08:29:10 +0000

Here's a pattern I keep seeing.

A team wires up an AI agent that can do real things — send emails, run commands, query and modify the database, call external APIs. The demo is magical. It reads a request, figures out the steps, takes them, reports success. Everyone's impressed, and it ships.

Then comes the first incident. It emails the wrong list. It runs a destructive command against the wrong environment. It reads a web page that quietly tells it to do something nobody asked for, and it obliges. Suddenly the magical demo is a very un-magical cleanup, and someone's asking how this was allowed to happen.

Here's the thing: the demo was never the hard part. Getting an agent to do something is genuinely easy now. The hard part — the part that almost always gets skipped in the rush — is everything that keeps the agent from hurting you when it inevitably does the wrong thing. And it will do the wrong thing, because it's a probabilistic system acting in an unpredictable world.

So this is the checklist I think belongs before you let an agent touch anything that matters. Not the fun part. The part that separates an agent you can actually deploy from a liability with a good demo.

1. Least privilege — the agent can only reach what it strictly needs

This is the highest-leverage guardrail, and it's the one most worth getting right first, because it makes entire categories of disaster simply impossible.

An agent that cannot reach production cannot wipe production. An agent that cannot send money cannot be talked into sending money. An agent with no access to a system can't be the cause of an incident in that system, no matter how confused or compromised it gets. So the question to ask before anything else isn't "what should this agent be able to do?" — it's "what is the least it needs to do its job?" Then give it exactly that and nothing more.

Almost every catastrophic agent story, when you trace it back, turns out to be a permissions decision someone made without quite noticing — handing over credentials that could reach production at all, or a tool scope broader than the task required. The destructive action got the headline, but the over-broad grant was the actual mistake, made quietly, long before. Least privilege is the guardrail that catches the error at the point where it's cheapest to prevent.

2. Human approval for consequential actions — gated by blast radius

Some actions you can let an agent take freely. Some you absolutely should not let it take unattended. The skill is in drawing that line well.

The irreversible or high-impact ones — send, spend, delete, export, deploy — should pause for a human. But two things make or break this guardrail. First, don't gate everything. An agent that asks permission forty times a session trains the human to click "approve" without reading, and now your approval step is theater — the click records attendance, not consent. Reserve the gate for actions that actually warrant it.

Second, the approval has to be meaningful. "Approve this action? y/n" on something the human can't evaluate is a rubber stamp. Show the blast radius: what this affects, what it will cost, what it's about to change, what the relevant history is. Give the approver something concrete enough to actually reject. An approval made blind isn't a control; it's a liability with a signature on it.

3. Treat everything the agent reads as untrusted

Anything your agent ingests — web pages, emails, documents, a teammate's file, the output of a tool, a code comment — can carry instructions. This is prompt injection, and it's not a solved problem: you cannot reliably detect malicious instructions hidden in natural language, because the space of ways to phrase them is endless and attackers adapt to whatever filter you deploy.

So don't put your faith in detecting the bad input. Put the control on the action instead. The set of consequential things an agent can do (send, spend, delete, export) is small and you can enumerate it — so gate those few calls with hard checks that don't depend on the model's judgment about whether the content it just read was trustworthy. The practical rule of thumb: an agent becomes dangerous when it has private data access, exposure to untrusted content, and the ability to act externally, all at once. Remove any one leg of that triad and a successful injection has far less it can reach.

4. A reviewer that can actually say "no" — and has been tested saying it

For consequential actions, a second check — a validation step, or a separate "judge" agent whose job is to review the proposed action before it executes — adds real protection. A system that has to convince an independent reviewer is much harder to push into a bad outcome than one that just acts on its own first impulse.

But here's the part people skip: a reviewer that always approves is not a control. It feels like safety, it generates a reassuring log, and it stops exactly nothing. Before you trust a reviewer, hand it a deliberately bad action — one you know should be refused — and confirm that it actually blocks it. A guardrail you've never watched engage is not a guardrail; it's a hope with good UI. Test the "no," or you don't have one.
Better still, make that test permanent: have a deliberately-failing probe run on a schedule and emit a receipt like any other check, so "the reviewer has been tested saying no" becomes a standing, provable property of the system instead of a memory of one afternoon. (Credit: @slabb.)

5. An independent audit trail — because the witness can't be the suspect

When something goes wrong, you'll go to the logs to reconstruct what happened. And here's the trap: if the logs were written by the agent, they were written by the very thing that misbehaved. A confused or compromised agent doesn't produce a broken log that tips you off — it produces a clean one, a tidy record of a bad decision, which is worse, because a clean log makes you stop looking.

So the record has to be produced somewhere the agent doesn't control — the infrastructure or supervisor layer around it, not the agent's own self-report. Seal it so that tampering leaves a visible gap rather than a silent edit. And capture not just what the agent did but what it believed at the time — which environment it thought it was in, which target it thought it was acting on — because the action is usually defensible given a wrong belief, and the belief is the part that actually explains the incident.

A quick, disclosed note on what this looks like in practice: I work on xenition.com, an AI workspace, and this exact cluster — approval gates, an independent audit log, a second reviewer — is something we had to build in deliberately rather than bolt on afterward. In our setup an agent's consequential actions pass through an approval gate, every step is written to an audit log the agent itself doesn't author, and a separate judge-agent reviews an action before it runs. I'm not holding it up as the answer — plenty of stacks assemble these pieces differently, and the right shape depends on your system. I mention it only as a concrete illustration that none of this is theoretical: the approval gate, the independent record, and the second reviewer are things you can actually ship today, and increasingly things you should.

6. Blast-radius limits — assume it will go wrong, and bound how bad

The guardrails above reduce how often things go wrong. This one accepts that something eventually will, and makes sure no single mistake is catastrophic.

Put hard limits around the agent: spending caps, rate limits, quotas on how many actions it can take before it has to check in. Prefer reversible actions by default — soft deletes over hard ones, staged rollouts over all-at-once, drafts over sends. The mindset shift is the important part: stop trying to guarantee the agent never errs (you can't), and start guaranteeing that when it does, the damage is small, contained, and recoverable. A mistake that costs you a reversible change and a shrug is a completely different thing from one that costs you a database.

7. Observability that measures the effect, not the report

Finally, watch the right thing. A dashboard built to answer "did the agent report success?" is, by construction, a dashboard built to trust the witness — and we just covered why the witness can't be trusted. The agent will happily report a valid-looking success while pointing at the wrong target, and your green dashboard will tell you everything is fine.

So measure the world, not the agent's account of it. Did the invariant hold? Does the total still balance? Is the referenced record actually there? Is the system still in a consistent state? These checks are more annoying to write than "did it return 200," and they are the only ones that catch the failure where the report looks perfect and the reality is wrong. Measure the effect, not the self-report.

The takeaway

Capability is the easy part. It's also the exciting part, which is exactly why it gets all the attention and all the demo time — and why the guardrails, which are none of those things, get left for "later," which often means "after the incident."

But an agent's real value in production was never what it can do. It's what it can do safely, repeatably, and recoverably — what it can do without becoming the thing you spend next quarter cleaning up after. The seven items above aren't the glamorous part of building with AI. They're the part that decides whether the glamorous part survives contact with the real world.

Build the brakes before you build the engine. Or at the very least, before you take it out on the highway.

If you've shipped an agent to production, I'm genuinely curious: which of these did you have in place before your first incident — and which one did you add right after it taught you the hard way? Most of us learned at least one of these the expensive way. Which was yours?

The Witness Was the Suspect: Why AI Audit Logs Can't Be Trusted

James Anderson — Mon, 05 Oct 2026 06:02:25 +0000

An AI agent does something it shouldn't. It leaks data, or wipes the wrong database, or makes a call nobody sanctioned. So you do the obvious thing: you go to the logs to find out what happened.

The logs are clean.

Of course they are. They were written by the same process that did the thing. The agent reported "success," in valid format, pointing at the wrong target — and your monitoring, built to answer "did it succeed?", lit up green. The record of the incident was authored by the cause of the incident.

That's the uncomfortable shape of this whole problem, and it's why I want to talk about it: in an AI system, the witness is very often the suspect. The thing that acts is the thing that reports what it did. And once you see that, a lot of our instincts about logs, audits, and "we have a verification step" stop holding up.

But before the logs — before the dramatic incident — there's a quieter version of this that every one of us has already lived. Let's start there, because it's the part that actually bites you on a normal Tuesday.

The failure that doesn't announce itself

Here's the thing about traditional bugs: most of them fail loud. The code throws. The test goes red. The build breaks. The failure happens right where you are, right when you're looking at it, and it basically grabs you by the collar and says fix me. That's annoying, but it's a gift — the error and the moment you could catch it cheaply are in the same place.

AI failure is the opposite. It fails plausible.

You ask for a function, and you get one that looks completely correct — clean, reasonable, right shape — and it's subtly wrong in a case you didn't check. You ask for a query, and it returns a number that looks fine. You ask for a summary, and it's confident and well-structured and quietly missing the one thing that mattered. There's no throw, no red, no flag. It sails right past the exact moment you'd have caught it for the price of a second glance, because nothing told you to look.

And then the bill arrives later — at the worst possible time, for the worst possible price.

You find it when a number is subtly off in a dashboard three weeks on. When a function that "worked" breaks on an edge case in production. When you realize the data's been quietly wrong since a change nobody flagged. And now the trail is cold. You're reverse-engineering what the AI did, when, and why, with no breadcrumb pointing back — and that costs hours, sometimes days. An error that had failed loud would've cost you minutes.

This is the part people miss when they say AI "saves time." Sometimes it does. But when it's wrong in the plausible way, it doesn't save the time — it moves it. It takes a cost that would've been small and immediate and relocates it into the future, where it's cold, compounded, and expensive. Fast to produce, slow to trust, brutal to untangle.

And here's where it connects to the logs: when you finally go to reconstruct what actually happened, you reach for the record — and the record was written by the thing that produced the plausible-wrong output in the first place. Which is where this stops being a productivity annoyance and becomes a genuine trust problem.

The assumption hiding in every tool we reach for

Think about what you actually do when something goes wrong. You check the logs. You read the audit trail. You look at the monitoring dashboard. You say "well, we have a verification step."

Every single one of those moves rests on an assumption we almost never say out loud: that the thing doing the recording is honest.

That assumption used to be safe, because the actor and the recorder were usually different things. The database recorded what your code did to it. The load balancer logged the requests it received. The reporter sat outside the thing it was reporting on, so it had no stake in lying.

AI agents collapse that separation. The thing that decides, acts, and then writes "here's what I did" is one system. So a compromised or confused agent doesn't produce a broken log that tips you off. It produces a clean one — a faithful-looking record of a bad decision. And a clean log is worse than a missing one, because a missing log makes you suspicious and a clean log makes you confident. You stop looking. The record did its job of reassuring you, and the reassurance was false.

So the natural response is: okay, add something to check the agent. Add a verifier.

Hold onto that instinct, because it's exactly the trap.

Why you can't verify your way out of this

Say you add a checker — a second process that verifies what the agent reported. Good. But now ask the obvious question: who checks the checker?

The checker is also just a process. Its report can also be wrong, or compromised, or fed bad input. So to trust it, you need a verifier for the verifier. And a verifier for that one. You've not solved the trust problem — you've moved it up one layer and added a box. It's verifiers all the way down.

People reach for CI here: "we re-run the verification in CI, outside the agent." That helps only if CI reads the ground truth itself. If CI trusts whatever the agent reported, you haven't escaped anything — you've just got the same trust problem wearing a CI badge. The regress doesn't care which layer you're on.

This is the same disease as letting a student grade their own exam — except worse, because you can't fix it by having a second student grade it when the first one can influence what the second one sees. Verification is itself a thing that can be compromised, so you cannot reach "trustworthy" by stacking more verification on top. There is no bottom to that stack.

Which means the whole framing is wrong. The question "can I trust this record?" has no clean answer, because the thing you'd ask to confirm it is the thing that might be lying. You have to stop trying to answer it — and ask a different question entirely.

The move that actually works: make tampering leave a shape

Here's the shift. Stop trying to make the record prove what's true. It can't — the recorder can lie, and you've just seen you can't verify your way around that.

Instead, make the record prove something humbler and achievable: who claimed what, and when — sealed at the moment of the claim, in a way nobody can quietly rewrite afterward.

Notice what that gives up and what it keeps. It gives up on certifying truth. It keeps sequence and authorship — and, crucially, it makes those tamper-evident. The chain doesn't vouch for the claim being correct. It vouches for the fact that this claim was made, by this party, at this point, and hasn't been altered since.

And that turns out to be enough, because of what it does to tampering. When you can't silently rewrite the record, a lie can't produce a clean result anymore — it produces a hole. A silent bypass shows up as an approval with no matching proposal behind it. A deleted step shows up as a gap in the chain. A forged decision shows up as a sequence that doesn't reconcile. You're no longer asking "is this true?" (unanswerable). You're asking "does the shape have a hole in it?" — and that is answerable, structurally, without trusting anyone's word.

That's the whole idea, and it's the thing that ends the regress: you don't verify your way to trust. You engineer the system so that tampering can't happen silently. Make a lie leave a mark, and you've converted an impossible question into a possible one.

What this looks like in practice

This isn't abstract — and I want to be specific about where it came from, because a piece arguing that provenance should travel with the artifact has no business burying its own. The core of what follows was ground out in public, mostly in the comments under my slopsquatting post, in a long exchange with @slabb and @xxxn3m3s1sxxx: the proposal/approval/execution split, sealing each claim at write time, the framing that the chain vouches for who claimed what and when rather than for truth, and the "approval with no matching proposal" hole. The "record the belief" and "name, not a role" pieces are mine; the rest of this section is theirs as much as anyone's. The mechanics that matter:

Separate the writers. Proposal, approval, and execution shouldn't be one process reporting on itself. Make them three events from three different parties, correlated by the thing they refer to. The agent that proposes an action is not the one that approves its own resolution. Then, when they disagree after the fact, you have a sequence to read instead of an opinion to negotiate — and "approval with no matching proposal" becomes a visible structural fact, not a judgment call.

Seal each claim at write time. A hash chain plus signatures, so each entry is bound to the ones before it. You're not proving any claim is correct; you're making it impossible to alter a claim, or reorder the sequence, after the fact without leaving evidence. The seal is what turns a silent edit into a visible hole.

Reconcile across independent streams. A single sealed chain can only vouch for who claimed what and when — a lie sealed cleanly verifies clean forever. But two independently sealed streams, written by different parties about the same event, can disagree, and disagreement between tamper-evident sources is the only evidence that reaches the claims themselves. (This one is @slabb's — the open reconciliation layer he's building is at github.com/noirebox.)

Anchor it outside the actor. The record's integrity cannot depend on the thing being recorded — that's the original sin we're trying to escape. An append-only store the operator can't quietly edit, ideally with external anchoring, so "I rewrote my own history" isn't an available move.

Record the belief, not just the action. The database-wipe incidents teach this one: the agent's action was often defensible given what it believed — it thought it was in dev, it thought that was the test target. So capture the agent's resolved view of the world at decision time (which environment, which identity, which target), sealed before it acts. The action alone doesn't tell you why; the belief does. Log the symptom and the cause.

A name, not a role. "Who authorized this" has to resolve to a specific person with something to lose, recorded — not "a reviewer," not "the system." Otherwise the authority is just another anonymous plausible why generated after the fact. The line was drawn by someone; the record should say who.

None of these pieces is exotic. Together they do one thing: they make it so that when something goes wrong, the failure shows up as a shape you can see, instead of a clean report you'll believe.

The honest limits (because this isn't magic)

I want to be straight about what this does and doesn't buy you, because overselling it would be its own kind of plausible-looking lie.

It proves the work happened under an identity that can't be minted, in a sequence that can't be rewritten. It does not prove the output was any good. Whether the thing the agent did was correct or wise is a separate, harder problem — machine evidence is cheap and scales; judgment is expensive and doesn't.

It proves who claimed what, and when. It does not prove whether the person who approved actually understood what they were approving — which, once you've got approval fatigue and forty rubber-stamped prompts a session, is the genuinely unsolved half.

And it makes tampering visible, not impossible. The guarantee is legibility, not prevention. You can still do the bad thing; you just can't do it silently.

That's a weaker promise than "trustworthy logs," and that's the point — "trustworthy logs" was never on the table once the witness became the suspect. "A lie has to leave a mark" is the strongest honest floor I know of.

Where I land

We keep asking the wrong question. "Can I trust this record?" feels like the natural thing to ask when an AI system misbehaves — but in a world where the thing that acts is the thing that reports, it's a question with no clean answer, because the witness you'd call is the suspect in the dock.

So stop asking it. The achievable goal was never a record that proves the truth. It's a record where a lie can't stay quiet — where the bypass shows up as a hole, the deletion as a gap, the forged approval as a step with nothing behind it. You can't verify your way to trust, because every verifier needs a verifier. But you can build a system where tampering leaves a shape — and then the question stops being the unanswerable "is this true?" and becomes the answerable "is the shape intact?"

That won't catch the plausible-wrong function before it ships. But it means that when you finally go looking — three weeks later, trail cold, dashboard quietly wrong — the record can't smile at you and lie. At minimum, it has to show you the hole.

Here's the one I keep getting stuck on, and I'd genuinely like to be argued out of it: every verification layer you add is itself a thing that can be compromised, so "make tampering leave a shape" looks to me like the actual floor — not a stepping stone to something stronger. Is there a move I'm missing that gets you more than legibility? And for anyone building this: what's the hole that's hardest to make visible?

Analytics Engineer: The Job That Didn't Exist 5 Years Ago (and Why It Does Now)

James Anderson — Sun, 04 Oct 2026 07:25:03 +0000

Here's a scene that plays out at basically every company that has ever had more than one dashboard.

Someone in a meeting pulls up the sales dashboard. It says last month's revenue was $2.1M. Someone else pulls up the finance dashboard. Their number says $1.9M. Same company, same month, same word — "revenue" — and two different answers. The room spends twenty minutes trying to figure out which one is right. Nobody can say for sure. The meeting moves on, quietly trusting neither.

If you've worked anywhere near company data, you've lived this. And here's the thing: it's not that someone made a mistake. It's that the way most companies handle data makes this outcome almost inevitable. There's a reason it happens — and over the last few years, a whole discipline (and one very popular tool) grew up specifically to fix it.

Let me walk you through why the dashboards disagree, and what "analytics engineering" actually is — because it's one of the more useful things to understand in tech right now, whether or not you work in data.

Why the two numbers are different

The dashboards disagree because somewhere, two different people wrote two different definitions of "revenue" — and neither of them knew about the other.

Think about how a number gets onto a dashboard. Raw data lands in a database — orders, refunds, discounts, taxes, failed payments, test transactions, canceled subscriptions. To turn that mess into "revenue," someone writes a SQL query that decides a hundred small things: Do we count refunds? Do we subtract discounts? Is tax included? What about an order that was placed but not yet paid? Does a canceled subscription count for the month it was canceled?

Every one of those choices changes the final number. And here's the problem: those choices usually live inside individual queries, scattered everywhere, written by different people at different times. The sales dashboard's query counts refunds one way. The finance dashboard's query counts them another. Both authors were reasonable. Neither wrote down their assumptions. Nobody reviewed either one. And now you have two "revenues."

Multiply that across every metric a company tracks — "active user," "churn," "conversion," "monthly recurring revenue" — and you get the normal state of most companies' data: a pile of undocumented, untested, uncoordinated SQL, where the definition of any given number lives in six different places and nobody's quite sure which is authoritative.

Now here's the part that should make a developer's eye twitch.

Data transformation was the last corner of software with no engineering discipline

Think about how you write application code. You use version control, so every change is tracked and reviewed. You write tests, so you find out when something breaks before your users do. You document things. You reuse code instead of copy-pasting it. You have a review process. These habits are so standard we don't even think about them — they're just how software is built.

Now look at how that revenue query got written. No version control — it lived in a BI tool or someone's saved file. No tests — nobody asserted "revenue should never be negative" or "every order should have exactly one customer." No documentation — the assumptions were in the author's head. No reuse — the next person wrote their own slightly different version from scratch. No review — it went straight to a dashboard the whole company trusts.

For years, this was just how data transformation worked. The entire last step — turning raw data into the numbers people make decisions on — had none of the engineering discipline we take for granted everywhere else in software. It's genuinely strange when you say it out loud: the most decision-critical code in the company was the least engineered.

That gap is exactly what analytics engineering fills.

So what is analytics engineering?

It's a role — and a discipline — that emerged in the last few years to sit in a gap nobody was covering. The easiest way to see it is against the two roles it sits between:

Data engineers build the pipelines that move raw data into the warehouse. (Plumbing.)
Data analysts take clean data and answer business questions, build dashboards, find insights. (Analysis.)
Analytics engineers are the missing middle: they take the raw, messy data that landed in the warehouse and transform it into clean, trustworthy, well-defined datasets that the analysts can actually rely on.

The one-line version: a data analyst spends their time analyzing data; an analytics engineer spends their time transforming, testing, and documenting it — so that when an analyst asks for "revenue," there's exactly one definition, it's correct, and everyone's using it.

And what makes analytics engineering a discipline rather than just a job title is the core idea behind it: bring software engineering practices to data. Version control. Tests. Documentation. Modularity. Code review. The exact habits that data transformation never had.

Which brings us to the tool that basically created the whole movement.

dbt: the tool that brought engineering discipline to data

dbt ("data build tool") is an open-source framework, and it's become the backbone of analytics engineering. What it does sounds almost mundane until you realize nobody was doing it: it lets you write your data transformations as modular, version-controlled, tested, documented SQL.

Here's what that actually looks like in practice — and why each piece fixes the two-dashboards problem:

Transformations become code in Git. Instead of a query hidden in a BI tool, your "revenue" definition is a SQL file in a version-controlled repository. Every change is tracked, reviewed, and attributable. There's one file that defines revenue, and you can see its entire history. The scattered-definitions problem disappears because there's now one place the definition lives.

You write tests on your data. This is the part developers love once they see it. dbt lets you write assertions that run every time your data builds — unique (this ID never repeats), not_null (this field is never empty), accepted_values (status is only ever 'active'/'canceled'/'paused'), relationships (every order points to a real customer). If the data violates an assumption, the build fails — and you find out, instead of a dashboard quietly showing a wrong number to an executive for three weeks.

Models are modular and reusable. Instead of copy-pasting the same logic, you build small models that reference each other. Define "clean orders" once; every downstream metric that needs orders references that one model (in dbt you literally write {{ ref('stg_orders') }} instead of hardcoding a table name). One definition, reused everywhere — so sales and finance are now mathematically guaranteed to be counting the same orders the same way.

Documentation is generated automatically. dbt produces docs — including a visual map of how every dataset derives from every other (data lineage). When someone asks "what does this column mean?" or "where does this number come from?", the answer is in the docs, not in an engineer's memory. Analysts can self-serve instead of filing a ticket.

Changes ship safely through CI/CD. Analytics engineers work in a development environment, test their changes, get them reviewed, and only then promote them to production — the same safe pipeline you'd use for application code. A bad change to the revenue definition gets caught in review, not in a board meeting.

Put it together and the two-dashboards problem is structurally solved: there's one definition of revenue, it's version-controlled, it's tested, it's documented, and both dashboards are built from the same model. They can't disagree, because they're the same source of truth.

Why this is worth understanding (even if you're not in data)

Maybe you're a web developer thinking "cool, but this isn't my world." Here's why it's worth having in your head anyway.

First, it's one of the fastest-growing, most in-demand roles in tech right now, and a lot of developers have vaguely heard "dbt" and "analytics engineer" without being able to explain either. Now you can.

Second — and more interesting — it's a beautiful case study in a pattern that shows up everywhere: a messy, error-prone, tribal-knowledge process gets transformed the moment someone applies basic engineering discipline to it. Version control, tests, documentation, modularity, review. These aren't exotic ideas. They're the boring fundamentals of software engineering. And the entire analytics-engineering movement is, at its core, just those boring fundamentals finally arriving in a place that didn't have them.

That's a useful lens to carry around. Any time you find a critical process that runs on undocumented scripts, copy-paste, no tests, and "ask the person who wrote it" — you've found the same gap dbt filled for data. The fix is almost always the same fundamentals.

The takeaway

Two dashboards disagree on revenue because, for most of software's history, the code that turns raw data into business numbers was written with none of the discipline we demand everywhere else — no version control, no tests, no documentation, no single source of truth. The disagreement wasn't a bug. It was the predictable result of an un-engineered process.

Analytics engineering is the discipline that closes that gap, and dbt is the tool that made it mainstream, by doing something almost unglamorous: treating data transformation like real software. Version-control it. Test it. Document it. Make one definition and reuse it.

The next time two dashboards disagree, you'll know exactly why — and exactly what fixes it. It's not a better chart. It's engineering discipline, finally applied to the last place that didn't have it.

A question for the room: what's the most painful version of "two numbers that should match but don't" you've run into at work? And if you've adopted dbt (or something like it) — what actually changed once you did? I'm curious whether the "single source of truth" promise holds up in practice or just moves the arguments somewhere new.

Everyone Told You to Grind DSA. They Left Out Two Things.

James Anderson — Sat, 03 Oct 2026 08:11:03 +0000

If you're just starting out as a developer, you've probably noticed that everyone's advice contradicts everyone else's.

One person swears you have to grind 500 LeetCode problems or you'll never get hired. Another says DSA is dead and you should just learn to use AI tools. A third says forget both, just build projects. And you're sitting there with a limited number of hours in your week, no idea who's right, so you either freeze — or you default to grinding DSA, because that's the loudest voice in the room.

Here's the honest truth: they're all half-right. And the thing nobody's actually telling you is how the pieces fit together.

So let me draw you the map I wish someone had drawn for me. There are three skills you need to balance as a new developer — I think of them as a triangle — and the third side is the one almost nobody teaches, even though it's quietly the one that actually gets you hired. Let's walk through all three, and then I'll tell you honestly where to spend your time.

Side one: DSA — what it really is (and what it isn't)

Data Structures and Algorithms. The thing you grind on LeetCode. Let's be fair to it, because it's not useless — but it's badly misunderstood.

What DSA genuinely gives you: a way of thinking. It teaches you to break a hard problem into smaller pieces, to reason about whether your solution is efficient or wasteful, and to recognize patterns ("oh, this is really a graph problem"). That mental toolkit is real, and it'll help you your whole career.

What DSA is not: a measure of whether you're a good engineer. This is the part beginners get wrong. Grinding 500 problems doesn't make you a good developer — it makes you good at passing interviews. Those are very different things, and confusing them will waste months of your life.

Why it became such a big deal: here's the honest history. DSA interviews exist because companies get thousands of applicants and need a cheap, standardized way to filter them. A LeetCode problem is easy to administer and easy to grade, so it became the gate. It's a proxy for "can this person think clearly under pressure" — not a test of the actual job. Useful to know, because once you see it's a filter rather than the job itself, you can treat it like one.

Your beginner takeaway: you need enough DSA to get through interviews and to think clearly — not enough to win competitions. Learn the core patterns (arrays, strings, hash maps, two pointers, basic trees and graphs, recursion), understand why they work, and practice enough to be comfortable. Then stop grinding. The 400th problem teaches you much less than the first 50 did.

Side two: AI fluency — the new side of the triangle

This side didn't really exist a few years ago, and now it's non-negotiable.

Why it matters now: AI tools are part of how real development actually happens. This isn't hype — it's just the current reality of the job. A developer who can work with AI effectively moves faster than one who can't, the same way a developer who knew their IDE's shortcuts always had an edge. Refusing to learn it doesn't make you more pure; it just makes you slower than everyone around you.

But here's the nuance that actually matters — and almost nobody tells beginners this clearly: AI fluency is not "let the AI do everything." This is the trap. If you lean on AI to write code you don't understand, you'll produce working-looking things without ever building the judgment to know when the AI is wrong — and it is wrong, often and confidently. You'll feel productive while quietly failing to become a developer.

Real AI fluency means using it to go faster while still understanding what it produces. Use it to explain a concept you're stuck on. Use it to draft something you then read, question, and verify. Use it to learn faster — not to skip the learning. The beginners who'll thrive are the ones who treat AI as a tool that accelerates their thinking, not a crutch that replaces it.

Your beginner takeaway: learn to use AI well, but make a rule for yourself early — never ship (or submit, or rely on) code you couldn't explain. Let AI speed you up; don't let it think for you. That one habit separates the beginners who grow from the ones who plateau.

Side three: the skill nobody teaches — and the one that actually gets you hired

Here's the side of the triangle that bootcamps skip, CS degrees barely touch, and no website lets you grind. It's also, in my honest opinion, the most important one.

What it is: actually building real things, and being able to communicate. Shipping a project from nothing to working. Reading code other people wrote and understanding it. Debugging something when it breaks at 11pm and the error message is useless. Explaining your thinking so a teammate gets it. Working with other humans without friction. Figuring out what to build and why it matters.

Why nobody teaches it: because it's not a tidy, testable curriculum. You can't put "knows how to debug a confusing problem calmly" on a multiple-choice quiz. You can't grind "communicates clearly" on LeetCode. So the educational system optimizes for the measurable stuff — DSA, syntax, frameworks — and this whole category quietly falls through the cracks. Nobody's against teaching it; it's just hard to package, so it gets left out.

Why it's the one that actually gets you hired — and keeps you hired: think about the mismatch. Interviews often test DSA. But the actual job tests this third side, every single day. The developer who can build a real thing end-to-end, explain it clearly, and work well on a team will beat the one who can reverse a linked list but has never shipped anything and goes quiet in a meeting. And here's the kicker: this side is the most durable. Tools change. Frameworks die. DSA trivia fades the week after the interview. But the ability to build, debug, understand, and communicate compounds across your entire career. It's the skill that's still paying off in year fifteen.

Your beginner takeaway: this is almost certainly the side you're neglecting right now — because it's the one nobody told you to practice. So protect time for it deliberately. It won't happen by accident.

So where should you actually spend your time?

Okay — the honest map. You've got limited hours. Here's roughly where they should go, as a beginner:

Learn enough DSA to pass the filter and think clearly — then stop over-grinding. Spend a focused chunk of time early on getting comfortable with the core patterns and understanding the why. Keep it warm with occasional practice before interviews. But don't let it become your whole identity. Past a certain point, each new problem teaches you less than building something real would.

Spend most of your time building real projects. This is the big one, and here's the secret: building real things exercises all three sides of the triangle at once. You use DSA (you'll hit a real performance problem and finally understand why it matters). You use AI (in context, as a tool, while still having to make it work). And you build the third side — shipping, debugging, understanding, deciding. "Just build stuff" sounds like lazy advice, but it's actually the most efficient advice, because one activity trains everything.

Learn AI in context, not as a separate subject. Don't set aside "AI study time." Just use it while you build and learn — and hold yourself to the rule of understanding what it gives you. Fluency comes from use, not from a course.

The meta-point: the three sides aren't in competition for a beginner. DSA sharpens your thinking, AI makes you faster, and building integrates both while developing the skills that actually matter on the job. The mistake isn't picking the wrong side — it's pouring everything into one side (usually DSA, because it's the loudest) and letting the other two wither.

The honest, reassuring truth

If you take one thing from this, take this: you do not have to be a LeetCode wizard to have a great career. Most genuinely good engineers aren't. Some of the best developers I can think of would struggle with a hard DSA problem on the spot — and it has never once mattered, because they can build real things, work with people, and figure out what needs doing.

You also don't have to be perfect at all three sides of the triangle. Nobody is. What you have to do is stop ignoring one of them. The developers who thrive aren't the ones who maxed out a single skill — they're the well-rounded ones: enough DSA to think, enough AI to move fast, and a real, growing ability to build and communicate.

So here's the whole thing in one picture. DSA gets you through the door. AI fluency keeps you fast and current. But the ability to build real things and work with people is what actually gets you hired, keeps you hired, and grows your career. Learn enough of the first two to stop them being blockers — then pour your energy into the third, because it's the side nobody teaches and everybody needs.

A triangle needs all three sides to stand up. Don't build one long line and call it a career.

If you're just starting out: be honest — which side of the triangle have you been pouring all your time into, and which one have you been quietly avoiding? And for the folks who've been doing this a while: what's the thing that actually got you hired, versus what you studied beforehand? I'd love for the beginners reading this to hear the real answers, not the LinkedIn ones.