AI Coding Assistants — What Actually Works in Enterprise

We have been running AI coding assistants across our engineering teams for several months now. Claude 3.5 Sonnet, GPT-4o, Cursor, and various IDE integrations. Here is my honest assessment of what works and what does not at enterprise scale.

What Actually Works

Code generation from clear specs. When engineers have well-defined requirements and ask the AI to generate a first draft, the results are consistently useful. Not perfect — but a solid starting point that saves 30 to 60 minutes per feature.

Test scaffolding. This is the single highest-ROI use case. Engineers describe the function and edge cases, and the AI generates test files with sensible assertions. Our test coverage went up because the friction of writing tests went down.

Documentation generation. API docs, README files, inline comments — AI handles these well enough that engineers actually do them now instead of skipping them.

What Does Not Work

"Fix this bug" with vague context. AI assistants are terrible at debugging when the context is ambiguous. They hallucinate fixes, suggest changes that break other things, and waste more time than they save.

Architecture decisions. I have seen junior engineers ask AI to design their system architecture. The results look plausible but miss crucial constraints — security requirements, scale considerations, organizational context. Architecture still needs human judgment.

Complex refactoring across large codebases. AI can refactor a single file well, but understanding the ripple effects across a 200-file codebase is beyond current capabilities.

The Governance Question

The biggest challenge is not the technology — it is the policy. Which AI tools are approved? What code can be sent to external APIs? How do we handle IP concerns? I spent as much time on governance frameworks as I did on the technical rollout.

Enterprise AI adoption is 30% technology and 70% policy, training, and change management.