> Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP.
> Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
Somewhat agree. Five years ago you could build an MVP without understanding how to open TCP sockets or how to parse HTTP headers. You didn't need to understand relational databases, let alone B-trees or cache locality. You didn't need to know how to install Linux.
Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
> You have to intentionally build your understanding as you build your projects.
Some things you need to understand-others, not so much. Depends on what you're doing, the scale, risks, etc, but that's always been the case.
> Some things you need to understand-others, not so much.
This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished.
You need to understand the abstractions, but also where they leak, when they won't match reality, and how. This is why knowing computer architecture and assembly helps you to optimize your code even if you are coding in a high level language.
The problem with coding agents is that they are tuned to work on all contexts so they always fill an underspecified request by optimizing the average case and often without stating all the assumptions that they make. So you still need to understand what you specified and what got filled in automagically by the agent. My experience is that they (even the paid frontier models) are poor judges of the most important assumptions they make, which will might be corrected by a prompt or a tool output in which case it is fine. Otherwise it will be ignored and steer the model into a weird loop. It then tries to fix things but can not do so since its mental model is totally broken now.
Do not get me wrong, I am so happy to let the agent handle tool building (especially those that involve a web UI) and fill in the CLI command line argument parser. But every time I trust the agent by relying on it to drive the mental model of what we are doing, I got seriously bitten. Well, maybe that should not be surprise me, but I can understand the confusion of less experienced programmers and non-coders. It must really be frustrating to be able to build so much, but also not to be able to fix seemingly small issues.
I'd like to add: we can't know a priori what will be needed to be known and what can safely remain behind an abstraction you just use.
That is revealed when our mental models grind against reality. Avoiding that friction at all costs is a problem because it will happen and you'll be unprepared when it becomes unavoidable.
Trusting some abstractions that have earned it but not all is how we deal with it. Limit your focus, and adapt. If you just trust all abstractions thrown in front of you until something breaks irreparably, you will be (person or organization) between a rock and a hard place and without any knowledge or skill on how to get out of that predicament.
That to me is the biggest risk in accepting the fallacy of general automation.
I’m in two minds about this, in some sense they did and it’s the same way in which the C code I write is mine, but the assembly underneath is an artifact of my intent, but I owe the compiler authors for it. On the other hand the cognitive distance between my C and the assembly is likely lower, but that’s because I’ve spent time staring at what was generated in order to figure out why my code was misbehaving. Which is itself not that dissimilar to figuring out how to get better at writing code with llms.
There's a pretty significant difference there, even in some of the examples you picked to make your point. TCP and HTTP are well defined standards that, for all their flaws, were designed and conceived to be useful abstractions that you didn't need to understand deeply in order to use. The things that LLMs allow novices to skip nowadays aren't designed with that in mind, and generally aren't something you can just skip over without getting yourself into hot water later. If you mess up Stripe or Auth0 setup because you don't understand the implications of the boilerplate the LLM spit out, you can very easily get your whole app compromised or end up on the hook for a lot of fraudulent credit card charges, etc.
I see the point you're making and I don't entirely disagree, but I think current iterations of LLM coding tools still make it far too easy for beginners (or even fairly experienced engineers) to convince themselves that a detail falls into the former category of abstractions they can safely skip understanding, when they're very much the latter.
That’s the power of abstraction when there’s a good API around something to hide the internal that doesn’t matter much at an higher level. You only need ‘open’ and ‘read’ instead of dealing with disk access and file system trasversal.
But those abstraction are deterministic in nature, so there’s a very good guarantee of their behavior. Someone using LLM and not caring about the generated code is just asking for trouble. The code may work, but there’s no guarantee about its behavior (including error handling and edge cases).
non deterministic abstraction are absolutely useful, outside of software sector they have been used since the start of civilization ("a worker" is a very very non deterministic abstraction, outside from the most basic tasks)
> "a worker" is a very very non deterministic abstraction, outside from the most basic tasks
Sure but we (usually) don't fool ourselves into believing otherwise. The problem with AI is that it suggests near-perfect intelligence with reproducible results. So many people are not acknowledging the fundamental limitations of LLMs, whereas we all have an intuition for the limitations of humans.
I’m sure that in every case where there such non deterministic abstraction, it’s been always statistically or with a lot of hand waving. So with a heavy dose of expected errors.
Pro LLM users don’t want to talk about the error margins of whatever practice or product they’re putting out.
> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases).
But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden.
My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
This is exactly true in my experience. I find myself trusting the LLM better than I ever trusted a development team to deliver accurate work. Just like you would managing a team of junior developers, you have to keep an eye on the output, but I think the agent is more transparent about that than your team would be. And it works faster, and you don't have to deal with emotional meltdown or active sabotage if you criticize in the wrong way.
The trick for the guy controlling the agent is to know about the gotchas that one would normally encounter when doing the work. Asking the right questions and mentioning the right things to pay extra attention to can make all the difference.
I think that's why it will be much more difficult for people to learn how to make software now. Those of us who have been doing it for years and years have experience that is valuable in steering the LLM. It will be hard for people new to software to get that same experience. But then things are changing so quickly right now, everything I just wrote my be irrelevant in a week.
> find myself trusting the LLM better than I ever trusted a development team to deliver accurate work
That’s the main issue. You’re talking about the development side guarante, while the most important is the user side guarantee. There’s a lot of talk about liking LLM interaction, but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets.
Which is why the most enthusiastic comments are about projects not released yet. Greenfield and released projects are different.
> but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets.
Here's someone's breakdown (with some things from the full report that aren't in the Faros blog post), showing how it's even worse than first impressions: https://unessays.substack.com/p/talk-is-cheap
> it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
What makes you confident the Microsoft and Google software isn't vibecoded slop?
Certainly Microsoft has made a lot of noise about all their software being LLMgen these years, and also gotten into hot water with their users for Windows 11's crappiness.
>My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
As in you get more mad at software you actually use being broken than software that you aren't using and just exists in blogposts?
I personally work a lot with vibe coded software, both my own and of others. And I do encounter a lot of issues, but in general they annoy me less than the enterprise engineered ones.
>Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
Ehhh, if you're smart you want to at the very least gloss over the details, and look at the code being generated by whatever model you're using for this solution.
Miro acquired my startup back in '21[0], so this is bittersweet as our users will be (eventually) affected by this. Founders and employees at Miro definitely deserve to cash out for their hard work and it's unclear (ie. not publicly known) if they will since this is a 10x down round.
Also weird that they had to sell - they were one of the most established (visual) collaboration platforms out there. I'd be keen on learning about the inside story if it ever gets public.
BS is known for aggressive management of companies they acquire, optimizing for cash flow and revenue, firing most/all of the original team, etc. Their acquisitions before Miro include Airtable, Eventbrite, AOL, Vimeo, Meetup, Evernote ... for at least a few of those, my direct experience with the product afterwards or in chats with their users, the platforms does get enshittified.
Do they even have the moat to pull the same sort of playbook with Miro? We used to use it for remote retros and whiteboarding, we ended up not renewing because we were already paying for Lucid and there was little added value.
I'm curious to know if it was ever as embedded as, say, Jira is, in some companies.
Maybe not to the same extent. In a company I worked with recently they used it a lot but didn't store data in it, meaning there was very little lock-in: mostly inertia/convenience.
If BS slightly raise the price and ruthlessly cut costs (think - leave just a skeleton crew to keep it running), the calculation may make sense even if there's slow churn in the users and no special lock in.
(disclaimer: pure outsider speculation on my part)
I know a lot of people who used it for one or both of these. Also for architecture/system design (ie. not UI - although I guess some used it for user journey or wireframing).
Yes, it's not a scientific benchmark but it's a good heuristic.
For a better eval, create a one-page prompt / mini spec related to whatever you're using the LLMs for, and see how well a particular one works for what's important to you.
I really like these tests for what its worth and I see them on youtube sometimes. I would like to ask a few things though
TLDR: Basically focusing on recreating pay to win (mobile or otherwise) games and recreating them non pay to win perhaps instead of focusing on recreation of minecraft for benchmarks could have a genuinely meaningful impact, and making these games portable as well could be another interesting idea. [so it can be played on any operating system/device so using web or if native then for (Android/IOS/Linux/Windows/MacOS) using game engines like (Preferably godot)/Unity/UE.]
Could the test focus more on pay to win games with unique dynamics.
For example: I literally wanted to create a clash royale recreation because clash royale is a highly pay to win game.
The game is unique enough to have memories but is pay to win enough that it ragebaits me as to what its current situation is, its so pay to win now. A recreation would have genuine effect whereas yet another minecraft clone wouldn't.
I have some fond memories of the game and my brother and I used to play it (my brother moreso than me). Also clash of clans and clash royale famously prevented windows users. So I remember downloading bluestacks to play it on laptop but it required 2GB of ram and back then we only had 1GB. (Ironic that we might come back to that time)
Another question that I have for you which I have been genuinely curious is: who is footing the bill for these benchmarks and youtube videos. What are the economics surrounding it?
I imagine the bill to run quite hot sometimes and I find running these benchmarks to be quite unaffordable personally.
I also wish to ask if you have any theories as to why not people on Youtube share their videos. I found this [0] Minecraft clone by Fable 5.1 extremely good yet they haven't shared the source. I am unsure as to what exact reasons might be behind most youtube videos on recreation with AI to not share the actual code. I don't find much rationale in not sharing AI generated code of a recreation of a game especially if one is making a video about it. So thanks for once for actually sharing the output code as well as I surprisingly found it to be a bit rare!
I'd make a distinction between youtubers who are incentivized to dial their reactions to the max for everything[0] and people doing silly tests but keeping their expectations and reactions real (most famously, Simon's pelican test).
As to why the prompts aren't shared, for these more complex things it's most likely a somewhat messy process (ie. not a single-prompt one-shot creation; some back & forth) that would make the whole thing seem less spectacular.
Likewise for the end result - it's probably cherry-picked what works well. For example, in Claude models' resuts I always get stuck in water (something about height/jump calculations is off), where with Astra I didn't have that problem. These sorts of issues you can only spot if you try to playthrough yourself.
This is just my speculation tho. As for me, I do the tests because I'm interested in the results (easy comparison across time & models) - then I started sharing them because people asked.
I have OpenAI and Anthropic subscriptions so testing these is not an extra cost for me (I'm sloppy around recording the tokens & API-equivalent cost tho - have to improve on this). For the other models, it's total a few bucks per month or so.
So if you're careful about the cost, it's not too much, especially for a serious youtuber who's doing it for commercial reasons.
Finally regarding your comment about cloning the popular enshittified games - I don't think people are going to be doing that for testing, but if you want to have a different spin (or do a close-enough clone for yourself) on a game you loved, the modern AI systems can often deliver!
[0] from the link you posted "i am in disbelief, this is insane, bro what is this, you can't believe it's ai" - yeah...umm, it's not that good :)
Instead, some telecoms give you a generous number of "credits" for calls, transfer, etc, and sometimes try to limit these to your own country. Then you have to pay overage fees (the same in your home country or elsewhere within EU).
The legality (or ToS language around this) is dubious, but the fact that telecoms try to skirt around the rules doesn't mean they don't work - switch to a better provider.
I just spent a week in another EU country and didn't think for a second about data usage, calls, fees, etc.
Combined with not having to do fx or even carry a passport (national ID is enough), minimal queues at the airport and zero customs annoyance, travelling across continent was as much hassle going to the next town (modulo actual travel time).
(Not to mention the actual benefits of membership, in this case, EU institutions slowly but surely cleaning up house).
They're required to grant roaming credits proportional to your monthly payment, but those are usually lower than you get in your own country for the same monthly payment. But they're also usually enough, and free to you. Which is much better than the previous status quo.
We all live in our personal info bubbles and sometimes it's hard to find information if you don't actively seek it out. This doesn't mean it doesn't exist.
Sadly the materials in the lack changed over time, the insides are basically just cardboard honeycomb with a thin veneer around it.
So if you want to follow the lack mods on the web, especially ones written in the 2010s, you need to make sure you strengthen the legs to accommodate the hardware
> Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
Somewhat agree. Five years ago you could build an MVP without understanding how to open TCP sockets or how to parse HTTP headers. You didn't need to understand relational databases, let alone B-trees or cache locality. You didn't need to know how to install Linux.
Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
> You have to intentionally build your understanding as you build your projects.
Some things you need to understand-others, not so much. Depends on what you're doing, the scale, risks, etc, but that's always been the case.
reply