1. For a techie, you can already de-Google yourself trivially by asking the AI to build you a bespoke web crawler and run it on Lambda or Cloudflare workers to index the entire internet and store it in DuckDB.
2. The answer doesn't actually help the user get back useful results from Google.
3. "Let me know" doesn't scale, and it's not obvious how talking to random internet strangers about their Google problems will increase your startup SEO?
Your qualms are noted. I'm not sure what de-Google really means in the real world.
I have a Google user account from the days when you were invited to grab a whole GB of email storage. Its just an email address, just a service. They have a fully tooled up data set on me in return, to flog. I use it for testing. They make more money out of the relationship but I also find it useful in many ways so I keep it on.
If I wish to de-Google (whatever that means) I will stop using it.
I don't think you really understood your parent's comment.
The above Opus games took ~45min to generate with the cost between $11 and $14 (per ccusage - I'm on a Max sub). Used from Claude Code with xhigh effort.
It's interesting that Astra has a clear style that it applied to both games. It's a refreshing design language, but maybe that's because it doesn't look like something Claude has vibe-coded. In terms of gameplay depth, the Claude versions appear to be closer to the original Minecraft
> but maybe that's because it doesn't look like something Claude has vibe-coded
Yes, it's solely because it's new. Back when the very first Opus vibe-coded websites appeared, we found them refreshing. By the 3rd one, we no longer did.
> 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.
If you ask LLM to code something for you, and you then work on the code, then yes, there is partial ownership. Just like if you had asked another, maybe junior, developer to write a piece of code, and then you helped them make it better.
I think the difference involves how many layers of stuff someone claims is "theirs" and whether that claim of credit and expertise is valid.
Imagine a coworker writes some decent C code, but then at a meeting they start taking credit for the bytecode and the default optimizations done by the compiler.
That's analogous to people who write LLM prompts and then claim the same level of authorship over the code which was all generated and edited on an indirect level.
Fixing stuff by driving an LLM to do it seems like a distinct skill unto itself. It’s kind of this blend of your normal debugging skills, carefully managing what goes into the LLM and carefully constructing your requests.
For me at least it’s the one thing that feels like a novel new skill to learn more than anything else. Normal LLM prompting feels like just an extension of the mental process I’d use when coding and designing in a way that trying to get the LLM to fix things kind of doesn’t.
I agree that it is a bit weird, kind of coding in natural language but also not exactly like that. Maybe as the agents stabilize and there are proper new tools for this new process we can relax a bit and it will become the new normal. For now it feels like surfing over an ever changing seascape, exciting but tiring at the same time.
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)
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.
> "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.
In addition to the reliability/security aspect, there's the claim to expertise and unwarranted confidence. We also don't (usually) fool ourselves into believing that the manager has gained the skills and expertise of the worker, simply because they gave abstract orders and a good result was achieved.
In other words, "I can code because I prompt an LLM" is like "I can do metalworking because I sign the paychecks of a blacksmith."
> 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.
Very good point. I would respond that I saw the deterioration several years before vibe coding became a thing, but maybe they did have a head start on the tech.
>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.
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.
>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).
1. For a techie, you can already de-Google yourself trivially by asking the AI to build you a bespoke web crawler and run it on Lambda or Cloudflare workers to index the entire internet and store it in DuckDB.
2. The answer doesn't actually help the user get back useful results from Google.
3. "Let me know" doesn't scale, and it's not obvious how talking to random internet strangers about their Google problems will increase your startup SEO?
reply