There is nothing like the feeling of "greenfield" coding - writing something new in code from the ground up. An empty editor on your screen, beverage of choice within easy reach, an open day in front of you, and a beautiful but complex tapestry of thoughts just waiting to be expressed and turned into a fully functional machine. It's as though you're breathing life into a new being.

This feeling is so psychologically compelling that it skews the focus of developer tooling. IDEs are easiest to work with when writing a file from beginning to end. Tutorials walk you through the process of building "Hello World" into a mildly interesting but not useful prototype. Job postings tend to focus on the cool things you'll build rather than the important things you'll fix. And now there's generative AI that will build an entire app from scratch into a preliminary first version for you.

Let's take a look at the data. If we completely optimize away the process of green field coding (the part that developers love) by handing it over to fancy tooling and generative AI, how much time and effort will we really save?

Studies show that developers spend 60%-90% of their time on maintaining existing projects, and 10%-40% on new projects. But, but, building a new project isn't just writing code. It also involves testing, bug fixing, documenting, and communicating status. Writing the code turns out to be 20%-40% of that time spent. And, it's not like the code is literally written from beginning-to-end in one continuous thought. So let's - conservatively - cut that time spent on fresh code down to 10%-20% of new projects.

10-20% of 10-40%...so that means developers spend at best 1% - 8% of their time writing from-scratch code.

Let's take a step back for a moment and consider the order-of-magnitude leverage here. A different way of looking at this: on average every new unit of code generates a minimum of 10x its maintenance cost.

So why are we building tooling that simplifies the process of writing new code?

We're doubling down on an industry where low-quality code is produced in droves, causing ever-spiraling bloat and maintenance costs. Any high-quality engineers who inherit this maintenance cost have low morale, are uninspired and therefore unproductive.

I've discussed the topic of AI-assisted coding with many developers. The sentiment is largely similar: neat technology, somewhat useful but not a panacea, and moderate concern about obsoletion. The most common "big win" I hear about: writing unit tests.

Writing tests! Developers hate doing it! It's incredibly important! It's a rote and repetitive process - perfect for AI! This is the way.

Don't give me an AI that writes from-scratch code that I drive myself crazy maintaining. Instead, give me AI that writes tests for me, writes documentation for me, determines and communicates status for me, helps me understand existing complex projects, and helps find errors in my code for me. Take away all the boring and routine and easy stuff so that I can focus on being, well...human - learning about the problem space, understanding the customer, and translating that knowledge into problem solutions. The AI can't do that for me.

And after all of those problems have been solved, build the AI that helps me improve my coding skills so that my first-pass code has less maintenance cost.

Put all this together and it's not just a recipe for improving AI assistance to coders. It's actually a roadmap to becoming a better engineer. Carefully consider that 10-1 ratio we discussed above - eliminate the behaviors that cause it to grow and double-down on the behaviors that cause it to shrink. This is the path to a more fulfilling and productive career as an engineer.

Which is why the veteran engineers I know aren't using AI just to write code (and when they do they tend to use it for very focused and specific use-cases). They're also finding ways to leverage AI for all that other stuff - drafting documents, summarizing white papers, learning and understanding. There's lots of ground to cover already, although I'd argue in these early stages that the tooling is still quite raw, and we'll see it converge to be more use-case specific over time. For now adopting AI often requires a little creativity, hackery, and self-awareness.

If you're an engineer worried about obsolescence to AI (or worse yet an engineer who rejects AI assistance as unhelpful), it's not the AI writing code on your behalf that you should be worried about, it's all that other stuff. Programmers who understand the leverage I described above use AI to make themselves more proficient and knowledgeable in more than just coding, and therefore become better engineers.