More generally, it's weird. 10 years ago, the technical aspects would legitimately be seen as a major, perhaps main obstacle to building a product. It's questionable whether that is really gone (can you really, really build a software product now with just LLMs? With deployment, security etc).
But for sure the technological bar is now much lower, it might disappear altogether, and what remains is actually finding a useful product, marketing, finding clients etc. Which I'd argue were actually always the biggest step to overcome.
Yeah I think that this was really more the advancement of frameworks, tooling and SaaS software. I see it all the time with non-technical people at work who demo something they built with LLMs and its always Next.js, Supabase and Tailwaind that are actually doing the heavy lifting, with the LLM invoking some commands for them. This all gets attributed to LLMs though since this is often the first exposure to those tools for non-technical people. Most engineers also knew how to scaffold a SaaS with Rails, Django or Next.js, Stripe etc. without writing much code.
Most web engineers do, certainly. But I work in data, so I didn't. And for me, LLM based tools have made it much, much easier to build relatively simple frontends for my data stuff that make my life a lot easier.
I'm partial to the notion that LLMs don't really raise the ceiling, rather they raise the floor by making web n00bs like me more effective at shipping stuff that can be used by others.
To be fair though, I'm much handier at Django now than I used to be, and am slowly learning JS/browser stuff as a result of these projects.
Yes! VCs want to make it so cheap and easy to build that you don’t need VCs anymore!
he would be extremely pleased to pay for (and have to listen to the complaints of) far fewer programmers.
Social media is, paraphrasing Jon Stewart, ultra-processed shit that's not good for most people.
Hey, who wants to start a project for CEO.ai?
[edit] also any interaction with storage / database isn't fun either, unless you use some ORM frameworks, and then you have some even bigger problems.
but it definitely rhymes.
Then a lot of things about the way code should be structured can change. If you're not editing by hand, and want to limit the scope of changes, and have AI tools to make future edits faster... THEN you can have a lot of redundancy in your code. You can just not have complex code that shares responsibility and instead have redundant repeated code that solves one problem differently.
It's not what I would advocate for every single part of every program, but many things now make sense to be structured in this way. Separate out concerns way more, and not try to have complex solutions that solve many problems at once, and favour repetitive code slightly more.
Much as you would structure a project if you had some junior programmers, you might have sections that only seniors should be touching - complex cores and difficult parts where you have way more oversight. And use more AI in the areas where you'd let juniors do scut work.
A. you are doing this "full time"
B. Know what to build
C. More importantly you know "how" you want it built and you push the llm to refactoring regularly in your style.
I don't buy into the "let the agent code for 6 hours straight" agentic nonsense. I review every (big) change and just saving me stackoverflow/Google visits has been a huge productivity booster. Heck I wrote css, proto plugins, dsl parsers, simple games and more because now I needed much less "onboarding" times.
Ask your AI to write tests and to review the code, of course /s
> And, what kind of solution needs 10,000 lines of code added to it daily?
In the first days, adding 10,000 useful lines a day can be very helpful. It means you get your MVP out earlier and/or makes it way easier to experiment with different ways to solve a problem.