The assumptions we made about code always led to the biggest issues. If you assumed a junior engineer, or even a senior engineer not familiar with the local practices, would not make certain mistakes, then those mistakes always slipped through. If anything, the AI makes us be _better_ reviewers, since we need to check more of our assumptions at the door. I used to check the compiler assembly output, in case I could optimize it either by hand, or by changing my code to use a do-while instead of a for loop. I don't do that anymore. The same thing is happening with AI-generated code. I used to have to check it all very carefully, and regenerate code when the AI chose to add a whole new mechanism to the code base rather than re-using an existing mechanism, to keep the code solid. That happens less and less, and soon, it won't make sense to read over the code at all. Maybe in some specific circumstances that will be necessary, but less and less overall. And that's ok. We have moved to higher and higher levels of abstraction over the decades that I've been coding, and each time we can take on bigger problems and invent new things.
I suspect the net result will be that more Pro $100 subscribers upgrade to $200/mo. If you explicitly do simpler stuff with Opus, you generally have enough Fable time for most programming and planning tasks.
A product is much more than the software and its reliability. The business side is just as big of a lift. You need to build a business, not just a product. A business includes understanding the value proposition, not just a potential solution in the form of a tool. It includes understanding how the software fits in to the target customer's workflow, and how it provides real value. You need to be able to communicate that value proposition to the customers, investors and your employees, amongst other stakeholders. Later, this transforms into understanding the sales cycle and how to use marketing to grow your users. The business side has always been the hard part. Software was always easy to build. The hard part is knowing what to build that really provides value.
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.
Thanks for the performance info! More recent Apple chips get much better performance. Also worth trying the Fast quality setting. Great suggestion about default camera positions. I'll add that to the to-do list. Love the idea of a blindfolded chess app with voice control.
Here's a dawn implementation with support for ray tracing that was implemented a number of years ago but never integrated into browsers. Perhaps it will help?
Yes, chessboard3d.app is written with raw JS APIs and raw WebGPU. It does use the rapier physics library, which uses WASM, which might be an issue? It implements its own ray tracing but would probably run 10x faster with hardware ray tracing support.
I think you'd get a lot of attention if you had hardware ray tracing, since that's only currently available in DirectX 12 and Vulkan, requiring implementation in native desktop platforms. FWIW, if the path looks feasible, I would be interested in contributing.