field note

The Commodification of Expertise

Expertise as an agent, software as an assembly line, and why you feel anxious

In my 20+ year career, I can’t think of a more exciting time to be in design & tech. The early days of the 2000s or the mobile app era come in as distant runners-up. The difference is that with this time around, the excitement comes with a large dose of fear, anxiety and a general sense of unease.

Expertise of old

I think this is really rooted in the commodification of expertise. Whatever it meant to be an “expert”, it used to be earned over time - attached to success and failure, a sort of cumulative measure of your ability to use past experiences, muscle memory, and domain knowledge to make judgments. Experts in a given practice or discipline could take pride in this journey; the late nights, hard work, and the satisfaction of working through problems and solving them came with some sense of recognition and professional meaning.

The unease people are feeling is the erosion of that idea. Something that took 6 months in 2023 now takes 6 hours with frontier models in the hands of a moderately capable engineer or engineering-minded designer.

My expertise is special

People see it every day and everywhere - an avalanche of data points that suggest your expertise is nothing special. On social media, much of it is noise, clickbait headlines or engagement seekers, but it’s also happening inside companies. Processes, projects, and entire functions being distilled into automated workflow gates replacing human expertise and judgment with agents.

Naturally, we find it hard to acknowledge or even consider that this is possible or practical. After all, we are experts and are used to thinking deeply about our given discipline… This often leads to conjuring edge cases, counterfactuals and other rationalizations on why our expertise is different. This is a quite understandable, probably a common first reaction and maybe even true at the moment.

Software as a supply chain

However, there are a few problems with holding on to this view. Generally, people outside your function who are decision makers have, at best, only a casual understanding of your contribution. If you’re a product manager, you set roadmaps and priorities. If you’re a designer, you make things look nice. If you’re a software engineer, you write the code. The business is a consumer of your expertise and it can very easily make the product development process look like a supply chain problem. The problem becomes less about “the product” and more about how it can be built in the most cost-effective way with acceptable results. This is why the AI/agent/automation promise is so alluring to executives - it’s built on a framework and mental model that views software development more like an assembly line than the often messy and non-linear course it so often takes. In my experience, this view of the process is quite prevalent at the Senior Director / VP levels and above where budgets get allocated and business priorities are set.

Good enough gets it done

The second related issue to mention is that, if you zoom out of your bubble where craft, nuance, and “taste” are viewed from the outside, it’s not clear that agents won’t produce an “acceptable” outcome in the very near future. The definition of acceptable is sort of in the eye of the beholder here, but that’s why we have to look at it from outside our expertise. As a designer, yes, we could look at designs or code produced by an agent and find flaws, improvements, and tell-tale agent fingerprints, but does that make it unacceptable? Maybe to some designers, but not for the vast majority of others. It appears replacing design as a human-only expertise is a “fast follow” for OpenAI, Anthropic, et al.

The present and future

Maybe ironically, one of the barriers to complete software automation (at least right now) is legacy brownfield software. Older codebases have often accumulated layers of custom logic, behaviors, and other oddities that make it more cumbersome to turn completely over to agents. For better or worse, changing some of these learned behaviors or expectations can be hard to execute, and migrating to another, more updated solution is often unfeasible or deferred in favor of duct tape and superglue. While not impossible, these types of legacy codebases can often be skipped over for other lower-hanging fruit.

A little farther in the future perhaps, lost in the day-to-day scramble to automate the current software lifecycle, is the larger question about the end-users of the future. Specifically, if you’re creating B2B or even B2C software, you have to consider agents as consumers of software. Whether that means a computer-use model like we see in the latest frontier agents in which humans and agents might use a traditional software GUI, or what I think is probably more likely, a GUI built for humans sharing a capability layer or API that can be directly accessed and used by agents. It seems as if significant efforts are currently focused on automating the software product cycle to produce software used by people, but if large chunks of the economy and workforce will be displaced by agents, who will be sitting around at their desk clicking through a software GUI?

So what should you do with your expertise?

In this environment, when it seems extremely valued / capable co-workers and entire teams are all subject to cost-saving efficiency measures, what is an expert to do? If you have a mortgage/rent and employer-sponsored health care, it’s hard to do anything but keep your head down and drink the kool-aid. It seems to me lots of people are choosing this route, hoping to build an AI-mastery reputation in order to survive the next round of cuts. If your LinkedIn feed looks anything like mine, this motivation appears fairly transparent. I am guilty of this too, but you have to wonder if you’re just retracing the steps of blue-collar workers in the 80s and 90s?