Blog
Writing Code with AI Feels a Lot Like Flying with Autopilot
Vibe coding feels a lot like flying Blackhawks with autopilot. The machine can carry part of the workload, but only after you've done the planning, and know when to take back the controls.
One of the closest comparisons I have for writing software with AI is flying a helicopter with autopilot. I used to fly Blackhawks, and the rhythm feels very familiar to me. The machine can take on real workload, but only after the human has done the hard thinking up front. And when it's time to land, you're back on the controls.
That's basically how development feels now. AI is genuinely useful. It can scaffold, wire things together, chew through boilerplate, and get a first pass on structure onto the page fast. But it isn't the part doing the mission for you. It's reducing workload in the middle so you can stay ahead of the project and think more clearly about where it needs to go next.
The manual parts always came first
When I was flying, the most manual parts weren't the glamorous ones. They were the preparation, the flight planning, the pre-checks, and the takeoff. You had to know the route, the weather, the aircraft, the mission, the risks, and what the ground unit actually needed from you. If that part was loose, the rest of the flight was already behind before you ever got light on the wheels.
That's a lot like architecture and project framing now. The important early work in software is still very intentional. What are we building. Why does it matter. What problem does the business partner actually need solved. What constraints matter. What has to be simple, and what absolutely can't break. AI doesn't remove the need for those decisions. If anything, it raises the stakes, because a fast tool will happily accelerate a bad plan.
There's another similarity I still think about a lot. In the Army, we were almost always flying in support of someone else. The ground unit was the supported element. Our job wasn't to admire the aircraft. Our job was to help them accomplish theirs. That's how I think about software work too. The supported element is usually the business unit. Technology is there to help them do their job better, not to show off how clever the engineering team is.
Autopilot gave you room to think ahead
Once you were in flight and things were stable, autopilot could take some of the constant mechanical workload off your hands. Not all of it, and not forever. But enough that you could zoom out a little. You could think about the next checkpoint, the next radio call, the approach, the landing, or what had to happen at the objective. The goal wasn't to mentally check out. The goal was to stay ahead of the helicopter.
That's what good AI assistance feels like in development. It isn't replacing engineering judgment. It's letting me spend less energy on repetitive assembly work and more energy on sequencing, tradeoffs, and delivery. I can let the tool take a first pass on scaffolding a page, writing a boring API wrapper, or connecting pieces that I already know belong together. Meanwhile, my mind is freed up to think about whether the workflow makes sense, whether the architecture is holding, what the edge cases will be, and what the finish line actually looks like.
Landing gets manual again
The landing is where the analogy really locks in for me. In a helicopter, you can get a lot of help in flight, but when it's time to touch down you're back in it. Hands on. Paying attention. Making small corrections. Feeling the aircraft. Finishing the job cleanly.
Software is like that too. The closer you get to delivery, the less this is about generating more code and the more it's about judgment. Is the workflow actually right. Is the partner ready for it. Have we handled the weird corners. Are we rolling it out in the right order. Do the final details support trust, or create friction. That's landing work. It isn't glamorous, but it's where the project becomes real.
That's why I don't see AI coding as the machine taking over. I see it more like a very capable autopilot. Extremely useful. Worth having. Able to reduce workload in meaningful ways. But only effective when a human operator has already done the planning, understands the mission, and knows when to take the controls again.
The art is still in the architecture, and the responsibility is still in serving the supported unit well. And the professional part of the job is still knowing how to land the thing. Especially in dust...computers hate dust.