Software developers have become researchers. We now hand most of the coding to LLMs, so the job has moved to what happens before and after the code. Predicting anything in tech is a poor bet. But I have used these tools hands-on since the start of the AI wave, and my working day has shifted.
The old question was: “Can you build this and own it?” The new one is: “Can you find out how to build this, and oversee the build?”
What the work looks like now
There is more context to prepare. An LLM predicts the next token from what you give it. The closer that input is to the problem, the closer the output lands to the right solution.
There are more tasks. Gathering context is research, and research breaks into many small jobs: things to do, things to review, things to check. I keep them as a checklist, on paper or on screen.
There is more information to manage. LLMs produce a lot of text, much of it boilerplate. Add diagrams, bullet lists and other documents, and you need all of them close at hand for the next iteration. Being organised matters more than it used to.
How I research a task
I borrow an idea from Terraform and declarative programming: state what you want, not how to get there.
I start every task with 15 minutes away from the LLM. It works like a warm-up at the gym. I write down a list of questions, and these become my guiding questions. When the model drifts towards something interesting but useless, I check the conversation against them to see whether we are still heading for a solution.
I keep at least one markdown note per task, story, feature or epic. It collects everything in one place. The habit was useful before LLMs. Now it is essential.
My mental model of an LLM is a tree. The model starts at the root and climbs down towards your problem. Good context takes it to the right branch, close to the true solution. Useless context, such as “My team wants me to solve this problem”, sends it to the wrong branch. You get “Here is a reply you could send: Subject: …”, which costs tokens, time and quality. Give it just enough of the context that matters.
To reach the right branch, I quiz the model first: “Do you know how to do X?”, “Do you know how many places do this?” That warms up the context before I paste the requirements. Easy tickets are the exception. When I already know the answer, I paste the problem straight in, because I can review the output against the solution in my head.
Will AI replace software developers?
Wrong question. The role has moved towards research, and research cannot be automated yet. It is the first step, before any agentic pipeline runs. It goes well beyond code review. It needs an understanding of how neural networks work and how to use them well. It also needs knowledge management: get the facts from subject matter experts and write them down, or, if they already exist, bring them into the context.
Without that knowledge, an LLM is a project generator. And if you don’t know what you expect, you can’t tell when the model is wrong. It will explain its output in fluent, confident prose either way.
The developer’s job is now research: gathering context, asking the right questions and judging the output. An LLM cannot do that part for us yet.