Another rant. In my last post I was talking about how AI is the end of development and the return of engineering. This one is about the perceived speed that we've achieved right now. And why most companies still don't really see it.

I'm talking specifically about senior engineers here. People who have already kind of developed their patterns of decision making, their iterative process, how to come to conclusions and how to not come to conclusions.

Seniors are still doing everything they did before

What I see right now is that most of the seniors are still leading projects the way they did before. And that was like orchestrating all the people who have a stake in it: stakeholders, other engineers, QAs, designers, product owners. Properly figuring out the requirements, figuring out what is going on, what needs to be done. That is still there. All these things are still there.

And before, you kind of knew that all of this was needed, because after that you also went into coding. And coding was a very time-consuming part. A lot of people were taking several days, weeks, sometimes sprints to write the code. So the planning was very important. Making the wrong technical decision at this step was very dangerous, because then you would end up rewriting. And a rewrite, again, is a project you need to sell, and everyone knows how long it takes to do any IT work at all.

There is a huge deception

Right now there is AI. AI writes code fast. It's doing it really, really fast. And it's doing it with really good quality too. So what's the problem?

Right now we can make many more decisions. We can try a lot more things. And if you take a look at the top-notch companies that are at the edge right now, like Anthropic for example, you see that they had to replace Git for their monorepo with their own system. Because they develop so fast and they do so much that normal Git cannot keep up. Their merges per day grew more than tenfold. They got blocked by the limitations of software that was written for people who push code every now and then.

And a lot of companies right now are very confused. Okay, we see these things, we see how fast AI is. And you don't even need to see that from someone else. You actually have proof. You can go to any of the AI agents right now and ask "hey, make me a $1 million app", and it will make you some random shit in like 20 minutes. You will have some sort of thing that deceptively looks like a website.

So what is wrong here? Why are most companies still not able to move fast?

It's people

The reason is very simple. It's people.

Most of the companies that were built before are still built around the idea of a software factory. And that idea is: we need to share the knowledge, we need to do PRs, we need to agree on everything, we need to figure everything out up front. We also choose some stack that we are familiar with.

So you have AI today. And if your company is using AI and is quick with it, you check and you see that almost all of your engineers are actually using AI. That's really cool. That's really great.

But why are we still stuck? Why don't we see like millions of features a day or whatever? Why do we still need sprint planning? Why are we still doing all this?

What it looks like from the business side

You come to the team and you say: okay, we have this problem. We see this feature could go out. We see that customers are asking for this. We see that this flow is broken. So you put several things on the table that are really relevant right now.

Then in two weeks you meet again. And you see that none of this is done.

Because of course there was planning, and that planning did not account for whatever you asked for. But you're also really confused, because most of the things you asked for should not really take that much time to build. So when will this be done?

And then people forget. Because again, there is a process. Someone has to write it down in the backlog. Someone needs to own the process. Someone needs to own the project. Everything must be owned. And then every time it's like, okay, do we pick this? Do we pick that?

And this is the thing. The code is not what slows you down anymore. The process slows everything down.

You're stuck in legacy

The reason is that you're actually stuck in old engineering problems. You're in legacy. Your tech stack, your old decisions, these are all legacy.

And you cannot really do shit about that unless you take a risk and reimagine how you can work much faster today. This is the only way. You cannot move faster if you keep working the old way. You cannot move faster if you keep using the old stacks. If you don't experiment, if you don't figure out what would be a more efficient way in an era where a big part of the code is automated.

My side projects as proof

To prove this, look at my side projects. I do side projects quite a lot. Before, I could take maybe one side project at a time, and usually I was taking it just to discover some technical things.

I mean, of course everyone wants to become a millionaire out of a random startup they do. But I did quite a lot of startups, and I know that this is quite random. Some projects actually blow up, some of them don't. You've got to be lucky to get some users and sell them something they really need. So for that you have to keep experimenting. And before, if you were an indie hacker, you had to put in 24/7. If you were full-time employed, the only thing you could do was something for fun, or for technical discoveries. That's mostly what I was doing: playing around with different tools, new technologies, different languages on the side.

But now with AI that's not really how it works anymore.

I work 36 hours a week, so once every two weeks I have a Friday off. In these three days I can build a whole product.

For example, I have SpotKat. It came from the idea... well, we lost our cat. And we were very, very sad. We were looking around. I was looking into local products. There were some volunteers, some other things that are supposed to help. But in practice nothing helps. Your neighbours can help. That's kind of the only thing. They're around the neighbourhood, and if they're aware, they might actually call you or tell you "I think I saw your cat". That's the only way we actually received anything. Volunteers didn't help.

So I was thinking that I could build an app which gives you, first of all, a link to share for your cat. But also, if your neighbours install the app too (of course that's very optimistic), and they take pictures, then you get the exact spot where your cat was seen.

So building an app that helps find lost cats was just a weekend idea. And at the end of the weekend I had:

• a front-end, a pretty small Next.js website,
• a Go backend, just purely an API,
• an admin panel where I could watch who registered or not,
• and two mobile applications, iOS and Android, fully built and actually submitted for review.

The iOS app went live within two days. Both are now in the App Store and on Google Play.

This is today's reality. If you are an engineer and you know what you're doing, and you're also full stack, you can build whole products in several days. The problem is not that. The problem, of course, is finding people who will use it. But this rant is not about that. This rant is about friction.

Would this be possible in your company?

Would this be possible in a company? In a company that is built around processes of agreeing, aligning, being on the safer side, "oh, we should not have any issues or users will be unhappy", whatever?

If you're this type of company, you can speed up some of the coding processes. Maybe you will need a few fewer people. But you will not see speedups like Anthropic's, for example. Those companies took a completely different turn and took completely different risks.

And I mean, it's your choice as a company. But this rant is also kind of to show that if you fully remove all the obstacles, you can move really fast. Fully remove the risk-avoidance. Fully remove "I will put out only bug-free software". Fully remove "I need to agree with everyone".

What it looks like when you remove the obstacles

I have several applications right now, and I don't even review the code anymore. Most of these applications actually have users. Maybe not millions, as much as I'd want that, but hundreds, thousands of users a week, a month.

And I release applications with bugs. I just detect them and fix them almost immediately. I have an almost fully automated pipeline that just fixes them and automatically pushes them. My deployments are zero downtime. I made it possible to just deploy as often as I want. Whenever I work on side projects, usually I deploy like, I don't know, 5–10 times in an evening or over a weekend.

So what is actually getting in the way?

Let me enumerate what else is getting in the way, because it's not only one thing.

People. I called it people, which is kind of unfair. Some people actually want more process. That's how they feel: more structured and whatnot. And again, this depends on what size of company we're talking about. Is it a startup, a scale-up, or just a huge corporate? When this is happening at a startup level, it's sad, because you're already stuck when a lot of things can be automated.

Process. Then of course the most difficult part is the process you built: how, what and when you do things.

Tools. Then this process is also using some tools. For example, if you use Jira, most probably you will not move fast at all, and almost never. It's a very slow tool, and there is not a lot of automation around it. Choose Linear, for example, or build your own tool. You can do that in most probably several days. A tool that you can use in your meetings or whatever, that will remember what you want to do, take the planning and create tasks for you, maybe even estimate their size, and maybe even cook you some PRs automatically in the background while you're still talking or doing triaging or whatever.

Observability. Then you have to have a really good observability stack. You need to know about errors not from users, but in an automated way. Every error must automatically go through some triaging, like a very fast language model that tells you if it's noise or not, mutes or unmutes the error, and maybe even creates a PR to fix it if it's a code bug. If it's an infrastructure problem, it might create a project to refactor things, and then you can prioritise it at some point.

Your coding stack. Then of course there is your coding stack, and this is one of the most important parts, because what you choose also defines how fast you can go. How safe is your language? How fast is your language? How fast is your framework? How many choices do you have? How good is AI at it? That's, I guess, actually one of the most important things right now. And how many resources does it need?

From code to deployment. How fast you can go from code to actual deployment. This is another bummer that you will hit. PRs, automated tests, a CI pipeline that runs for like 40 minutes, a deployment that runs for another 50 minutes. You will never see 20 features a day if your CI pipeline runs that long. And if you need to fix any bug that's happening in production, and you have to go through the whole pipeline again, through the whole project and the whole flow again, then of course you will just not do that. And a lot of bugs will just stay in production.

There are a lot of places where you can really automate things and make your life easier. But for that, you have to make really bold decisions.