Being a Good Developer Is Not Enough Anymore

When we talk with customers these days, the request sounds more or less the same. They are not looking for a developer. They are looking for a person who can take a vague idea, turn it into something that works, keep an eye on what the users actually do with it and carry the team along the way. Then they add that the person should of course be up to date with AI tools, because the team is expected to move faster now. When I ask how the search is going, the answer is usually that it is not going.

I understand why. What they are describing used to be four different people. They want it in one person now because the shape of the work has changed, and they are right about that.

‍

The hard problems moved

For a long time the hard part of a software project was building it. Getting the architecture right, getting the code to work, getting it to production without breaking anything. Product decisions mattered too, but building was slow and expensive enough that it dominated everything else. A bad prioritisation decision cost you a few weeks. A bad technical decision could cost you the project.

That balance has flipped. With AI-assisted development we build in days what used to take weeks, and in our own projects the total cost of a feature is a fraction of what it was a few years ago. When building gets five times cheaper, nothing stops a team from building five times more of the wrong thing. That is the new expensive mistake. The hard problems moved to the two ends of the project. At the start, what the vision actually is, which ideas should die early, who the end users are and what the data says they do. At the end, whether it really works, whether the quality is good enough to defend, and what the release changed in the numbers. The build in the middle still needs to be done well. It is just no longer where the project is won or lost.

‍

What the job ad is actually asking for

Look at what the customer is asking for and you get a list of jobs rather than one job. Deep software engineering is still the base. You cannot review what an AI agent produced if you could not have written it yourself, and somebody still has to own the architecture, the security and the cost when the thing runs in production. On top of that they want somebody whose AI skills are current, which means something different every few months. Then product thinking, which is talking with end users, reading the analytics and deciding what not to build. Then communication and planning, because the same person is expected to explain the plan to the CEO in the morning and to a junior developer in the afternoon. And leadership, starting with leading yourself when nobody tells you what to do next.

The old name for this shape is a T-shaped developer. Deep in one skill, wide across many. What has changed is how wide the horizontal has to be, and how fast one part of it keeps moving.

‍

Why these people are so hard to find

Each of those is a career on its own. Most people build one of them deep and the others shallow, because that is how jobs are shaped. A developer is measured on shipped code. A product manager is measured on outcomes and rarely touches the code. An architect is often the furthest from the users. The combination almost never comes out of one career path. It comes from people who have been forced to do all of it, usually in small teams where there was nobody else to do it.

The AI part makes it harder still. It is not a skill you learn once. The tools and the working methods that were right a year ago are not right today, and staying current takes real time every week. Someone who also carries product responsibility and leads a team does not have that time by default. The people who have made it work anyway are rare, they know it, and they are not sitting in the job market waiting for a call.

It also cannot be fixed by hiring more developers. There are plenty of developers available right now. What is scarce is people who can decide what those developers, and the agents, should build next and can tell whether it worked.

‍

What the work looks like now

In our projects the week of a senior architect looks quite different from a few years ago. Less time typing code and more time reading and reviewing code the agents wrote. A recurring conversation with the customer's product owner about what to cut. Time in the analytics, looking at what users did with the last release before deciding the next one. Writing down decisions and context so that the rest of the team, people and agents both, work from the same understanding. And still, when it matters, going deep into a hard technical problem, because that is what everything else stands on.

‍

We know it is not easy

We are not going to pretend this hire is easy. It is not, and we see customers search for months. It is also the profile we have built Softlandia around. We hire and grow architects, people who cover more than one column of that T, and that is what we look for as the company grows. Our consultants have carried product responsibility, led teams and rebuilt their own way of working around AI tools more than once. That is why customers bring us in when the search has taken too long, or when they need this kind of person in the team next week rather than in six months.

There is a second way to use us that customers often do not think of at first. Bringing one of these people into a team for a while tends to change how the rest of the team works. The agent workflows, the review discipline, the habit of looking at user data before deciding. Those stay after we leave, and that is usually the part the customer values most a year later.

If you are looking for this kind of person, or trying to grow them in your own team, we are happy to talk.