Another Skill

The first day of my first college programming course, the instructor said: “This is one of the only courses at this university that teaches a skill.” I’ve never forgotten that. I like doing things, and I was excited to learn the skill of programming. I learned it, I practiced it, I got good at it, and I did it for a long time.

Perhaps this seems obvious. But people sometimes treat agentic development as more akin to magic:

1. Users who conclude, when they aren’t having good results, that it must not work at all, when they’re just not good at it yet.
2. Developers who believe that as soon as you start working with coding agents you’ll immediately be great at it.
3. Educators who worry that, once we stop teaching classical programming, there’ll be nothing left for students to learn.

Coding agents can feel like magic initially, when you’re used to coding by hand. But once you adjust to their capabilities they start feeling familiar, another tool that rewards skillful use.

Several implications are clear. People who want to create software should learn agentic development. They should expect that to take practice. Educators should determine how to teach this new skill. Until we do, we should not stop students from practicing.

There’s also one less-obvious conclusion I’m drawing from watching experienced developers begin using coding agents. Nearly every developer today who learned computing in college went through a traditional computing degree curriculum. Not all of them are succeeding at agentic development. I think educators hope that, until we update our programs, a classical computing education prepares students to succeed at agentic development. I’m not sure that’s entirely true. It’s probably better than nothing, but also worse than it could be.

What enables success at agentic development? How should we be teaching our students? I don’t have the answer, I can only speculate from watching myself learn this new skill.

I was trained in computer systems. My sense is that, compared with other subfields, computer systems spends more time zoomed out and less zoomed in, providing a better overview of computing. Working with coding agents sometimes feels like working as a general contractor, guiding a team of specialists to create something complete. Systems people also identify most development decisions as tradeoffs. It’s true today that coding agents make rapid pivots much easier. But making tradeoffs well still accelerates development, even if swapping between algorithms, databases, or cloud providers is now much quicker. And just knowing that certain tradeoffs exist improves your ability to guide your agents.

I’ve worked for decades as an independent solo developer. Partly by choice: I’ve enjoyed learning about a variety of different aspects of computing. Partly by necessity: As an educator building educational software, I’ve never worked with a team of full-time developers⁽¹⁾. I maintain entire user-facing systems: frontend interfaces, backend private cloud orchestrators, and everything in between. I suspect that my breadth of knowledge contributes to my ability to collaborate with coding agents.

I was also reasonably attentive to good development practices like testing and linting—which are invaluable when you work on a large number of projects. Drop in, run the tests, reproduce the failure with a new test, fix that test, confirm everything else still works, deploy the fix, switch projects, start over, eventually it’s lunchtime. That’s essentially the same workflow my agents use now—minus lunchtime—and it allows them to make progress unsupervised. All my projects now have extensive test suites, written by the agents as they add features and fix mistakes.

I’ve spent several decades describing computer systems in writing—papers, grants, proposals, emails, designs, slides, assessments. I learned how to do this largely through practice, and I was lucky to have a doctoral adviser who wrote well and cared about writing quality. To quote, again, one of my favorite essays on coding agents by Kailash Nadh: “An experienced developer who can talk well, that is, imagine, articulate, define problem statements, architect and engineer, has a massive advantage over someone who cannot, more disproportionately than ever.” I’d go farther. Today, the definition of an experienced developer is someone who can talk well. Code that an agent can write in seconds is no longer evidence of expertise. What’s left, and what’s now scarce, is the ability to specify what should be built and recognize when it has been.

You may be wondering: Didn’t you write code for multiple decades? That must help, right?

There has to be a better way. Determining what knowledge leads to success at agentic development and how to impart it to students—these are the urgent questions facing computing education.