LLMs and Artists

Most of history’s great artists were leaders of a studio, not loners. Rembrandt had apprentices, Andy Warhol had The Factory, and most of today’s successful artists also work with a team. While a handful of famous artists (including astonishingly prolific ones, like Picasso) have worked alone, for most of human history art has been more of a team sport. The still-popular image of artists as lone geniuses is a leftover from the Romantic movement of the 19th century.

Today the craft of software is going through its own studio-like renaissance. That clicked for me when Simon Willison recently observed that when you take an experienced engineer and have him write a quick and dirty project via LLM, what you get out of it is … actually good code. 

The reason is that this engineer understands how to treat the LLM like an artist treats his or her studio.

A Dutch master in the 17th century had to know what parts he needed to sketch an outline for, what parts he needed to carefully attend to by hand, and what parts he could leave entirely to his team to handle as they saw fit. Today, a senior engineer must develop a similar intuition for when LLMs need him to design a package hierarchy or outline an algorithm in pseudocode, and when it’s more productive to write a core data structure by hand.

But just as working with apprentices was a related but distinct skill from manipulating paint on canvas for Rembrandt, supervising LLMs is a new skill for today’s engineers to learn. It takes practice, and getting that practice requires a certain amount of humility to recognize that this is in fact a new skill that you are starting from zero at. To paraphrase an anonymous aphorism, good prompting depends mostly on experience, and experience is the result of poor prompting.

Because low-level work is a skill in its own right, I sympathize with the many engineers who enjoy the syntax-level details of writing code and are reluctant to give that up. But I disagree with the commentators who think that turning some or most of that over to an LLM necessarily makes me a worse programmer. It’s true that I can no longer give you the syntax to use Java’s Collectors.groupingBy off the top of my head. But like Rembrandt letting an apprentice handle faces in the crowd so he can focus on his painting’s subject, letting an LLM handle details like groupingBy leaves me free to spend my time on the more interesting parts of the problem.

Doing this effectively means I have to understand the codebase well enough that I can effectively review the code that I’m delegating to the LLM. It means accepting that there is no magic black box to which I can delegate the responsibility of sourcing the right content for my LLM’s Workspace. But most of all it means seeing LLMs as another tool for me to master and use effectively. At the end of the day, I'm still responsible for the code I commit.

Rembrandt gave software developers a model to follow in the age of AI. Sketch the vision, hand off routine brushwork, and preserve your own time and attention for what matters most.