As I process what AI means for the job description of software developers, I keep coming back to one concept: taste. Now that writing code is no longer a required skill for development (!!), the basic skill becomes prioritizing the tradeoffs that the code needs to match. Does the code have too much structure? Not enough? Do these tests provide real value? Are the tests too inflexible? Is it even worth the effort to change any of those things?

I find this frequently when doing AI-assisted development. I find that I can get 90% of the way there with the first pass of an agent running at the task. The “second 90%” of the work is examining the code and adjusting it to match my taste.

What is taste, though? It was important before, though (IMHO) not talked about enough. Thankfully, I’m seeing discourse shift to examining the concept, with more being written on the subject. And it’s great stuff.

Today’s instant-favorite of an article helped me better define what taste is: flexibly adapting values to a situation. For a given project, feature, or task, what’s most important? How do we rank them? How and when do we exceed the bounds of what’s acceptable?

This was previously something that was implicitly learned by the best developers through experience, and applied by gathering and synthesizing organizational context and culture. In the future, AI may be able to do that, but not until it can digest and structural organizational tradeoffs. We’re a long ways from that.

That means we now need to do what we probably ought to have been doing all along: clearly articulating exactly what our values are, and documenting how they change for different areas. Do your values change depending on the maturity of a feature? (hint: they do!) Figure out how, and write that down. And then write down the maturity of each feature. (Bonus exercise: can the AI assess that on its own? Does its assessment match your expectation?)

Working through this is how I’m starting my week.