Every engineering team has a list of problems it knows about and never gets to: a latency issue, a PII problem, the internal tool that would make everyone faster. For years the reason was the same. There was no time, because someone had to write the code.
The skills an engineer needs are different now, and the change starts with what drops out. Our opinion is that the time code used to take now belongs to that list, and the engineers who stand out will be the ones who spend it there.
This piece is one of a pair. The other, Our job was never translating requests into code, is about how the work gets done day to day. This one is about what to invest in.
Writing and reviewing code are losing value
The clearest skill to lose importance is writing code, in every sense, including the ability to review it. Once a system can hand you the output, the environment, the artifact, whatever it is, and you can check it directly from a functional point of view, code review stops being where the value is.
The same goes for defining an architecture graphically. Claude is going to do that for you too.
New skills appear, starting with the obvious one: these AI systems have to be learned, and learning them matters. But the bigger shift is in skills that were always important and rarely got the time.
The time code used to take now goes to engineering problems
Before, some things could not be prioritized. Latency problems, or PII problems, could take a long time, and prioritizing them was a serious problem. So they waited.
Now they get prioritized. They ask for time, attention and a share of problem solving as an engineer that they rarely got before. One of those PII problems, and what solving it took, is in Our job was never translating requests into code.
That has a consequence for engineers who were never very fluent at that kind of problem solving: now they have to be. If you want to stand out, or just be useful, those are the situations where an engineer can be far more useful than before.
The internal tooling that used to be a time sink now pays off
Our team has a lot of people who treat development almost as a hobby. For years the same thing kept happening: everyone wanted the perfect development environment for their own team. People would spend time on “I’ll build this library, this tool”, and it was always a time sink. It never really sped anyone up, and the day-to-day work ate it.
AI gives us a huge capacity to build, and we have not managed to exploit it fully yet. Seeing both at once changes the calculation. What used to be a time sink, building a tool like that, now makes a lot of sense for a company like ours. It is how we ended up building Facility, large and complex tooling for working with AI that works very well, and reached effectiveness in a short time.
We think any company should start considering what used to be the time sink nobody touched: spending time on its own software development lifecycle. That is what will actually speed it up, and quickly.
There is one condition. You can only do it if you have the tool and you understand the rules of the game.
The rules are learned from people who have hit the problems
There is too much hype. You try to stay optimistic, but a lot of it is easy to question unless it comes from very reliable sources, and if you let everything you see online carry you, you end up overwhelmed. It happens to all of us.
Consuming content is an important part of learning. But the people we end up learning from are the ones who have actually faced the problems. What they keep running into is that things are not that easy. That is good news. It means there is a lot to learn, and it means you do not have to try everything, because not everything is useful.
That is why being in the same room with people who are really doing the work matters so much to us. It is what separates being overwhelmed from being grounded, focused on what actually works for you.
Bigger systems carry more responsibility
We are going to build more, and bigger. Complexity will grow, and so will the responsibility and the impact software has on people.
That is where engineers stay necessary: engineers who can keep control of the AI, make it evolve within the domains they work in, and deliver value with it. Someone has to maintain and improve those systems so they keep serving the people who depend on them.
The job will be more complex and will need different skills. There is an opportunity now to adapt and do bigger, better things with what we have.
Take the list of problems your team knows about and never schedules. Pick one, and give it the time the code used to take.