Notes

This is a great write-up going over the basics of Big O notation.

Khlaaf pointed to Three Mile Island as an example of an entirely human-made accident that AI may replicate. The accident was a partial nuclear meltdown of a Pennsylvania reactor in 1979. “What happened is that you had some equipment failure and design flaws, and the operators misunderstood what those were due to a combination of a lack of training…that they did not have the correct indicators in their operating room,” Khlaaf said. “So it was an accident that was caused by a number of relatively minor equipment failures that cascaded. So you can imagine, if something this minor cascades quite easily, and you use a large language model and have a very small mistake in your design.”

File this under "what could possibly go wrong?"

But it’s a trap. Vibe coding doesn’t create developers; it creates fragile intermediaries. People who can generate code but cannot read, debug, or maintain it.

If you’re a new developer, this isn’t a shortcut. It’s a cliff. And you’re being encouraged to run straight toward it.

There's a reason people are offering services cleaning up vibe code...and getting hired to do just that. Learning the basics is important, use AI to supplement your coding if you must, but know how code works.

The result is a dangerous illusion of competence. You can generate output, but you cannot command it. When it breaks (and it will), you have no map, no tools, and no idea why. This isn’t coding: it’s outsourcing your own understanding.

Eventually every vibe coder reaches the point where the returns start heavily diminishing. Their site gets hacked and they need to actually sink the time to learn how security works. The app gets too big for context windows and things start looking and functioning inconsistently. Real frontend engineers who know what they are doing are hired to implement a consistent design system and UX.

I think that's the biggest thing with vibe coding, you want to build a simple little tool for yourself, it can probably work well enough. Want to build a new SaaS product...whelp...good luck with that.

There is no secret herbal medicine that prevents all disease sitting out in the open if you just follow the right Facebook groups. There is no AI coding revolution available if you just start vibing. You are not missing anything. Trust yourself. You are enough.

Oh, and don't scroll LinkedIn. Or Twitter. Ever.

Always good advice.

When teams need a new frontend, the conversation rarely starts with “What are the constraints and which tool best fits them?” It often starts with “Let’s use React; everyone knows React.” That reflex creates a self-perpetuating cycle where network effects, rather than technical fit, decide architecture.

I'd be lying if I said that my knowledge of React makes it a quick choice.

React’s dominance creates self-reinforcing barriers. Job postings ask for “React developers” rather than “frontend engineers,” limiting skill diversity. Component libraries and team muscle memory create institutional inertia.

Risk-averse leaders choose the “safe” option. Schools teach what jobs ask for. The cycle continues independent of technical merit.

That’s not healthy competition; it’s ecosystem capture by default.

Because why not have some fun with your designs.

A lot of us spend the majority of our days in front of a screen. We have online conversations and collaborate with people from all over the world. We read each other’s blog posts and social media rants. But behind every line of code, behind every post about the latest CSS tricks, behind every talk and video tutorial, there’s a real person. A person with a story, with struggles, with a life. And a few of those people are now here at the conference. That’s when you realize: the Web isn’t just a bunch of servers and websites. The Web is the people building it. The Web is community.

I can't say I've ever been to a conference, but the community out there is awesome. So many web devs building cool stuff and sharing their creations.

So, stop claiming that we want to deny you freedom of expression; otherwise, we’ll have no choice but to take that freedom away.

The Harvard Business Review study came out the day after a Financial Times_analysis of hundreds of earnings reports and shareholder meeting transcripts filed by S&P 500 companies that found huge firms are having trouble articulating the specific benefits of widespread AI adoption but have had no trouble explaining the risks and downsides the technology has posed to their businesses: “The biggest US-listed companies keep talking about artificial intelligence. But other than the ‘fear of missing out,’ few appear to be able to describe how the technology is changing their businesses for the better,” the Financial Times found. “Most of the anticipated benefits, such as increased productivity, were vaguely stated and harder to categorize than the risks.”

No single study on AI in the workplace is going to be definitive, but evidence is mounting that AI is affecting people’s work in the same way it’s affecting everything else: It is making it easier to output low-quality slop that other people then have to wade through.

The great works of Victorian England were erected by engineers who could not be sure of the properties of the materials they were using. In particular, whether by incompetence or malfeasance, the iron of the period was often not up to snuff. As a consequence, engineers erred on the side of caution, overbuilding to incorporate redundancy into their creations. The result was a series of centuries-spanning masterpieces.

AI-security providers do not think like this. Conventional coding is a deterministic practice. Security vulnerabilities are seen as errors to be fixed, and when fixed, they go away. AI engineers, inculcated in this way of thinking from their schooldays, therefore often act as if problems can be solved just with more training data and more astute system prompts.

More risks from vibe coding. If you're going to use AI in production environments, you better be able to understand and work with the code it spits out.

When we use the term "best practice", it sounds like what we're saying is, "what you've done is fine, but here's another way you could have done it." When in fact, what we're really saying is, "I want you to fix this accessibility issue, but I can't technically fail you on it, because it's outside the scope of this particular standard."

This was just so cool.