I'm often curious how well the arena approach works for highly dynamic graphs. You end up having to reimplement the ref counting or a custom GC, which carries more risk.
Even memory locality of a arena doesn't provide benefit, because memory order does not mirror execution order.
It is full of these short sentences that AI writing loves, sort of to feel "punchy". Normally you would copy-edit that stuff, join them up, have the writing have some rhythm. I agree with GP, the article is hard to read because it seems to have a lot of https://tropes.fyi/
Twitter is full of strung together short punchy sentences, and it spread to articles long before AI.
Not discounting the possibility that it's AI, but it didn't have the same repetition, contradiction, and inaccuracies I notice in other AI content. Though even that isn't exclusive to AI.
Try for too much impact, and you end up browbeating the reader until they're little more than metaphorical pulp. A human writer might like using those types of sentences--or any of the obvious LLM writing tropes--in specific contexts, but they'll usually recognize the need to avoid overusing them.
LLMs don't, and so the tropes get repeated ad nauseam. It doesn't help that social media posts are a huge part of their training data, and there's a large body of research on how Twitter and social media in general have altered grammar and sentence construction towards patterns more commonly found in oral-based traditions as users sought out ways to make their voices heard.
It's easy to imagine a more polished version of a line like "It's not X. It's Y!" being tossed out during a speech precisely because it can be dramatic and punchy. When it's done in every other paragraph, however, it can become rather disconcerting.
People are losing their ability to reason without prompting an LLM first.
It's affecting their ability to collaborate. They retain the confidence of years of experience, but their brain isn't going through the appropriate process anymore to check their assumptions.
I've seen a similar thing happen to engineers who move into management, but this is now happening at such a large scale.
It's much more than a management problem, experienced software engineers are actively opting into apathy and atrophy of their craft.
I see many peers getting worse in their abilities. It's especially disheartening to see people I admired for their problem solving devolve into someone who delegates more and more of their reasoning to LLMs. It really negatively affects working with them. If you have a concern or criticism of "their" approach to a problem they either dismiss it off hand as invalid, or they go discuss it with their LLM of choice making themselves a bottleneck to collaboration.
As the article suggests I suspect we're in for a real dark age of software as companies struggle to know who to keep, if they can even trust that those who have vital knowledge and skill today will retain it going forward.
This is my take away too. I see some interesting toys here and there, but not much of substance. Meanwhile all the GitHub issues I follow for open source projects have slowed to a halt, the products I use have no significant updates. Even AI products are slow to improve their interfaces.
It's a nice sentiment to say use HTML (or HTMX), but often the people that push for that either don't know enough HTML to know how broken the spec is, or they don't know enough about the requirements of modern web applications.
If you're making static blog or landing page with HTML you won't hit many of the bad parts.
There's really no chance of fixing the HTML spec though, despite the many attempts, which tend to make it worse. Many of the framework authors know this, and in part that's why they've chosen such a user-space heavy path. It allows working around the bad parts of the platform, and iterating in ways where ideas that don't pan out can be left behind.
Security through obscurity can be a good security layer, but you need to maintain obscurity. That's a lot harder than Cal.com seems to realize.
For example using something like Next.js means a very large chunk of important obscurity is thrown out the window. The same for any publicly available server/client isomorphic framework.
Exactly, that's why most Saas companies are in a very tough position.
You have to bring value that goes beyond the source code and hosting, otherwise your clients are going to vibe code a custom solution instead of paying you.
> otherwise your clients are going to vibe code a custom solution instead of paying you.
How many things do you want to be responsible for? How many vibe coded projects do you want to maintain?
I think this line of reasoning is overblown. Just because you can doesn't mean a significant number of people will. I think the 3D printer comparison is apt.
Same story as always, writing the code in the easy part. Requirement gathering, analysis, consensus, direction, those are all the hard parts. Enterprises have a business to run and don’t want to run a software shop on top of everything else.
The story is usually that businesses don't want to commit to indefinitely expending their limited efforts maintaining software which isn't part of the company's core competencies. Most of the cost and effort of software happens after the first release is delivered.
> Enterprises have a business to run and don’t want to run a software shop on top of everything else.
It sounds like you mostly understand here. The biggest part of "running a software shop" they want to avoid is responsibility for support, bugs, fires, ongoing maintenance, and legal issues, of post-release software.
Dave's Pizza around the corner doesn't make a social media app, not because Dave can't figure it out, not because he can't vibe code one, not because he can't contract someone to do it, but because running a social media site isn't a core competency of Dave's Pizza. Instead, Dave uses existing social media sites, and focuses his efforts and passions on making pizza.
So I work in enterprise tech. consulting, my current project is with a large, global, chemicals company (it wouldn't be right to call out my client by name). This client is extremely competent from their multiple enterprise architects down to their analysts, they're a pleasure to work with. One of the business requirements could be met by a very simple in-house developed and hosted API, it's a perfect use case for GenAI assisted coding too. There's no magic, it's a problem solved over and over already. However, they don't want to touch inhouse dev with a 10 foot pole for the reasons we're both talking about. They don't want to support it, extend it, back it up, monitor it, and all the other things that have to happen after the code is done. They're perfectly happy to buy licenses from a saas so if anything goes wrong they can tell the CTO "it's not me, it's them". And when the CTO says "why doesn't it do this too!?!" they can say "i'll call our rep and ask".
saas value to an enterprise is more than just the functionality provided and I think that is lost on a lot of the heads down software devs here.
They are, and always have. Looking over "software engineer" roles in my local area, I see folks at companies in a variety of industries: finance, health, logistics, health care, and the local power utility, all well outside the software industry.
Most enterprise companies don't develop everything in house, but usually do have a varied mix of in-house infrastructure, IaaS and PaaS solutions, and SaaS products. Large organizations across varied industries often have multiple internal dev teams, and the availability of increasingly sophisticated AI tools is going to enable the same teams to be effective at more, and more complex, projects. AI will definitely start shifting make-or-buy decisions, especially for mature, commodity use cases, to 'make'.
I don't think it's much cheaper. Writing some code to do some CRUD has always been easy. Getting to a proof of concept is definitely quicker. But creating something that can be relied upon in production? That's as difficult and time consuming as it has ever been.
Yup. I've explained it as okay, some software is free as in beer and others are free as in speech. DIY software is free as in yacht.
It sounds nice, but now you have something that takes an enormous amount of time and effort to use and maintain, plus you need to have someone with the skills to run it.
They won’t, because specialization is a key aspect of capitalism.
This is why companies outsource anything. Google, Inc. is big enough to own farms and ranches to grow the food eaten in its cafeterias. They could make trucks to transport that food. They could operate factories to make cutlery, etc. Why do they instead choose to pay layers of margins to layers of middlemen?
Absurd example? How about Apple? They outsource production of their chips, instead of capturing the margin they are currently gifting to their partners. Why?
Delta Airlines doesn’t operate oil fields or even refineries even though a major cost of their operations is jet fuel. Why?
Once you can reason through these very simple examples, you will understand why enterprises are unlikely to walk away from SaaS.
s/Delta/United/ or s/Delta/Southwest/ or s/Delta/Lufthansa/. Or if you prefer, s/refinery/oilfield, or s/refinery/pipeline. Or even s/refinery/farm/ because Delta also buys food in vast quantities (I would not be surprised to find they have interests in ag producers that offset a small % of their food purchases, which does not diminish the argument).
Delta also does not make airplanes, jet engines, seats, radios, GPS, glass, or even wires. They don't distill the spirits they serve on their flights. They don't own and operate a satellite Internet capability. They don't even make movies for in-flight entertainment.
The point is that Delta, like most successful firms, outsources key aspects of core service delivery.
The second article you linked says plainly that the refinery is an offset/hedge. QED Delta still outsources the vast majority of its fuel costs. (They could, for example, own large swathes of the Permian and do E&P as well. They choose to leave that to others.)
Vertical integration has been a common practice in industry for 150 years.
Yes, very few firms fully control their upstream supply chains, but very few conversely produce nothing but their core market offering in-house. Most companies are somewhere in between, doing some things in-house, and obtaining other things from vendors.
Most large firms have in-house software dev teams responsible for at least some portion of their development work. I know software engineers locally working, variously, at banks, pet supply distributors, power companies, soft drink bottlers, and many other non-tech industries. And AI can and will extend these teams' capacity to internally manager larger segments of their companies' tech stacks.
> How many vibe coded projects do you want to maintain?
here comes the next SaaS idea - vibe coded services as a service. You tell what service you want, may be point out a couple examples, and you get that service vibe coded and hosted for you for a small monthly fee!
I agree with the other poster that mention this is likely a publicity stunt but all it's really showing is that VC is still incredibly stupid with their money. All the more reason to seize it from them then properly fund useful software and not subsidize vanity projects for stanford grads.
About the friction, not the capabilities...I haven't switched off my biz calendar/appointment provider I'm paying for even though I've kinda outgrown it.
Email is actually a excellent example of something with network dependence. Changing email providers requires that you change your email address too (unless you own and use your own domain). An address change causes friction from having to update the network of contacts and services which used your old email address.
I might be in the minority, but I think the best way to learn how to write a compiler is to try writing one without books or tutorials. Keep it very small in scope at first, small enough that you can scrap the entire implementation and rewrite in an afternoon or less.
Even memory locality of a arena doesn't provide benefit, because memory order does not mirror execution order.
reply