Learn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry.
Everything developers need to know about LLMs.
Machine learning tips, tricks, and best practices.
Explore the capabilities and benefits of AI code generation and how it can improve your developer experience.
Resources for developers to grow in their skills and careers.
Insights and best practices for building apps.
Tips & tricks to grow as a professional developer.
Learn how to move into your first professional role.
Stay current on whatâs new (or new again).
Learn how to start building, shipping, and maintaining software with GitHub.
Get an inside look at how weâre building the home for all developers.
Discover how we deliver a performant and highly available experience across the GitHub platform.
Explore best practices for building software at scale with a majority remote team.
Get a glimpse at the technology underlying the worldâs leading AI-powered developer platform.
Learn how we build security into everything we do across the developer lifecycle.
Find out what goes into making GitHub the home for all developers.
Our engineering and security teams do some incredible work. Letâs take a look at how we use GitHub to be more productive, build collaboratively, and shift security left.
Explore how to write, build, and deploy enterprise software at scale.
Automating your way to faster and more secure ships.
Guides on continuous integration and delivery.
Tips, tools, and tricks to improve developer collaboration.
DevOps resources for enterprise engineering teams.
Learn why Gartner positioned GitHub as a Leader for the second year in a row.
Keep up with whatâs new and notable from inside GitHub.
An inside look at news and product updates from GitHub.
The latest on GitHubâs platform, products, and tools.
Insights into the state of open source on GitHub.
The latest policy and regulatory changes in software.
Data-driven insights around the developer ecosystem.
Learn how to use retrieval-augmented generation (RAG) to capture more insights.
How open source is driving positive change.
Organizations worldwide are incorporating open source methodologies into the way they build and ship their own software.
Helpful tips on securing web applications.
Learn about core challenges in DevSecOps, and how you can start addressing them with AI and automation.
Learn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry.
Everything developers need to know about LLMs.
Machine learning tips, tricks, and best practices.
Explore the capabilities and benefits of AI code generation and how it can improve your developer experience.
Resources for developers to grow in their skills and careers.
Insights and best practices for building apps.
Tips & tricks to grow as a professional developer.
Learn how to move into your first professional role.
Stay current on whatâs new (or new again).
Learn how to start building, shipping, and maintaining software with GitHub.
Get an inside look at how weâre building the home for all developers.
Discover how we deliver a performant and highly available experience across the GitHub platform.
Explore best practices for building software at scale with a majority remote team.
Get a glimpse at the technology underlying the worldâs leading AI-powered developer platform.
Learn how we build security into everything we do across the developer lifecycle.
Find out what goes into making GitHub the home for all developers.
Our engineering and security teams do some incredible work. Letâs take a look at how we use GitHub to be more productive, build collaboratively, and shift security left.
Explore how to write, build, and deploy enterprise software at scale.
Automating your way to faster and more secure ships.
Guides on continuous integration and delivery.
Tips, tools, and tricks to improve developer collaboration.
DevOps resources for enterprise engineering teams.
Learn why Gartner positioned GitHub as a Leader for the second year in a row.
Keep up with whatâs new and notable from inside GitHub.
An inside look at news and product updates from GitHub.
The latest on GitHubâs platform, products, and tools.
Insights into the state of open source on GitHub.
The latest policy and regulatory changes in software.
Data-driven insights around the developer ecosystem.
Learn how to use retrieval-augmented generation (RAG) to capture more insights.
How open source is driving positive change.
Organizations worldwide are incorporating open source methodologies into the way they build and ship their own software.
Helpful tips on securing web applications.
Learn about core challenges in DevSecOps, and how you can start addressing them with AI and automation.
Three Java Champions share how they use GitHub Copilot to solve problems, accelerate development, and keep humans responsible for the results.
AI coding tools can generate code quickly, but speed alone does not solve the hardest software engineering problems. Developers still need to provide context, validate results, protect maintainability, and remain accountable for what ships.
To learn how experienced developers strike that balance, we spoke with three Java Champions, all with over a decade of experience in using Java. They shared concrete examples of using GitHub Copilot in production and open source, along with the practices they use to turn AI-generated output into reliable software.
How has GitHub Copilot helped you recently?
Iâve been using it to analyze, design, and implement various features in both Hypersistence Utils and Hypersistence Optimizer.
For example, Iâve been wanting for a long time to develop a web application that provides Optimizer event history so we can see how performance improvement efforts are materializing in application performance. Before AI, I kept postponing this task because it would have taken me weeks to develop. But using Copilot is like having a new team member, so I used it to create an app that will ship in the next version of Hypersistence Optimizer. Instead of weeks, this task took just two days to implement.
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 because itâs convenient to run while reviewing source code or during a debug session.
Itâs very useful as a code assistant, and it helps me speed up both investigations and building prototypes for features that need validation.
I still review the plans and the code that is generated by AI since 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, so a draft comes back sounding like my blog instead of like a language model. This is really useful when generating documentation for this project, since 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âve 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.
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, understand where the team currently stands, define where we want to go and how we will know that we are improving, and then move there step by step.
Depending on the situation, that can mean Software Craft practices such as TDD, refactoring, continuous delivery and XP; architecture and modularisation with Spring Boot, Spring Modulith; Spring Security; optimising Java and Spring Boot applications for containers; or increasingly, agentic engineering.
The important part for me is that I work with the team. We make decisions together. I donât 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.
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âand realistically, I might simply have avoided doing it because it was such tedious work.
With Copilot, I approached it differently. We first analysed the existing material, defined the target, created a migration plan, established constraints, provided examples, and 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 and 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.
A second example came from building a terminal UI application with Tamboui. It initially worked perfectly in Linux under WSL, and I had completely forgotten that somebody might run it directly in Windows CMD or PowerShell.
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, created a local fix, traced the real problem into Tamboui, and 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 â step â 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.
The third example is completely different again.
Someone close to me needed to practise mathematics, and 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, and 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 Pages.
What started as a small experiment is now being used and shared among friends. It accidentally became a little product.
That experience showed me another side of Copilot: donât only use it to implement your solution. Use it as a sparring partner to expand and challenge the solution space before you start building.
I actually donât use the classic Copilot autocomplete experience anymore.
My work has moved almost completely toward agentic workflows.
I use VS Code when I need a tight visual feedback loopâwhen I want to look closely at documents, code, presentations or intermediate results and adapt the process as I go.
For larger execution-oriented tasks, I often work with the coding agent from the terminal. There I am more comfortable delegating a piece of work, letting it execute, and then inspecting the complete result. The interface I choose depends mostly on the feedback loop I need.
I also had a fascinating experience using the coding-agent workflow through GitHub while travelling to JavaLand. I had started exploring an idea for a Maven plugin that optimises which Spring Boot auto-configurations are loaded. During roughly a four-hour journey, I was steering the agent from my phone: giving it a task, reviewing what it had done, thinking about the next step, and sending the next instruction.
By the time I arrived, I had a working Maven plugin, a CI pipeline, performance tests against a sample application, and reports that could demonstrate whether the optimisation actually worked.
That was the first time I had worked that way, and I was amazed that it actually worked. I wasnât trying to write Java on my phone. I was reviewing, deciding and steering while the agent executed.
I also use MCP servers when they give me useful capabilities or context. For example, I have used Context7 for documentation, integrations with my Logseq knowledge base, and I have experimented with an MCP integration for Adobe Premiere Pro.
But I donât use MCP just because I can. If a good CLI exists, I often prefer the CLI because it feels more direct and faster to me.
The agent is also not a âjunior developerâ in my mental model. I think of it much more as a sparring partner. But just like anyone joining a project, it first needs to be brought up to speed.
Can you share some tips and best practices?
The biggest thing I would recommend is: stop one-shot prompting.
For anything non-trivial, I want to understand the problem before execution starts. Quite often I explicitly ask the agent to interview me first. The purpose of that interview is to uncover assumptions and expectations that are still implicit.
A good agent can execute the wrong idea incredibly quickly. That does not make the detour cheaper.
I experienced this myself while working on my Spring Boot auto-configuration optimiser. Initially I wanted to support both Spring Boot 3.5 and 4.x. There were architectural differences, so we implemented both approaches. Later I realised I no longer needed the 3.5 path and removing it was painful.
The lesson was simple: detours are expensive. Get the requirements right before you accelerate.
Once the intent is clear, I want a plan. When I review that plan, four things matter especially to me: are assumptions visible, are verification gates defined, does the approach fit the architecture, and does it avoid unnecessary work?
The second principle is to define task-specific verification gates.
âDoneâ should not mean that the model says it is done.
For a refactoring, the gates might include passing tests, proving that all intended files were handled, updating documentation and leaving no TODOs behind. For the slide migration, the gates included screenshots, visual diffs, animations, PDF output and content completeness.
The gates depend on the task. The principle does not: the agent should be able to provide evidence that the work satisfies the definition of done.
I recently came across a skill called unlazy that follows a similar idea: create explicit gates, work through them deliberately, and prove that they have been completed rather than taking shortcuts.
The third principle is to turn your lessons into reusable skills.
I have started writing and maintaining my own Agent Skills. When I learn something from an executionâperhaps the agent misunderstood a convention, a useful check was missing, or I found a better way to approach a taskâI update the skill.
The next time I perform that task, the lesson is already there.
One example is a skill I call maintainer-audit, inspired by work in the open agent skills community. I use it across my own repositories. It checks and, where appropriate, fixes the things I expect a maintained project to have: repository documentation, CI pipelines, Dependabot configuration, CodeQL, consistent cleanup and other project standards.
The goal is not to generate another audit report for me to read. It brings the repository back toward the baseline I want automatically. That makes my projects more consistent and easier to maintain.
I think of these skills as living engineering knowledge rather than static prompts.
The fourth principle is to put deterministic engineering tools around the probabilistic model.
I have my own quality harness that wraps tools such as Checkstyle, PMD and Spring Modulith architecture checks and produces a consolidated report that the agent can consume. I can run that from hooks and let the agent iterate:
change â execute checks â read findings â fix â execute again.
It continues until there are no findings left.
That does not mean I stop looking at the software. I still run the application, interact with it and decide whether it behaves and looks the way I expect. Sometimes I deliberately implement feature by feature because the feedback loop is much tighter.
I learned that asking for everything at once because âthe AI can do itâ is usually a bad idea. Large, generic specifications create large, generic implementationsâand cleaning them up afterwards can be harder than building smaller increments correctly.
More broadly, I think we developers need to talk much more about how we use these tools. Share the experiments that worked. Share the ones that didnât. Borrow ideas from each other and adapt them to your own context instead of looking for one universal AI development process.
That is also why I like the idea of AI as a sparring partner. On a Friday night, when I want to experiment with something and no human pair is available, I suddenly have somebodyâor somethingâI can challenge an idea with, review an approach with, or use as a very sophisticated rubber duck.
But I still take those ideas back to real people. Human feedback, product understanding and real-world context remain essential.
How do you think AI is changing our profession?
I donât think software engineering students should primarily aspire to become code-producing machines. They need to become strong problem solvers. They need to understand users and stakeholders, discover the real problem behind a requirement, challenge assumptions, understand products and markets, make architectural trade-offs, think critically, work in a structured way and transfer useful solutions from one context into another.
The model is extraordinarily good at generating possibilities and executing things. But as a human, I usually know much more of the actual contextâincluding the things nobody ever documented.
So I want to remain in charge of shaping the solution and let the agent take over more of the execution.
In that sense, I think AI is putting the engineering back into software engineering.
Iâve been fascinated by computers since I got a Commodore 64 when I was 11. Took some side steps into video production and television work after school but turned back into coding as that video needed to be put on DVD and the very first websites⊠Yes, Iâm that old ;-).
How has GitHub Copilot helped you recently?
Itâs a perfect companion to evaluate pull requests and investigate bug reports.
One remarkable story is about the Pi4J library that lets you build Java applications to interact with electronic components on the Raspberry Pi. In February 2026, we released V4 which has a new plugin using the Foreign Function & Memory API. We tested it thoroughly before releasing, but still, shortly after the release someone reported that using 5 input buttons doesnât work as expected. Pushing one of the first four configured buttons triggers a code execution as expected, while nothing happens with the fifth button.
This is the kind of report you donât want to get. Nothing was visibly broken. No exception, no warning in the logs, the fifth button was simply silent. And it got worse: with the older gpiod plugin, the exact same hardware and the exact same application, worked fine. So the problem was in our new FFM code, which sits on top of the Linux kernelâs GPIO character device and talks to it through native calls. That is not the part of the codebase where you expect to find a quick answer.
So I assigned the issue to the Copilot coding agent and gave it two file paths as a starting point, the provider class and FFMDigitalInput. About half an hour later there was a pull request, with an explanation I really did not expect.
Each input runs an event watcher that blocks in a native poll() call, waiting for the kernel to report a change on its GPIO line. Those watchers ran in virtual threads. And a virtual thread that blocks inside a native call cannot be unmounted from its carrier thread. It stays pinned there for the whole duration of the call. A Raspberry Pi 4 has four cores, so the virtual thread scheduler has four carrier threads. Register four inputs, and all four carriers are parked in poll() forever. The fifth watcher is created, but is never scheduled. That is exactly the bug that was reported. Not âevents are flakyâ, but âthe fifth one does nothing.â
What I liked most was not the diff, it was the conversation that followed in the review. I left a comment asking Copilot to explain this in more detail:
I thought the goal of virtual threads was exactly to step away from the platform thread limit? So how is this a problem that four virtual threads block the four threads on a four-core processor like the Raspberry Pi?
Check the pull request for the full conversation. Copilot was able to link the use of the Raspberry Pi which has four CPU cores with the reported problem. It was able to propose a simple fix for the problem, plus some extra improvements it found during its investigation.
Can you share some tips and best practices?
Writing code got faster. The work around it didnât. See how you can plan, write code, review changes, and investigate production issues with GitHub Copilot, and what work still needs your judgment.
Louis Erbkamm built the first prototype in his free time. Now GitHub Copilot helps him maintain it alone.
Writing code got faster. The work around it didnât. See how you can plan, write code, review changes, and investigate production issues with GitHub Copilot, and what work still needs your judgment.
Learn how to move an agent session from the GitHub Copilot app into VS Code without losing the conversation, code changes, or working context.
GitHubâs context-aware secret classifier improves detection quality, raises weighted acceptance by 11.5%, and reduces median scan execution time by 86%.
Everything you need to master GitHub, all in one place.
Build whatâs next on GitHub, the place for anyone from anywhere to build anything.
Meet the companies and engineering teams that build with GitHub.
Catch up on the key announcements shaping the future of software development.
Discover tips, technical guides, and best practices in our biweekly newsletter just for devs.
→ Baca artikel asli