I have few sticks in the sand in my thinking framework:
* writing code has always been the easiest part of building software, deciding what to do and what not to do is something else that takes forever sometimes
* there are several open source projects that can replace commercial SaaS and still people prefer to purchase commercial SaaS. These are available immediately, deployed immediately etc etc.
* along the same line, some of those open source projects offer self-hosting and cloud version: I would always personally go for the cloud version because in a small team I don't want to operate something that other people built and I don't know how to operate. That's not my job not my team job
* people are underestimating how draining is operating and maintaining software, which is something that goes beyond the adrenaline rush you get after "building" something with Lovable or similar tools. Also, I find it extremely easy to get 80% done quickly but excruciatingly slow to get things done right.
* I still see huge value in using tools like Lovable to build a working prototype and validate assumptions so that you get quickly build the right thing right solving the right problem in the right away avoiding waste
* camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
* same can be said for other things like restaurants, where sometimes it's more convenient (although expensive) to buy vs build.
> camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
tiktok alone has 1.5 million directors! it's just that we call them creators now.
the meaning of the word director has changed, that's all. but professional roles shift in meaning all the time. a computer used to be a literal human doing arithmetic. an engineer was someone who designed war machinery. being a doctor used to mean teaching at an university.
human beings are natural tool makers. we always have been. the frontier material to manipulate where the most advanced engineering happens constantly changes: stone -> bronze -> iron -> ink (descartes) -> steel -> silicon -> javascript (YOU ARE HERE).
notice how each step is an improvement/abstraction on top of the steps that came before it. some say english is next in that chain. i honestly have no idea. all i know is there will always be The Next Thing and it'll be much nicer to work with.
>people are underestimating how draining is operating and maintaining software
Yep. Many SaaS have an edge because they factorize the struggle of many customers, if a SaaS has 1000 customers, each customer vibing their way into a home-built solution will require dedicated efforts at maintaining it. Even with AI, those efforts aren't negligible.
Many companies don't even operate any IT infrastructure, cloud or otherwise, themselves, beyond office connectivity, AI replacing SaaS will require someone in charge of that at the very least.
> writing code has always been the easiest part
Let me provide some possible evidence against this: so many teams are desperate to rewrite their codebase but struggle to actually do so. And when they finally make the leap, it takes them 5x as long as they had hoped. Then sometimes the new code isn't even any easier than the old code.
I personally find writing code to be a huge time suck and I'm very happy that AI helps me save that time.
Most of a software project's lifetime will be spent as a maintenance challenge. i.e. How do we add the 237th feature without adding to the performance problems that already exist. Hence, the desire to rewrite the codebase to incorporate the abstractions of all 236 features.
I don't see AI helping with this. From my experience, it seems like the opposite. It can help you write the code after you've deconstructed the problem yourself and know how to keep it in check.
But again, how much of that time is spent writing code?
I've done rewrites, replatforms, a bunch of times. The actual programming is not the tricky part, but instead (1) picking apart the legacy system, understanding what to build, (2) orchestrating the work to shift transactions from service A to service B without breaking anything.
Teams and especially developers love to think they can skip that phase and just crack on with the programming, invariably what happens is the same as described above: intoxicating velocity followed by a hard stop when you realise you haven't solved problems (1) or (2) above
I reckon a lot of re-writes tend to take "them 5x as long as they had hoped" and "isn't even any easier than the old code" exactly because writing the code wasn't the problem in the first place.
It's business logic, edge cases and other small necessary details that accumulated over time which make the code 'messy'. Once you've integrated all those in the new system, it likely looks equally messy. And discovering and implementing all those extra requirements is probably what took you the longest.
Not to say this applies to all re-writes or that AI tools can't help the process
> “…deciding what to do and what not to do is something else that takes forever…”
If that’s the case, then I should think business owners and office workers should be able to sort that out, lestwise on the “how to automate the boring stuff” front. That repetitive, boring, time consuming, error prone work. Incremental, least work for greatest impact.
The danger is they pull a 1999 Mars Climate Orbiter —level mistake. Or their solution suite grows to big to manage with mounting tech debt.
Also, if you’re software also required some custom domain hardware, then there’s your bottleneck for protectionist business practices.
and also:
* several companies require their tool to have several certifications (SOC 2, ISO 27001 etc etc), how this will work with vibe coded tools?
I agree with your larger point, however:
> camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
That’s exactly what happened. There are more filmmakers than ever now due to the accessibility of cheap cameras, then digital tools, including affordable HD cameras. Especially once the DSLR revolution took off circa 2011, which enabled budget-constrained aspiring filmmakers to use prime lens sets rather than fixed/built in zooms on cheap camcorders. With proper lighting they could actually make something look pretty damn cinematic. The entire industry has radically shifted in the last 15 years in particular due to these changes, but it started to shift around 2000 if I have to assign a particular year to it.
When you had to shoot on film stock, which was expensive and had a whole processing pipeline that one couldn’t reasonably do at home, there was a much thicker barrier to entry. You basically had to go to film school or get into the industry before you could start making your own stuff. Hell the Duplass brothers started out on crappy camcorders. Now? A smartphone, some cheap LED’s, a basic computer, you can really make something.
My point was along this line: writing code is different than building a product as much as recording a video is different than telling a story with a movie (long and short that you want).
Do everyone has the capability to build a comprehensive set of features that we call a product to solve problems that people or business have in their life?
That’s why I’m always skeptical about measuring AI impact based solely on quantitative metrics.
Like I said I agree with your larger point. But it’s actually not a great example, because lowering the barrier to entry, particularly the hardware side, led to a massive increase in the number of filmmakers and films in the world. People telling full stories from start to finish included. The reason it doesn’t graft well onto the AI discussion is that the process and output are controlled and measurable. There’s no real black box element. What you see is what you get and the output of the camera is fully controlled by the user.