The AI-Era Engineer

After developing software, including production systems, exclusively using AI for more than a year now, I have been trying to identify and codify the patterns that work best for AI-assisted development, as well as define the AI-Augmented Engineer profile that can adapt best to software development in the AI era.

In the last several months, I have put together a series of reusable rules and patterns that leverage documentation as the best context for AI-assisted development, managing the constraints of LLM context boundaries, and that emphasize self-documenting repos where an LLM can easily "catch up" with the status of the repo and can accurately initiate sessions with little to no effort by the developer.

This is very close to spec-driven AI development, and I have noticed it is where the industry is converging. In particular, the focus is to curb the runaway trains that LLMs are when receiving open-ended prompts, which lead to endless lines of code, documentation, and unexpected (and undesired) assumptions.

As I feel confident that this type of methodology (if I can call it that) is decently successful, I wanted to focus more on the question of what the right engineer profile is for developing production-quality enterprise software using AI assistants.

Engineering as It Should Have Been

When we look at what makes a successful AI-era engineer, we realize it is almost no different from what good software engineering has always demanded. Systems thinking, iterative design and coding, clear specifications, quality verification, product awareness — this is what we should have been doing for decades. Most of us never had the time. We were too busy writing code.

AI changes that equation. When LLMs take on the bulk of code writing, engineers finally have the space to do all of the things that make software good, not just functional. The training, mentoring, and hiring of engineers should emphasize these skills not because they are new, but because for the first time in a long while, we can actually spend meaningful time on them. AI isn't creating a new kind of engineering. It's giving us room to do engineering the way it should have always been done.

What This Looks Like in Practice

Here is what I think is required for a successful AI developer:

Thinking as an architect: Decomposing a product into its components, how they talk to each other, how state is stored and how data flows.

Deep familiarity with software patterns: A lot of the software we build today has optimal patterns. We need developers that know or are familiar with those patterns.

Infrastructure awareness: Engineers need to understand the infrastructure their software runs on — whether it's AWS, Azure, GCP, on-prem, or a hybrid. Decisions about architecture, scalability, cost, and deployment strategy are all constrained by infrastructure choices. Knowing whether you're working with serverless functions, containers, managed services, or monolithic deployments fundamentally changes how you design a system. An engineer who ignores infrastructure will make design decisions that don't survive contact with reality.

Ability to write (including with the help of LLMs): LLMs cannot write honest good content for you if you are not a good writer yourself — but they can help you significantly. Specs, design documents, and guides must be clear and specific enough for the AI to work within controlled boundaries. This requires someone who can form clear ideas and put them into words. It requires someone to methodically clean up gratuitous content.  LLMs can help with the grammar, structure, and flow, but you bring and curate the ideas and keep them clean and brief.  (Mark Twain explains it well when he said: "I didn't have time to write a short letter, so I wrote a long one instead")

Encoding checks into systems that verify the system itself: With the amount of code that gets generated, it will be impossible to have a human review every line of code and output. Engineers need to be able to use devices and methods that check the system being created, and define and codify those checks. Testing, formal verification, and pull request reviews need to be scaled up to keep pace with the amount of code created by LLMs, but the engineer needs to be on top of the sprawl in a methodical way.

Multidisciplinary thinking: Engineers should not be focusing only on software in the operational or technical sense, but also thinking in product terms — building the right thing, for the right audience, with the right outcomes — as well as in quality terms and user experience.

What Comes Next

I don't have all the answers, but the industry and education systems need to identify and help form the kind of engineer profile that takes advantage of the speed and capabilities of AI, so we can train or mentor engineers into more satisfying jobs, and give companies the most effective results when creating software.

Open Questions

• What are the ideal processes to help experienced engineers leverage their existing expertise to fully embrace AI-assisted development?
• What does the growth path look like for junior engineers entering the field now?
• Can you identify the right skills during a hiring process to optimize for adaptability and growth into AI-assisted development?
• How do you develop and evolve methodologies and processes that work for different companies and people?