Three veteran Java developers report that GitHub Copilot cut a two-week project down to two days, but they insist speed is only part of the equation. The engineers argue that context, validation, and maintainability remain the developer’s responsibility.
We spoke with three Java Champions who have more than ten years of experience. They shared specific examples of using GitHub Copilot in production environments and open source projects. Their focus was on converting AI output into reliable software.
Meet the Java Champions
- Vlad Mihalcea, founder of Hypersistence and author of the book High-Performance Java Persistence
- Patrick Baumgartner, software crafter at 42talents with over 20 years of Java experience
- Frank Delporte, senior technical writer at Azul and maintainer of Foojay.io with more than 15 years of Java experience
vlad mihalcea
GitHub profile: @vladmihalcea
How has GitHub Copilot helped you recently?
I have used it to analyse, design, and implement features in both Hypersistence Utils and Hypersistence Optimizer.
I wanted to build a web application that displays Optimizer event history. This would show how performance improvement efforts are materialising in application performance. Before AI, I postponed this task because it would have taken weeks. Using Copilot is like having a new team member. I created an app that ships in the next version of Hypersistence Optimizer. The task took just two days.
What’s your typical usage? Are you using GitHub Copilot as an IDE plugin or the GitHub Copilot app?
I use GitHub Copilot in IntelliJ IDEA. It is convenient to run while reviewing source code or during a debug session.
It is very useful as a code assistant. It helps me speed up investigations and building prototypes for features that need validation.
I still review the plans and the code generated by AI. Their goal is to improve my productivity, not replace me entirely. While AI provides the right answer in many situations, there are still times when the response is not satisfactory and requires my intervention.
Can you share some tips and best practices? For example, which skills are you using?
I created my own skills so that whatever text Copilot generates looks like something I wrote by hand.
This skill captures my voice from 65 of my published articles. A draft comes back sounding like my blog instead of like a language model. This is really useful when generating documentation for this project. It lets the LLM learn from 12 years of blogging and provide examples that follow the same principles, such as expressiveness, testability, and simplicity.
Throughout my career as a software engineer, I have learned that we spend far more time on code maintenance than on creating it. Therefore, because maintenance and stability are critical for existing products, I developed skills that help AI mimic existing code practices in accordance with the principle of least astonishment.
One tip is to change the model type based on the type of operation. For thorough thinking, I use Opus with the 1 million context window and Extra High or Max reasoning. However, for simpler tasks, such as generating reports, release notes, or verifying documentation, I use lighter models that consume fewer tokens.
patrick baumgartner
GitHub profile: @patbaumgartner
Your work involves coaching teams. What is your approach?
A lot of my work happens while the normal business still has to keep running. You cannot stop everything for six months to transform. We usually start by solving immediate problems together. We understand where the team currently stands. We define where we want to go and how we will know that we are improving. Then we move there step by step.
Depending on the situation, that can mean Software Craft practices such as TDD, refactoring, continuous delivery and XP. It can mean architecture and modularisation with Spring Boot, Spring Modulith. It can mean Spring Security. It can mean optimising Java and Spring Boot applications for containers. It can mean agentic engineering.
The important part for me is that I work with the team. We make decisions together. I do not want a team to become dependent on me. Ideally, after some time they no longer need me except perhaps as a sparring partner.
And maybe that explains why I find this new generation of AI tools so interesting. I like working with people, learning, experimenting, and solving problems. AI gives us another very powerful tool for doing exactly that.
Can you share a good story about how GitHub Copilot has helped you recently?
There are actually three very different examples that changed how I think about working with GitHub Copilot.
Let’s start with the first one.
One was a migration of around 900 teaching slides across 15 presentations from Reveal.js to Marp. These were not simple slides. Many contain code, animations, and even interactive examples where I can change JavaScript live while teaching. More importantly, the presentations had already been battle-tested with students. The flow worked. Losing one small piece could break the story I use in the classroom.
Doing that migration manually would probably have taken me a week or more. Realistically, I might have simply avoided doing it because it was such tedious work.
With Copilot, I approached it differently. We first analysed the existing material. We defined the target. We created a migration plan. We established constraints. We provided examples. We defined what had to remain intact. Then we worked from the big structural changes down into the details.
The really important part was verification.
We generated screenshots of the Reveal.js and Marp versions. We compared them visually and algorithmically. We built a small application where I could run both slide decks next to each other to verify animations manually. We even compared the generated PDFs.
That meant the agent did not just say, migration complete. We had evidence.
The entire migration took me roughly eight to ten hours. I still owned the content, the teaching intent, and every meaningful change. Copilot could fix a typo automatically. But if content, versions, dates or meaning changed, that was something we discussed.
For me, that experience reinforced an important principle. Delegate execution, not responsibility. I own the result.
Can you share the second example?
A second example came from building a terminal UI application with Tamboui. It initially worked perfectly in Linux under WSL. I had completely forgotten that somebody might run it directly in Windows CMD or PowerShell.
And then a real user did.
They discovered that the Enter key was simply ignored in some forms. That is another principle I strongly believe in. Ship software early, because you learn from how people actually use it.
We used Copilot to turn that feedback into reproducible UI tests. On Linux, Copilot was navigating the application with tmux. Through working with it, I learned about psmux and could execute similar flows in PowerShell. We reproduced the problem. We created a local fix. We traced the real problem into Tamboui. I submitted the upstream fix, which was merged.
During this work, the test descriptions themselves became too large for the available context. So I asked Copilot to help me redesign the way the tests were represented. Instead of verbose tables containing identifiers, names and repeated descriptions, it proposed a much more compact arrow notation. Step arrow step arrow input, with additional information only where it was critical.
That surprised me. We were not just using AI to execute information. We were working together on how information should be represented for execution. It did not have to be maximally human-friendly. It had to preserve the semantics while being efficient for the agent.
How about the third example?
The third example is completely different again.
Someone close to me needed to practise mathematics. I thought: why don’t we build a small learning app?
It covers addition, subtraction, multiplication, division and division with remainder for grades one through four. But I did not want to build another simple quiz application. Together with Copilot, I researched learning approaches such as spaced repetition, immediate feedback, adaptive difficulty, motivation, cooperative learning and gamification without dark patterns.
Interestingly, during that research Copilot challenged one of my original assumptions. I initially wanted the application to be generic for children everywhere. The research led us toward looking at the actual school curriculum instead. I realised that the order in which topics are introduced, the operations and number ranges differ enough that making it universal immediately was unnecessary.
So we focused on Switzerland first and aligned the progression accordingly. Because Switzerland is multilingual, the application is available in German, French, Italian and English.
It also has cooperative and competitive two-player modes. When someone gets an answer wrong, the application explains one way to solve it and brings similar questions back through spaced repetition.
I deliberately chose an architecture without a backend. There is no reason for me to collect children’s personal data on a server. So the data stays on the device and the application can simply be hosted on GitHub.
