From Programmer to Director

Introduction

If agents are better than me at writing code, what’s my job? How long will I still have one? Every individual contributor in a software engineering role has been forced to confront this unsettling open question. In this article, I’ll share some of my software development journey and how I have reconsidered my role in recent months.

Where I Started

I started working as a software engineer in September 2022, shortly before ChatGPT was released to the public. I am not an “AI-native” developer; I slowly integrated AI into my workflow as it proved more capable.

I learned to program with Python, C, JavaScript, and Java. I settled on being mostly a VS Code user, writing web applications in .NET and React. As such, the first AI tool that meaningfully extended my capability was the VS Code extension for GitHub Copilot.
I was already comfortable with an existing ‘autocomplete’ workflow driven by IntelliSense and language servers (LSPs). Copilot offered the next logical step in this development workflow.
Instead of suggesting the next word or auto-importing a module I referenced, Copilot would suggest a whole new function or author a suite of unit tests to cover the function I was writing.

This approach was an augmentation of my existing ability to be a Programmer. It didn’t represent a paradigm shift in how I reasoned about my work.

Where I Am

I don’t work in an IDE anymore. I work in the terminal with Claude Code almost exclusively, jumping into an Obsidian notebook to review plans and reports, all authored by AI.
For more involved planning sessions, I’ll jump into a browser to iterate on rich HTML documents generated by conversations with Claude Artifacts or the lavish skill.

This represents a major upwards shift in my focus. My approach has moved up and away from reasoning like a Programmer, towards thinking like a Director. I’m less concerned with spot checking syntax, and more concerned with specifying goals and constraints for my system.

What My Role Is

The difficult problem in software development is not producing good programs. It’s producing the right program for a given business context.
Identifying a right path requires digesting domain and architectural constraints to produce verifiable acceptance criteria.
As a Programmer, I was often handed constraints and criteria from the product team. As a Director, I’m involving myself at a higher level of these conversations, and handing off slices of my understanding to a team of agents who implement it for me.

Today, I work on a municipal fund accounting system, still with a “Full-Stack Web Developer” title. But my day-to-day is research into the accounting domain, meetings with stakeholders, and formalizing requirements that incorporate both streams of information.
Once the requirements exist, I breathe a sigh of relief, press play, and walk away. Agents implement, review, iterate, and produce a verification record. Then it’s my hands again to assess the evidence they provide and apply my judgement.

Summary

Engineering with agents is a paradigm shift for software developers. We are facing a new class of problems. It’s not enough to augment our previous approach; we need to explore novel paths forward and accept additional responsibilities.

Ignoring this paradigm shift and continuing to be a Programmer would limit my ability to succeed. Embracing a new level of abstraction as an agent Director and involving myself more meaningfully with business concerns, is how I will continue to be relevant and effective in a new age of software engineering.