Developer work is changing. Where does experience fit?
🎧 Listen to every article back to back
I have watched work shrink for myself and other developers. At the same time, AI lets me try ideas I previously lacked the time or money to pursue. I write about this change from my own experience: what needs rethinking and where I want to focus as a developer.
In my view, an experienced developer’s work is moving towards understanding the problem, designing a solution and checking the result. Faster code gives us a chance to tackle work that used to be too expensive or complex. That is where I am looking for my next opportunities.
Three working days for one package of changes
My latest work on Suveniiripood (opens in a new tab) covered synchronising product data and copy, improving the purchasing journey and interface, and testing those changes. This package took me three working days. With my earlier methods, I estimate the same work would have taken about three weeks. That comparison is my judgement from experience; the three days did not cover building the whole shop.
AI helped work through solutions and write code and tests. My part was to identify needs, direct the work, assess proposed changes and decide whether the result fitted this shop’s workflow.
One specific issue in the package was search feedback. After submitting a query, shoppers did not get a clear indication that they were viewing search results, or what to do when there were no matches. A test run before the fix confirmed the missing heading. We added a visible search term, a results heading and an explanation of empty results with a suggestion to try another term.
We checked searches with and without matches, long input, HTML-like text and operation without JavaScript. On a phone, a long search term had to fit the screen; entered text had to remain text. An observed usability problem became a check we could repeat after later changes.
The saving came from more than writing code faster. We also had to understand what needed changing, which parts depended on each other and how to check that the rest of the shop still worked. I would therefore measure time to a verified result, rather than to the first piece of code.
I see the change in projects and people too
I have watched work shrink for myself and other developers. Internationally known developers are looking for work on LinkedIn, and local developers have asked me for advice. In the press I see redundancy announcements and accounts of workflows changing through AI use. These observations are not labour-market statistics: the economy and earlier business decisions matter too. They are nevertheless signals I need to take into account when planning my own work.
Skills learned over years and difficult problems solved become part of your identity. When a tool produces the start of a solution in minutes that would once have taken you hours or days, you have to reconsider your role. Some of those solutions might previously have remained unbuilt because of their complexity. What interests me now is what we can do with that possibility.
Some clients build for themselves. Others choose a new focus
Some people who previously commissioned development now use AI to do it themselves. They know their workflow, see the result and can try it immediately. They can skip explaining it to a developer, several rounds of clarification and sometimes a misunderstanding. That is a real benefit for the client, and some familiar commissions will disappear as a result.
Building it yourself can also leave security overlooked: a solution working on screen does not yet show whether access permissions and data protection have been thought through. Responsibility shifts along with the work. When you build it yourself, you also need to arrange verification, updates and fixes, or find a partner for those tasks. This may be exactly where a developer can help turn a working first version into a system people can rely on in daily use.
But people will not take on every task themselves. Being able to build something does not create the time or interest to do it. One person wants to shape their own tools; another wants to concentrate on their core work and entrust development to someone else. The focus shifts: where does a developer’s help make the greatest difference?
I see work in connecting existing systems, reducing manual tasks, checking solutions and developing them further. A client may build a first version independently but need help making it fit their other systems, data and users.
Drupal experience helps you ask the next question
Someone who has worked with Drupal for years knows the distance between a working first view and a solution that can be used for years. Code for a block displaying a signed-in user’s information may be quick to produce. Next come permissions and caching: could one person’s information reach another? Drupal describes these dependencies in its cacheability documentation (opens in a new tab).
Asking that question at the right time is part of experience’s value. Experienced developers also need to update their methods. AI makes experiments faster, but you still need to judge whether a proposed solution fits.
There is work in things we have left undone
An editor repeats a manual task. Two systems do not exchange data, so someone moves it between spreadsheets. People avoid touching an old custom feature because no tests check its behaviour. If tackling those jobs becomes affordable, some can finally go ahead.
I have also built hobby projects and experiments for which I previously lacked time or money. I can now try some of those ideas in practice. A smaller organisation may be able to afford a tool previously outside its budget. I see opportunities both for new development and for meaningful improvements to existing systems.
At WebPro, we always use tests in AI-assisted Drupal development and try to turn new observations into reusable practices and automated checks. Time savings should reach the client through less work to pay for, or more useful work within the same budget. Some saved time can go towards more thorough verification. Our job is to decide with the client which problems are most worth solving and direct the work accordingly.
Giving direction starts with listening
Different people notice different things in the same website or system. Suveniiripood’s search could count as technically working if it returned the right products. For a shopper, it remained incomplete if they could not tell what had been searched for or why there were no matches. An editor might ask how products should be described so that searches can find them. These perspectives give the same development work different directions.
To me, a good developer has always been someone who notices problems, proposes solutions and thinks alongside the client. They ask what problem a requested change solves. That approach helps when directing AI too. The transition has been easier for me because listening to clients and finding solutions together have been part of my work for years.
When teaching, I also talked about understanding what you are building, for whom and why, and how your work fits the rest of the system. Practical experience often brings that idea into focus. As code becomes faster to produce, understanding the wider picture becomes more valuable.
Conversations with my long-time friend Tiit Lepik (opens in a new tab) have made me think more about content and its structure. Tiit contributed to the Melges24 project, and together we audited the kik.ee (opens in a new tab) portal and developed an architectural proposal. KIK is the portal of a state foundation under Estonia’s Ministry of Climate (opens in a new tab). Such work requires asking what information people need and how it connects. Drupal remains a good fit for managing structured content; faster technical implementation gives us more room to work through those questions.
My experience helps bring the whole solution together
My next direction is to help people connect their needs into a working whole: listen, propose solutions, build and verify. Years of experience help me notice connections between existing systems, data and people’s work. AI lets me turn more of those ideas into reality, including work previously put aside because of cost or time.
I develop my methods through concrete tasks whose possibilities and limitations I understand. Suveniiripood’s latest package of changes is one such experience. It gives me a basis for judging where the new approach saves time and where careful investigation is still needed. That combination is where I am looking for my future work.
The thoughts, experiences and substantive decisions in this article are mine; I shared and refined them over several hours, using AI to help with structure, wording and the read-aloud audio.
