How I’d start my engineering career today

Estimated reading time: 7 minutes

Key takeaways:

• Kent Beck recently said “90% of my skills are worth $0, the other 10% worth 1000x.” Judgment beats speed now.
• Ask “can I own this at 2am,” not “did I finish the ticket.”
• Review AI code one level up: ask what assumptions it depends on, and what if they’re wrong?

---

If I could start my engineering career over again, I wouldn’t spend it chasing the same skills.

I still remember my first major production incident. It was many years ago and I was a senior engineer working on a search advertising product. A teammate had deployed a major change the day they were due to board a flight. Their new code introduced a new database schema and significantly changed one of the product’s critical algorithms.

As you can imagine, when the flight took off, things started to go wrong with the system. The system had already made changes to the live data, so I couldn’t simply revert the code without knowing exactly what had happened. If I wasn’t careful, I risked leaving the system in an even bigger mess. I had to figure out what had changed and how to fix it without causing more problems.

This was a pivotal night for me, as it taught me that the most useful person in an incident isn’t the one who codes the fastest. Instead, it’s the person that has intimate knowledge of the system, including where to look, what signals to pay attention to, and why one seemingly minor change has severe effects on other components of the system.

Don’t get me wrong, programming languages, frameworks, and libraries matter. However, over the course of my career, I have found that they are not what most distinguishes an effective engineer. System understanding, judgment, communication, and ownership do.

AI is making that distinction even more important. Kent Beck described the shift provocatively when he wrote that 90% of his skills are now worth $0, while “the other 10% are worth 1000x.” I think this captures the essence of the shift we are seeing with AI-coding assistants.

The question then becomes: which engineering skills are more valuable when implementation becomes cheaper? I believe the answer increasingly comes down to judgment, understanding, and ownership.

AI changes what engineers should learn

If I were starting my engineering career today, I’d take a different approach to learning. I’d still study programming languages, frameworks, and data structures because engineers need to understand how code works and be able to think critically about what an AI system produces. 

However, I wouldn’t stop there. I’d use those technical skills as a starting point, not the ultimate goal.

I’d also learn how to work effectively with AI systems and apply them to real-world problems. The goal wouldn’t simply be to generate more code. It would be to understand how to use these tools to solve problems that previously would have been too expensive or time-consuming to tackle.

I think back to when I first started my career and could only dream of having this kind of capability. There were prototypes I wanted to build that would have taken too long, migrations everyone agreed on but nobody had time to implement, tests and scaffolding nobody had time to write, and one-off internal tools that were useful but difficult to justify.

There were many things that were simply too expensive to try. Now, that is changing. It’s not that every idea is suddenly good or every generated solution is ready for production, but the cost of exploring, learning, and getting to a working version has decreased dramatically.

That creates enormous leverage for engineers but it also makes judgment much more important: knowing whether what we produced is actually any good.

Learn to verify, not just generate

Engineering judgment is not something that magically appears. I believe it can be developed and strengthened over time through practice. Every project can be an opportunity to improve how you think about outcomes, assess risks, evaluate evidence, and understand complex systems.

Instead of measuring progress only by asking, “did I finish the ticket?” I would ask a harder set of questions: can I explain why we made this change? Can I trace what happens from the original product need through the architecture and implementation to the user? Can I explain the important tradeoffs? Do I have evidence that the result works?

That changes what you learn from the work. The code is not the entire lesson and the reasoning that makes the code trustworthy is part of the engineering artifact too.

This becomes particularly important when AI can create code faster than you can develop intuition about the system around it. If generation becomes cheap, understanding becomes the scarce resource.Developing that understanding doesn’t happen in isolation.

Study how experienced engineers make decisions

My most influential mentors didn’t just show me how to improve my coding skills. They gave me insight into how experienced engineers handle unclear situations, weigh risks, make difficult decisions, and learn from their mistakes.

I learned a lot simply by watching them work. When something went wrong, I’d see where senior engineers looked first and ask why. During design discussions, I’d notice which risks they thought were acceptable and which ones they wanted to avoid. Over time, I began applying that same thinking to my own projects.

AI can explain a design pattern or propose a debugging plan. That is useful. What it cannot fully reproduce is proximity to someone making a consequential decision within the context of your actual architecture, customers, constraints, and organizational history.

As AI starts to handle more implementation work, those opportunities to observe experienced engineers may become even more important.

Mentorship has to scale realistically, though. Senior engineers can’t review every decision their less experienced colleagues make. The learning that sticks is often much narrower: one hard incident watched closely, one architecture decision taken apart, or one production failure someone actually revisits afterward. A few visible decisions can teach more than another step in the approval process.

That creates a responsibility for senior engineers too.

What this shift asks of staff+ engineers

This shift changes the job for staff+ engineers. Our value can’t simply be reviewing more code or helping teams produce more of it. We have to spend more time considering whether we’re building the right thing, what assumptions we’re making, where the system could fail, and whether we understand the consequences of the change.

That may also require changing how we review AI-assisted work. A line-by-line code review still has value, but it tells us less when large amounts of reasonable-looking code can be generated quickly. Reviews increasingly need to ask questions one level above the code:

• What assumptions does this change depend on?
• What happens when those assumptions are wrong?
• How does it affect the rest of the system? 
• How will we know if it isn’t behaving the way we expect in production?

Staff+ engineers also have a responsibility to make that kind of thinking visible. When we reject an approach, we should explain why. When we accept a risk, we should say what gives us confidence. When something goes wrong, we should spend time understanding the decisions that led there rather than only fixing the immediate problem.

The goal shouldn’t be to protect junior engineers from AI or artificially preserve work that technology can do more efficiently. It should be to give engineers meaningful ownership of the outcomes. Let AI help with the implementation, but give people responsibility for understanding the system, defending their decisions, watching what happens in production, and learning from the result.

There’s a question here for engineering leaders too. Are we using AI only to get our teams to produce more, or are we redesigning the work so people make better decisions as the technology gets cheaper and easier to use?

If AI allows teams to produce more code but leaves fewer engineers capable of owning what that code does, we haven’t actually made engineering better.

Build your career toward ownership

Modern aircraft can automate large parts of a flight. That doesn’t remove the need for a pilot who understands the aircraft, monitors the instruments, recognizes when reality has diverged from the plan, and takes control when necessary. I’d approach AI the same way.

If I were starting out in engineering today, I would make use of lots of automation: exploring unfamiliar code, prototyping ideas, generating tests, and moving faster through implementation. 

However, I would use any time saved to better understand how things work, to figure out where they break, and to understand the decisions that experienced engineers make in tough situations. 

Most importantly, I’d own the result, not just produce the code.

On your next AI-assisted change, don’t stop when the code works. Trace the system, test your assumptions, name the tradeoffs, and ask whether you could confidently own that change during a 2 am incident.

AI can help fly the route. Engineers still own the landing.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.