My Software Engineers Need a New Job Title

Most of the people at NGS have "Software Engineer" on their offer letter. I think that title is wrong now, and I don't have a better one yet.

A few weeks ago we wrapped up something we called Claude Days of Summer. Everybody got time to take a project, push Claude as hard as they could, and show the team what came out the other side. I learned more about what my team's job actually is from that one meeting than from anything else this year.

Gary had a side project, a DraftKings lineup optimizer he'd been running off the command line every Sunday for years. Pull the rosters, ingest somebody else's projection list, run his genetic solver, screenshot the results, send them to Discord. He gave himself 8 hours to turn it into a real hosted app with Google login and a decent UI. That took about 4. So with the other 4 he had Claude build the machine learning model for player projections that he'd been paying someone else for. Then he added a weather map for the stadiums because why not.

Gary didn't write much code that day. He decided what the app should be, who gets in (our domain and a short list of his buddies), where it runs, and how it deploys. That's a product owner, an architect, and an ops guy.

Brian is pushing GeoHub toward a multi-tenant SaaS with agents running pretty much around the clock opening PRs. His biggest problem wasn't code at all. It was "what's version 1?" Ask Claude what's next and it'll happily give you ten more things, forever. Somebody has to say stop, and that somebody is Brian. (Claude also occasionally decides it's done enough for the day and suggests he get some sleep. Brian did not take the advice.)

Cole went the other direction. He told us he normally uses Claude as little as possible, so he had it build a notification system for MedCOP one commit at a time. Go backend, Postgres notify channels on watched tables, server sent events to the front end. He reviewed every commit and made it simplify anything he didn't understand. He was the reviewer and the tech lead the whole way through, and he came out of it knowing exactly what to write up for the ticket.

Chris made a point that stuck with me. Left alone, agents don't really follow design patterns. They just plug things in using that massive context window, and good luck following what it did afterward. So somebody has to set the architecture up front. Brian's trick is to have the big model write a plan detailed enough that a cheaper, faster model can execute it. That's a software architect handing a spec to a dev team. The dev team just happens to be Sonnet.

And somebody has to check the work. A friend of ours who runs a large software company told us they use a separate tool to QA Claude, because Claude thinks everything it writes is great. It does.

So add it up. My engineers are deciding what to build and when to stop, setting priorities on what gets fixed next, picking the architecture, deciding where things run and how secrets get handled, and reviewing output. That's product owner, scrum master, PM, architect, and QA rolled into one person. The typing is the part the agent does.

None of this works without the people driving it. The tool is very powerful, but the magic is really in your brains. These guys have been doing this long enough that the decisions come naturally, and that's the part Claude can't do for them.

People ask me if this means we stop hiring junior developers. I think it's the opposite. A junior dev today can learn to code the same way we did, by building stuff and breaking it. They just have a tool that'll explain every line and stand up a working prototype in an afternoon. Getting the code to run used to eat most of your day. Now that part's mostly handled, so they get to spend their time on the questions that actually decide whether a product is any good. What should this thing do? Will it hold up past 10 users? Who has access to what, and where are the keys? How do I know it's broken before the customer calls me?

That's product design, scalability, security and observability. Good engineers have always been separated by those things. The new ones just get to start there.

So I still need a job title. If you've got a good one send it my way. Best suggestion gets a lineup from Gary's optimizer.