For the past few months I have been building an application for precision agriculture. A web application with maps, an API, a field mode that works without a signal, and its own cloud infrastructure. The back end is in Python — a language I had not shipped anything production-grade in for fifteen years.
It went considerably faster than it would have two years ago. That is not a marketing line, it is simply what happened.
What interests me more than the speed is where exactly the AI stopped being enough, because those are the places that showed what clients are actually paying me for.
What the AI handled
Nearly everything that can be stated as a requirement.
Components, forms, validation. API endpoints with their error handling. Database migrations. Build configuration, pipelines, infrastructure as code. Tests. Working with a library I had never touched — describing what it should do was enough.
Python stopped being a barrier. Not because I learned it, but because knowing the syntax stopped being the bottleneck. I know what a well-designed API looks like, and that knowledge travels between languages. The rest is translation, and translation is something a machine now does well.
If I counted the lines I wrote myself in that project, the answer would be zero. I adjusted a setting here and there, touched some configuration. Everything else the AI wrote — and where it got stuck, I put a second model on it. Two models get stuck on different things, which is a useful finding in itself.
Where it stopped being enough
This is the interesting part.
The data model. AI will design tables from whatever you describe. The catch is that a good design depends on knowing what changes in that business and how often. A field is a stable entity. The crop on it changes every season. An operation carried out on that field is an event in time, related to both. That distinction does not follow from the requirements — it follows from having seen what happens three years later when you skip it.
I have made that mistake often enough in my career to recognise it before it happens.
Coordinate systems. AI will happily write map handling in whatever system is common on the web. That the source data from the official land registry arrives in a different one and needs converting is not something it proposes, because nobody asked. And it will not ask on its own.
That is the more general pattern: AI cannot ask the question that was missing from the brief. It will answer that question well — once you are the one who asks it.
What has to work offline. Technically this is not hard. What is hard is deciding which operations those are. You do not find the answer in documentation; you find it in knowing what the user's working day looks like. Someone in a field needs to record what they did and see what they are supposed to do next. They do not need to edit reference data out there.
Every feature you allow offline is also a source of sync conflicts later. The decision that something will not work offline is often worth more than the opposite one.
What it actually looks like in use. The user is outdoors, there is sun on the screen, possibly gloves on their hands. Those are not details to polish at the end — they are inputs to the design.
What this changes
I used to estimate projects around the implementation. The centre of gravity has moved: the expensive part is now deciding what should be built and how it should be arranged so that it lasts.
That part has not become cheaper. If anything the opposite — once everything else speeds up, it becomes visible that this was the substance all along.
For me it means that fifteen years of analysis, architecture and understanding business processes is no longer something that supplements the ability to write code. It is the main thing I offer. Code has become the cheapest part of a project.
One note on caution
None of this means you can skip reading the output. I read every line that goes to production — not because AI makes many mistakes, but because the ones it makes look correct. A bug in code that looks wrong is found immediately. A bug in code that looks entirely standard is found in production.
For the data model that goes double. A badly designed table does not show its cost until it holds data that someone else depends on.
If you are working through something similar — whether that is a custom application or the decision about what still belongs on the platform and what does not — reach me at vit.lachner@email.cz or on LinkedIn.