Many software engineers will tell you that their day-to-day work has changed dramatically over the last year thanks to the AI boom and company expectations about developer productivity. Even just one year ago these tools didn't have nearly as big an impact. Some bleeding-edge developers were exploring agentic AI, others were leveraging ChatGPT as a super-powered search tool, and some were writing code blissfully unaware of the change the coming months would bring. The casual conversations in engineering circles have shifted from tabs-vs-spaces, which language is best, microservice-vs-monolith, and buy-vs-build to which model codes vs plans better, which MCPs and skills we're using, and "context engineering".

Company expectations for engineers have never been higher; not only are companies paying steep salaries for highly skilled talent, but now they are also paying (sometimes) exorbitant token usage costs and reading headlines about companies and individuals who have single-handedly "vibe-coded" replacements for expensive SaaS products. In an industry where layoffs are common, these heightened expectations have made many engineers feel even less confident about their standing within a company.

I've often prided myself on my unique blend of quality, velocity, and communication. However, agentic development using a decent model on an appropriately scoped problem normalizes quality and velocity across the board. Said simply: AI has made good, fast solutions easy to find. So what's left for me as an engineer to pride myself on? Where's the craftsmanship I got into this field for? Communication? No, that's just a bonus modifier that helps when I talk to stakeholders or my peers; being the most charismatic and eloquent person in the room doesn't actually get the job done.

Looking at our process for what it is today can help answer those questions. Rather than compare what we do today to what we did last year and ask "how can I get any better," we need to look at what we're doing today objectively. It might sound shocking to some, but the software development lifecycle hasn't changed at all. As a reminder, these are the key steps to turning an idea into enterprise software:

  • Ideation
  • Discovery
  • Design
  • Development
  • Verification
  • Delivery
  • Observation

This post isn't going to explain those in detail, and I leave ideation out entirely because it deserves its own post. I will call out that things like prioritization, resourcing, and approvals are mixed in as well. However, those are the irrefutable stages that good software goes through.

It's easier to see that AI hasn't completely changed the game when you see it laid out like that. Sure, development is now generally quick and good quality, but what about the rest of the stages? The benefits of AI vary at different stages, and I've seen engineers use it effectively to complement their activities in different ways. It only seems to serve as a true drop-in replacement when isolated to writing code, which is one aspect of the development and verification stages.

I think the craftsmanship of engineering is exactly where it always has been: everywhere. The stages haven't changed, but where and how we spend our effort has.

We've all been in this situation before: you're working on a project, collaborating with your peers, debating the merits of a particular solution, the value of certain tests, or the rollout strategy for a feature you're nearly done implementing. You call a meeting to get feedback or approval from a wider audience, and a high-level engineer catches you off guard with a question like "why are we doing this instead of X?" You take a moment to gather your thoughts, probably act a little defensive depending on how far along you are on the project, and answer. Before you know it, the meeting has gone sideways, focusing on a question you hadn't considered until now.

This is a process failure all too common in this industry, and it typically happens when there are two major forces at play: stakeholders or leadership are motivated to accelerate a project's timeline and the engineer(s) responsible for implementation have a clear idea of what the code will look like. The engineer will jump into development, having skimped on the previous stages, and the stakeholders are happy to let it happen because oftentimes the sooner you start development, the sooner you finish the project.

This failure mode is much easier to capture now that we've removed the romance from development. At least for me, the idea that AI is writing the code and not me has resulted in me feeling less emotionally connected to any particular implementation. What matters to me now is not the same as what mattered to me a year ago with respect to the actual code that gets written. With that emotion removed, I'm more interested in making sure I'm not asking AI to do something dumb. This shift in focus is small, but it's what disarms the engineers who previously asked "why not X?" I've had the time and focus to think through a much wider range of possibilities and concretely document why or why not.

At the outset of my AI adoption era, I spent too long trying to make every problem "one-shottable". This means I would feed in one prompt, and the problem would get solved. I realized over time that I need to properly spec out the problem. This has resulted in more standardized "spec" files in my own research repositories. I gather supporting documentation, artifacts, prior art, relevant (transcribed) conversations or meeting notes, and put them together alongside this spec. My job is to organize everything I think is relevant into a format that the model can digest, with a goal of reducing the time spent leveraging MCPs or exploring the codebase(s) for answers. This has become my new process for discovery.

The outcome of discovery is a plan: all of the major milestones that will get us from point A to point B. Just like working on a big project with multiple engineers, it's a bad idea to hand someone milestone names and say "go do this," so you need to expand them into sub-plans. This is where the process somewhat repeats for design. I'll take a particular milestone, create a design-spec for it, feed in relevant artifacts and ideas I have for how implementation can go, and iterate. I'll collaborate with my peers for ideas and read articles myself, but all roads lead back to that design-spec. Eventually I'll produce milestone plans that can be handed off to an engineer or an agent for implementation.

The funny thing is that this process isn't all that different from what good engineers have always been doing. I don't categorize myself as always having been a good engineer, either, so don't take this as some humble-brag about how great I am. My point is that when I'm less emotionally connected to the actual code that's being written, and that code is being written much faster than it previously was, I have more time for other engineering activities. I've also realized that the better prep you do, the better implementation you get, and better implementations often lead to easier releases and require less monitoring. So it makes sense that I took this time and reinvested it upstream into discovery and design processes.

The biggest beneficiary for me has been verification. An agent often produces more test coverage than actual implementation, which means I spend much more time reviewing tests. The effort shifts to weeding out the wasteful tests and asserting that the meaningful requirements are covered, instead of dealing with the test-framework-of-the-day in a particular repository. Oftentimes manual testing can be supplemented by AI putting together a script that stages data just the right way for me, so my work is reduced to pushing a couple of buttons and using my eyes.

This also allows you to spend more time thinking about delivery and observation. Again, speaking from my perspective, creating dashboards and thinking about sequenced releases is a lot less fun than debating what methods belong on what interface to form a coherent set of contracts within a system. But the former is a lot more valuable to the overall success of a project than the latter.

When you are spending more time thinking through the big-picture plan and the milestones that will get you there, it's easier to catch gaps in the would-be release plan. Out-of-order milestones or implicit dependencies will become obvious more quickly, and these "small oversights" are typically very costly when caught late. Good release planning often goes unseen because the side effect is that the project just gets released.

Good design plans for observation. You can't know whether you'll succeed if you don't know how to measure that success; that's always been true, but it's easier to acknowledge when you have space for it and care enough. Leveraging AI here simply means not having to hand-write the queries that will power those dashboards or scrutinize the joins and table indices.

So when I say craftsmanship is everywhere, I mean it. It always has been. Agentic development has allowed me to apply my craft more evenly across all stages of the SDLC instead of prioritizing the craftsmanship of writing and architecting code. If I had a crystal ball and could tell you how to ensure job security, I probably wouldn't have written this article. But if you feel like AI has stolen your value as an engineer, it hasn't. It forced you to put your energy elsewhere.

This is an ongoing adventure, and that's why it's called a career, so check back in a year to see if I still feel this way. I've realized lately that what I love about engineering is still a critical part of the job, and the craftsmanship is far from gone. Maybe I'll write less code by hand over the next fifteen years than I did over the previous fifteen, but I'll surely be thinking about it a lot more than ever. That's what excites me the most: I get more time to think through how solutions should be implemented, and I'm no longer limited by my own knowledge of a particular programming language or my bias for particular typing patterns. I feel truly empowered to execute my best ideas faster than ever before at the cost of having to express them in agonizing detail.