AI the way out of doubt

When it comes to AI, I believe to be a rational pessimist. I am using AI-powered tools here and there, but I don't see it as a second coming of Jesus that would take our dev jobs and replace us. It is a useful tool, but only a tool. This is probably why I am always a bit behind the newest features and trends that keep emerging every week.

On the other hand, I am not reluctant to AI either. I don't think it is crippling my mind not to write everything by hand and rather focus on the bigger picture than wiring all the boilerplate together. But finding the right tasks to be asked about or even delegated to AI-agent seems to be the biggest bottleneck in my workflows. I am being constrained by too much thinking.

While the other extreme - not thinking and all and just vibe code the entire app and let it to production without any sanity and security checks - might be even worse, not shipping anything, because you cannot decide how to put it together, is not the ideal outcome either. Whenever I manage to break from the circle, the positive results surprise me. I decided to write this article to share my latest small win achieved through AI. Maybe it inspires you too.

The scene

I have a custom page where I collect and keep all my running since 2013 - where I run, how many meters and what time. I am just a casual runner, but it's becoming decent set - nearly 2000 entries and closing to 12K kilometers. And it all can be tracked down to March 11th 2013, when I started with first 1825 meters in 9 minutes and 15 seconds.

The website offers both displaying and filtering the records and the simple admin form, so I can add new record just after I stop running from my phone. It was evolving over the time from custom PHP glued to HTML page to being part of a Nuxt application with using my own nuxt-neon module for database connection.

It had one big flaw - for simplicity, I placed logic to frontend and then never troubled with moving the database operations to server-side. Because noone really cared about my running data, there was no urge to change it. I was always like "yeah, I should do it", but then always like "but not today".

The process

Last Wednesday was another such day.

Productive me: _I should do it now. I need some task for daily GitHub streak anyway."

Lazy me: But I am tired from coding all day at work. And surely some issues will arise and I will have to sort them out till midnight. Nah, let's play videogames instead.

But then for some reason I got that little lightbulb above my head like in cartoons. What if I just try asking Copilot to refactor my code and see what happens?

I nearly fell in the How to write the correct prompt? trap, but this time I didn't get distracted. I decided to apply KISS principle and see.

Therefore, my first prompt was pretty straightforward:

Refactor "getTracks" and "getRuns" methods by moving them to Nuxt server side 
and expose as API routes under /server/routes/tracks.get.ts 
and /server/routes/runs.post.ts. Preserve the "filter" as POST input.

Few months ago, my newsfeed was full of articles about prompt engineering or even context engineering as an emerging must-have skill. But fast-forward to present. Your codebase is the context and even a mere Copilot (with Pro subscription) can understand simple prompts good enough to deliver expected results. I am using Claude Sonet 4.5 model recently, but I didn't really try any comparison with others.

It was thinking and working for a while and then I got my refactor. Being aware of The AI Manifesto, I didn't just accept the something it spit out. I went through all changes carefully.

This is a big advantage for us, seasoned devs - we can verify the results by understanding the code. Even if I am using AI to discover how to do XY, I can follow up to some level and get a basic idea about what is going on. And I can challenge parts I truly don't understand, asking What does this do? or Why you put it there?.

This time the code review was easier because I know how to write a Nitro route. I just took liberty not to since now I have a pocket junior dev who can do it for me. I wouldn't be bothering you with implementation details, I have a series of Nuxt tutorials if you're interested.

Anyway, the outcome exceeded the expectations. The delivered code was fine. The only issue that Copilot cannot foresee (unless I would ship an MCP server along with my nuxt-neon module) was that I recently split server- and client-side composable, so it must import useNeonServer instead of useNeonClient.

I fixed that manually. Towards Copilot, I had one additional remark:

Do we need "useAsyncData"? Shouldn't we be fine with "useFetch"?

This was merely a cosmetic thing, the simpler way of achieving the same result - getting data from backend into frontend. And honestly, it was my fault, because I was using useAsyncData in my code and gullible Copilot just copied it. But he also delivered a fix in no time.

Reading data was secured at backend. Now I needed to do the same for adding new runs. My third prompt was:

Going further. Lets also move "submitRun" method from client side Form.vue 
to new server side /server/routes/runs-add.post.ts and redirect client 
Vueform component to it.

This was fast including AI picked up change to useNeonServer and mimicked it correctly. But a technical issue arose - because the data from input form are being posted as multipart/form-data, standard Nitro readBody method cannot be used for parsing the request. The correct method handling this case is readFormData. Copilot helped me debug based on a simple console log and fixed the error itself.

The last piece was to migrate function for deleting erroneous entries:

Last refactor. Move "deleteRun" from Table.vue to backend to 
/server/run-delete.delete.ts

This would have been a walk in the park, if I didn't misclicked to "undo" instead "keep" button and didn't accidentally erase all the changes 🙈 Fortunately, AI doesn't judge and swiftly re-created the edit.

I spend some more time testing (and coming up with new refactoring ideas), but the job I was afraid to start was done.

The outcome

One evening, less than one hour, and the migration from vulnerable Nuxt frontend to more secured Nitro backend was completed. Most of the time I didn't write code, I was just reading and verifying what Copilot produced.

The task I didn't want to start was finished before it could bother me. It was fun, it was useful and it moved me forward. Just wonder how many more tasks like this wait ahead. Let's find out.