Gpx

Companies that in 2024 have in their email signatures, "Please don't print this email. Think of the environment." Yeah, I wasn't planning to.

It really is difficult to balance the need to push a team to innovate and adopt new technologies and practices with the need to avoid micromanaging. I see this a lot lately with AI adoption. Some companies are looking at how much AI is used, how often it is used, and whether people are using it enough. But this is not new. It happened in the past with other innovation cycles too. TDD and automated testing are examples that come to mind. The trick is to convince before you mandate. If the change really is valuable, there should be ways to show it. Show that it improves quality, reduces risk, shortens feedback loops, or helps teams move faster without creating more chaos. If the evidence is there, people are more likely to pick it up and want to learn. A mandate may still be needed at some point, but it should not be the first tool. Otherwise, what could have been a meaningful improvement easily becomes just another process imposed from above.

This is something I’ve been thinking about a lot lately: the psychological impact of innovation on different people. According to Wardley and Cringely, there are three distinct behavioral archetypes within a company: Pioneers, Settlers, and Town Planners. Pioneers thrive in chaos. They like operating on the bleeding edge, where things are unclear, unstable, and full of unknowns. They are usually the first to experiment with a new technology, not because the business case is already obvious, but because they are comfortable exploring the unknown. Settlers take what Pioneers discover and turn it into something useful. They look for patterns, remove some of the chaos, and make the technology reliable enough to generate business value. They are not necessarily late adopters, but they usually need more than hype. They need to see that something can actually work. Town Planners scale what Settlers built. They care about standards, governance, repeatability, and operational stability. Their job is not to chase novelty, but to make sure the organization can depend on something at scale without everything falling apart. This made me think about AI adoption. But this post is not really about AI. AI is just the current example. The real question is: how does each archetype deal with the introduction of a major technological shift? My suspicion is that most of the people who feel burned out by AI are not Pioneers. Pioneers are probably enjoying the chaos, the experimentation, and the lack of clear rules. Settlers, I think, are slowly getting more interested as the technology matures. Once there are more proven patterns, better tools, and clearer ways to turn AI into actual business value, it becomes much more interesting to them. Town Planners might be the most cautious, and maybe for good reasons. Their job is to scale, standardize, and reduce operational risk. A technology that changes every few weeks is not exactly comfortable territory. Since this will not be the last technological shift we’ll see in our careers, I’d be curious to hear how other people are dealing with it. Which archetype do you relate to the most? And how are you experiencing AI adoption right now? Feel free to DM me if you prefer to keep it confidential.

A small piece of advice for engineers interviewing right now. Prepare an answer to this question: How do you use AI agents or AI tools in your work? More and more companies are asking this. As usual, there is no single correct answer. What matters most is that you can justify your answer. For example: “I use ChatGPT to reason through prototypes before jumping into code. I apply spec-driven development, so I first prepare a plan with the help of AI. Then I convert that plan into a task list and execute it with a swarm of agents. Each task is limited in scope and validated by tests I have written beforehand.” This kind of answer tells me much more than “yes, I use AI.” It shows that you think about the problem, understand the trade-offs, and know where AI fits in your workflow. In an interview, that matters more than saying you know how to use a particular tool.

"I need to find a way to burn some AI tokens." I heard this directly from someone working at a tech company. Their leadership team had created a mandate to increase AI usage. The logic is simple (and wrong): if people use more AI, the company is more productive. So people started finding ways to burn tokens. Some generate memes, some build personal projects, some help their children with homework... nobody does anything related to the company's goal. After all, the mandate is to use AI, not to use it properly. This is what worries me about the current AI adoption wave: there's a growing disconnect between leadership and the people they are supposed to lead. In many companies—not all of them, of course—leaders seem to have already decided that AI must deliver a certain level of productivity improvement. Not because they have strong data. Not because they understand where the improvement will come from. But because the market expects it, the hype promises it, and everyone else is doing it. Then, when the expected gain does not materialize, the conclusion is not: "Maybe we misunderstood the problem." The conclusion becomes: "People are not using AI enough." So they create mandates. They measure how many tokens are consumed. The metric becomes the goal. This is dangerous because a company does not hire engineers, designers, product people, and the like just to execute leadership's assumptions. You hire them because they understand aspects of reality that leadership cannot see on a dashboard. You hire them because they can tell when something does not make sense. You hire them because, sometimes, you need them to tell you that you are wrong. But if people stop pushing back for fear of losing their jobs or because they have learned that nobody is listening, the company has a much bigger problem than AI adoption. AI will not fix that; it will make it worse. Treating AI adoption as a proxy for progress is lazy. Usage is not impact. Token consumption is not productivity. Mandates are not strategy. And if your employees are inventing nonsense ways to use AI just to satisfy a leadership target, the problem is not that they are resisting the future. The problem is that your organization has stopped learning from the people closest to the work.

It might be because English is not my native language, but what does "AI native" mean? Isn't the fact that we're adopting it at odds with the very definition of native?

I think this is a good take, but it does not fully match my experience. For me, the dominant feeling around AI in software development has not been grief. It has been fear. From the moment ChatGPT was released, the discourse centered on whether AI was going to replace developers. Companies were built around that promise. We got endless demos showing LLMs replacing engineers, benchmarks claiming models performed better than developers, and a constant stream of messaging pushing the idea that our work was about to be automated away. And we still do. What helped me was trying to look at the technology as objectively as possible. Once I did that, the picture became much less extreme. LLMs are not as amazing as they are often sold, and they are not as bad as the detractors claim, either. They do have a place in software development, and they have changed the way many of us work. But not as radically as some people claim. Could they evolve to replace us one day? Maybe. But if the current trend continues, I think that is unlikely. That is why I suspect that, in many cases, denial and anger are not really a consequence of grief.They look more like a fight or flight reaction to fear. andrewmurphy.io/blog/the-five-…

⚙️What does it take to build web systems for the AI era? Join 50+ deep engineering sessions at Web Engineering Summit on June 11 & 15 in Amsterdam & online. Topics include: AI development, system design, scalability, performance, full-stack architecture, & more. Don’t miss out!

In many cases, software developers are not seen as professionals in the same way as doctors, plumbers, or lawyers. A big part of it is our own fault: too often, we are not seen as professionals because we do not act like them. Often, the way we are perceived and perceive ourselves is as people who write code based on someone else’s idea. We can clearly see this now, with many people trying to replace software developers with LLMs. If your job is framed as just turning instructions into code, then of course, people will assume a machine can replace you. The problem is that this was never the real job. The real job is understanding trade-offs. Understanding risk. Understanding how systems fail. Knowing when a request is reasonable and when it is dangerous. Knowing when speed today creates a bigger problem tomorrow. That is what professionals do. And yet, too often, we accept deadlines we do not believe in. We skip tests because delivery pressure is high. We keep building on top of systems that are already unstable. We stay quiet when we should push back. We act like our responsibility starts and ends with producing code. It does not. A professional does not just execute. A professional uses judgment. A professional protects the integrity of the work. A professional is expected to say no when no is the right answer. If we want this field to be treated as a profession, we need to stop behaving like typists for product ideas and start behaving like people accountable for the quality, safety, and durability of the systems we build. Because if we keep presenting our work as “just coding”, we should not be surprised when others start asking why they need us at all.

I regularly interview candidates for software engineering positions and conduct many system design interviews, so let me give you some advice based on the most common error I have seen. If your solution relies on a cron job or on polling a service, it is often wrong. If you find yourself relying on it, stop and think if there is a better way. If you are polling many times, it is usually because you are not sending an event or you do not understand how to get the data in a more straightforward way.

Call for Speakers for JSHeroes 2026 is open on Sessionize, and I've just submitted a session! sessionize.com/jsheroes-2026/

@adamstern_ @charliedeets @diabrowser Bring back the sidebar!

Building @charliedeets's design for a sidebar option in @diabrowser. We’re torn: should we ship it?

This. AI is another tool. If you replace expertise with tools, you don't understand what programming is

I've been doing a bunch of TypeScript and I found out I don't know how to spell "unknown"

@mattcarrollcode I did not. None of my projects have noticeable performance issues so I don't feel I need it. Memoization is something I very rarely reach for

@Gpx Have you tried it on any of your own projects yet?

Automatic repositioning logic! 🏗️ One really cool built-in feature of native customizable select:

Hey, @krisvelkov, I read your article about using a flat structure for logic. What do you think of this alternative implementation? frontendworld.substack.com/p/javascript-t…

@elmlang @reasonml github.com/tc39/proposal-…

@elmlang @reasonml github.com/tc39/proposal-…

Around ten years ago, it seemed JavaScript was going the functional programming route with libraries like Ramda becoming popular. It unfortunately ended up in a few unmaintainable codebases full of tiny undecipherable functions and some good projects like @elmlang and @reasonml that remained niche. JavaScript wasn't a good fit back then because it didn't have types. But now we have @typescript. I think projects like @EffectTS_ and the excellent ts-pattern (by @GabrielVergnaud) have the chance to change how we write JS applications.