Which skill are you worried about atrophying? Writing code, reading code, or something else?

I find agents very useful for exploring, and understanding existing code bases I am not very familiar with, or if there are time constraints. One thing I have been thinking about, is using agents to assist with creating a plan, but instead of getting an agent to implement that plan, I’d rather make the code changes myself.

Another way could be regularly doing exercises at Exercism.

Could you please elaborate on this? All the article is saying is if a site doesn’t have a dark color scheme, then Safar will dynamically generate one.

Here is the key point if don’t want Safari to manipulate your site’s colour scheme:

If you don’t want Safari to handle dark mode for your website, you can do that as well. For this, you can declare the color-scheme of your website like so.

<meta name="color-scheme" content="light dark">

This will tell Safari that the website supports both schemes (even if the website doesn’t support a dark mode in actuality). It’s a signal for Safari not to manipulate the color scheme on its own.

Most of the variance in developer output, even with AI augmentation, is not about the developer, it’s about friction. It’s about how many times a day someone gets interrupted, how long the builds or tests take, how quickly a review is turned around, how confident they feel deploying on a Friday afternoon, whether the test suite is trustworthy, and whether they spend their week on work they consider meaningful.

100% this! If you want to improve developer output, then protect them from unnecessary meetings and distractions.

I’ve been thinking about this, and I do think it’s a great form of degradation. I would love to see more sites that are statically rendered, but under load dynamic features are removed.

If you’re using quotes around your own terms and preemptively closing any discussion about it, then you’ve already lost.

This is exactly what the article is trying to argue, in the authors own words, he wants a “meaningful conversation”. As for the quotes, it’s challenging the claim that “coding is largely solved”, as made by Boris Cherny at Anthropic, by dissecting what is meant by both “coding” and “solved”.

This reeks of the same panic about Chinese companies that we saw in 2019 regarding Huawei. Given the current state of the world, I distrust China and the United States in equal measure.

Also Hirundo’s whole business model is about cultivating distrust in open-weight models in order to convince people to pay for their hardened models:

Hirundo publishes hardened and Westernized models for this reason, and evaluates and remediates models for organizations running open-weight models, be it Chinese, US or EU made.

Judging by this quote, the only thing dying is quality:

Since the beginning of the year, the quality of software has been degrading pretty much everywhere, much of it caused by over-reliance on AI, or perhaps more accurately, the outsourcing of thinking and decision making to AI. In July, I moved my video podcast off of Spotify after a series of unexplainable outages, and Spotify’s engineering team seemed to take no real pride or accountability in fixing the root causes of the issue.

Only this week, Uber shipped a new feature to production in the Uber Eats app – a new way to select extras with your food order – with seemingly no QA testing:

That’s exactly my issue with people saying something is “AI slop”, it’s a lazy way to shutdown conversation on something you disagree with.

Can you prove it’s AI slop? The author has previously posted that they don’t allow AI-generated content on their blog.

What’s the alternative? The end of openly available knowledge to thwart training language large models, would be a case of cutting off the nose to spite the face.

Could you give an example of what makes this an AI article? If you’re referring to the image, that is credited to the Illustrator Jeffrey Phillips.

As for airline backend infrastructure, I remember attending a great talk from Skyscanner, explaining how airlines were ahead of the curve getting computers but the problem is they haven’t kept them modern. That however, is not an excuse for poor front-end performance that the article discusses.

Reading through the article I wasn’t sold on the argument until I came to third example:

Many traditional productivity tools require you to manually construct task lists, drag items across Kanban boards, and assign micro-deadlines. Goblin.tools is a free, single-page suite of single-task AI tools designed specifically for neurodivergent users or anyone feeling overwhelmed, requiring zero sign-ups or configuration.

Many interfaces can be too overwhelming, particularly for neurodivergent folk, so it’s important to consider different paradigms for interaction.

This could be done on the device, for example the Android app ObscuraCam has automatic face detection.

This is true not just for AI, but also adding more engineers to a project that isn’t going well. No matter how many resources you throw at it, it will continue to be slowed down by the underlying problems with the team or company culture.

Good question, though wouldn’t that be a feature of the browser? It wouldn’t be a good user experience asking people to manually enter coordinates.

Today I stumbled upon Don’t paste the AI:

When someone asks you something, they want your answer. Not a wall of ChatGPT text. A short answer from a human will always be worth more than one from a robot, even if the robot is right.

Exactly this! If I am talking to someone who has expertise in an area, I want to know what they think, not what an LLM outputted.

This sums up my current bugbear with people using Claude, as its output is too verbose. I don’t mind the use of agentic tools, though I want a concise explanation written by a human.

But where it starts to get dicey is when you have both jargon and long text explanations being generated by machines, for people at different levels of understanding. “Bumped dependencies” is good. Everyone knows we are updating packages. “Performed a scheduled dependency refresh as part of ongoing maintenance practices. Minor and patch-level version bumps were applied across the dependency graph, including transitive dependencies where applicable” is bad.

My takeaway from the article was, in the author’s own words, “start with debt in code you’re about to change anyway”. That’s not to say you shouldn’t tackle technical debt in code that isn’t changing, rather it’s lower priority.