DEV Community: PLC Creates

We Have Database Rollbacks. Why Don't We Have State Rollbacks?

PLC Creates — Tue, 17 Feb 2026 14:19:00 +0000

We Have Database Rollbacks. Why Don't We Have State Rollbacks?

Backend systems treat data as sacred. Frontend systems treat state as
disposable.

That distinction no longer holds.

The Backend Discipline

On the backend, rollback is normal.

Transactions
ACID guarantees
Migrations
Backups
Rollbacks

We assume failure and design for recovery. We would never ship a
database without a way back.

Rollback is not an advanced feature. It is table stakes.

The Frontend Reality

On the frontend, the culture is different.

Autosave
Rehydration
Optimistic UI
Validation on submit

If the latest snapshot restores successfully, we tend to consider the
problem solved.

But restore does not mean recover.

SPAs Changed the Game

Modern SPAs are no longer thin clients.

They contain business logic, multi-step flows, derived state,
client-side validation, schema evolution, partial persistence, and
optimistic mutations.

In many applications, frontend state is not a temporary UI concern. It
is production data.

A multi-step form in a SaaS product.\
An admin dashboard with derived metrics.\
A rich editor with optimistic updates.

The client state holds business-critical transitions.

Yet it has no rollback discipline.

The Missing Primitive

Consider the difference.

Backend data lifecycle

Write → Validate → Commit → Rollback (if needed)

Frontend state lifecycle

Mutate → Autosave → Rehydrate → Validate on submit → ?

If a restored snapshot turns out to be invalid:

There is no last known good state
There is no deterministic recovery
There is no versioned state discipline
There is no safe fallback

We retry.\
We clear the state.\
Or we hope validation catches the issue early enough.

Validation Is Not Recovery

Validation answers:

Is this state valid right now?

Rollback answers:

Can we return to a known good state after corruption?

Detection and recovery are different responsibilities.

The Structural Question

If we would not ship a database without rollback, should we be
comfortable shipping complex client state without it?

As frontend systems absorb more responsibility, perhaps our recovery
discipline should evolve with them.

Closing Thought

Client-side state now carries real business weight. As that
responsibility grows, so should the reliability expectations around it.

I have been exploring recovery patterns for client-side state and
refining a model around deterministic restoration. Curious how others
approach this problem.

Autosave Works. Until the Restored State Is Invalid.

PLC Creates — Thu, 12 Feb 2026 19:23:04 +0000

Autosave feels like a solved problem.

You serialize the state.

You store it.

You restore it.

Users don’t lose their input. Everyone’s happy.

That’s what I believed too.

Until I realized something uncomfortable:

The last saved state is not always a safe state.

Saving Is Easy. Restoring Is Not.

Autosave is straightforward:

serialize state
store it in localStorage (or IndexedDB)
reload it on startup

In most cases, that’s good enough.

But here’s the nuance that changed how I think about client-side persistence:

There’s a big difference between:

“This is the latest snapshot.”
“This is a valid state for the application.”

They are not the same thing.

And most implementations quietly assume they are.

A Concrete Example: Multi-Step Onboarding

Imagine a multi-step onboarding flow:

Account information
Preferences
Payment details
Success → profile created

Behind the scenes, the state evolves at every step.

Now imagine this:

The user completes payment details.
A derived field recalculates something.
The app crashes.
Autosave restores the last snapshot.
The UI looks correct.
The user clicks submit.

But what if:

A derived value was computed from stale data?
A field was partially updated?
A migration changed the schema between deploys?
A validation rule evolved?

The UI looks fine.

The state is not.

And now you’re submitting a transactional form based on a logically inconsistent state.

No error.

No visible corruption.

Just subtle inconsistency.

“But Isn’t That Obvious?”

To engineers who work on complex systems: yes.

To many frontend implementations? Not always.

Most libraries focus on:

validation while the form is active
saving frequently
restoring automatically

Very few ask:

Was this state actually valid when it was saved?

And even fewer provide:

rollback to last known valid state
deterministic recovery rules
versioned schema validation on restore

When It Actually Matters

In many apps, restoring slightly inconsistent state is harmless.

But consider:

insurance quote forms
loan applications
subscription onboarding with payment
enterprise admin panels

In these flows, silent inconsistency can create:

subtle validation failures
mismatched derived values
incorrect submissions
hard-to-debug support issues

And the user believes everything was fine.

Because the UI said it was.

What Changed My Thinking

Autosave is necessary.

But it’s not sufficient.

There are two separate concerns:

Persistence — keeping user input safe.
Validity — guaranteeing the restored state respects invariants.

SafeState Recovery emerged from that distinction.

Instead of assuming the latest snapshot is safe, it asks:

Does this state pass validation?
If not, can it be deterministically repaired?
If not, what is the last known valid state?

That’s a different layer of thinking.

Not about saving more often.

But about restoring responsibly.

If you’ve worked on transactional or multi-step client-side flows:

Do you explicitly validate restored state?

Or do you assume the latest snapshot is safe?

I Lost 25% of a Form by Scrolling Up. Nobody Noticed.

PLC Creates — Sat, 24 Jan 2026 21:07:20 +0000

This is a short essay about a quiet problem in modern web applications.

Not crashes, not server errors, and not bugs that light up dashboards. It’s about data loss that leaves no error, no alert, and no feedback.

Absence of evidence is not evidence of absence.

— Carl Sagan

A very ordinary moment

A few weeks ago, I was filling out a survey for a major Canadian airline on my phone.

It wasn’t a short form. It had multiple sections, a visible progress indicator, and I was about a quarter of the way through when I made a small upward scroll. The page refreshed, and everything was gone.

There was no warning, no recovery, just an empty form.

I didn’t complain, I didn’t report a bug, and I didn’t try again. I simply closed the page and moved on.

Nothing broke, but the user left. Nobody noticed.

A quiet problem in modern web apps

Data loss in web forms isn’t new. What has changed is how invisible it has become.

Modern web apps are used more on mobile devices, across unstable networks, with aggressive browser lifecycle management. Forms are longer, more complex, often multi-step, and users are interrupted constantly. The result isn’t necessarily more bugs, but more opportunities for normal human behavior to cause data loss.

What we measure — and what we don’t

Most teams are very good at measuring what breaks loudly.

We track server errors, crashes, failed payments, validation issues, and performance regressions. When something goes wrong at scale, it usually leaves a trace somewhere.

What we almost never measure is what disappears quietly.

When a user refreshes a page, closes a tab, or loses a form because a browser crashed, nothing necessarily looks wrong from the system’s point of view. No error is thrown, no alert fires, and no red line appears on a dashboard.

From the product’s perspective, nothing failed. From the user’s perspective, everything did.

Silence is not satisfaction

When users lose data, they rarely complain. They often assume they made a mistake, shrug it off, and move on.

This behavior isn’t exceptional. It’s normal.

Customer experience research consistently shows that only a small minority of dissatisfied users ever provide feedback. The vast majority don’t escalate the issue or explain what went wrong. They simply leave.

Visible complaints are just the surface. Under each one sits a much larger volume of silent abandonments that never appear in metrics or reports.

Why this keeps happening

There are solutions for form persistence, but many fall into familiar categories: legacy libraries that are no longer maintained, heavy integrations that require deep framework coupling, or partial fixes that don’t reflect real usage patterns, especially on mobile.

Meanwhile, form data loss keeps happening quietly and repeatedly.

Why Savior exists

I didn’t build Savior to polish UX details or optimize charts. I built it because people are human.

They get interrupted, they reload without thinking, browsers crash, and phones do what phones do.

Savior exists as a local safety net for those moments. It quietly keeps form data around so that a brief interruption doesn’t erase several minutes of effort.

Savior Core is an open-source library for basic form persistence. Savior SafeState Recovery adds deterministic recovery for crashes and edge cases.

More at Zippers.dev.

One last question

What’s the most expensive failure you’ve ever shipped that left no error trace?

Programming was the right vehicle

PLC Creates — Sun, 18 Jan 2026 16:55:45 +0000

Some will argue it shouldn’t even be peanut butter.

Programming was the right vehicle

I realized something fairly late.

Creativity isn’t a talent for me. It’s not a preference either. It’s a need.

I didn’t always have the words for it. But looking back, it explains a lot.

Before I knew what I was looking for

I changed paths more than once.

Different fields, different interests, different attempts at finding something that would stick. At the time, I didn’t call it creativity. I just knew I needed to make things.

Not necessarily useful things. Not impressive ones. Just something that came from me and existed afterward.

There was always this low-level discomfort when I wasn’t creating anything. And a quiet relief when I was.

The map in the passenger seat

When I was a kid, sitting in the car, my mother taught me how to use a road map.

The real skill wasn’t reading it. It was folding it back properly on the first try so it would fit in the glove compartment again. If you know, you know.

Once I understood how the map worked, I said something very casually:

“There should be a map where you can see the car. Where we are.”

This was the late 80s. It made my mother laugh.

In my head, it made sense. I could actually see it. The map, the car, the position updating as you moved.

I remember telling her I wanted to become an inventor. Even now, just writing this, I feel that light tension in my stomach.

She told me it wasn’t really a job. Not in the academic sense. There was no degree for becoming an inventor, no clear path, no box to put it in.

She wasn’t dismissive. She was practical.

But something closed there. Not dramatically, not violently. Just enough to be felt, and then quietly carried forward.

Experimenting before knowing how

When I got my first electric guitar, I didn’t know how to play it, but I played it anyway. I composed, and the next day, I played the same piece again.

I didn’t know how to cook either, but I cooked anyway. When I was a kid, what came out of it, my mother used to call it “experiments”.

And she wasn’t wrong. I would add something just to see what would happen. To see what it would do. Sometimes it worked, sometimes it didn’t.

All my life, I’ve been experimenting, trying things simply to see what happens, to see what they do.

When creating disappears

When I don’t create, or when I spend too long doing work that doesn’t stimulate me intellectually, something shifts. I don’t just get bored. I slowly get heavier. Quieter. Less present. Over time, it turns into something that looks a lot like depression.

I didn’t understand that at first. I tried to push through it, to be responsible, to fit into roles that looked fine from the outside.

At one point, I was working as a middle manager in aviation security. On paper, it was a serious job. Stable. Structured. Important. In reality, it asked almost nothing of the part of me that needs to build, explore, and figure things out.

I burned out.

That burnout forced a pause I hadn’t allowed myself before. And in that pause, something became obvious: if I kept choosing paths where creation had no place, I was going to keep breaking in the same way.

So I made a turn. Out of all the disciplines, jobs, and careers I could have chosen, I enrolled in a programming program at CEGEP.

It wasn’t an ambitious choice. It was a necessary one.

When programming entered the picture

Programming didn’t arrive as a revelation. It arrived as something that fit.

Creating something that didn’t exist and seeing it take shape. Before, there was nothing. After, there was something.

No spectacle. No fireworks.

Just the satisfaction of having brought something into the world. Even if it was small. Even if it was imperfect. Even if no one else ever saw it.

That was enough.

Creating is not about being special

We tend to put creativity on a pedestal. We imagine geniuses, outliers, people who pull ideas out of thin air. But no one creates from nothing.

Creating is a series of deductions based on what we already know, what we’ve seen, and the mental paths we take when faced with the same stimulus.

When someone says:

“I don’t know how they even thought of that.”

What they usually mean is that they didn’t take the same route.

Different inputs. Different paths. Different results.

That’s it.

Ideas don’t matter without action

I’ve heard this sentence countless times:

“If I had a good idea, I’d build something.”

But the hard part isn’t the idea. It’s doing the work.

You can have great project ideas. If nothing leaves your head, nothing exists. A good idea with no action is effectively the same as no idea at all.

Creativity only becomes real once something crosses the line between thought and reality.

You think you’re not creative? Here’s a thought.

Take 50 people and ask them to make their own version of a peanut butter and jelly sandwich.

No one will make the same one.

What kind of bread? White, whole grain, rye, baguette, brioche.

Toasted or not? Lightly toasted? Dark? Almost burned?

What kind of peanut butter? Creamy, crunchy, natural, dark roast, with salt, without.

Some will argue it shouldn’t even be peanut butter. Almond, cashew, sunflower seed.

How much do you put on the bread? Room temperature or straight from the fridge? Do you let the toast cool, or do you like it when everything melts together?

Peanut butter first or jelly first?

And the jelly. What kind? How much? One flavor or two? Spread to the edges or kept neatly in the center?

Crust on or off? Sandwich closed or open-faced?

Cut or not? Triangle, square, rectangle?

Add a banana? A drizzle of honey? Is it still a PB&J then?

Do you toast the bread in a toaster, a pan, an oven, over a campfire?

Do you eat it with your hands, or do you dip it in your latte?

Same goal. Same ingredients. A thousand tiny decisions.

You are creative.

Leaving a trace

It doesn’t have to be perfect.

Waiting for perfection is often just a way to delay doing anything at all.

Creating is leaving a trace of our passage. A small mark. A commit. A project. Something that exists now, even if it’s flawed, because of you.

That’s what matters.

Everything else can be improved later.

The line between developer and architect is getting thinner

PLC Creates — Sat, 03 Jan 2026 14:19:00 +0000

The line between developer and architect is getting thinner

I didn’t plan to become an architect.

Like many developers, I started by writing code.

Solving concrete problems. Making things work. Improving them one commit at a time.

But lately, something has shifted.

With AI doing more of the implementation work, I find myself spending less time writing code and more time deciding what should exist, how it should be structured, and why it should work that way.

And that’s where the line starts to blur.

Writing code versus designing systems

Traditionally, the roles felt distinct.

Developers implemented.

Architects designed.

One focused on execution, the other on structure and long-term decisions.

But when AI can generate implementations in seconds, the bottleneck moves.

The hard part is no longer typing code.

It’s making the right decisions before the code exists.

What should this component own?

Where does this responsibility belong?

What happens when this scales, changes, or breaks?

Those questions used to live “above” the code.

Now, they are part of everyday development.

I notice it in small moments.

I’ll ask an AI to implement a feature, then spend more time reshaping or discarding the result than I would have spent writing it myself.

Not because the code is bad, but because the decisions behind it are wrong.

AI didn’t replace developers, it shifted the weight

I don’t feel replaced.

But I do feel repositioned.

The value I bring today is less about syntax and more about:

defining boundaries
choosing trade-offs
anticipating consequences
keeping coherence across a system

AI helps me move faster, but only if I already know where I’m going.

Without direction, speed just creates confusion.

If I’m honest, I think we are becoming more like architects, and less like pure producers.

And personally, I see that as a good thing.

Not because coding matters less, but because it becomes more accessible.

Lower barriers mean more people can build, experiment, and create.

The focus shifts from “can you write this?” to “does this make sense?”

Not everyone wants to be an architect

And that’s important to say.

Some developers genuinely enjoy deep implementation work.

Optimizing, refining, polishing details.

Living close to the code.

If AI pushes everyone upward, toward abstraction and decision-making, it raises a real question:
what happens to those who don’t want that role?

Are we all becoming accidental architects?

Or will the definition of “developer” simply expand?

I don’t have a definitive answer.

But avoiding decisions doesn’t preserve the old role.

It just means those decisions get made elsewhere.

A role in motion

What I do know is this:

the boundary between developer and architect feels thinner than ever.

Not because titles are changing, but because the daily work is.

I still write code.

But more and more, my main responsibility is making sure the code that exists makes sense as a whole.

An open question

So I’m curious how others experience this shift:

Do you feel your role changing with AI in the mix?

Are you spending more time on structure and decisions than implementation?

Is this a direction you welcome, or one you’re resisting?

I’d like to hear how you see it.

Autosave works. Until it doesn’t.

PLC Creates — Sat, 27 Dec 2025 16:19:29 +0000

The problem isn’t that autosave fails often. It’s that the consequences of failure are not negligible.

Most custom autosave systems work.

They save drafts, restore content after a refresh, and give both developers and users a reassuring sense of safety. For weeks or months, everything behaves exactly as expected. Nothing breaks. Nothing complains.

And then one day, a user loses everything.

Not because the developer was careless. Not because the code was rushed or poorly thought out. But because the web is a hostile environment in ways that don’t show up in local testing, staging, or happy-path demos.

This isn’t a story about bad code.

It’s a story about invisible complexity.

The browser doesn’t owe you a last save

Many autosave implementations rely on a comforting assumption: when the page closes, there will be one last chance to save.

In practice, that assumption is fragile. Browsers make no guarantees here. beforeunload is not reliable, tabs can be killed without warning, and on mobile devices pages are routinely backgrounded or terminated without giving JavaScript a chance to clean up. The operating system decides when your code is done running, not you.

If the browser needs to reclaim memory or enforce a policy, your autosave logic is not consulted. There is no final callback you can depend on. There never was.

Safari iOS can silently delete your data

This one catches even experienced teams off guard.

On iOS Safari, localStorage can be purged after periods of inactivity or after a device restart. When it happens, there is no event, no warning, no error message, and no obvious signal that anything went wrong.

Yesterday, the autosave worked.

Today, the data is gone.

Nothing crashed. Nothing failed loudly. The browser simply reclaimed the storage and moved on. If you haven’t been burned by this yet, it’s usually just a matter of time.

The last keystroke is the one that gets lost

Autosave timing looks simple on paper, but in practice it’s full of trade-offs.

Debounce delays, throttle windows, performance concerns, battery constraints on mobile devices — all of these influence when data is actually written. Users don’t type in neat, predictable intervals. They paste text, undo changes, and close tabs immediately after finishing a sentence.

More often than anyone likes to admit, the most important sentence is the one that never makes it to storage. Autosave doesn’t fail randomly. It fails at the worst possible moment.

Dynamic forms break restoration assumptions

Saving form state is relatively easy. Restoring meaning is not.

Modern forms are dynamic. Fields appear conditionally, schemas evolve, sections are reordered, and inputs are removed or renamed over time. Restoring raw values into a structure that no longer matches what was saved leads to partial restores, misplaced data, and subtle corruption.

From the user’s perspective, the form loads and some fields look right. Others don’t. The system “kind of worked”, which is often worse than failing outright. Restoring state is not the same thing as restoring intent.

Multiple tabs quietly overwrite each other

localStorage is shared across tabs. That means there is no built-in locking, no isolation, and no warning when one tab overwrites another.

Two tabs. The same form. The same storage key.

Whichever tab writes last wins, and the other loses silently.

Most developers don’t test this scenario. Most users don’t even realize it happened. They just know something disappeared.

Storage limits are real, and failures are often silent

Storage quotas exist, they are smaller than most people think, and they behave differently across browsers.

When those limits are reached, writes may fail or be ignored. Errors may not surface clearly, and autosave logic can stop persisting data without crashing or throwing exceptions. From the UI, everything still looks normal. From the user’s perspective, the safety net is still there.

It isn’t.

The autosave didn’t crash. It just stopped existing.

The most dangerous part is the false sense of safety

Across post-mortems and developer accounts, one sentence comes up again and again: “We thought it was solid enough.”

The autosave worked in testing. It worked in staging. It worked for most users, most of the time. Until one edge case erased real work.

That’s the real danger. Not failure itself, but confidence built on an incomplete understanding of the surface area.

This isn’t about incompetence

Reimplementing autosave is a rite of passage. Many teams do it carefully. Some do it exceptionally well. And they still miss cases.

Not because they are bad developers, but because the web has more failure modes than intuition suggests. The problem isn’t that autosave is impossible. It’s that it’s much harder than it looks, and rarely treated as such.

Why this matters

Autosave is a trust feature.

When it fails, users don’t blame the browser. They don’t blame Safari or storage quotas. They blame the product, and they stop trusting it.

If this article resonates, it’s probably because you’ve seen one of these failures yourself. Or because you haven’t yet, and now understand why people do.

After re-implementing autosave too many times and still missing edge cases, I realized the problem wasn’t effort. It was surface area.

At least that’s where I am today.

This may change.

Why this piece lives on Medium

PLC Creates — Sat, 27 Dec 2025 14:14:00 +0000

Context

I don’t usually decide where something will be published before I write it.

I write first. When a subject sticks around long enough. When it starts to take space in my head. Only after that do I ask myself where it belongs.

This one ended up on Medium. Not because it’s better. Just because it felt like the right place for it to exist quietly.

The piece is about projects. Not the exciting parts. Not shipping, not momentum, not wins. More about what a project asks from you over time. And how that cost slowly changes shape.

I didn’t want to rewrite it to fit somewhere else. I’ve done that before. It always costs more than it gives back.

So I’m trying something simpler now:

I write once.

Then I choose the place that fits the text.

Elsewhere, I just point to it. That’s what this post is.

If you’re working on something on the side,

you probably recognize that moment where progress is real,

but so is the weight of continuing.

That’s what I tried to write about.

The full piece is here, on Medium:

👉 What a Serious Project Eventually Asks of You

https://medium.com/@plc.creates/what-a-serious-project-eventually-asks-of-you-03d6f08e1bf7

I’m not trying to be everywhere. I’m trying to stay coherent across platforms and stay true to myself when I write a piece.

That’s where I am right now.

This may change.

Why chasing a dream feels heavier than staying put

PLC Creates — Tue, 16 Dec 2025 23:15:59 +0000

When staying put feels safer than moving forward

This morning, on my way to my day job, something small shifted.

Nothing cinematic.

No revelation worthy of a before-and-after.

Just a thought that arrived quietly, carried by the road unspooling ahead of me, by a song I’ve heard too many times without really listening to it, by the rare luxury of not being in a hurry.

The thought was this:

Staying put feels safer to me than chasing a dream.

I don’t fully trust that thought yet.

But it stayed with me.

Why staying put can be comforting

Staying put is a known landscape.

If a project stalls, if momentum fades, if something I hoped for refuses to take shape, I already know the shape of the days that follow.

I return to routine.

To the scaffolding of days I have practiced for years.

To familiar obligations, familiar limits, familiar ground.

There are no sudden decisions waiting there.

No new version of myself demanding to be inhabited.

No unfamiliar altitude where the air might feel thinner.

Staying put does not ask me to change.

It asks only that I continue.

Why chasing a dream can feel heavier

Chasing a dream behaves differently.

It rearranges things.

It opens doors that do not close behind you.

It brings questions that refuse to stay theoretical:

What now?
What do I commit to?
What do I risk losing if I keep going?
Who am I required to become if this actually works?

A dream shifts the ground while you are standing on it.

Even when it is something you asked for.

And that instability, however hopeful, can feel like weight.

The quiet relief of “I can always come back”

What eased the tension this morning was a simple realization.

The worst realistic outcome is not collapse.

It is return.

Returning to a life I already know how to live.

Returning to a version of myself that has proven survivable.

That thought loosened something.

It didn’t shrink the dream.

It redistributed the weight.

Made it lighter.

Made it portable.

Trying stopped feeling reckless.

It began to feel reversible.

And yet, I’m not sure that safety actually helps me move faster.

It might just help me move at all.

Giving yourself permission to move

We often speak of failure as the thing to avoid.

As the cliff edge that must not be approached.

But sometimes, it is the acceptance of return that makes movement possible.

Not because we aim to go back.

But because knowing we can endure it creates room to step forward.

Risk becomes tolerable when retreat remains allowed.

At least, that’s where I am today.

This may change.

I’m coding with AI, and sometimes I have to reverse-engineer my own code

PLC Creates — Sat, 13 Dec 2025 14:33:00 +0000

I’m coding with AI, and sometimes I have to reverse-engineer my own code

Let’s be honest for a moment.

Today, AI is already part of many developers’ daily workflow. Not in some hypothetical future. Right now.

I use it too.

I describe an intention, a structure, a problem to solve. In return, it generates blocks of code that are clear, functional, sometimes even elegant.

It’s impressive. And above all, it’s fast.

Sometimes too fast.

So fast that I find myself doing something I never imagined a few years ago:

reverse-engineering my own code.

Moving fast, understanding more slowly

The generated code is not bad. Quite the opposite.

But it arrives fully formed, all at once, without the hesitation, the trials, the detours that used to build my understanding along the way.

Before, understanding was part of the journey.

Now, understanding sometimes becomes a step that comes after.

I have to slow myself down on purpose.

Read. Break things apart. Verify.

Regain control over something I explicitly asked for.

I often picture it like this:

I’m moving forward on a sled pulled by AI. The speed is exhilarating, but if I let go of the reins for too long, I lose track of what’s actually happening beneath my feet.

Are there still purists?

I sometimes wonder about that.

Are there still developers who write everything by hand, without ever relying on AI?

Maybe.

But is that still the norm, or has it become more of a posture?

Because we can debate endlessly, but the reality is simple:

AI is here to stay.

And it is an incredibly powerful tool for writing code.

The real question is probably not whether we should use it, but how we use it without losing our understanding, our judgment, our responsibility.

I write less code. I still love it just as much.

This is what surprised me the most.

I write less code than I used to. Yet I haven’t lost the passion.

It forced me to rethink what I actually enjoy about this craft.

Maybe it was never about typing every line, but about understanding a system, shaping an idea, turning something fuzzy into something coherent.

And that, AI doesn’t do for me.

An open question

I thought I loved writing code.

But now that AI writes a large part of it for me, I realize I still love developing just as much.

So I’m asking myself, and I’m asking you:

What do you really enjoy about coding?

How do you use AI without losing control over what you build?

Do you recognize this need to reread, and sometimes dissect, your own generated code?

Curious to read your experiences.

I tried to break my autosave library in 25 different ways, and it survived

PLC Creates — Mon, 08 Dec 2025 14:17:00 +0000

I tried to break my autosave library in 25 different ways, and it survived

Over the last few weeks, I’ve been building Savior, a tiny, dependency-free autosave engine for HTML forms.

The goal is simple: users should never lose what they write.

It sounds easy, but guaranteeing that in every situation is another story. Before releasing v0.3.0, I set up a crash-test suite with 25 manual scenarios. No automation yet. Just real testing of the real library in real conditions.

Here are a few of the situations I used to try and break it:

Flaky storage drivers

Random failures in save, load, or clear.

Corrupted or invalid JSON

Broken JSON placed directly in LocalStorage before initialization.

Dynamic DOM changes

Inputs added or removed after Savior.init.

Cloned forms

Identical nodes with different identifiers.

Stress input

Hundreds of rapid input events fired in a row.

External tampering

Storage keys deleted or altered while typing.

Restricted environments

Private mode, quota issues, partial storage support.

The result

Across all 25 tests, Savior showed the same behavior:

zero unhandled exceptions
stable and predictable restore
strict isolation between forms
identical behavior with LocalStorage and SessionStorage
effective debouncing under heavy input

These are small wins for a small library, but meaningful ones. The process turned a simple autosave script into something more reliable than I first expected.

The project also received its first stars today. A small detail, but enough to make the work feel real.

If you want to take a look:

https://github.com/Pepp38/Savior

What’s next

Probably automated tests.

Maybe more drivers.

Maybe a deeper look at the internal workflow.

For now, v0.3.0 is out, stable, and I’m satisfied with where it landed.

I Fell in Love With Programming Long Before I Learned It

PLC Creates — Sat, 06 Dec 2025 14:24:00 +0000

I Fell in Love With Programming Long Before I Learned It

"A robot?" — Jesse Pinkman

(That line stayed with me. A mix of surprise, naïveté, and wonder. Exactly the feeling I had as a kid seeing my first robot, and years later, my first real piece of code.)

Before diving in, a quick note.

This is not a tutorial. It is a story about where programming begins, not in code but in curiosity and small sparks that follow us across the years.

When Programming Looked Impossible (To a Kid From the 80s)

When I enrolled in computer science, I did not really know what it was. Not precisely.

I thought I would become the guy who tells people: “Have you tried restarting your computer?”

For someone born in the 80s, programming looked like a closed world: nerds in a windowless room, speaking an incomprehensible language. Almost unreachable.

During the first weeks of the program, they gave us a choice between development and infrastructure. One day, they had us try low-code with simple drag and drop logic. The moment I touched it, a childhood memory resurfaced.

The Childhood Toy That Changed Everything

I must have been around eight when I bought my first Capsela toy. Those little capsules snapped together to build cars, boats, anything my imagination suggested. Each module had a role: motor, gear, wheels, floats. I saved every dollar to buy a new one.

Then one day, I got the ultimate set: the Capsela 2000. A robot you assembled yourself with lights, sounds, and simple movements. Unlike the others, it came with a small controller that let you program its actions. I programmed it, pressed “Play,” and watched it go.

It was the first time I touched something that reacted to my instructions.

A thing that did exactly what I imagined.

I think that is when something imprinted itself in me. The idea that you can make the world move by giving it sequences, logic, and a plan.

I found that same feeling years later in programming. Telling a computer what to do. Creating anything I wanted, without buying parts or building anything physically.

In that moment, something simply aligned. Not a revelation, but a quiet recognition. As if that robot had been an early initiation to logic and creation. A simple way of telling the world “do this,” and the world obeyed.

When My First Line of Code Felt Familiar

Years later, looking at my first real line of code, I felt the same sensation.

The same inner mechanism.

The same quiet joy whispering: “I know this.”

As if the kid I used to be was giving me a nod from across the years.

It stayed. My way of approaching programming never changed. Idea first, tools second. Always. Start with the result, then figure out how to reach it.

Why I Still Love Programming Today

Despite the years, despite the technologies that come and go, the same thing still moves me. Seeing an idea take shape, leave my head, and exist for real.

Something shifts in the world simply because I imagined it.

That is what made me fall in love with programming long before I learned it.

First in front of a plastic robot.

Then in front of a line of code that did exactly what I asked for.

Yes, science.

If This Resonates With You

If you have a moment where programming “clicked” for you, feel free to share it. I genuinely enjoy reading how others discovered this field.

You Can Build Ideas on a Phone, But You Can’t Build Software There

PLC Creates — Sat, 29 Nov 2025 14:00:00 +0000

Phones can generate code instantly with AI, but they still can’t act as real development environments. Here’s what they can do, where they break down, and why the gap still exists.

You Can Build Ideas on a Phone, But You Can’t Build Software There

I was on the bus when a small idea hit me.

Nothing huge. Just a tiny tool I wanted to write to help manage files.

I pulled out my phone, opened ChatGPT, described the idea, and within seconds it generated a working prototype. So far, so good.

I asked it to launch the canvas preview.

Not possible on iPhone.

Alright, fine. I’ll at least create a GitHub repo to save the idea before it slips away.

Also not possible from the mobile app.

And that’s when something clicked.

My phone is faster than the laptop I had ten years ago. It can generate code instantly with AI. It can record 4K video, run advanced apps, handle complex tasks. Yet the moment I try to actually build software with it, everything falls apart.

We’re in 2025. Why is coding from a phone still such a dead end?

What Mobile Is Actually Good For

To be fair, a phone isn’t useless for a developer. Far from it.

I can capture ideas the moment they appear.

I can write drafts for articles like this one.

I can plan features.

I can check GitHub issues or discussions.

I can keep my project visible on X or Reddit.

Phones are great for thinking.

But thinking is only half the job.

Where Everything Breaks Down

No local build

Nothing runs. Not even a tiny snippet.

Without a build, you can’t validate anything.

GitHub mobile is too limited

You can scroll and read but not much more.

Creating repos is impossible.

Diffs are cramped.

Branches feel hidden behind too many taps.

No real preview

I can generate 200 lines of code with AI in seconds.

But I can’t see it run.

It’s like having a full meal in front of you and being told you can’t use a fork.

No debugging tools

No console.

No inspector.

No environment.

Just the idea, floating alone.

No deep work

Mobile keeps you in short-task mode.

Architecture, design patterns, systems thinking… none of that sticks when you’re holding a phone in one hand and balancing yourself in a bus seat.

The code creation part is now effortless thanks to AI.

The rest of the workflow is still stuck in another era.

The Gap Between Potential and Reality

We can generate full components, utilities, even small apps on a phone.

But we can’t test them, preview them, or push them to a repo.

It creates this weird disconnect.

The device is capable. The software isn’t.

Sometimes I wonder if it’s just a matter of demand.

Maybe companies assume no one wants to code in a bus.

Maybe it’s still seen as unprofessional.

Maybe the idea feels too strange to build tools around it.

But as a solo dev, I’d love to test ideas right when they’re fresh.

Not later, when I’m home, when the spark has already cooled.

I’m Not Trying to Replace My Computer

I don’t want VS Code compressed into a six-inch screen.

I’m not dreaming of running Docker on my phone.

I just wish I could do the basics:

create a repo
push a file
preview a small UI
test a simple snippet
validate an idea quickly

That would be enough.

Not a full dev environment.

Just a minimal way to turn sparks into tiny proofs of concept.

Maybe the Solution Exists, Or Maybe No One Built It Yet

Maybe there’s an app I simply don’t know about.

Maybe someone already solved this.

Or maybe I’ll have to build something myself.

For now, my phone remains what it is.

A notebook with way too much processing power for what it’s allowed to do.

When I get home and finally sit down in front of my keyboard, that’s when ideas become real.

A phone can start the story, but it can’t write the full chapter.

At least not yet.