TL:DR - Coding agents expedite delivery by allowing non-software engineers directly contribute to sprint work, expanding who can steer the product. While this increases team velocity, it significantly increases the importance of responsible software engineering oversight.
When I was young, my siblings and I would keep an eye on the mailbox down the street so we could meet our father on his way home from work. I kept a vigilant eye out because on the days when it was my turn, I would sit on my dad's lap and steer the car all the way home from the mailbox to the carport. Of course Dad had his hand on the wheel the whole time, and he was the one on the brakes and gas. But I didn't care about any of that. I was five years old and I was driving a car!
I wasn't completely and totally driving a car, obviously. I was turning a wheel while someone with years of experience made sure nothing went wrong. But the feeling was real and the learning was real too. Over time, I started to understand how far to turn the wheel to aim where I wanted to, how to read what was coming, and steer away from (or sometimes intentionally towards) the pinecones on the road. Dad didn't keep me from driving. He made sure I could do it safely, making small corrections to keep things on course.
That feeling, the thrill of doing something real before you fully understand the machinery underneath, is exactly what I see happening right now with agentic coding tools. Product managers, business analysts, and designers now have the ability to directly shape a codebase in ways that would have been unthinkable a couple of years ago. No more waiting on sprint capacity to test an idea or mocking something up in Figma and hoping it translates. They can sit down with a coding agent and drive things forward themselves, and the output is real working code that does what they asked for.
That's genuinely exciting and I don't want to diminish it. The value that product and design bring to a team has nothing to do with whether they can write code. It never has. What's changed is that the barrier between having an idea and implementing it just got a lot lower and that's a good thing for everyone. Allowing more contributors to the codebase adds to team velocity and allows more people to steer the product in real time.
But here's the part we need to be honest about: the barrier got lower, it didn't disappear. The codebase is still the codebase and its power and complexity remains despite having easier access to steering it. Architecture, dependency chains, security, test coverage expectations, and deployment pipelines all need to be respected because of their impact on the quality of the product. A coding agent can produce working code without understanding any of that context, and so can the person prompting it. That's not a knock on the person, it's the nature of the tool. The agent is the car. Anyone can steer it but someone still needs to be paying attention to the road and the complex things going on under the hood.
This is where experienced software engineers have to step up, not as gatekeepers but as the people responsible for controlling the pace of adoption. Not because other roles can't contribute (they absolutely can and should) but because engineers are the ones who understand what happens downstream. We know which parts of the system are fragile, where a seemingly harmless change can cascade and when the code an agent produces is technically correct but architecturally wrong.
There's another detail I left out: Dad's car was a manual transmission. Far from the pedal-backwards brake on my first bike or the on/off throttle and resistive braking on my Power Wheels, there was some complicated stuff going on under the hood. Same goes for architecture, security, testing, documentation, and all the other unglamorous considerations that go into keeping a software product running. These are things you only learn to respect by working with them over time. I've learned to code manually with years of practice and my mistakes were and are guided by collaboration with well-versed peers.
We should be building hype and excitement as we welcome new enthusiasm and creativity into application development. But the responsibility of control needs to stay with the people who have been driving the car and understand the whole vehicle. Software engineers should be gladly welcoming new drivers in the codebase and it is our responsibility to ensure progress is driven responsibly.