Do the Hard Thing

Negotiating AI's role in the workplace

Forty years after Fred Brooks’ paper, there is still no silver bullet, though software engineers remain as trigger-happy as ever.

Citrini Research’s epic troll of the entire stock market was a lot of fun, assuming you were not, say, a DoorDash investor. But the anxieties it fed upon were not novel. The dream of a tool that could allow businesspeople to write their own software, replacing programmers entirely, is older than his 1986 paper. From 4GL to low-code and no-code tools, this idea that a tool could turn intent into software has been every programmer’s Janus-faced nightmare: something that could make your job much easier would also be something that could make your job obsolete.

This is not at all to understate the power of AI’s application to software engineering. A historical perspective only takes you so far. But if you haven’t read Brooks’ paper, now might be a good time. It has aged well:

The essence of a software entity is a construct of interlocking concepts …. This essence is abstract, in that the conceptual construct is the same under many different representations.

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation ….

If this is true, building software will always be hard.

The starting point for any creative project — not just software — is the vision of what you want to create. Writing code is no more the essence of software engineering than typing is the essence of novel-writing. I have always believed that part of the value of a great software engineer in a business context is his or her ability to think systematically and abstractly about business processes: to see that the task to be automated is not the act of feeding paper into a FAX machine or updating seven spreadsheets, but to confirm a trade or prepare a financial statement.

Representing and testing the fidelity of that understanding takes time — less and less time as programming languages have evolved; much less with AI — but the essential work is still conceptual. Nothing humbles you like thinking you understand a problem and then struggling to explain it. You realize it’s actually all junk and confusion in a warm bath of good vibes once you try to make it concrete.

Still, the more time I spend doing AI-assisted engineering, I think there are anti-patterns emerging in how people use the technology.

AI can be used at three levels:

1. Automating the trivial: AI is already capable of doing well-bounded tasks exceptionally well, and for these it can eliminate almost all effort.

2. Accelerating the mundane: In a co-pilot mode, a software engineer can produce the same output much faster. The time spent moved from production of code to its refinement through an iterative process, but the final product is the same.

3. Expanding what’s possible: AI assistance is used more like an intellectual exoskeleton to do things impossible without its help. Reports of AI brain fry might come from overdoing it in this mode.

The problems with working at Level 1 should be fairly obvious. If too much of your job can be done this way, the value of your contribution collapses. Some portions of outsourcing industry could sustain heavy damage: unsophisticated output sugar-coated with labor arbitrage cost savings doesn’t add enough value. Personally I think there is less of this than the doom-mongers claim, but it’s not zero.

The issues at Level 2 are more subtle. Laboring at the jagged edge of AI competency does add value, and the potential for increased productivity in skilled hands is high. There is still work to be done in tooling and process changes. Likely the nimbler startups and scale-ups will figure that out sooner than larger company IT shops. It’s another old story — startups win when they get distribution faster than incumbents get innovation. Still, this is just a matter of diffusion rate. Eventually the knowledge will spread across the software industry.

The problems here are for the individual software engineer, and economics. AI productivity increases are a classic surplus. Who gains from that surplus? I would argue that if your job is mostly operating at Level 2, it’s not without value, but the lion’s share of gains from faster development will accrue to your employer. If your value-add is to produce the same output faster, the company can grow engineering talent sub-linearly. This kind of surplus doesn’t make you more valuable.

As it happens, this trend also hurts early stage venture capital if all the VC is doing is writing a check: the capital requirements to get to Series A and beyond are lower now. It’s easier to self-fund or get off the ground with friends & family and angel checks alone. Expect to hear early-stage VC firms trumpeting even more their ability to coach founders, refer prospects and smooth the way to later stage.

This brings us to Level 3. AI-assisted engineering can allow an individual developer or small team of developers to increase their ambitions with regard to complexity, not just time. As I have grown older, there are things I can no longer do. I don’t have the time or energy to hit the high notes any longer, or do multi-hour benders of heads-down coding. Over a 30 year period I switched from C++ to Java and then to Python: moving down the curve in language difficulty. It is hard to acknowledge but a lot is well beyond reach now. However, recently I started a hobbyist high-performance computing project in modern C++. The only way I was able to tackle this is by maximizing use of AI: not just for speed, but to dial up the difficulty level.

We are already starting to see some daft management practices with the rise of AI. Junior developers being told they are not allowed to code. Performance reviews based on token consumption. Mandates to use specific tools, without enough emphasis on first figuring out how best to apply those tools. The whole my-business-is-failing-but-AI-sounds-like-a-better-reason-for-layoffs thing. They are daft because they erode people’s ability to operate at a much higher level: all cost, no benefit. If you want to run 100 miles per hour with help, first you need to know how to run.

Want to get the most out of all of it? First, focus on fundamentals. If your employer is telling you it’s not worth learning to code because of AI, find another job. Seriously. And then remember that it is far easier to divide a bigger pie. Going after previously-impossible problems has the potential to generate a much larger surplus. It’s no longer just about increased productivity — which could just fall through to the company’s bottom line in the form of lower R&D costs — but greater innovation. To the degree you make that happen, you indisputably add value. Finally, even with all that, remember Brooks: there is no silver bullet, still. Software will always be hard, because understanding what’s needed and articulating a solution is hard.

Do the hard thing.