When the CTO Asks You to Use Autocomplete

When companies publicly announce on LinkedIn that they're embracing AI, what are they actually doing internally? Are they replacing developers with agentic AI that swarms through code, debugging errors and deploying fixes? Are they parsing business requirements, accessing repos, building features, and deploying them before the 9am standup? For outside observers, it's hard to tell. But as a developer, I can assure you there's often a disconnect between what a CTO says and how the day-to-day workflow is actually affected.

In 2018, I joined an AI startup and experienced something completely new. The founder, who was also the main code contributor, didn't use an IDE. He worked solely in vim. His window was a black background with white text. Nothing else. There was no autocomplete, and worse, there was no syntax highlighting. At first, this felt like a handicap. Why would you deprive yourself of syntax highlighting? Autocomplete makes life so much easier.

I was just learning Golang, and initially I loaded everything into my IDE and used all the tools at my disposal to make programming easier. But then I had an epiphany: I'm just learning this new language, if there's any time I can make a drastic change in my workflow, it's now. So I ditched the IDE and embraced vim. I set up my machine just like his and started working. At first, it felt counterintuitive. I had to reshape my entire workflow to embrace this new paradigm.

But I learned something profound. Turning off all these visual aids helped me focus better on the code. I paid attention to what I was writing and kept a mental model of the available functions in my head. At some point, I could even debug errors without looking at the code. I was lying in bed when I figured out a solution to this problem.

When the company grew, we didn't enforce this rule. Every new engineer came in with their own toolkit, and as long as they produced code that fit our contribution guidelines, it would be merged. But now imagine this: what if we had enforced it?

What if I had been an expert in Golang when I joined and the CTO had told me I had to use a specific IDE and had to use autocomplete? I probably would have told him not to be concerned with how I write code, as long as it's worthy of a PR merge. Remember, the tools you use to write code don't leave a signature in the final product. It's like banging a nail into the wall with the back of a screwdriver because you can't find your hammer. If it goes in, no one can tell the difference. But what if you're required to use a specific tool? That's what it's like when a company mandates that employees use AI.

The good news is that in general, companies will call themselves "AI-first," then pay for a Copilot subscription. That's pretty much it. Some developers will use it as a glorified replacement for Stack Overflow. Others will use it to generate boilerplate code for new modules. There won't be an easy way for the company to track how much of the code in a repo actually comes from AI.

When you have an old repo with hundreds of thousands of lines of code, it's much harder to use agentic AI to contribute meaningfully. AI tools are great for side projects that you want to deploy over the weekend, though.

The Real Question Isn't "How" But "What"

Here's the thing that CTOs often miss. The value of a developer isn't in their typing speed or their tool proficiency, it's in their problem-solving ability and code quality. Whether I write a function using autocomplete, vim, or even dictating to an AI doesn't matter if the end result is clean, maintainable, and solves the business problem.

The most productive developers I know have wildly different workflows. Some live in their IDEs with every extension imaginable. Others prefer minimal setups. Some embrace AI assistance, while others avoid it entirely. What they share isn't their tools, it's their understanding of software architecture, their ability to debug complex systems, and their skill at translating business needs into code.

So when a CTO mandates specific development tools, they're optimizing for the wrong metrics. Instead of focusing on how code gets written, focus on what gets written. Establish clear coding standards, implement robust code review processes, and measure outcomes, not inputs. Because at the end of the day, users don't care if your feature was built with AI assistance or crafted entirely by hand. They care if it works, if it's fast, and if it solves their problem.

The future of development isn't about forcing everyone into the same workflow. It's about empowering developers to be productive in whatever way works best for them, while maintaining the standards that matter for the business.

---