My thoughts on AI Coding

The early days: Copilot revolution

I was an early adopters when GitHub Copilot launched back in 2021. At the time, it felt like magic - an AI that could understand context and generate code snippets that actually made sense. The autocomplete was revolutionary compared to traditional IntelliSense or basic snippets. I remember being amazed when it could complete entire functions based on just a few lines, comments and well named variables.

The evolution: From autocomplete to autonomy

As the AI coding landscape evolved, so did my toolchain. I experimented with Cline for quite some time, using Gemini in a sparse way. It was interesting but didn’t quite stick in my daily workflow. The integration felt clunky, and I found myself falling back to Copilot for most tasks.

Then came Windsurf, which impressed me with their best-in-class tab supercomplete. The suggestions were more contextually aware, and the integration felt smoother. I used it for several months, appreciating the improved accuracy and better understanding of larger codebases.

But the real game-changer has been Opencode. Since I subscribed to the z.ai coding plan, I’ve seen massive gaps in terms of agent autonomy with GLM 4.6. This isn’t just autocomplete anymore - it’s a genuine coding partner that can take on complex tasks with minimal supervision.

The productivity paradox

There’s no denying the productivity gains. I’m producing more code than ever, and repetitive tasks or tightly scoped features are an absolute bliss to implement with AI assistance. What used to take hours now takes minutes. The speed is intoxicating.

However, this productivity comes with a cost that I wasn’t prepared for: a drifting gap in terms of ownership and knowledge of the code I’ve AI generated. I don’t like to call it “vibe coding” because I carefully review the context and the code, but there’s definitely a psychological distance that’s hard to ignore.

I spend a lot of time cherry-picking the context needed, referencing files, websites, or pointing at specialized MCP servers. The AI becomes incredibly effective when given the right context, but this context curation is a skill in itself - one that requires deep understanding of the codebase.

The ownership crisis

The most troubling aspect is the feeling that I’m not the one working anymore. Despite producing more code than ever, I don’t get that serotonin rush of building something. The satisfaction of solving a complex problem or crafting an elegant solution is diminished when the AI does most of the heavy lifting.

Even though I never commit any AI-generated line I haven’t read, there’s still a sense of detachment. I can explain the code, I understand how it works, but it doesn’t feel like “mine” in the same way that hand-written code does. This is a genuine concern for long-term maintainability and personal growth as a developer.

I’m not alone in this feeling. The more I talk to other developers, the more I realize this psychological distance between developer and code is a real phenomenon that affects code ownership and long-term comprehension.

Finding balance: Plan mode vs Build mode

My current rule of thumb is to spend a lot of time in Plan mode, challenging my ideas, brainstorming, and refining a plan that I’ll code more and more by myself. This approach helps me maintain ownership while still leveraging AI capabilities.

For complex features, I always resort to Plan mode to validate the LLM flow and ensure I understand the architecture before implementation. I use the AI as a thinking partner - someone to bounce ideas off, catch edge cases I might have missed, and suggest alternative approaches.

Build mode is reserved for when I have to go fast, take shortcuts, or write tests. It’s perfect for well-defined tasks where the implementation details matter less than the speed of delivery. Tests, boilerplate code, and straightforward implementations are ideal candidates for AI assistance.

This dual approach has been working well. I get the productivity benefits when I need them while maintaining the craftsmanship and ownership that keeps me engaged with my work.

The key is maintaining the human element in the loop. AI is a tool, not a replacement for thinking and craftsmanship.

Conclusion

AI coding tools have fundamentally changed how we write software. The productivity gains are undeniable, and I can’t imagine going back to coding without AI assistance. However, we need to be mindful of the trade-offs.

The loss of code ownership and the psychological distance from our work are real concerns that can affect job satisfaction and long-term code quality. For now, my approach of using Plan mode for complex work and Build mode for routine tasks seems to be a good compromise.

As AI tools continue to evolve, becoming more autonomous and capable, the challenge will be finding the right balance between productivity and craftsmanship. The future of coding isn’t about choosing between AI and human developers - it’s about finding the sweet spot where AI enhances our capabilities without replacing the creative problem-solving that makes development rewarding.

The tools will keep getting better, but the fundamental question remains: how do we use them to become better developers without losing the joy and ownership that drew us to coding in the first place?