I have noticed that many of the AI generated slop posts intentionally contain grammatical and spelling errors. Sometimes missing or inappropriate words. Clearly this is intentional and designed to make it seem more like a human wrote it, when obviously it was an AI.
Exactly. Do not use blur to hide information. Blurring simply "spreads out" the data, rather than removing it. Just search (you know, on Google, without an LLM) for "image unblur".
Though we seem to disagree, perhaps less than you might think, I'm very happy that my comments made you think for so long and write so much in response. It will be interesting to see how this all plays out over time.
While a co-founder can help, it can also ruin everything. As you say, there are other relationships and ways of interacting that can easily fill the same role, ie. advisors, board members, customers, etc. Statistically, I think that co-founder infighting is one of the largest reasons why many startups fail. It's also a fantastic way to ruin friendships.
That's an excellent list of positive strokes. I wanted to punch up your bullet on talking to people. Face to face is always better. It pulls me out of the void. Rather than chatting on text-based social media, set up video chats. Going to small conferences in your market is a great way to get a boost of energy. If you're good at it, you can even get a few customers. Seeing the emotions on the face of the person I'm talking to really helps boost my energy.
I've been writing code since before GUIs existed. Last year, many, probably most experienced programmers were skeptical about using LLMs to help write code. This year, there are vanishingly few who don't use an LLM every day. Words are easiest for LLMs so programming changed first. Images, audio and 3D are next. It really isn't a question whether the change is coming, it is just a matter of time. And, change is coming faster and faster. It isn't perfect, but it is getting better at an alarming rate. It is just a new interface, not a replacement. The new interface allows you to iterate in different ways to produce a result. It isn't about providing the right magic incantation and having a perfect result. Like with current tools, you iterate, taking bigger steps each time and as you learn how to better use the system.
Because what you describe in the chat has a much more significant impact. Sure, you could mimic each little mouse click and short cut, or you could say "make the arms longer", or "write a test for the new endpoint".
AI chat will replace the huge number of menus and complex interactions in many content development applications. In VSCode, for example I rarely touch 98% of the UI anymore. I just use Copilot. I no longer need large, complex chunks of the IDE, like the old refactoring code, or the formatting tools. Similarly, in 2D and 3D content creation, isn't it clear that we'll move to some iterative process using AI chat instead of millions of mouse clicks? There are clearly still issues with this, but there were issues with the early GUI tools too. I think huge swaths of complex GUI interfaces will disappear over the next few years. I know many folks who have spent decades in the VFX industry learning how to use Maya, video editors, paint tools, and proprietary tools, and lots of developers who built custom pipelines who might think it will take a bit longer. But it is coming for sure. Maybe you can optionally use voice, but that's not the important bit. This feels like it is going to be a significant shift in how we use computers, and it is already happening.
There are many customers that care about owning their own data. Despite what you might think, there are lots of companies that do not trust sending their data to the cloud. In addition, there are lots of companies and individuals that have all their data local, for a variety of reasons (often security) and primarily use desktop applications to work with that data. The "vast majority" may never care, but the compliment is still a very sizable market.
I would love to see another way to deploy local software, aside from building dedicated Windows and MacOS apps. There are efforts in the Docker container world to provide smaller deployment frameworks. There are efforts in the WASM world to replace containers with WASM deployment (which works well in browser, BTW).
Those are good points, but, of course, until your platform takes over the world, I would argue that browsers are not going anywhere, and work now, bearing in mind the corner cases you mention. Seems to me that fixing those persistence issues is easier to do by improving, rather than replacing, browsers.
If you use a local, browser-based database, and allow your app to be installed as a PWA, then you are ejectable? The only "server" is just a host for HTML+JS that your browser automatically downloads when you visit the site. The app runs locally, like a desktop app, inside your browser. No need for the items listed in the article.
Future code bases will contain more detailed specifications, design documents, and company guidelines and the code will become more of a byproduct, generated as needed. I already do this more and more with my LLM config files. This has already happened awhile ago with compilers replacing machine code and more recently with open source libraries replacing proprietary code. So, yes, more "intent" based documents, which represent a higher level abstraction of the problem.
Developers are either forced to track their time, or their time is tracked for then by the company for a very practical, but stupid reason: taxes. There are R&D tax credits, at least in the US, that require a breakdown of developer time. There are consulting companies that spend their time preparing these reports for startups and larger companies. It's serious and stupid. At least in many cases, these reports are not used to micromanage, they exist to get free money.
Writing code is easy compared to supporting, debugging and enhancing code. AI is much better at "greenfield" coding where you start from scratch, either on an entire app or a new feature. For anything non-trivial, it is terrible at debugging. At best it is a super-rubber-duck that is nice to talk to that might have a few words buried inside screenfuls of text that help a human realize what might be going wrong. We're still in the honeymoon phase, where AI has only written new stuff and hasn't been around long enough to have to support code with tens- or hundreds-of-thousands of LoC.
Apple should Open Source its OSes and internal apps. Of course this is very NOT-Apple, but it would allow folks to fix their apps. There's really no advantage to keeping it all proprietary. Apple's software teams are completely under water whereas Apple customers are diehards and would gleefully help fix issues. It would avoid the need to reproduce problems internally prior to ranking their importance for the internal team to fix. Besides, MacOS roots are in Open Source.
Your criticisms seem to attack the less important bits. If Marcus' view was the majority opinion, your comments might make sense. But the AI and AGI hype is everywhere, and we need a great deal more of "correct-but obvious" commentary to pierce the hype bubble.
If you just want to display pages of mixed text and images, it would be much easier. However, browsers are closer operating systems, capable of supporting rich desktop apps, without the antiquated desktop APIs. Browsers have more sophisticated security than desktop systems, and provide direct access to hardware resources like cameras, microphones and GPUs. In fact, webGPU would probably be considered a much better interface for GPUs than the desktop APIs like DirectX, WebGL, though maybe Vulkan is just as good. Browsers are also forming the basis for WASM development, though there are other deployment platforms, browsers are the biggest.
The answers to your questions come from your customers. Spend your time reaching out to customers and talking to them one-on-one. Do not tell them about your product or technology. Read "The Mom Test" to learn how to ask the right questions. Most importantly, listen. Talk to a few dozen. Look for patterns. Try and understand the value that you provide to your customers. Understand how your product makes your customers more money, or saves them time or money. Learn how to communicate that value proposition clearly and concisely. If you think that finding and talking to a few dozen customers is hard, selling to them is even harder.
Startups are a terrible way to make money. It is far far easier to make money at a larger company than it is at a startup. It's even worse if you start the company yourself. The chances that you'll ever make money are pretty small, and getting to a regular salary can take 3-7 years. Even the chances of making life-changing quantities of money are much smaller. I've been working in this industry for 40 years and all the people I know who are rich did it at big companies, most recently at Nvidia, earlier at Apple, Sun, Facebook and similar. I know tons of startup founders. Almost none of them made significant money. It's more like authors and artists - start a new company because you are driven by an invisible force and you want to do things that you can't do anywhere else. Maybe you want to run your company differently. Maybe you want to work on something that nobody has figured out how to make profitable. A great reason to take a job at a startup is that you like working with small teams and You think you can learn from your coworkers. Do it because you have no other choice, not because you want to make money.
This discussion is not about technology. It's about technical people learning that business, product and users are actually important. The best advice I can give technical people about working at startups is that you should learn everything you can about business. You can do that at a startup much easier than at a big tech company. Spend as much time as you can with your actual users, watching them use your product. It will help you communicate with the rest of the team, prioritize your technical tasks, and help you elevate your impact.
Simple, obvious answers appeal to a broader, less-knowledgeable set of people. In fact, it really doesn't matter if there is any basis for the answer, like a lower-dimensional approximation. If repeated enough, more people tend to believe the simple, baseless answer. I feel this is a bigger issue these days than needing to use more complex answers among people who understand the complexity of the problem.
The underlying problem here is best fixed by engineers learning just enough about business to start their own companies, without the people that think of them as overhead.