What matters when everything changes

I’ve worked in software development for around 20 years. For me, it has always been about the same thing: understanding a problem and finding a way to solve it.

Code was simply the way to get there.

And yet, over time, we ended up spending more and more of our energy on the way itself.

At some point, software development became very grown-up. Teams got larger. Roles became narrower. We got frontend and backend, QA, product owners, and more layers between the people with the problem and the people able to solve it. Systems were split apart. Microservices promised autonomy. Processes promised control. Patterns made solutions predictable. Branching strategies made it safer for many people to work in the same codebase.

Most of it came from good intentions. Much of it solved real problems.

But the sum of it changed something.

The distance between the problem and the person capable of solving it grew.

I remember development before that as more direct. We sat close to the business. We talked to people, understood what they needed, and fixed things. We worked across the stack. There was freedom, responsibility and a fair amount of exploration.

Over time, it became more conformist. More attention went into how things should be built, how work should be organised, and which patterns should be followed.

I’ve probably always been slightly allergic to that. Not because structure is bad, but because structure has a habit of becoming an end in itself. We introduce control mechanisms to deal with complexity that partly exists because of all the control mechanisms we introduced before them.

That is why the last year has felt so strange.

For the first time in a long time, software development seems to be moving in the opposite direction.

We stopped writing code

Around Christmas, we went all-in on AI at SkyeTec.

Since then, nobody on our development team has written code.

Not one line.

That may sound like we stopped being developers.

To me, it feels almost like the opposite.

If I put deliberately rough numbers on it, I probably used to spend 95 percent of my time on code and five percent figuring out what we actually wanted to build.

Now it feels close to the reverse.

I move between Claude and Codex. VS Code is gone. My workspace is now a collection of colour-coded terminal windows, often with four, six or eight things running in parallel.

But the biggest change is not how much I can do at once.

It is the level at which I can begin.

I can tell an agent, at a fairly high level, what I want to achieve. It starts working. When it reaches a decision where my judgement actually matters, it pulls me down into the details.

I am not avoiding the details because they are difficult.

I am avoiding them until they matter.

That is a profound difference.

The developer was never the code

One of the more frustrating reactions early in this transition was the idea that perhaps we would no longer need developers.

If you believe the primary function of a developer is to produce code, that is a perfectly reasonable conclusion.

I have just never seen the job that way.

The best developers I have worked with are good at understanding other people. They can talk to the people they are building something for and work out what the real need is. They understand the business. They see connections. They share what they know. They take initiative and ownership.

They also notice when something is off, often before it is obvious exactly why.

Experience is visible as knowledge, but perhaps even more often as judgement.

That has become incredibly valuable.

At the same time, other things are becoming less important. I care less and less about which programming language a developer knows. When I see someone hiring a “Java developer”, I increasingly find myself wondering why Java matters so much.

We still need to understand what technologies do, what properties they have, and the trade-offs they introduce.

But we increasingly do not need to identify ourselves with the implementation.

I think of our developers more and more as tech leads for their own teams of agents.

The job is no longer to tell the machine exactly how every line should be written.

The job is to understand where we are going.

Exploration became cheap

This might be my favourite part.

We can play again.

In the past, we could have five possible solutions to a problem. We would discuss them, try to predict the consequences and choose one.

We had to.

Building all five just to see which one actually worked best would have been absurd.

Now, increasingly, it is easier to try.

That changes the relationship between thought and action.

I have built games for platforms I barely know. I built a small DAW over a weekend because I wanted to see whether an idea worked. At work, we move into domains where we previously would have spent a long time learning the implementation details first.

The interesting part is not that things move quickly.

The interesting part is what happens when curiosity becomes cheap.

Build something. Look at it. Talk about it. Find out whether the idea was actually any good.

But this new capacity creates a new constraint.

When it suddenly becomes easy to build things, it also becomes very easy to build too much.

We have learned that firsthand.

The bottleneck is no longer necessarily how fast we can produce software.

It is how quickly people can understand, use, react and learn.

Paradoxically, the enormous increase in capacity has made us even more interested in something very old: short feedback loops.

Get something real into use. Watch what happens. Let experience determine the next move.

The difference is that the loop can now begin almost immediately.

Control has to move

It is easy to interpret this way of working as less control.

I think that is wrong.

As both people and agents gain more autonomy, control becomes more important.

It just needs to exist in the right places.

For a large part of software history, we have put control directly into the workflow. Pull requests. Branching strategies. Approval processes. Handoffs. Roles whose job is to check other roles.

Some of that will still have a place.

But increasingly, we are trying to move control out of the path of the work and into the systems underneath it.

Agents need to know who they are. They need to know what they are allowed to do. They need the right context. We need to be able to see what they have done.

Some actions can be autonomous.

Others should hit a hard boundary and wait for a human.

Agents can have enormous freedom to explore, build and test. That does not mean everything they produce should immediately be used. New functionality can remain disabled until we deliberately decide to turn it on. Production is still an explicit decision.

Freedom and control are not opposites.

Good control may be exactly what makes extreme freedom possible.

The same is true for people.

Ownership scales better than control

I have always believed most strongly in teams where people know each other well, enjoy working together and feel genuine ownership of what they are building.

It is the team where someone fixes something on a Sunday without being asked.

Not because it is expected.

Because they care.

If you have hired smart, motivated and reliable people, I find it strange to build a system around the assumption that they need to be watched.

I do not need a set of individual metrics to know whether someone on my team is doing a good job. I work with them. I talk to them. I see how they take ownership, how they work with others, and whether we are moving in the right direction together.

If there is something the team believes is useful to measure, we measure it. If the customer wants to know whether something is actually improving, of course we measure it.

But measurement is a tool.

It is not a substitute for leadership.

For me, leadership increasingly means enabling people. Setting direction. Connecting people. Discussing. Making sure they have what they need. Giving responsibility to those who are ready and willing to take it.

And creating an environment where it is safe to try and safe to fail.

AI has not made that less important.

I think it has made it more important.

The organisational map is starting to look old

It is hard to imagine this not changing how technology companies are organised.

Frontend developer. Backend developer. QA. Platform engineer.

I am becoming less convinced that these boundaries will remain particularly interesting.

People do not need to become the same. Quite the opposite. Different experience, temperament, domain knowledge and perspective matter.

But I think more of us can once again simply be developers.

People who understand problems and can make things happen.

The same applies to architecture.

I used to worry about what would happen when agents were given substantial freedom over time. Would systems gradually decay? Would we end up with enormous codebases that no human could properly understand?

I worry less about that now.

We let agents review what they and other agents have built. We let different models challenge each other. We build context around the systems. And when something no longer makes sense, we tear it apart.

We have already done that several times.

Architecture can become more emergent when the cost of changing it falls.

We humans can focus more on the properties we actually care about: security, functionality, performance and the ability to change.

What happens under the hood becomes gradually less important.

And there is one thing worth remembering.

AI will never again be as bad as it is today.

We are not finished

The way we work has changed several times in the last year alone. We have taken wrong turns, reversed decisions, torn apart things we had just built, and continuously moved the boundaries of what we allow agents to do.

That is not a problem.

That is the point.

We are learning this by doing it.

By giving people room to explore. By occasionally going too far. By bringing those experiences back into the way we work.

A lot of what we do today is not something we would have arrived at in a strategy meeting a year ago.

And it will change again.

Those waiting until they fully understand this before they begin will wait too long.

What are we actually trying to achieve?

We are now experimenting with working environments where people, customers and agents are part of the same conversations.

This is not a sketch of how we think development might work someday. We are doing it now.

We talk about what works and what does not. Agents act on the context, find what is missing and collaborate with other agents. They respond to user feedback and operational insight without waiting for someone to write a ticket. They can take initiative themselves.

The line between discussing a problem and solving it starts to disappear.

We do not yet know how far this can go. But we have no intention of waiting for someone else to find out.

Humans do not need more information. We need insight. We need to understand what matters. Set direction. Make trade-offs. Talk to each other.

And eventually that leads to a much larger question.

If machines can do more and more of the mechanical work, what do we actually want humans to spend their time doing?

The easiest answer is more. More output. More efficiency. More growth. More money.

I hope we can be slightly more ambitious than that.

We are entering a technological shift without knowing what exists on the other side. It may change software development, organisations, and eventually our relationship with work itself. That also means we have some agency over where it takes us.

I hope this technology becomes a democratising force. That the ability to create does not become concentrated in a handful of companies. That capable people get more room to act. That technology removes more meaningless work than it creates. And that we spend less of our time serving the systems we built, and more of it on each other.

Those are big questions. We are not going to think our way to all the answers.

#FÅDETPÅ