Is the tech stack irrelevant?
You might have heard about the opening keynote at Rails World a couple of weeks ago. We are a Ruby on Rails shop, so some of our engineers were there. David Heinemeier Hansson (who created Ruby on Rails) talked about HEY, the email product his company makes. HEY was written in Rails. They rewrote it with a Rust back end to make it faster, so they need fewer servers to run it. His argument was essentially that AI writes and reviews all the code. Why should he care what the stack is? He just tells AI what the outcome should be.
And in his case, it was even easier. They already had a working product — AI just had to make something that functioned the same way.
Hold on. This is a Ruby on Rails conference, and the person who created Rails is telling us he moved off Rails? People were outraged for all sorts of different reasons. But the argument itself is valid.
We have been having this same conversation on our engineering team and with our customers: If you believe in how fast AI is improving, it is hard to deny that this is a reasonable approach.
How we thought about things yesterday
Once upon a time (OK, basically last month), choosing your tech stack seemed really, really important. The tech stack is everything the software is built on: the servers it runs on, the database, the backend framework, and the frontend framework. At Aha! that is Ruby on Rails on the back end, React on the front end, and Postgres, all running on AWS.
Our engineering teams chose their stack very carefully because we were trying to optimize a lot of things at once. The most important was the team's expertise. Learning a tech stack is a big investment. Most engineers specialize in one and maybe know a few others. There was also a trade-off between developer experience and code execution speed.
Switching stacks is also expensive. I do not mean dollars so much as time, and engineering time was always a key consideration. You had to retrain your team, rewrite parts of the functionality, and change your infrastructure and how you run operations. So a company usually made the decision once and built everything after that with the same stack. You were a Java shop, or a Python shop, or a Rails shop, or a Node shop.
We have always had a really strong philosophy of using one tech stack — the one we are experts in. We were absolute experts at Ruby on Rails and used it for everything. That paid off for us really well.
I contrast that with other companies that use different stacks on various projects because whoever started the project said, "This is my favorite stack." Or the worst case, which happens all the time: "This is a new technology I would love to learn. Let me use it for this next project." Then you end up with many stacks, and nobody is an expert in all of them. That has been very difficult to maintain historically, and your improvement velocity goes down.
If engineers are not writing the code ...
In a world of AI, sticking to the one stack your team knows best is much less important. If AI is writing the lines of code instead of an engineer, the tech stack matters a lot less.
There are two ways to think about it.
The purest way is: I do not even care. AI can choose the tech stack. I will tell AI what I want it to do, and it works out the rest. Product managers will recognize this one. It is pretty much how product management already works. The product manager tells the engineering team what they want the product to do. The engineers decide how to build it and what stack to run it on.
Engineers are now working that way as well. We build by describing the outcome, and much less by describing how to achieve it.
The other way is that being free to select a stack lets you optimize for different things. Ruby on Rails is well known for how quickly you can develop with it. But it comes with the trade-off that its execution performance is poor. For us, time to market and ease of development usually mattered more. We can solve performance by scaling horizontally.
Other stacks make the opposite trade-off. They are harder for developers to work with, but the code runs more efficiently. That was C++ a while ago. Now, it is languages like Go and Rust. If I do not care how the code gets written, I would much rather choose a stack that is fast. Which is exactly what the HEY team did.
Who reviews the code?
So, do engineers still need to know the stack well enough to review what AI wrote? That is the biggest point of debate among engineers right now.
One school of thought is where our team leans today: Reviewing the code, understanding it, and being able to operate it are critical. And so the tech stack does matter, because we need to be experts to review code effectively.
But that is changing fast. The other school of thought is that this will not be relevant soon. AI will review the code, and it will review it better than people ever did. It does not matter what the stack is at that point — AI is an expert in all of them.
Starting something new
At Aha! our bet on the tech stack was made long ago, and we are unlikely to change that significantly. Moving a large operating platform to a new stack would be an unreasonable investment.
When starting a new project, the choice of tech stack is a question that needs to be answered, either explicitly (by leaving it to AI to choose) or by using a no-code platform (like Aha! Builder, where AI does the building, but in an environment where the stack is part of the platform that also operates the running code).
Choosing one stack and building everything with it is how we thought about things yesterday. Today, I care a lot less what the stack is as long as it gets the job done.
