Of course Solopreneurs were a thing long before AI. It just takes special people. I think the assumption of this article is that there may be a larger array of people capable of running their own business with the aid of AI. I'm similarly leery of this for the same reasons covered in the post. Solopreneurs were generally technical people who had been forced to learn the business side after playing a senior role, generally a CTO or CEO, of a previous startup. They are "full stack" founders, who have deep understanding of the entire business stack, both on the business and technical side. These special people will likely be supercharged by AI, which they can intelligently direct to offload much of the grunt work, both on the technical side, and on the business side, especially for marketing.
I mean, it is possible, that, after verification, credits are added to the Fable usage from your existing subscription plan. Maybe not. But maybe yes. No way to know. And, remember, when Fable was first released, they announced that it was only going to be on the existing subscription plans for a short period.
I have 35+ years experience as a manager and engineer at large enterprise tech companies (what the kids now call FAANG, though some of the company names were different back then), and was a Founder, CEO and CTO at a $7M VC funded company and several other "differently-funded" startups.
Harsh take: AI should replace most middle management. It is the easiest part of an organization to replace. The people making things should mostly communicate about company strategy, cross-team issues, and job requirements with an AI. There should be a handful of high-level strategy on top of the AI. The AI should have access to all the documents for the company. The middle management should be put in a spaceship along with HR and sent off to another planet so the people who build things can just get stuff done. This will never happen.
Then you should be scared about every single online account you use, since they all have this same capability of suspension of your account. That's inherent in any service policy.
The economics work if you generate the video locally, using your own compute and a pretrained model provided for a fee. The compute bit is the expensive part. Local users could trade time for money. They just don't have a business or security model that allows them to distribute the model for people to use locally. Sure, you might need to wait all night for 10 seconds of video generated on your 4090, but you could do it, and folks might even pay for the privilege of using the pretrained model. Licensing for local compute might even pay back the cost of training the model with enough time and users.
> I was afraid the puzzle-solving was over. But it wasn't—it just moved up a level.
The craft can move up a level too. You still can make decisions about the implementation, which algorithms to use, how to combine them, how and what to test -- essentially crafting the system at a higher level. In a similar sense, we lost the hand-crafting of assembly code as compilers took over, and now we're losing the crafting of classes and algorithms to some extent, but we still craft the system -- what and how it does its thing, and most importantly, why.
Just saying "no" is unclear. LLMs are still very sensitive to prompts. I would recommend being more precise and assuming less as a general rule. Of course you also don't want to be too precise, especially about "how" to do something, which tends to back the LLM into a corner causing bad behavior. Focus on communicating intent clearly in my experience.
Yes, more time on up front spec and plan building. Bite sized specifically to fit within the context window of a single implementation session. Each step should have a verification process that includes new tests.
Prior to each step, I prompt the AI to review the step and ask clarifying questions to fill any missing details. Then implement. Then prompt the AI after to review the changes for any fixes before moving on to the next step. Rinse, repeat.
The specs and plans are actually better for sharing context with the rest of the team than a traditional review process.
I find the code generated by this process to be better in general than the code I've generated over my previous 35+ years of coding. More robust, more complete, better tested. I used to "rush" through this process before, with less upfront planning, and more of a focus on getting a working scaffold up and running as fast as possible, with each step along the way implemented a bit quicker and less robustly, with the assumption I'd return to fix up the corner cases later.
I think that comment is interesting as well. My view is that there is a lot of Electron training code, and that helps in many ways, both in terms of the app architecture, and the specifics of dealing with common problems. Any new architecture would have unknown and unforeseen issues, even for an LLM. The AIs are exceptional at doing stuff that they have been trained on, and even abstracting some of the lessons. The further you deviate away from a standard app, perhaps even a standard CRUD web app, the less the AI knows about how to structure the app.