I've been in IT for about 15 years, almost all of it in startups and scale-ups, first as a full-stack developer and later as an engineer. I've seen companies at pretty much every stage, and right now I'm watching our industry go through the biggest shift I've seen. This post is a bit of a rant, but it all comes down to one bet:

If you want to survive in IT with AI around, you have to be an engineer. Engineering is where this industry came from, and it's where it's going back to.

That's a bet, not a prophecy. I don't know how this turns out. But here's how I got there.

It started with tinkerers

Most of the companies I worked for followed the same story. Someone finds a problem in a niche that few others can reach. Usually the founders know the right people in a very specific field. They find something close to product–market fit, at least for a while, and then they milk it. Some of those companies were sitting on a gold mine. Some had one huge customer they depended on completely, and a few were wiped out the day that customer left.

The technical side started the same way every time. A friend of the founder becomes the CTO. They're a tinkerer, a full-stack person who can just build things, and they hack together the first version. Then the business grows faster than one person can handle, so they hire more people like themselves.

That's where my career started, and almost everyone around me was a tinkerer. Honestly, there wasn't another way in. The barrier to getting into development was high, so you had to be genuinely curious to even begin. Curious people try things, build side projects and break stuff, and that's how they got experienced. My friends back then were all like that.

It helped that there wasn't much to choose from. You were a PHP developer, a Ruby developer or a Java developer. The frontend was jQuery and nobody cared about it, so user experience was terrible across the board. AJAX was new and exciting: you could send a request without reloading the whole page. Everything was just starting, and everyone was figuring it out by hand.

Then the web hit its limits

Then the big companies realised how much could be built and automated on the web, and giants like Facebook appeared. More importantly, lots of companies started hitting the limits of the technology they had.

Apache, PHP and MySQL on a single server work fine with ten users. With thousands of users spread across regions, you start hitting network problems, then local problems, then the server goes down and your site goes down with it. There were hard problems at every layer, and solving them produced a huge number of really good technologies.

None of that could be solved by "just writing some code that queries the database." You had to zoom out, understand the whole system, and figure out how to optimise it, set new standards, or combine technologies in ways nobody had before. To me, that was the start of the engineering era. I wasn't part of that ecosystem in the US. In Russia things looked a bit different, but we used the technologies that came out of it every day.

Writing code was always the boring part

Here's the thing about engineering work. First you figure out what the problem actually is. Then you figure out how to approach it, what it affects, what the trade-offs are, and maybe you change the plan. Only at the very end do you write the code that does what you already decided it should do.

That last part was the smallest part of the thinking and the most tedious part of the work. The logic has to be right, it has to hold up in every condition, and you have to type all of it. Whole industries grew around making it less painful: IDEs, boilerplate generators, frameworks. It was still slow.

Meanwhile, the important problems sat on either side of the code. Before it: what are we solving and how? After it: how do we deliver it, deploy it, and keep it running? How do we get metrics and data flowing, connect services together, and build a user flow that actually converts? Those problems were always the important ones. Writing the code just took the most time.

The developer factory

Because writing code was so slow, companies turned into developer factories.

The software gets more complex, so you hire more people. Someone has to watch the logs, someone has to own the infrastructure, someone has to write the code. Code is slow, so you hire 50 people to write it. Now 50 people are stepping on each other, so you need structure: Scrum, Scrum masters, sprints. Product wants everything now, but writing code takes time, so you slice the work into chunks you can deliver. Then you need engineering managers to manage developers who can't agree on how to name a function. Then you need endless PRs, reviews and checks.

Then you need QA. Their job was to make sure of quality, but most of the time that meant manual testers clicking through features after the developers, because the developers often hadn't checked their own work. Nobody was measured on that. What mattered was delivery rate, so everyone focused on shipping and everyone hated it when a PR sat in review for too long.

Whole industries grew up around making code production smoother. Look at the media from those years: books, courses and YouTube channels about writing clean code. That made sense. The product never stops changing, so code can't just work for today's feature. It has to stay maintainable, so that anyone on a large team can pick it up and change it later.

Then there's legacy. Any company that has been around for ten years or more is carrying technology bets that didn't pay off. You either keep supporting them or find a way to isolate them, and a lot of tooling exists for exactly that: containers, Kubernetes, sidecars, layer upon layer that lets the old and the new run side by side. Much of it solves another coding problem: refactoring is the most expensive thing you can do. Any real refactor is a huge chunk of work, so you have to sell it. The pitch is usually "we'll stop stepping on each other". From a product point of view nothing changes. Maybe you get fewer incidents, but even that isn't guaranteed, because rewriting a big chunk of logic is a risk of its own.

That's why I call these people developers. Most of their work really was developing code, in a narrow scope. There were frontend developers and backend developers. And there was a whole industry training them. You could take a frontend course, learn React or another framework, and join a company as a junior or medior straight after. Backend was much the same: learn Laravel, Django or Spring, name all the OOP patterns in the interview, and you could get the job, because that's what companies checked for. They needed someone who could add one more abstraction so people didn't step on each other's feet and the team didn't drown in merge conflicts.

That was the developer factory. And to be fair, it kind of worked. But it took a lot to keep it running. You needed really senior people and constant effort just to keep the factory alive. You needed different kinds of managers to make sense of what everyone was doing, and you needed proper planning. That's why Scrum was so popular in those years: in a real factory it was one of the few ways to bring order to the whole thing. You needed logistics and organisation, and roles like head of engineering to steer the ship towards something they could hold onto and hope it would still work in three or four years, until the company was sold.

So there were a lot of bets, and the ship moved at an okay-ish pace. Things happened. But however hard people tried, they still produced legacy. With that many people there was a lot of disagreement, and getting to the same conclusion was hard. There were layers of hierarchy and decisions on top of decisions. Bigger companies split into domains, and those domains rarely worked well on their own. They still had to talk to each other, so new roles were created just to coordinate them. More hierarchy, just to keep the machine running.

Was it effective? Somewhat. But it was built to handle one thing: the code. And that was always my problem with it. I never thought the code was the important part. What matters is the product problem, and solving it in a way that lasts for years. Code was usually the most boring and the worst part of the work, and with a whole factory built around it, it got even worse.

From toy to tool

AI isn't new. Engineers have been building algorithms for specific problems for a long time, like image recognition or translation. They worked, but they weren't what we call AI today. None of them could take any kind of input and turn it into something meaningful.

For me, the story starts with GPT-3, one of the first models the public could actually play with. It was impressive, but it wasn't useful. People were amazed on a very human level: you type "hey, can you talk?", it answers, and you think "wow, it can talk." It can't. It's a statistical soup of tokens. That's how the technology works.

Then it got better, and the first really interesting product was GitHub Copilot, the VS Code extension. You no longer had to go to the browser and copy-paste chunks of generated code back and forth. It was right there in your editor, and I think that changed everything.

It was bad, and everyone knew it. Of its bigger suggestions, I kept maybe one in ten. The inline completions were a bit better, and they did speed things up. You felt it most when you turned it off. It didn't really help with logic. It helped with boilerplate. You'd start typing, a faint grey suggestion would appear, and you'd press Tab to accept it. Then you'd click into the parts that were wrong and fix them. I still changed most of what it wrote, but it typed a lot of the text for me. We already had autocomplete and IntelliSense, but this gave you more: a whole suggestion you could reshape into whatever you actually wanted.

The models that came next were somewhat better or faster, but there was no big leap. I never let it work on more than a couple of functions at a time. Like a lot of engineers back then, I was curious and played with everything from the start, and I got into the Cursor beta. Cursor was the next big step. It indexed your files and sent the relevant ones along as context. That mattered, because many of us had already figured out that the way to get better results was to give the model enough context, and we'd been doing it by hand. Now it happened automatically. You could ask for a new file, and it would follow the examples already in your codebase.

Then the harness became the most important part. The harness handles the loop, the tools, and all the back and forth you used to do by hand. Before, you'd write some code, maybe with AI, run your tests and watch them fail. Then you'd copy the logs, paste them back and say "fix it", or go hunt down the edge case it missed yourself. Now the harness runs the tests, reads the logs, and fixes the problem or digs into why, maybe spawning a sub-agent to investigate possible causes. The loop runs itself, and the context fills itself.

That's where we are now. If you steer it well enough, AI can build whole projects. The code isn't perfect. Neither was the code those 50 people wrote. And what's left for you is architecture.

You're the captain now

AI can produce what you want, but only if you know what you want. Think of yourself as the captain of a ship that produces a generic soup of tokens. Who steers it, and how, matters a lot. You decide where it goes, and you know how to make the result work: how to verify it, monitor it, deploy it and keep it running.

But it's a coding ship. So if coding is solved, what's left?

What's left is the most important part of the work. It was always there, but it rarely got enough attention, and now people are finally paying attention to it. That's also where the stakes are: how do you make a better product?

If everyone can code, how do you compete? You have to figure out what actually makes your product better than the others. Maybe you understand more deeply what people really want. Maybe you know how to design specific flows that work. And most importantly, you have connections offline: companies that trust your decisions, how you do things and how you guarantee them.

Can a competitor appear overnight? Probably. They can code most of what you have. But will they understand what they're doing? If your product is "put something in a database and add an API endpoint for it", you'll have a million competitors tomorrow. Work that is easy to figure out barely matters anymore. SaaS that does really simple things probably won't survive. SaaS that takes on hard, niche problems, the kind that involve regulation or dealing with the government, might get through this storm. You can't ask AI to solve your legal problems. It can guide you, but dealing with them is product work.

So what's left are product people: the ones working directly with customers, figuring out what needs to exist, and making sure it really makes people's lives better. And engineers who go much deeper into product than before. You have to understand the problems, be part of the discussions about them, and then work out how to make it happen.

That's also why one company reports being 10x more productive with AI while another just burns time and money on it. The difference is the people steering it. Ask for "an admin panel" without knowing what you want, and the AI will happily build one, full of its own assumptions and whatever generic patterns it was trained on. Say "I need this specific thing, it has to work this way, test it like this, prove it works like that, and emit these metrics", and it will do exactly that. You still have to check its work, and there are tools that help enforce quality. But people who understand what needs to be done, and how to make sure it's done well, get far more out of AI than people who say "make me something good". In the fight between developers and engineers, it's one more nail in the developers' coffin.

Code for machines, not for humans

You've probably heard that there's a technology for every need. That's not really true. There are far more languages than you'd think, and some were written just for fun. A lot of technologies exist as a consequence of their time, not because everyone really needed them.

Take PHP. It was great because it let you fail. It didn't ask you to care much about your code, or about how much memory a variable takes. That's how a lot of people got into coding: it made writing things and tinkering fast. And for the web, the trade-off made sense. Memory and compute kept getting cheaper, so who cared? You could spin up more servers while you were getting users, and spend far fewer days writing code.

Once a company grows from a startup into a scale-up, the choice changes. You pick what the team knows, but also what the hiring market has. Technologies became self-reinforcing. Look at frontend jobs and it's mostly React, or Vue in some regions. On the backend you see a lot of Laravel, Java, .NET and TypeScript. Community drove that too. Once enough people use a technology, even an imperfect one, they build plugins and tools around it, then businesses come and invest even more. That's how TypeScript took off even where it isn't a perfect fit. It's still a real step up from PHP, Python or Ruby. But the choice was mostly economics: how easy it is to hire, and whether the libraries cover what your project needs.

Now, if you start a project from scratch, you'll probably still pick something familiar, because you still need to understand what's going on. But if you're brave enough, you can pick anything. What matters is how you make sure it works: it passes tests, security checks and whatever other checks you need. If you can guarantee that, do you still care which language it's written in? You still care about the ecosystem. You could write a server in C, and there are options, but nowhere near as many as in Go or Rust today.

Pick Go or Rust and you'd still get a working service, but a smaller one that uses fewer resources, and probably a more reliable one, because the code is compiled and memory-safe. Languages like these were always the better choice, but they took a much bigger investment, so mostly big companies or CTOs who already knew them made that bet. When the machine does the typing, that cost mostly disappears. And compute is getting more expensive again. A PHP or Python server can need five or even ten times the resources of a Go one, while Go gives you proper concurrency out of the box.

So maybe it's time to stop choosing technology the old way and find new ways to judge it. The frontend is a good example, and maybe a controversial one. It's far from solved. There are plenty of options: React, Vue, Angular, Solid and many more. But AI is really good at React. So do you pick the technology that's better and faster, or the one with a huge ecosystem, where so much is already solved and AI is great at it? React kind of won that race, fortunately or not. You could choose something else, but then you'd have to rebuild a lot in it. Maybe that isn't worth it. Or maybe it is, because AI can rebuild it for you. That's where the bets get interesting.

Refactoring changes too. It used to cost so much that you'd almost never do it. A refactor was a half-year project just to keep the application running. Now, why not? You can refactor a lot in a single sprint.

Which also means "I'm a Python developer" doesn't mean much anymore.

What we see when we hire

AI won't replace your job, unless your job was writing code.

I work at Attendi, a health tech company in the Netherlands. Over the past year we realised we don't write much code by hand anymore. We still review it. We still build the things that stop it from breaking production. But for our team, writing code is basically solved.

And we're still understaffed. Coding was a big chunk of the work, but removing it leaves plenty of other chunks: figuring out what to build, how to solve it, design, delivery. Those still take time, and we still need people for them.

So which people? A developer who copied code from Stack Overflow without understanding it? Or an engineer who doesn't care much about the language or the framework, and cares about figuring things out? We decided we want engineers.

In interviews we still meet a lot of developers, and I genuinely feel sorry for them, because we won't hire them, and I think most companies will soon stop hiring them too. AI costs money, but with engineers it costs less. Instead of 50 people, you have 10 or 15 plus AI. They'll do more and build platforms and tools that make themselves faster. They'll move far faster than 50 people with all the ops, process and coordination overhead that comes with them.

If that sounds like you, we're hiring: see the open positions at Attendi.

What AI won't do

I don't think generative AI replaces engineering. It still needs a lot of steering before it produces what you actually need.

It also won't find users for your product or keep them happy. That work is all still there.

It won't replace designers either. It makes okay-ish mockups and okay-ish experiments. But if you don't want your product to look like everyone else's right now, you still need a designer.

If you're starting out

First of all, good luck. I mean that.

Second, fill your tool belt. Tinker with different technologies. Don't refuse to use AI: use it to learn faster and try more things. Learn architecture, learn how technologies actually work, learn where their limits are. Look around and don't stay in one narrow lane, because being narrow is what's going to hurt you most right now.

If you're a frontend developer, good luck. If you're a backend developer, also good luck. Today you need to be full-stack and really understand everything around the code.

It started with engineers, and it's coming back to engineers.