From Autocomplete to Co-Author: My Year with AI
My honest look at Copilot, Junie, Claude, and what actually changed.
As the year comes to an end, I want to reflect on my AI journey and how it gradually became part of my day-to-day work. My experience with GitHub Copilot dates back to mid-2023, when it gave me an early glimpse of AI-assisted development, without yet feeling transformative.1
Early Experiments and Mild Disappointment
I wrote about Copilot some time ago. Back then, I was kind of disappointed. Especially in IntelliJ, Copilot was merely an autocomplete on steroids. It was useful, no question, but it was far from groundbreaking.
I kept Copilot active in my IDE back then but did not see any amazing benefits or productivity gains. Throughout 2024, I mainly used my former employer’s own GPT version, which was not as good as ChatGPT but comparable. The workflow was the age-old “copy code into the prompt and ask for stuff.” Results were better, but it was not an efficient workflow.
2025 was the first year I used AI exhaustively in my day-to-day work. Due to the generous AI policy at my workplace, I got to try a lot of tools that year.
It started by ditching Copilot in favor of JetBrains AI. To me, they were similar, but JetBrains AI is way better integrated into IntelliJ, and the results are overall better (I still love the commit message generation function).
I continued to use ChatGPT and added Gemini to the mix. However, I do not ask them anymore to write tests, find bugs, or the like, although they have gotten way better at this kind of prompt. I use them as a sounding board for more abstract topics, such as architecture questions. You need to prompt them carefully, but in the end they are like the coworker who read all the blog posts. I would not base my decisions solely on a chat with them, but they provide good starting points. I also like to paste long stack traces into them, as they are faster at finding the important spots and often provide good solutions for more generic problems.
When AI Started to Actually Change My Work
This is all nice, but I still did not experience any really big improvements in my day-to-day work. The tools definitely save me time overall. However, I was able to produce code faster once I started using Junie, which became available in mid-2025 for us. To be honest, at first, I had the preconception that it was just some vibe coding junk. And vibe coding is dead, isn’t it?
But there’s no point in being stubborn. “We’ve always done it this way” is the dumbest argument there is. You have to try new things before you can hate them. And I hated it. At first.
I did not use Junie in my production code straight away. I tried to really vibe code. I wanted to do things I was not capable of doing because I lacked the knowledge, so I decided to create a simple IntelliJ plugin. I know Kotlin and Java, but I have no experience creating IntelliJ plugins. The goal was simple: a plugin that changes the text color in the file tree based on regex. For example, if a file matches .*Document, its name should be yellow. Junie quickly delivered convincing code, including a dialog box in the settings where you could configure the color and RegEx. But in the end, it didn’t work; the text always remained black. After two hours, I gave up in frustration. In retrospect, that was premature.
I then used Junie in a domain I am more knowledgeable about, and the results differed vastly. Junie was able to produce meaningful test suites following the general patterns already present. It could also create new functionality and alter existing functionality. The quality was good overall, but not perfect.
But one thing bugged me: it was painfully slow. Strikingly, it seemed slow even on easy tasks, such as modifying an enum. For a few days, I tried to use Junie for literally everything. Through a lot of trial and error, I learned how to get the most out of it. As a result, most of my work consisted of 30% Junie and 70% code I wrote myself, including modifications to Junie’s code.
Junie and I had grown into a happy relationship, until Jolene Claude appeared. Sorry Junie, but Claude is everything you are, just better. From day one, I was able to use Claude more efficiently than Junie. It is faster, and the results are better.
Don’t get me wrong: even Claude produces bullshit from time to time. I would never trust AI’s results blindly. But given a good prompt, the amount of corrections I had to apply to Claude’s code was minimal. In the end, the ratio shifted to 70% Claude’s code and 30% handwritten, including corrections and modifications.
Where This Leaves Me
So this is the state of the union for me currently. I can churn out code faster without compromising quality. From an economic point of view, that’s perfect. But is it still fun? To be honest, yes and no2.
I still love my job, even with the shift it has made due to AI. Writing code was never the focus of software development, at least not once you have some years of experience. Writing code was definitely the focus of my early years, which is probably why graduates and junior devs have a hard time now.
Reading, understanding, and debugging code (and maybe changing 1–2 lines after that) are far more common. This has increased even further with AI. Now I feel more like a pull request review machine than a coder. The number of actual pull requests opened on GitHub has increased, since people can write code faster. At the same time, I am constantly doing mini reviews on the code Claude produces. Code reviews are now my main focus (for the coding part) of my job.
Not sure how to feel about that, to be honest.
With that being said, I thank you for reading my short end-of-year AI summary. I wish you a happy new year (in which I hope to be able to write more again).
So long!
This sentence was produced by ChatGPT as I did not find a good start for the article. I used ChatGPT to fix spelling and grammar issues through the whole article, as english is not my native language.
Or “jein”, as we say in German