Writes vs Talks About Software

Getting good results out of AI-assisted coding might be harder for some.

Some people in engineering organizations spend a lot of their time writing code, some people in an engineering organization spend a lot of their time talking about code.

Everyone else falls somewhere in the middle.

Everyone in the software industry with a few grey hairs looks back on this time in their career with rose colored glasses. It was just you your computer and pure grit and determination. The reality probably looked more like you flailing with unclear tasks and if you were lucky leadership that gave you a few hours a week of guidance on how to better accomplish your tasks. A lot of your time was spent reading questionable code and documentation and trying to divine how that might inform you getting your work done. Even though well-designed training programs and explicit mentorship would probably produce better results aspiring software engineers that run this gauntlet and survive pick up a lot of useful skills along the way.

Junior developers spend their day knee deep in code and their hands on keyboard time is the highest in the company. This is where you develop opinions about what makes software good and slowly learn how to turn bad into good yourself.

For people finding themselves in this situation AI-coding tools are a bit of a trap, you haven’t yet learned how to specify what you want, you are still developing opinions about good and bad code, and having a bot slinging way more examples at you than you can possibly consume can be more confusing than it is helpful. At least Stack Overflow had comments and discussions to provide you some context to learn from.

I’m jumping right past senior engineers as they share traits with both junior and staff and can skew heavily one way or the other in terms of their hands on keyboard desires and time. Staff engineers are tasked with thinking about software problems at a higher level. Typically they will have spent several years in the trenches writing and wrestling with code problems, and are now expected to think outside of the narrow scope of the singular application and start to think about:

1. How does this piece of software interact with other pieces of software

2. How is this hosted, tested, validated, monitored

3. What are the business problems that inform the need for this software

4. How do I decompose a very large project into smaller pieces for multiple individuals

Knowing all of that information and being able to selectively provide the coding tool with this type of information can produce very good results. Working with AI tools can feel a lot more like being in a never-ending planning meeting than it feels like being up at 2am composing interfaces and refactoring functions.

A lot of staff engineers or people with equivalent experience seem to be producing very good outcomes using AI tools. They were thinking about how to provide just the right amount of context to humans before any of us were thinking about how to provide that to models. They have strong opinions about the structure of the code and the architecture of the whole system. They can’t afford the luxury of ignoring quality but they know the right time to trade quality for speed.

At this point in your career you are thinking a lot more about stakeholders, business context, resourcing, headcount and how that will inform what software gets built and when it gets built than you are thinking about the details.

You may be producing very good results with AI tooling on your side projects or weekend projects where you control all the variables. You are probably pretty excited that you can produce heaps of working code with your rusty programming skills and software experience. The risk is that you have also forgotten some of those hard won junior engineer lessons on what makes a codebase pleasurable or painful to work with over time and may be plowing past that risk in your excitement.

Engineering managers have had to get very good at describing the type of software they want to see always riding that blurred line between being too prescriptive and too vague. It just so happens that this sweetspot is also where AI agents can do some of their best work. Agents do best given clear constraints on the functionality and some freedom on the implementation details just like individual engineers. The best managers seem to make the best orchestrators.

This is the only role in this scheme that I have not held myself, so my extrapolation may be working a little harder here. Product managers are constantly thinking about features and functionality but are rarely thinking about the shape or quality of the software.

Engineers and engineering leaders tend to get stuck in the tactical which is leaving a lot of potential capability from the AI tool on the table.

Product and business leaders have none of these qualms and have been pushing these AI tools very hard, pasting in a PRD and seeing what results. Always eager to please the AI tools will throw together a messy prototype using a popular language or framework gaslighting the user into thinking they have a fully functional production ready piece of software. This creates a big risk of people on the far right of the diagram wrongly thinking all the hard parts are now easy.

I’ve never met an engineer that says their favorite part of their week is planning meetings. Unfortunately feeding the AI machine involves a lot of planning and constantly maintaining a healthy backlog. The AI itself can help with this, but this is the place where personal judgement is most important and you are risking some chaos if you pass too much of this responsibility off to the AI. For the junior engineers that hate their once monthly planning meetings and story points exercises, here’s a little surprise, everyone above you spends way more of their time planning. An experienced manager can fill a backlog in hours if not minutes.

The unsurprising and predictable truth is that we are all going to have to work together a lot better than we have in the past to continue to produce great results in this new reality. Junior engineers don’t have the experience or information to fill their own backlog, and product owners can’t get a production application back online at 3am. Product needs to accelerate the idea pipeline and engineering managers need to start thinking on an accelerated timeline worrying about token budgets as much as headcount.

The age of agent orchestration is here, and everything only accelerates from here.