Notes

It’s not fair that newer writers will have to prove (to a larger extent than more established writers) that they can actually write, and that what they’ve written is actually their own work, not the result of a prompt. It’s especially unfair when the makers of the tools writers use to write — I’m looking at you, Microsoft and Google — are frantically stuffing “AI” tools into the programs writers rely on. No, Microsoft, I don’t fucking want Copilot to “help me write” in Word, and no, Google, I don’t fucking want Gemini to “help me write” in Google Docs. The very fact these “AI”s are hovering around my writing at all is bad enough from a provenance standpoint. These “AI” tools are making it harder for all writers in this regard, not easier.

As someone who writes for my site, as well as trying my hand at a novel, this kind of scares me. I write all my posts in markdown, and I've gone back and forth between writing my novel in markdown or LibreOffice. None of my tools have AI assitants or AI tooling built in, which is what I want, but anyone reading or judging my writing won't necessarily know that. Newer authors are going to have to find a way to prove to publishers and the world that they wrote it themselves. It's not something I look forward to.

Therefore, if you take a step back, it's basically Meta getting to write the standards for child safety across the big players of the internet.

And if you don't believe that Meta has been particularly good, like what amazes me of the people celebrating this are the same people who are like Meta is terrible and we don't trust them.

And now you have handed them the pen to write the rules of how internet safety for children works across the internet.

And even if you say, well, it's just limited to these biggest players, if they can convince YouTube and TikTok to go along with it, the trickle down of this is also really problematic because now what is happening is you've blessed these specific things, the two hour limit, the hidden likes, the things that we don't know whether or not they actually work.

But if any other platform wants to avoid getting sued in the future, the easiest thing to do is just say, well, we're doing the industry-wide standard as defined in this settlement between Meta and all of these states.

And so the way to reduce liability, if you're a company, a smaller company, an upstart trying to do something different, maybe you have an idea of how to actually protect children more.

That's now risky.

The easiest thing, the thing to do to reduce and avoid liability is to just go with the flow, take what Meta has agreed to and say, we're just going to do that because that is the industry standard.

And that really concerns me, especially when we don't know what actually works right now.

The laws of unintended consequences is likely to be seen heavily here. Sadly, Meta is probably going to love this. It puts them in the driver seat to put walls up making it harder for new players to enter the market.

Standardized APIs have intrinsic value, independently of browser implementations.

We think of polyfills as a toggle: use a polyfill, leave it in there, and later when all browsers implement the feature natively, it gets removed.

This misses out on one of the biggest benefits of polyfills: decoupling API design from implementation.

Completely agree. It's nice when you can easily enhance functionality while not tying yourself to a specific implementation too tightly. Time moves on, implementations become standard across the different browsers, and you can go in and get rid of code. It's a great feeling.

It can also help handle things if a library ceases being maintained, or a vulnerability of some form is found in the polyfill library, or anything else. The easier things are to swap out implementations in general, the better.

Let’s not beat around the bush: This is effectively malware behaviour. It’s bullshit. It’s cancer. It’s deeply disrespectful toward the user. It’s prioritizing hollow metrics at the expense of everything else.

...

But, an app installing a global keyboard shortcut without user consent is bad. This can never be anything other than opt-in. At the very least, Chrome should have shown me a clear UI that said “We’re thinking Ctrl+G would be fun for you to use. You okay with that?” and a button for me to press to confirm.

Completely agree with everything Marcin is saying. And to me, it feels even worse since it doesn't feel like it's something that feels like we'd expect. When I installed Alfred and Raycast on my Mac, I installed them to get that launcher. I don't install a web browser for that. In either case, we shouldn't have apps be able to just steal global shortcuts without side kind of "hey, do you want this application to do X" What's next? Remapping Cmd+Z?

Seniority, at least in architecture, often means noticing the missing question before the missing answer turns into an incident. The same logic applies to coupled systems. A component can behave well on its own and still create trouble once the rest of the system starts reacting to it.

Senior developers can see things newer developers might miss. That comes with having more experience both with the software being developed, and many years of experience, likely making the same mistakes or missing the same things being caught in review. But even with all the experience, so much goes into software, it's hard to catch everything. The best you can do is set systems up with a good foundation, so when things go wrong, you probably already know where to look to fix it.

The point is not documentation for its own sake though, but to make the system legible before production does the explanation instead.

The more I think about it, the less sympathy I have for Grid Lanes. You create a DOM order that you think makes sense, then you mess it up with CSS. Then, if you're aware of the problem, you fix it again with CSS. Finally, you have a patched-up layout that may have created other issues you can't address.

I'm looking forward to Chrome's, Firefox's, and Safari's next moves. Until then, to sum it up, my slightly adjusted recommendations are:

• Always test your Grid Lanes with the keyboard or a screen reader across different screen sizes.
• If you find a mismatch between the DOM and the visual order, increase the flow-tolerance value. You may have to use a high value or even infinite.
• As soon as it's available and supports Grid Lanes, try using reading-flow instead.
• If that doesn't work, consider using a regular grid.

Some good thoughts and examples here to help with accessibility should you choose to use CSS Grid Lanes.

In the beginning there was ai, and bosses everywhere lost their minds and said you must all use this technology no matter whether it is useful and no matter how much it costs. And they introduced ai leaderboards and came up with stupid words like “tokenmaxxing”. And lo, usage did indeed rise. And then the bosses remembered some very basic concepts like “budgets” and realised that this might not be such a great idea after all. And then a different question rang through the boardrooms, and this question was about returns, and it was harder to answer.

Measuring productivity is almost always difficult. With AI it can be even more difficult as it can be hard to identify how any gains now can be countered by the potential for tech debt later. If AI generates code that someone else has to keep cleaning up later, how much is really gained?

From a software engineering perspective, if a company is going to use AI coding assistants, it should make sure the engineers are keeping tabs on the code generated and that the engineers are taking responsibility for any code they use AI to produce.

More than a century before Japanese whisky became one of the most coveted spirits in the world, a young merchant in Osaka had a simple observation: the wines and liquors being imported from Europe didn’t suit Japanese tastes. What he built from that insight—one product at a time, for the last 127 years and counting—is now one of the largest beverage companies on earth.

As a fan of whiskies of all kinds, it was an interesting story of Suntory's history.

By the way, it’s not just documents… I’m also seeing the same pattern in pull requests, automated tests, and even decisions. We’re going faster by passing the slow part (the reading, the actual understanding) to whoever comes next. A Ponzi scheme?

Don’t get me wrong: by all means, do use AI. I do too, and I’m (probably) not going back. The thing is: the model is giving you many hours back, so please spend a bit of them editing!

I already have a rule for AI-written code: if I can’t explain the change, I can’t ship it. The same rule applies here: if you can’t defend a sentence with the document done, it’s not really done, is it?

If you're going to use LLMs, the least you can do for those you work with is to fully review the output and ensure you understand it.

CSS Grid Lanes has started to ship in browsers. It’s in Safari and behind a flag in Chrome and Edge.

It enables masonry layouts, where items get packed together in the most efficient way possible.

Unsurprisingly, I’m a fan of a layout tool where the browser does all the hard work. It very much aligns with the idea of declarative design; you specify the boundary conditions, and then browser does the maths and heavy lifting.

This is so awesome, I'd recommend checking Jeremy's full post out as well as the documentation.

Some of these are petty in just the right ways.

Since you don’t respect my opinion anyway, quit pestering me to fill out a survey after every single consumer experience. I keep wondering who looks at these surveys. Is the CEO sitting in his wood-paneled office, reading each individual response on an old-timey stock ticker? If so, you can keep doing this. If not, I rate this experience zero stars out of infinity.

Let's see how we can enshittify things further...

In conclusion: Stop forcing me to download a dang app to use my air fryer! I WOULD THROW MY PHONE INTO THE AIR FRYER OVER THIS IF I HAD ANY WAY TO TURN THE AIR FRYER ON AFTER IT WAS IN THERE.

I want dumb appliances, not everything needs to be internet connected.

Here is something that gets lost in all the excitement about AI productivity: most software engineers became engineers because they love writing code.

Not managing code. Not reviewing code. Not supervising systems that produce code. Writing it. The act of thinking through a problem, designing a solution, and expressing it precisely in a language that makes a machine do exactly what you intended. That is what drew most of us to this profession. It is a creative act, a form of craftsmanship, and for many engineers, the most satisfying part of their day.

This times 1,000. In a team setting, code review is always part of the job, but something gets lost when thatS all your job becomes.

One engineer captured this shift perfectly in a widely shared essay, describing how AI transformed the engineering role from builder to reviewer. Every day felt like being a judge on an assembly line that never stops. You just keep stamping those pull requests. The production volume went up. The sense of craftsmanship went down.

This is not a minor adjustment. It is a fundamental shift in professional identity. Engineers who built their careers around deep technical skill are being asked to redefine what they do and who they are, essentially overnight, without any transition period, training, or acknowledgment that something significant was lost in the process.

Having led engineering teams for over two decades, I have seen technology shifts before. New frameworks, new languages, new methodologies. Engineers adapt. They always have. But this is different because it is not asking engineers to learn a new way of doing what they do. It is asking them to stop doing the thing that made them engineers in the first place and become something else entirely.

I want to create things, I want to build features and fix bugs. I want to see the code as my canvas. The code over my life has included multiple languages, the tooling has changed, but the general concepts haven't. Now all of a sudden, the primary job that I've done is being offloaded to an LLM. Time will tell what the final result becomes.

There is an irony at the center of the AI-assisted engineering workflow that nobody wants to talk about: reviewing AI-generated code is often harder than writing the code yourself.

When you write code, you carry the context of every decision in your head. You know why you chose this data structure, why you handled this edge case, why you structured the module this way. The code is an expression of your thinking, and reviewing it later is straightforward because the reasoning is already stored in your memory.

When AI writes code, you inherit the output without the reasoning. You see the code, but you do not see the decisions. You do not know what tradeoffs were made, what assumptions were baked in, what edge cases were considered or ignored. You are reviewing someone else’s work, except that someone is not a colleague you can ask questions. It is a statistical model that produces plausible-looking code without any understanding of your system’s specific constraints.

Again, this will only add cognitive debt to your application. Tech debt you at least often have the knowlege of why you built things the way you did. When no one wrote the code, you lose that knowledge and the "why".

First, do not abandon your fundamentals. The pressure to become an “AI-first” engineer is real, but the engineers who will be most valuable in five years are the ones who deeply understand the systems they work on. AI is a tool. Understanding architecture, debugging complex systems, reasoning about performance and security: these skills are not becoming less important. They are becoming more important because someone needs to be the adult in the room when AI-generated code breaks in production at 2 AM.