One of my most controversial opinions is that designers are not special; the “everyone is stupid except me” attitude is not only counterproductive but downright wrong. Our enemy is not Product and Engineering; our enemy is Projects and Coding.

Iris Meredith’s Becoming an AI-proof software engineer makes the distinction stark. The entire essay is worth your time, but there are two key points I want to pull out for my purposes. The first is the importance of maintenance (regular readers of the Picnic will remember I’ve talked about maintenance before, in the context of UX):

Engineers can’t think in short-term projects and features, because they take responsibility for what they build. Someone who sees their job solely as writing code is missing most of the job of being an engineer. And if all they do is code, they are merely a coder.

Unsurprisingly, the second piece of advice I want to emphasize is for engineers to learn something that isn’t code. Not only because it helps stretch the mind, but because it creates an appreciation for expertise from other fields. Coders lack this appreciation:

This framing benefits from a callback to Olia Lialina’s timeless 2012 essay, the Turing Complete User, which itself cites a 1987 piece by Ted Nelson. After all, there is nothing new under the sun. What bedevils us today is the same thing that bedeviled us in Lialina’s time, and in Nelson’s time, and in the decades prior: the myopic belief of coders that the computer is the only thing that matters, that in some sense only the computer is real.

Yes, finally we are getting back to UX (Don Norman makes an appearance!) but this is very much an engineering text. The very same people we assume “don’t get it” write this:

Hopefully, the distinction is clear. Engineers think in systems, and those systems include real-world components. Coders only care that they finished writing their code, and now the finished code is someone else’s problem. Because coders only contribute code, they can can be easily replaced by Cursor or Claude, which can contribute much more code, much faster.

This is why I love delving¹ into analogous domains. Because we can take the exact same lesson and apply it to product and design. If the way to AI-proof your developer career is to stop being a coder and start being an engineer, then the way to AI-proof ourselves is to stop thinking about the work as projects and features.

When people talk about how AI is causing roles to merge, these are the roles they are talking about. Being able to prompt up a prototype before the problem has even been framed is not a design skill, or a product skill, or an engineering skill. The people chasing this niche are all going to be replaced by middle managers who can do the same thing just as well.

Or do the thing even better. Because the manager’s unit of output is not actually projects. It’s predictability. Within management, the computer brain manifests itself as an organization driven by burndown charts. Data points exist only to be put into a slide deck and presented to the level of management above. And doing it yourself is always going to be more predictable than delegating it to a worker.

The definition of success becomes “check the box by the deadline.” The consequences of the box-checking exercise are not within the computer, and therefore unimportant, so long as the box became checked. If the outputs are regular, it’s ok that they are pointless, because we are Doing Agile (where “doing Agile” really just means doing two week sprints even though the sprints are killing us).

This is the thing AI is really good at. Click a button, and outputs appear. Ignore the coarse early signals of impending issues, and let the salience of vibe-coded prototypes carry you down the lazy river of false certainty.

To companies still practicing agency thinking and treating Agile as a way to squeeze more velocity out of waterfall, this is revolutionary. Now they can cut out 75% of their staffing costs, and still check off all the boxes. Wow.

It should be obvious that the way to compete with this logic is not to get better at clicking the buttons yourself, but to play a different game. Stop chasing pure velocity as the only value you can offer.

It’s not an easy task, because bringing up problems without solutions is usually stigmatized by the types of managers who don’t want to be snapped out of the artificially logical computer world, where the dashboards and the chatbots (and the dashbots) whisper only stories of inevitable success.²

One of the really effective ways of pushing back against this false certainty is to give managers exactly what they want: granular transparency into the work. The key difference is that this transparency is not modulated through a Gantt chart, but through the lens of your choice. Unpacking tasks not only helps you estimate better, but it also helps identify gaps in the thinking that the slick vibe coded prototypes paved over: if we expect X to happen, what is the user behavior that leads to X? Do the users know that’s what they are meant to do? Are you sure?

However, don’t over-index on the estimating too much. Chasing estimates is also project thinking. Estimates only have value to project managers, the computer-brained overseers of the burndown chart.

If you really want a deep dive into how chunking work into small pieces & making it visible pays off, read Dorian Taylor (specifically ROI of a Solved Problem and The Principle of One Degree).

To aim the course of your product development down a more productive path, there are two tools you should know. One is the pre-mortem (here’s a practical case study about using pre-mortems to get a design systems team off the ground). The other is the Futures Cone, which is simple enough that you can throw it up on a slide and dazzle stakeholders with your diagram prowess.

⸻

1: Do people still assume that using “delve” means the text was AI-generated? It’s a good word. I’m taking it back.

2: If I was using AI to write, would I have produced this horrible sentence?