It was never about coding

"With the AI doing the coding, do we just spend all day reviewing its output?" The rapid onset of impressively capable coding agents continues to raise this question in conversations with peers, to press interviews, to podcasts. I remain an optimist, convinced that this is the magical technology I've always wanted - a way to get more done, in less time, with higher polish than before. I can reach further into my backlog than ever before, reaching for the nice-to-have tasks that were triaged out of every sprint plan.

While I used to spend a lot of time interacting directly with code - writing, reviewing, debugging, fixing, refactoring, and operating (dealing with the consequences of mistakes), I have always viewed that as only part of my job: a means to an end, not the end. So then what is my job?

What's in a name?

When I tell people what I do, sometimes I say "programmer" to have a short, understandable, and non-pretentious sounding description of my job to people who don't code. But that's not my job title. The thought of being called a "coder" somehow feels almost derogatory, because of how shallow or superficial it is as a description of what I do. It's one of the things I was hired to do, but it's not the full picture at all, often not the hard part, and not my job title. So what is my job?

What about Software Architect? Well I'm not a Software Architect. I love hearing Real Architects describe the concepts around buildings - their design, aesthetic, married with function and usability for the people who occupy them, with adaptability toward future unknown use. My friend of 23 years and college roommate for 3 of those, Steve, is an architect, and whenever we are near or in a building, I love it when he goes on an explanation of the things about buildings that are not obvious to a non-architect like me. He describes the customer - the people in or around the building - and how the design is meant to be intuitive, helpful, but grounded in the reality of the tradeoffs of physics and cost to build. A lot of the Architect title sounds like what I do day to day when it comes to designing systems and how they meet my customer's needs, but still, Software Architect isn't my job.

Some people describe the job as Software Engineering. While I'm not technically an engineer from a professional license standpoint, there are plenty of parallels to what real engineers do. For example, Civil Engineers don't build bridges. They design, they plan, they model, they test, they measure, they feel the weight of responsibility for safety and resilience, scale, and they reflect on the process that they go through along the way to make sure it's right. That same friend Steve also has a Civil Engineering degree in addition to being an Architect, which is a hell of a combination. With both architecture and engineering degrees, he works across both worlds: the artistic, focusing on the beauty of design and the lives of the people who occupy the buildings, and also the unglamorous but life-safety behind-the-scenes reality of what it takes to prove that a design can be brought into reality. While I can draw connections to the testing, simulation, and planning work I do in the digital world, Software Engineer is not my job either.

So what is my job? My job title is Software Development Engineer. Isn't that the same thing as Software Engineer? Well it has an extra word in there, so I guess not. That extra word, "Development", is a process. The "Engineer" term is a modifier on "Development". So that means I'm engineering the process of software development. But that sounds like a pedantic unimportant difference, like Michael Scott correcting Dwight Schrute's title as being Assistant TO the Regional Manager. But if I think about what I've been doing for the last 20 years, the work I've done around process has been more lasting and impactful than the code. For a given project, I'm working on design, implementation, testing, and operations. But the most impactful and durable parts of that work are the in-betweens where I'm making those things easier the next time around. If something didn't go quite right the first time around, I make sure that I, and my team, or organization, doesn't make that same mistake or hit that roadblock the next time around. Essentially, when instead of engineering the software, I'm engineering the process of engineering the software.

Of course this distinction of "SDE" vs "SWE" is a convenient play on words. Even though role names and responsibility vary across companies, I think these roles are actually equivalent and all focus on all of these aspects, from designing to building, to maintaining. And all throughout that, people in these roles spend time and effort trying to improve their process to take things they've learned and somehow "codify" for themselves and for their teams so that things are better the next time around. (Wait, the word "codify" also looks similar to "coding"! Foreshadowing!)

What does software development look like today?

Building software today is a lot like an automated factory. An idea gets turned into a requirements and design, which gets turned into code, which gets tested, merged, and deployed. But it's a little different than a linear assembly line, where a conveyor belt moves a product (or in this case a "feature") from one stage to the next. Like a conveyor belt style, this one has tons of quality gates. When a feature, design choice, or important decision needs to be addressed by a human, the feature is set aside until someone answers, and then the feature resumes its path on the assembly line. In the meantime, the rest of the features move forward on the assembly line. But maybe unlike an assembly line, this one has loops. The in-progress code change gets sent back for rework a ton of times until the tests pass and all of the quality gates approve it. It also has merges where features (commits) come together into the mainline branch, and they're further tested and released together. If these tests fail, there's a different loop in the assembly line that figures out what to do about the failure. It triages, and figures out which commit broke the tests or the deployment, and finds the best way to unblock the assembly line. It might either rush a patch while more changes pile up, or find and kick out the offending change and let the rest of the feature development advance.

In a sense, this is a lot like a normal agentic loop. In a nutshell, agents are super simple - a while() loop that tries something, sees if it's done, and if not, tries something a little different. But it's more complicated than that. We can't just take a coding agent and say, "Hey design and build this feature. Make no mistakes." The agent won't follow my rules, might make decisions or assumptions I don't want it to make, could break my application, or any number of things. So this factory is all about having the right deterministic checks and gates in place so that it can't proceed until its work is correct (verified by tests and testing agents, and sometimes humans), and done the way I want it (verified by agents and sometimes humans).

The machinery to drive the factory is rapidly changing, with new tools sprouting up every day. It seems like every 3rd person I meet has made their own. There are a ton of open source ones out there, from Gas Town to more unopinionated building-block tools like Kiro Crew.

So where do I fit into this as an SDE? When coding agents first came out, it started with me pressing "yes, approve this tool use", and copy-pasting error messages from one tool to the next. Sure it was an improvement over doing everything myself sometimes, compared to copy-pasting the error into stack overflow and fixing the error myself. But it wasn't a huge step function multiplier advancement in productivity.

To get that big improvement, I - and my team - had to change from babysitting the agents to nurturing them. We spend our time focusing on building and tuning the machinery, so that we can be in the way of the assembly line only when we truly want and need to be to make sure the right things happen.

Unlike physical factories that make physical things, software factories are easy to change. There's no need to move heavy machinery around the factory floor. Improving the factory can be as simple as adding a bullet point to an AGENTS.md file. Or better yet, having an agent run periodically to find rough spots in the process from looking at past runs, and propose changes to the factory code and configuration to improve it.

So then what is my job?

Every day I'm defining, designing, evaluating, and shipping things for my customers. I have more time than before to listen to their needs, respond to their questions. I have more time to be curious and dig in about the operational performance of my systems, and look around corners. But the biggest flywheel comes from continuously improving the software factory.

Clare Liguori wrote the Frontier engineering manifesto that breaks down how we at Amazon approach software development in this new world. It describes a shift in mindset and effort, toward focusing on the process of making sure the coding agents are held to the standards that you set for yourself. It's a good read. Principal Engineers across Amazon weighed in on it, but Clare is the mastermind who brought it all together in this compact and dense form. Here's a short version.

• You are the architect, not the typist. Write intent, direction, and targeted review of what you want.
• Maximize agent time, minimize your involvement. Rethink when you need to be involved in a coding agent's session. Challenge yourself to have multiple sessions running in parallel, and structure their tasks so they won't constantly nag.
• Build your codebase for agents. A new human team member onboards to your team once and maybe every few months or years. With agents, you have team members onboarding 1,000 times a day.
• Give agents a fast feedback loop. Give your agents the tools they need to run fast, local tests that are as end-to-end as possible. Give the agent a web browser tool to do its own evaluation of the interfaces it touches.
• Execution is cheap. Direction is everything. Collaborate back and forth with the agent at the important points, like on design and definition.
• Treat code as disposable. It's way easier to discard and replace than ever before.
• Hold AI output to human standards. With a well designed factory, you can get higher quality code than before.
• Trust the boundaries, not the agent. Put the agent in a sandbox with a thoughtful boundary.
• Use agents for everything, not just code. I even used an agent to find my lost coffee mug, which was missing for weeks.
• Continuously tune your agent setup. I view every steering I have to do as a possible defect in my factory.

As a Software Development Engineer, I build and tune the factory. I add review agents and improve their steering, direct the agent to write better tests, review their output (but strategically at just the right time and just the right way), look at the process to see where I'm wasting time or where the agent is getting stuck. But what does this mean? The Frontier engineering manifesto describes the types of things I spend time on at a high-level, but for blog form, stay tuned for part two!