That Couldn’t Possibly Work Here
Some ideas for building software better get a lot of pushback. Pair programming. Trunk-based development. Test-driven development. Despite the evidence, people insist these techniques can't possibly work here. And "here" means either their company in particular or "the real world" in general.
It might well be true that these ideas wouldn't work there. Right now. So ask: Why not? What would have to be true for it to work here? Work backwards from that and you've got your task list for organizational improvement.
AI is now dangling a juicy carrot in front of all of us: much faster code generation. So ask the same question. What must be true about your organization for that speed to translate into a net benefit? And whenever a roadblock pops up that seems to make it impossible, ask again: What would need to change for it to stop being a roadblock?
It depends on where your organization sits on engineering maturity, but some common levers:
Solid test automation and good coverage, plus a culture of small incremental changes, make it much safer to absorb the increased output of AI.
A non-negotiable commitment to quality, baked right into the pipeline, to keep a lid on AI slop. Simple tools like Python's radon or heavier ones like CodeScene are worth exploring.
A mandate that empowers everyone to move toward the improved state and flag blockers as high priority. That's the big one that gets missed in the "use AI for everything or get fired" mindset. Sure, push people to use the tools more than their current baseline. But give them a venue to flag where it's not quite there yet.
None of this is new or specific to AI. It's how you improve your organization, period.
