DEV Community: Raffi Hovhannesian

Model Collapse Isn't New, Nor Is It Specific to AI

Raffi Hovhannesian — Thu, 08 Oct 2026 20:20:13 +0000

We've all heard the usual complaint, that AI just remixes open-source code it was trained on. That's true, and it's been argued to death, but something quieter is happening, and I think it matters more.

You open the chat and type "Help me build a note-taking app". AI suggests features, then a name, a color palette, a pricing model and a launch strategy. You pick the ones that you like and feel like the architect.

Nothing is wrong with that, until you zoom out and realize you didn't design anything. You just chose from a menu someone else wrote. In some cases, your original goal has quietly been replaced by something you might or might not need.

And it doesn't stop at your product. In a study of 1,506 people, those who wrote with an opinionated AI assistant didn't just write differently. Their own opinions shifted toward the AI's.¹

When one entity has processed nearly all the information in the world, it develops a very specific sense of what's "correct": the best practice, the balanced take, the optimal answer. And it doesn't just advise you. It advises everybody.

Millions of people, one oracle, one answer. Then they publish it, and it becomes tomorrow's training data.

Researchers have already measured what happens next, at least inside the machines. In a 2024 Nature paper, Ilia Shumailov and his colleagues found that training AI on AI-generated content "causes irreversible defects in the resulting models, in which tails of the original content distribution disappear." They called it model collapse.²

The "tails" are the rare stuff: the unusual, the weird, the one-in-a-million. In other words, exactly the things that drive progress.

The answer isn't wrong. In many ways, it is the truth. That's the problem.

It is an averaged truth. It is correct. It is polished. It is optimized for agreeableness. But, it lacks the dynamo of real life, it lacks the mistake that turned into a discovery that no other entity in the world has discovered before.

We've seen this before, long before the machines.

For centuries, much of Europe ran on a single source of truth: a sacred text, and an institution that interpreted it.³ You didn't need to work things out for yourself. You asked, and you received the answer, the same answer everyone else received. This isn't a judgment on faith, which has given people meaning, community and a moral compass for thousands of years. It's about what happens to thinking when everyone consults the same source. Questions start to look like heresy, and variation starts to look like error. Interpretation becomes stable, coherent and very, very slow.⁴ The tails disappear.

The sacred text was never the problem (internet data). The monopoly on interpreting it was (AI version of truth).

Then something broke the monopoly. The printing press put the text in more hands than any institution could supervise. People read it for themselves, disagreed and argued, and some of them were burned for it. The tails came back, and with them came the Reformation, the scientific revolution and the messy, noisy, self-correcting world we live in today.⁵

The Difference

This time, in the age of AI, there's a twist.

Nobody forced this oracle on us. No institution demands our obedience, and there's no penalty for heresy. You can close the tab whenever you like.

We chose it, because it's convenient.

And convenience is a far more effective authority than force. Nobody rebels against something that saves them time. There's nothing to smuggle when nothing is forbidden. There's just one very helpful answer. Each of us gets a better answer, and together we all get the same one.⁶

The printing press broke a monopoly that was imposed on people. But nobody has invented a printing press for a new monopoly we all signed up for. Not yet.

The Way Out

The way out isn't to stop using AI. Use it, build with it and let it save you time.

Just don't let it be the only voice in the room.

Seek the second opinion:

When the AI gives you the answer, ask a human. Better still, ask someone who disagrees with you.

Find the stranger:

Show your idea to someone outside your field, your feed and your industry. They haven't been trained on the same data you have.

Keep a heretic around:

Every team needs the person who says "that's the best practice, so let's try the opposite." They'll be wrong most of the time. The time they're right is the discovery.

Protect your original goal:

Before you open the chat, write down what you actually wanted to build. When you're done, compare. If the AI's version won, make sure it won on merit and not on convenience.

Take advice, but don't outsource your taste:

AI can tell you what's correct. Only you can decide what's yours.

Model collapse isn't new. Humanity has lived through it before and found its way out, through stubborn, inconvenient people who refused to take the same answer as everyone else.

Be inconvenient.

Jakesch, M., Bhat, A., Buschek, D., Zalmanson, L., & Naaman, M. (2023). Co-Writing with Opinionated Language Models Affects Users' Views. Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3544548.3581196 ↩
Shumailov, I., Shumaylov, Z., Zhao, Y., Papernot, N., Anderson, R., & Gal, Y. (2024). AI models collapse when trained on recursively generated data. Nature, 631, 755–759. https://doi.org/10.1038/s41586-024-07566-y ↩
Harari, Y. N. (2024). Nexus: A Brief History of Information Networks from the Stone Age to AI. Random House. Harari argues that treating a holy book as infallible doesn't eliminate human fallibility. It shifts authority to its interpreters, and he contrasts this with science's self-correcting mechanisms. ↩
Historians rightly caution against the "Dark Ages" myth. The medieval Church also preserved texts, founded universities and supported early science. The point here is narrower: what happens when a single source holds the monopoly on interpretation. See Numbers, R. L. (Ed.). (2009). Galileo Goes to Jail and Other Myths about Science and Religion. Harvard University Press. ↩
Eisenstein, E. L. (1979). The Printing Press as an Agent of Change. Cambridge University Press. ↩
Doshi, A. R., & Hauser, O. P. (2024). Generative AI enhances individual creativity but reduces the collective diversity of novel content. Science Advances, 10(28), eadn5290. https://doi.org/10.1126/sciadv.adn5290 ↩

Optimistic UI is an architectural decision, not a minor UX tweak

Raffi Hovhannesian — Sun, 27 Sep 2026 13:03:27 +0000

While building Rulrmail, an open-source, email-first CRM, I wanted one small thing: when you star an email, the star should light up now, not after a round trip to a mail server somewhere.

The technique has a friendly name: optimistic UI. It means the interface acts on what you asked for straight away, as if the server had already said yes. The request goes off in the background, and in the rare case the server says no, the interface quietly undoes the change and tells you why.

Same slow kitchen. You just didn't have to watch it. (Out of salmon? He comes back and says sorry. That's the rollback.)

Most frameworks make it look like a one-liner. In case of Inertia (Laravel + Vue) it really is:

router.post(`/mailbox/${account}/actions`, { uids, action: 'star' }, {
    optimistic: (props) => ({
        messages: starred(props.messages, uids),
    }),
})

So it looks like a UI tweak. It isn't. It's the moment your app stops doing one thing at a time.

1. Clicks start overlapping

Before, every click waited its turn. Now you can star three messages in a second. By default, a new visit cancels the one in flight, and the screen briefly "un-stars" the first message.

The fix is to let requests run side by side:

router.post(url, data, {
    async: true,          // don't cancel the other clicks
    preserveState: true,  // keep selection, scroll, open panes
    optimistic: () => changes,
})

2. Feedback lags behind the change

The star was instant, but the little "Starred · Undo" toast still waited for the server. The screen said done while the confirmation said wait.

The fix flips who's in charge. The page shows the toast itself, with an id, and sends that id along. The server answers with the same id, so its toast updates the one on screen instead of adding a second one.

const toastId = uuid()
toasts.show({ id: toastId, message: 'Starred 1 message.', undo: pending })
router.post(url, { ...data, toast_id: toastId }, options)

// The server's toast replaces the page's, or turns it into an error.
return back()->with('toast', Toast::success($message)->toArray($request->toastId()));

3. Users act before the server has

With an instant Undo, people click it before the original change has even reached the server. There's nothing to undo yet.

So the page puts things back immediately, remembers the request, and sends the real undo the moment the server's answer arrives:

if (toast.undo.token === null) {
    waitingForToken.set(toast.id, restore)  // send it when the answer comes
    router.replace({ props: (current) => ({ ...current, ...restore(current) }) })
}

4. Shared state starts racing

Two requests in flight at once meant a message the server had stored in the session "for the next page load" got picked up by the wrong request and vanished. Anything that quietly assumed one request at a time broke. The cure is the same as above: the page keeps what it needs instead of relying on server leftovers.

"For whoever asks next" only works when one person is asking. (The fix: write the table number on the plate. That's why every toast now has an id.)

5. The database notices

Even the local database complained. SQLite allows one writer at a time, and our parallel requests collided until database is locked showed up in the logs.

You might say: who cares about SQLite, that's just local development. Well, I do. It's a red flag anyway: if two requests can collide on my laptop, they can collide in production too, just less often and much harder to reproduce. Local is where that kind of bug is cheapest to catch. A few settings fixed it: wait for the lock instead of failing, let reads and writes happen side by side, and take the write lock up front.

// config/database.php
'sqlite' => [
    // …
    'busy_timeout' => 5000,            // wait for the lock, don't fail
    'journal_mode' => 'wal',           // readers and the writer don't block each other
    'synchronous' => 'normal',
    'transaction_mode' => 'IMMEDIATE', // a read that becomes a write can't wait
],

6. The last details: the illusion is fragile

A loading bar for a change that's already on screen tells users you don't believe your own UI:

router.post(url, data, { showProgress: false, optimistic: () => changes })

And a browser API that only exists on HTTPS (crypto.randomUUID()) silently broke every action on a plain-HTTP dev domain, while the tests, running on 127.0.0.1 (which counts as secure), stayed green:

export function uuid() {
    const bytes = crypto.getRandomValues(new Uint8Array(16)) // works on plain HTTP too
    bytes[6] = (bytes[6] & 0x0f) | 0x40
    bytes[8] = (bytes[8] & 0x3f) | 0x80
    const hex = [...bytes].map((b) => b.toString(16).padStart(2, '0')).join('')
    return `${hex.slice(0, 8)}-${hex.slice(8, 12)}-${hex.slice(12, 16)}-${hex.slice(16, 20)}-${hex.slice(20)}`
}

The lesson

Optimistic UI isn't a coat of paint. The moment the screen stops waiting for the server, you've built a system where:

requests overlap,
the screen and the server briefly disagree,
users act on things that don't exist yet,
and every layer, from the browser to the database, has to cope.

Plan it like an architecture change, not a feature. Decide early who owns the truth at each moment, how you roll back, and what happens when two things happen at once.

Done well, nobody notices any of this. The star just lights up. That's the point.

A fully local Mailtrap style inbox for Laravel

Raffi Hovhannesian — Mon, 05 Jan 2026 15:15:00 +0000

I just released Mailpot, a local, dev-only mail inbox for Laravel. And now its installed on all my Laravel projects.

It intercepts and stores sent emails so you can inspect them inside your app, with:

no Docker
no SMTP setup
no external services
unlimited emails for free

Think Mailtrap / Mailhog, but fully embedded in Laravel.

GitHub: https://github.com/rulr-dev/laravel-mailpot

I’d really appreciate feedback, issues, or feature ideas from other Laravel devs