I have been putting this post together for about eight months, somewhere between conversations with colleagues, with people in my network, and with myself.

All of us have watched the industry change over that time. Companies have closed whole divisions because of AI, people have lost their jobs, the way we measure productivity has shifted, and the paradigm of the whole profession is changing.

The argument I stopped having

I have always seen AI as an opportunity and an accelerator. I keep meeting engineers who see it as a threat and who are sure it will not last. It is too expensive, they say, and one day it will cost so much that companies will need their people back, get smart, and forget about the hype.

I am tired of having that argument. This is the world we work in now. The models are getting cheaper to run and smarter at the same time. On AutomationBench, Opus 5.5 at medium effort passes more tasks than Opus 5 did at its highest setting, and costs less per task than Opus 5 did at its lowest.

That does not mean there is nothing to be afraid of. I do not know what this job will look like in a couple of years, or whether there will be jobs like it at all. I loved the profession from the first day - writing code, exploring technologies, learning new languages, building products and features - and I still lose track of time when I work. I accept the change anyway, because it is for the better. We all build and ship faster. A feature that used to need a team and a month now fits in a weekend, and it keeps getting easier.

The people starting out pay for that. Juniors have a harder road than ever, and nobody has time to teach them any more. That is bad, and the industry will have to work it out at some point. It is not only software: lawyers, marketers, business developers and almost every other digital profession are in the same position. I recently interviewed a candidate who is still at university, and I came out of it with no doubt that the next generation will find its way in.

Then there are the larger predictions. Some AI researchers expect mass unemployment, some expect extinction, and their arguments make sense to me. A couple of months ago I was afraid too. Then I stopped worrying about it. We should be cautious, and I agree with that, but beyond voting there is very little I can do, and I cannot stop living.

A new skill on the list

For as long as I have been in this profession, a good engineer was measured by coding skills, concepts and OOP principles. Those still matter, but there is a new skill on the list that nobody can ignore any more: working with AI.

It reminds me of search twenty years ago. Once Google was good enough, remembering things mattered less than knowing how to find the information you needed. AI goes further than search did. Search helped you link the dots, and AI builds them as well. It helps you traverse the information you need, and then it designs, draws the mock-ups, builds the infrastructure, writes the code, reviews it, and challenges it against your security, performance and quality standards.

So software is getting cheaper. Building the tool the customer actually needs, finding the market fit, and building it right are not getting any cheaper. The job is organised around those now, and I think it stands on three pillars.

Skills

The first pillar is everything we spend our careers mastering: technical skills, product skills and soft skills, and all of it still counts. A good engineer has always been someone who can think a problem through and construct a solution to it. Languages and frameworks were the material, and typing was the smallest part of the work. Sometimes the right solution is the quick one and sometimes it is the reliable one, and knowing which to apply when is what the years of experience buy. A model writes both kinds equally willingly. A landing page for one audience can be rough, owned by a designer and rebuilt next week. A card payment that times out on a terminal cannot be guessed at, so the bridge that handles it treats every outcome it cannot prove as unknown.

AI skills

The second pillar is working with AI and the modern tools around it. It is a skill like any other, but it has become so powerful and so broad that it changes the game. An engineer who skips it will fall behind and struggle to progress.

I have never seen a tool like it. For a product engineer it shows up in every part of the day: working through a domain model before any code exists, mock-ups and front-end designs, the data models, and the infrastructure they run on. A move off Heroku that would once have been a project of its own came to about three weeks of work, fitted in between the features and bug fixes that did not stop for it. A mock-up starts with two models given the same prompt, and the better result wins.

Prompting is the smallest part of the skill. The rest is knowing what context a model needs and writing it down where the model will read it, splitting the work so each piece can be checked, and having a second model review the first. A change of more than 150 files that one model planned, built and tested still carried two issues that would have broken production, and the other model found both of them.

Product

The third pillar is the one I underestimated as a junior. There was always a product owner telling me what to build and how it should behave, and the user experience was something they worked out with a designer. My part started at the ticket.

That split is closing. When engineering ships several times faster, the product owner becomes the bottleneck, and the code waits for decisions instead of the other way round. The same tools let a product owner build a proof of concept without waiting for an engineer, and let a designer own a live site end to end. The software engineer and the product person are slowly merging into one role, and I call it the product engineer.

In a start-up the merge has already happened. Where I work there is no product manager and no project manager, and there is no room for an enterprise-grade feature delivery process. The product engineer talks to the customer, decides what is worth building, designs it, builds it and runs it, from the way a screen looks to where the service is hosted. When Salto asked for our OpenID Connect discovery document, nobody wrote a specification and handed it over. The identity provider was researched, built and tested that afternoon, and by the evening it was merged and serving the document from staging.

The harder part of the role is choosing which problem to solve, and judging the result by what changed for the customer. Moving a club onto our platform used to take two working days of someone's time, and it was the slowest part of signing a new club. With an AI import for the bulk load and an MCP server for the leftovers, it takes one to two hours. That is the number we quote. The one we watch is how many migrations we had to do twice, and it has fallen furthest.

Watching how a feature is used after it ships matters as much. We expected the MCP server to be an engineering tool, and club owners turned it into a customer one: they connect their own assistants and ask for the reports they used to email us about.

This pillar is the least transferable of the three. The skills and the AI skills move with you to a new job, and so do the general habits of product work: talking to customers, choosing the problem, watching the numbers afterwards. The product itself stays behind. A new role brings new customers, a new market and a reason behind every screen that someone else decided. For the most part you start from a blank page, ready to learn, and dedicate yourself to figuring the product out until it is yours.

Where that leaves the profession

Each of the three has been part of the job for a long time. Engineers have always needed the skills, the good ones have always picked up the best tools of their time, and some of them always cared about the product. The engineers who will do best in the years ahead hold all three at once. They think a problem through before anything is built, let the tools carry most of the building, and stay close enough to the customer to know which problem was worth solving.

The same pillars give someone starting out a place to begin. The first still takes years. The second and third can start on the first day: a junior uses the same tools everyone else does, and a product of their own, however small, comes with a customer to talk to and a number to watch.