Back in October, I mentioned that I don’t write TypeScript anymore. In other words, at the time, I still wrote programs in languages I knew well, like Go or Python. However, after a short and memorable winter break, when I started programming again, I found out I didn’t need to write those either.
Suddenly, I realized that last December was probably the last time I hand-wrote Go code.
Before the AI boom, this is how I worked: I wrote down the idea for something I wanted to build in a Markdown file. If it was just an initial idea, I’d try to articulate it well so that either the idea was killed after careful thought, or it was established enough to move to the next stage. Then I would lay out the detailed requirements. Once the document was written, I knew well enough how to build the project. The next step was converting those requirements into multiple cards in Trello, where each card might contain a checklist. Each item in the checklist was one small feature of the project, and I translated those items into code. Item by item, card by card, the project was built.
Of course, you’ll find this experience very similar to working in a team.
I still write the idea down. I kill the fragile ideas and write down the requirements when an idea is solid. Then I tell an agent to read the doc I wrote and ask it (it still feels weird to call it it) to finish the development.
The agent (could be Gemini or GPT-5.2) picks up the requirements.md and, even without asking too many questions, the work is done a couple of minutes later.
Even after months of working with agents, I’m still astonished by the process and the results.
Continuing with the previous example: usually, after such speedy work, you would question the quality. I did some tests and noticed some issues. I reported them back to the agent; the issues got fixed, but then another issue came up. Oops—we were in a vicious, endless loop. I gave up, sent the pull request anyway, and expected the PR review agent to provide some clues.
And guess what? It did. It turned out my original design was not sound. The design caused the seesaw issue. I changed my design, the agent fixed the issue, and it was done.
So, my coding agent did exactly as I told it to. The review agent pointed out the flaw in the design. I fixed the design, and the coding agent updated it accordingly.
I was the stupid one.
Just about three months ago, I still hadn’t felt a clear productivity boost; sometimes I still had to wrestle with the agent to achieve a goal. However, now, given their capabilities, building a sophisticated tool takes less time than a single trip to the toilet. No wonder the value of SaaS companies has vanished by more than $1 trillion (link). People are asking: is SaaS dead?
Let’s use an example. Writing a TODO app was the canary test for JavaScript frameworks back in the day. A TODO app is a classic example that looks simple at the beginning but soon becomes quite complicated when you want to polish it:
The list could go on forever. Complexity grows exponentially as you add more items. As the designer/developer, it’s your responsibility to manage that complexity at both the product and technical levels. Software can become bloated if you just keep adding features. When it’s bloated, it’s also brittle—it could break at any time.
While the sales and non-technical parts of SaaS are intimidating, we aren’t talking about those here.
From my observation, the hardest part of building a SaaS is the conflicting interest between the unique requirements of a few customers and the nature of any SaaS product: standardization. This applies not only to public SaaS but also to internal services serving as platform software for internal teams.
For example, if a team is building a container-based app deployment platform, they’ll usually choose Kubernetes as the orchestrator and develop some APIs on top of the Kubernetes API. It all looks pretty cool. The team expects users to use their APIs to run containers and serve production traffic. However, after a few production incidents—big or small—new requirements from customers start coming in:
These requirements are still relatively simple and can be considered healthy improvements to the platform. But experienced developers know that any feature requirement should be abstracted into a concrete new feature that can later benefit the majority of customers. In other words, you should NOT build a single feature for a single customer or a single scenario.
After some iterations, the product looks mature and stable. But new requirements keep coming:
Unlike the initial requests, these requirements are truly sparse. In other words, 100 customers might provide 80 different requirements. It’s really hard for platform developers to decide what is valuable to most people. In the end, it comes down to experience. Only people who have been in the field long enough know how to build a product that serves the most common interests. Usually, these people are deep in one vertical field, often in platform teams (or SaaS companies).
Similar to the previous example, just continuing to add features to the platform will surely make it unstable and eventually unusable. Experienced people know when and how to say no.
So, will SaaS die? I don’t think so. Complexity doesn’t go away. What’s worse, many complexities are hidden. You only discover them once you start building.
AI surely has enabled us engineers to build in ways we could only dream of in the past. Features that took us weeks or even months in the past now probably take less than an hour. There is no excuse anymore. That also means we have more tests to run, more documentation to understand, and the software becomes much more complex than before. Considering much of the code will not be written directly by us, understanding the software and maintaining it will become much more difficult.
But this is what engineers do. We tame the complexity and enjoy the process.