The authors rely on themselves, not other people. The developers of local first software take on the responsibility of making sure the app runs entirely on local resources. That's not the job of anybody else, and you don't need to pay for it like you do with cloud resources. This means it's cheaper for a startup to distribute local first software. The trick is that it's much harder to get paid for the app.
The reason it's easier to scale local software is that it does not rely on cloud resources. As a result it's cheaper for a startup to distribute local first software since they don't need the infrastructure of a traditional cloud app. The problem is there is no business model for local first software like there is for subscriptions with SaaS. Traditional desktop apps were sold as single purchase items on CDs. That just doesn't work for local first software, since you probably just navigate to a website to get the software.
Correct. SaaS is a business model, not a technical concept. But the real problem is that there is no equivalent business model for selling local first software. Traditional desktop apps were single purchase items. Local first is not because you just navigate to a website in your browser and blammo you get the software. What we need is a way to make money off of local first software.
Goal #2, your data is not trapped in a single device is the hard bit, especially with goal #3, the network is optional. For #2 to be true, this means the network is *not* optional for the developer, it is required. Thus the entire complexity of building a distributed app, especially one without a centralized server, which is particularly difficult even with modern local first database tools, greatly increases the complexity of writing this type of software compared to either traditional desktop apps or cloud apps.
What if education became research? If, in the hypothetical future, the AI can answer any question about any book or scientific theory, perhaps the educational system could focus on teaching people how to come up with good ideas to research, and how to do that research effectively? Rather than making the questions about historical information more difficult, or answering them in person or writing them in bluebooks, make the process of learning about how to create new knowledge? Educators would become people who teach you how to learn, how to design questions, and how to research those questions to produce factual answers. We've known lectures have been the worst way to teach for decades. Why maintain that failed system? If the reductionist goal of the college system is a degree that certifies you as an expert in historical knowledge, maybe we can just throw that away since the AI can handle that part now, and instead certify that people know how to ask the right questions of the AI, and how to interpret their answers to create new knowledge for humanity?
Unlimited vacation is in no way the same thing as 6 weeks of actual vacation. Look into it a bit more. You'll see that unlimited vacation is really just a scam. In your case it's worked out. Actual vacation days are tracked and part of your salary. For example, if you leave, you are entitled to the wages of your remaining untaken vacation days. Unlimited vacation is a favor that your manager is granting. The company is not obligated to grant your request. You have no legal right to take the days off as you do with real vacation.
The problem with unlimited vacation is that the majority of engineers never have the guts to ask for it, just like they don't know how to negotiate. Unlimited vacation is a benefit for the company not the employee. It avoids taxes and complications due to carryover constraints.
We're you willing to walk away if you didn't get what you wanted? Or were you just hoping they would capitulate? IMHO, The key to negotiating is knowing where your red line is, and being willing to walk away if you don't reach it.
Startups also have more non-cash options. E.g. they can offer more than 4 weeks of vacation, unlike many enterprise companies. As a CEO, when I gave people 6 weeks of real vacation, they would never leave, since they cannot get that at bigger companies in the US. (We also stongly encouraged them to use their vacation, because a healthy work-life balance is better for the company.) Startups also have more flexibility on WFH, travel options, and other non-cash benefits like providing more authority over your schedule and tasks. They are typically strapped for cash, unless they are not actually startups anymore because they raised $100M, and just like the moniker.
What's going to happen? Maybe it will help make the LLM better at code gen, and help everyone. I've written hundreds of thousands of lines of code that have disappeared into the void of history. It would have been nice if all that hadn't been lost.
If I had to guess, the reason WebGPU is not implemented in Linux is because nobody is paid to add features to Linux. This means that new features are delayed by several years. WebGL is old, and well supported. WebGPU is newer, and has less support.
If only it was exponential in the beginning, as word-of-mouth spreads. Sigh. The reality is that you need to claw and scrape your way to your first customers. The numbers vary depending on whether your product is b2b, consumer, or more niche, but the first customers are the hardest. You rarely get word-of-mouth in the beginning. Instead, it comes much later, typically after a long period of slow growth as you learn more about your customer's workflows and problems and adjust the product to get closer to PMF.
Or, O(n^2) companies are founded and run by people motivated solely by making lots of money, while O(n) companies are there for multiple reasons: passion for the topic, making employee's lives better, and helping their customers solve problems. Though those motivations exist at O(n^2) companies too, they are in the shadow of making money. While, at O(n) companies, money is also essential, but it exists to support the other goals. A slight shift in priorities can make all the difference.
Or, really, to say the unsaid bit out loud: there are lots of important considerations when taking a job. The author seems to assume that money is the only driver, when, for many top candidates, money is not their primary motivation. The ability to plan well and thereby reduce stress is a good measure of the management experience. Other non-cash incentives tend to be given out more readily at well-run non-enterprise companies, including remote work, longer vacations, and more strategic control, to name just a few.
Normally, with big-O notation, the goal is to reduce complexity. The author's wording kinda reverses that assumption only to "surprise" you in the end? A somewhat forced irony.
> O(n) companies can’t afford to hire the absolute best talent.
O(n) companies tend to have more experienced founders and engineers in my experience. This is partly why they have "nice deadlines, clear SoW" and "understand their customers" enough to have PMF. The strength of their talent, experience and job networks often greatly outweighs the cash incentives, allowing them to hire top candidates. They do not just hire "to fit a job description" because, since money was tighter, they are super conservative about hiring, have always done the job they are hiring for themselves for a long time, and know exactly what they need. It is the O(n^2) companies that hire for job descriptions that fit the positions the VCs tell them they need. I think your experiential datapoints may be too sparse.
Another way of saying this that might not trigger your alarm bells is that even a perfect image analyzer is not enough to replace a radiologist. The job consists of much more than just analyzing images.
It will be glorious! LLMs Will replace most managers and all executives. Developers will use their corporate AI to answer all questions from the outside world, allowing them to focus entirely on writing code. No need to talk to other humans, aside from other developers. Coders will develop lasting personal relationships with their IDEs. AI enhanced design tools will provide pixel perfect designs that users always love. Glorious.
I'd love to see things like Brokk experiment a bit more with what other information to include in our git repositories, besides the code, that helps improve AI-based code generation. For example, perhaps the repo should include more design information about the look-and-feel, as visual information or Figma files, rather than just, say the CSS and HTML. Or it might help if the repository included more business requirements so that the AI has better information to guide prioritization of changes. Obviously other bits, like coding standards, should be included as well, though perhaps using a larger context might mitigate the need for coding standards if the generated code followed the existing code (which often doesn't happen).
I am a huge supporter of completely re-working the IDE UI as well. I'm not arguing for keeping the existing IDE interfaces. I like that folks are experimenting with entirely new interfaces. In fact, I'd go further and suggest that all of the overly complex interfaces used on any sort of content-creation app, like Unity, Unreal, Photoshop, as well as code IDEs, will eventually be completely refactored to remove all the old complexity in favor of either chat-based or other AI-driven interfaces. My point is simply that there are too many new AI-driven IDEs for folks to try out, even the developers of those IDEs. Many of the features in Brokk that were seemingly described in the Brokk 101 blog video as "differentiators" are existing Copilot features. Has the author ever used Copilot? Or just Cursor? Or another AI variant?
The "Read" file list sounds a lot like Copilot Edit mode, where you manually specify the list of files that are added to the context. Similarly, Copilot has an Ask (Chat) mode that doesn't change the code. One of the downsides of all these new IDEs is that it is difficult, even for the developers of those tools, to have enough time to test out coding in each of their competitors. Also, the switching cost of changing IDEs is pretty high, even if they are forks of the same code base, which makes it hard for the users to really test out all the options. In the long run, I expect that the "larger" IDE providers will purchase the smaller ones. IOW, if you wait long enough, all the good bits will be in Copilot (or maybe Cursor with their new funding).
It is exceedingly rare that voting shares play a role in any of these decisions. When you need cash to pay salaries, the decision lies in the hand of the stakeholder with the cash, not the shares.
At a smart business, you work for your customers. If you're at a company that works for your investors, you're going to have this problem over and over again. In fact, you might as well give up on the idea of planning and decision making based on what would be best for the product and your customers.
The problem here is that your company is on the "get the next round of funding" train instead of on the "get revenue from customers" train. It's a bigger problem then irrational love of AI. You will consistently sacrifice the product and your customers in favor of whatever people think will get you the next round of funding. If you manage to solve your current funding crisis by convincing some investor that you have an AI plan, don't worry, you'll have another crisis in a few months.
I've always found ecards to be insulting and never read them. The article has nothing to do with financial commitments. It's about time, a much more valuable and limited resource.