I’m Not a Programmer. Here’s What AI-Assisted Development Looks Like for Me.

I didn’t start using AI because I wanted to build software.

At first, it was simply a faster way to research things, compare products, translate awkward text, or deal with support in a language that wasn’t my own.

Then I tried something much more ambitious.

I had to migrate a long-running media and community platform from an old DLE installation to WordPress.

The project meant preserving more than 17,000 users, comments, favourites and viewing states, moving hundreds of content records and thousands of actor/director records, redesigning the site into one responsive interface, adding a dark theme, cleaning legacy data, and substantially improving performance.

The main migration took roughly a month and around 200 hours of real work. More polishing and optimization followed afterwards.

One unexpectedly large part had almost nothing to do with software.

The database contained nearly 4,000 Korean and Japanese names, including duplicates, garbage records and inconsistent transcription. I ended up learning to read Hangul, studying Korean phonetic rules and academic transcription conventions, and manually checking names against their original spelling and external sources.

AI helped enormously.

It automated cleanup, transformed data, wrote scripts, proposed solutions and turned repetitive work into something manageable.

It also made mistakes constantly.

Even after I explained the rules and gave it examples, I still had to check the results myself.

That became the recurring pattern of nearly every technical project I worked on afterwards.

The biggest misconception I had about AI-assisted development was that once the model could write the code, the difficult part would disappear.

It didn’t.

AI is extremely good at solving the problem it thinks you asked.

It is also extremely good at spending a long time solving the wrong problem.

My favourite mental image is a model repeatedly trying different angles to squeeze through a hole in a fence. It changes variables, adds workarounds and keeps improving the attempt.

Meanwhile, five metres to the left, there is a gate.

Someone still has to notice the gate.

After the website, projects started coming one after another: a real-time tournament timing and control system, an Android app for tutors that reached Google Play, game mods, and eventually reverse engineering of proprietary game resources.

I still don’t consider myself a programmer.

I know basic HTML and CSS, but I can’t sit down with a blank editor and write thousands of lines of C++, Lua or Kotlin from memory. In many of my projects, AI handles much of the implementation layer.

But that doesn’t mean I press “Generate” and wait for a product.

My part is defining what the system should actually do, keeping the larger logic consistent, testing real behaviour, bringing back logs and evidence, noticing when a technically convincing hypothesis doesn’t match reality, deciding what is worth investigating next, and killing approaches that have stopped making sense.

That distinction becomes more important as projects get more complex.

A model can produce perfectly valid code that implements the wrong architecture.

It can fix a symptom instead of the cause.

It can add layers of complexity to compensate for an earlier bad assumption.

And because the output often looks plausible, the easiest mistake is simply to keep following it.

The useful skill isn’t writing the perfect prompt.

It is being able to look at a polished, confident answer and say:

No. That isn’t what is happening. We need to understand why.

For me, that is the real value of AI-assisted development.

It doesn’t magically remove the work. It changes which parts of technical work are accessible.

A few years ago, many of the projects I work on now would simply have been outside my reach because I lacked the implementation skills.

Today AI can provide much of that missing layer: write code, inspect structures, analyze logs, generate tools and test hypotheses quickly.

The human part is still the goal, the context, the judgement, the testing and the responsibility for the result.

AI didn’t turn me into a programmer.

It gave me a way to build technical products without pretending that I am one.