I wanted to build a hiking app. It changed how I think about my work.

I spent about four years working on a watch I built myself. Mostly in the evenings, alongside my job. A black dot appearing on the E Ink display, an LED lighting up, a sensor finally working: those were small successes that gave me a lot of pleasure.

Recently, I gave the code I had written over those years to an AI agent and asked it to look for bugs and other problems. About half a minute later, it returned a list of roughly 15 points. When I checked them, I had to admit that some were valid findings. There were places where I had not been particularly careful.

It was impressive. And a little sobering.

My background is in IT, and I now work in finance, reporting and data analytics. I have been exploring AI closely since I first tried ChatGPT. Even so, my own projects have surprised me in ways that product demonstrations never quite did.

I wanted to find out what AI could already do. Along the way, I came to understand more clearly where my own experience still matters.

Three projects that changed my expectations

My first larger experiment was called “Before We AI”. I wanted to check whether the data were suitable for a particular analysis in the first place. Were the terms clear? Did the tables fit together? Was information missing that would leave the AI guessing?

My idea was to build a largely deterministic set of rules. Check the prerequisites first, then let the AI do its work. Even where AI helped identify relationships between tables, fixed rules were supposed to validate the result.

My comparisons did not produce a clear winner. Both the rules and direct AI analysis missed errors and got many things right. The rules also required a lot of manual confirmation. I had underestimated how well AI, given enough context, could identify relationships and work out what needed checking.

These were limited experiments of my own. But they were enough for me to put the project on hold and question some of my assumptions.

Next came “Have I Been Here?”. The Android app uses location information in my photos to check whether I have visited a place before. I built an initial version with Claude Code within two days. Along the way, I learned a great deal about Kotlin, Android, user interfaces, testing and releasing an app.

Then came Tirol.

I have enjoyed using Komoot for many years. On one hike, my planned route suddenly disappeared, and without a signal I could not replan it. That made me wonder: could I use AI to build an app that handled situations like this the way I wanted?

That was the beginning of OnPath. I was already using it to hike and try out the navigation during the holiday. Back home, I added more features and prepared it for other people to use. An initial test is now running through Google Play.

Building it was often easier than deciding what was right

What surprised me was how much help was available beyond writing individual functions. The AI proposed an architecture, considered edge cases and found solutions I would not have thought of myself.

One example is BRouter, the open-source routing software. OnPath uses it on the phone, and the browser planner is built on the same routing foundation. I did not have to design a second routing system.

Later, when I wanted a 3D flyover along a planned route, I had a first working version in about half an hour. Previously, just getting familiar with the subject would have taken me considerably longer.

The user interface was a more persistent challenge. When is a button easy to understand? What should be allowed to change during navigation? How do you prevent accidental input while the phone is in a pocket? Having a function that works technically does not answer those questions.

My way of working changed too. At first, I had individual pieces of code written in a development environment. Later, I gave an agent larger tasks in a terminal. Eventually, several agents were working on the app, browser planner, website and marketing, coordinated through GitHub.

At times, it felt like having a development team of my own. I could request substantial changes while also working on small details. During hikes, I dictated observations into my phone. Later, I had a new version built and installed it through the test app’s update function.

Sometimes, only a few minutes separated an idea on the trail from a change I could try out.

Can anyone do this now?

I need to write less and less of the code myself, and understand more and more clearly what I actually want to build.

I still had to know what I wanted to achieve. I had to define requirements, assess architectural proposals, spot contradictions and test the results. Sometimes, I had to stop an approach because the agent was getting stuck in a solution that missed the underlying problem.

Finding the right level of detail was particularly demanding: enough guidance to get a suitable result, and enough freedom to leave room for better suggestions.

That required domain knowledge, IT experience, imagination and persistence. But I no longer needed to know every technical implementation step myself.

Some of my most demanding architectural discussions were also with an AI. To make those conversations useful, I had to provide my requirements, terminology and previous decisions. The better the context, the more helpful the discussion became.

For me, that is part of the human side of the “harness”: the framework within which an agent works. Alongside tools and tests, it includes clear goals, accessible documentation and someone who notices when the work gradually drifts away from its purpose.

What this might mean for finance and analytics

These experiences have also stayed with me at work.

An analysis can work technically and still be wrong in business terms. The same term can mean different things in two departments. A table can look complete while containing the wrong set of records. In accounting entries, forecasts or intercompany reconciliations, those differences have consequences.

People also make mistakes when they describe requirements or develop software. So I am not convinced by a blanket distinction between unreliable AI and dependable human work. I am more interested in how we can check the results and which controls actually work.

I expect business teams to gain much more scope to create things themselves: analyses, tailored reports and, eventually, clearly bounded workflows carried out by AI agents. Where decisions or accounting entries are involved, permissions, approvals and checks that can be reviewed need to be part of the design from the beginning.

My attention is shifting as a result. I spend more time thinking about which data and rules are needed, how relationships are described and how to recognise a correct result. Technical implementation still matters. But it takes up less of my own work than it used to.

The cost is falling. The sense of achievement is changing.

During the intensive development phase of OnPath, my additional AI subscription spending was around €300 to €400. That is not the full cost of the project. My time, experience, existing hardware and the open-source projects I used are part of it too. Running and maintaining the app will also require work.

Even so, it has become much easier for me to take a substantial idea and actually try it.

There is a personal downside to that. When I used to find a bug after many attempts and my program finally worked, I felt proud. Now, I sometimes wait a few minutes, check the result, tick off the task and move on to the next one.

I can build much more now. Whether it makes me more satisfied is another question.

That is why I want to hold on to my curiosity and deliberately look for tasks that help me keep learning. I still enjoy software development. That enjoyment is changing, and I do not yet know quite where it will lead.

For me, OnPath has become both a useful app and a very practical learning experience. I would like to bring what I have learned into my work with finance, analytics and AI.

If you enjoy hiking or cycling and have an Android phone, you can take a look at onpath.earth and ask to join the test. For me, the project also includes learning how to take an experiment through testing with invited users and eventually make it publicly available.

My intention is for OnPath to remain free to use. Later, I could imagine a fair charge for additional, optional online services, with some of the proceeds going to charitable causes. AI and servers consume resources, which is another reason I want to be thoughtful about how I use them. I have not decided on the details of that model.

If this experiment becomes a helpful app, gives me a reason to keep learning and eventually allows me to give something back to others, that would be a good reason to keep going.