5-Minute DevOps: Growing New Developers in an AI World
I was speaking at DevOpsDays Dallas this week about AI-assisted development, how to do it, how it allows me to deliver much faster, and why most organizations won’t see any benefit. I also had a lot of good conversations about the topic because, as you can imagine, it’s top of mind for people in the industry.
One topic that has been haunting many of us is “how do we train junior developers in the age of AI?” I’ve been thinking about this quite a bit, and I’m embarrassed I didn’t have an answer sooner. It should have been obvious to me, considering my work history and the operating models I advocate.
First, let’s consider the main concern many people have about using AI for writing code. It’s easy to get in a hurry and not pay close attention to the code being generated. I’ve done it myself. I will come back and refactor the code (with AI assistance) later, but sometimes I just want to get something done. If you aren’t cleaning as you go or you stop paying attention to the code, it’s easy to drive up tech debt and to build systems you don’t understand and cannot fix when they have defects.
Next, let’s consider what makes someone a senior developer. Is it time in grade? The ability to write code fast? Is it how many patterns they can name or how fast they can invert a binary tree? No. It’s their experience trying things, failing at things, and succeeding at things. They know how to continue learning, have good engineering habits, help others avoid repeating their failures, and mentor the next generation. They can look at the code and see that it’s hard to maintain and hard to fix because they’ve had a lot of experience changing and fixing code they didn’t write.
So, what is the solution?
“You build it, you run it!”
This has always been a best practice. The people who built a system should be the experts at supporting it, and this concept has always been core to DevOps. Quality is an outcome of how quickly you can detect that there is a quality issue, and it requires ownership. The team needs to own the problem they are solving, own how it is solved, and own the consequences of their decisions. This operating model changes coders into software engineers who think twice before committing garbage code. It makes teammates think twice before spending 30 seconds to comment “LGTM” on a code review for an 800-line delta. The team members are incentivized to help spread knowledge and take ownership, regardless of whether the code is written by them, a teammate, or a robot.
So, if you are concerned about quality and how you can grow new developers into senior software engineers, first make sure you have some seniors who believe their job description includes cloning themselves, and then shift to a DevOps operating model. No team should be developing code with the expectation that Ops will clean up their mess.
Some organizations are banning new developers from using AI. That’s dumb. All it does is create a class system and block learning. Teach everyone how to use AI correctly, starting by driving acceptance test-driven development and continuous integration as the workflow. No one should be coding until the team defines the outcome, and all changes should be small and integrated very frequently. Not working this way causes pain. Without AI, the pain is often like a low-grade ache. People live with it and become used to it. With AI, it’s like breaking your leg because AI amplifies everything.
