Why technical taste and skills still matter

AI vs experience

These days, it is easy to create a working app with a few prompts and AI. At least, something that works well enough to show someone.

But I think the difference between an experienced developer and someone who is just quickly prompting an app into existence becomes more visible after that first version is finished.

What happens when people start using it? When their data has been there for a year? When you need to change something that the original implementation never considered?

This is what I mean by technical taste. Being able to look at a solution and notice what will be difficult to maintain, what is unnecessarily complicated, and which decisions will be expensive to change later.

In my previous post about software development in the AI era, I wrote about product understanding and responsibility. Maintenance is where that responsibility becomes very concrete.

A product is more than a list of features

AI can help with quite sophisticated work: prepare an implementation plan, write the code, and put together large parts of an app. But a plan can look complete while still missing important questions:

• How will we know that a feature is failing on a user's device?
• What happens to existing data when we introduce a breaking change?
• How do we get a fix to the affected users, and what can they do while waiting for it?

Of course, AI can help answer all of these. It may even bring them up itself. But I would not assume that a prompt asking for a feature will also produce a sensible plan for operating and maintaining it.

You still need to ask the right questions, make decisions, and keep those decisions in the project context. Otherwise, the next feature may be implemented in a way that ignores them.

And you need enough technical understanding to judge the answers. A migration plan that sounds reasonable is not much use if it quietly assumes that every user is online.

Offline-first also means planning for old data

A good example is Proof Pocket. It is an offline-first application, with a local database and encrypted files stored alongside it.

The database is the obvious part. Change its structure, and you may need a migration. But what if you change the format of the encrypted files, or the metadata needed to read them?

Updating the database does not automatically make those files compatible. You need to know which format you are reading, how to handle older versions, and what happens if the conversion is interrupted.

Imagine a user with hundreds of documents whose phone runs out of storage halfway through a migration. Can the app recover without losing the original files? Can the user safely try again?

These are questions I would want answered before shipping the change. For an app that people trust with their documents, getting the new version to work on a clean installation is only part of the job.

Backups bring the past back

There are also user-managed backups. Someone may update the app regularly but restore a backup created a year ago. Suddenly, the latest version needs to understand files and metadata from a much older version.

So the question is bigger than "can we migrate the data currently on the device?" It is also "what can users still restore?"

Maybe we keep support for the old format. Maybe we provide a conversion path. If support has to end, users need a clear explanation and a way to act before their backup becomes unusable.

I would also want to test restoring an older backup, rather than only creating and restoring one with the latest app. The second case can work perfectly while the first one is broken.

How will you know something is wrong?

Another easy thing to postpone is logging and diagnostics. Everything works on your device, so it is tempting to move on to the next feature.

But a user may have a different operating system version, limited storage, or a problem you cannot reproduce. "It failed" does not give you much to work with.

Useful diagnostics should help identify which operation failed and under what conditions. In an app handling sensitive documents, that also means being careful about what gets logged. Document contents and passwords should never become debugging material.

For an offline app, I would also think about how users can share diagnostics when they need help. You cannot assume that every failure will arrive in a central dashboard.

A fix is not finished when the code is merged

Finding the bug and fixing it is one thing. Getting that fix onto the affected device is another.

For a mobile app, there is a release process, distribution, and the question of when the user actually installs the update. Meanwhile, they may still be using the version with the problem.

Can they continue safely? Should one operation be temporarily blocked? How will they find out that an update is needed?

Even "just force an update" needs some thought in an offline-first app. How would it learn that an update is required while offline? Would blocking access leave someone unable to open their own documents?

I do not think there is one answer for every product. But these decisions belong in the plan, especially when a change affects access to existing data.

Ask what happens after it works

I am not suggesting that every small app needs a huge operational plan. The amount of planning should match the risk. A disposable prototype and an app storing someone's important documents have different needs.

But before adding a feature, I would spend a little time thinking beyond the implementation: how it can fail, how we will investigate it, what existing users need to migrate, and how we will communicate changes they need to act on.

AI is very useful here. Give it those constraints, ask it to challenge the plan, and use it to explore failure cases you may have missed. Then check whether the proposed solution actually fits your product.

For me, this is why technical taste and skills still matter. Experience helps you notice the missing questions. Technical skills help you decide whether the answers are any good.

That's it!

Thanks for reading, and see you in the next post :)

Photos: Daniil Komov (cover) and Arina Krasnikova (external drive), via Pexels.