GitHub Copilot in Java Teams: Verification Gates, Model Choice and Context Habits From 3 Java Champions

By Sarah Chen, Tech Daily — MyTechDailyNews Software desk

Whether an assistant makes typing faster stopped being an interesting question. What engineering teams still argue about is everything sitting around the generated text: who supplied the context, who proved the output correct, and whose name ends up attached when it ships. MyTechDailyNews put those questions to 3 Java Champions, each with over a decade of experience in using Java, and asked for named projects instead of opinions. What came back covered two open source libraries, a classroom slide estate, a terminal utility, a children's maths app, a Maven plugin, and a driver regression on a Raspberry Pi.

The conclusion is unglamorous and immediately usable: the assistant is only as dependable as the gates you build around it. Task-sized context, written definitions of done, reusable skills, deterministic checks wrapped around a probabilistic model, and a conscious choice of model and interface for each job. That is the organising logic for everything below.

Start with the four numbers

Scale first, so the practices do not float off into theory.

Task described	Estimate before AI	Outcome with GitHub Copilot	What stayed with the human
A web app exposing Optimizer event history so users can watch performance work turn into application performance, slated for the next version of Hypersistence Optimizer	Weeks	two days	Review of plans and generated code; shipping decisions
Migration of around 900 teaching slides across 15 presentations from Reveal.js to Marp	a week or more — tedious enough that avoiding it altogether was the realistic baseline	roughly eight to ten hours	Content, teaching intent, every meaningful change
Investigation of a Pi4J bug reported after the February 2026 release of V4	Not the layer of a codebase anyone expects a fast answer from	About half an hour to a pull request	Scoping the entry files, reviewing an explanation he really did not expect
An idea for a Maven plugin that optimises which Spring Boot auto-configurations load, explored during roughly a four-hour journey to JavaLand	Not attempted while travelling	Working plugin, CI pipeline, performance tests against a sample application and reports showing whether the optimisation worked — all by arrival	Reviewing, deciding, steering: hand over a task, read what came back, send the next instruction

Vlad Mihalcea: encode your voice, then swap models per job

Where the tool went into the work

Vlad Mihalcea has used GitHub Copilot while analysing, designing and implementing features across Hypersistence Utils and Hypersistence Optimizer. The event-history application above had been postponed for a long time; he compares the experience to gaining a new team member rather than gaining a faster keyboard, and the result will ship in the next version of Hypersistence Optimizer.

Interface and review posture

Given the choice between an IDE plugin and the GitHub Copilot app, he stays inside IntelliJ IDEA, because the moments that matter to him are reviewing source code and sitting in a debug session. He rates it as a code assistant that compresses both investigations and prototype builds for features that still need validation. Plans and generated code still pass under his review, since the goal is raised productivity, not full replacement: many answers are right, some are not satisfactory, and those require his intervention.

Skills as house style

He writes his own skills so that whatever the tool produces resembles work he hand-wrote. The clearest example is a skill built on 65 of my published articles, which returns drafts that sound like his blog instead of like a language model; in his description this lets the LLM draw on 12 years of blogging when generating project documentation and return examples built on the same principles — expressiveness, testability, simplicity. A second skill set goes to maintenance. Across his career he learned that far more time is spent maintaining code than creating it, and because stability matters most for existing products, he teaches the assistant to mirror established code practices under the principle of least astonishment.

Model choice as a cost control

His cheapest efficiency lever is switching model type to match the operation. Thorough thinking gets Opus with the 1 million context window and Extra High or Max reasoning. Reports, release notes and documentation verification get lighter models that consume fewer tokens.

Worth copying from this setup

• Keep the assistant where the reading happens — review and debugging in IntelliJ IDEA beat context switching.
• Write a voice/style skill from your own published material before you ask it to write docs.
• Write a maintenance skill that encodes existing conventions and least astonishment.
• Route by task: heavy reasoning model for design, light model for boilerplate outputs.
• Treat every generated plan as a pull request: accepted only after human review.

Patrick Baumgartner: three very different examples

The constraint: business keeps running

Most of Patrick Baumgartner's work happens while normal operations continue, so you cannot stop everything for six months to “transform.” His entry point is solving immediate problems with the team: understand where they stand, define where they want to go, agree how they will know they are improving, then move step by step. Depending on the situation that involves 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. Decisions are made with the team and the aim is never dependency — ideally the team stops needing him except as a sparring partner. That preference explains why this generation of tools interests him: they extend the human work of learning, experimenting and solving problems.

Example 1 — a slide migration that had to bring evidence

The material was around 900 teaching slides across 15 presentations moving from Reveal.js to Marp. This was never a format conversion: many slides carry code, animations and interactive examples where he changes JavaScript live during class, and students had already battle-tested the flow, so losing one small piece could break the story he tells in the room.

His workflow, in the order it was executed:

1. Analyse the existing material and define the target.
2. Draft a migration plan and set the constraints.
3. Supply examples, and state explicitly what must remain intact.
4. Work from the big structural changes down into the details.
5. Generate screenshots of both the Reveal.js and Marp versions, then compare them visually and algorithmically.
6. Run a small application that places both decks side by side for manual animation checks, and compare the generated PDFs.

Because of steps 5 and 6, the agent could not simply announce “Migration complete.” — evidence backed the work. Content, teaching intent and every meaningful change remained his: the agent might auto-fix a typo, while changes to content, versions, dates or meaning were discussed. The rule he took from it is delegate execution, not responsibility, while he owns the result.

Example 2 — Tamboui: a real user found the compatibility gap

A terminal UI application he built with Tamboui worked perfectly on Linux under WSL, and he had completely forgotten that somebody might run it directly in Windows CMD or PowerShell. A real user did exactly that and found the Enter key ignored in some forms. He is a strong believer in shipping early, because you learn from how people actually use software.

Copilot then turned that report into reproducible UI tests. On Linux the agent drove the application through tmux; working alongside it taught him about psmux, which let him execute equivalent flows in PowerShell. After reproducing the problem and creating a local fix, they traced the real cause into Tamboui itself, and he submitted an upstream fix that was merged.

The part that surprised him was the representation. Test descriptions had outgrown the available context, so he asked the agent to help redesign how the tests were written. Instead of verbose tables of identifiers, names and repeated descriptions, it proposed compact arrow notation — step → step → input — with extra information only where it was critical. They were no longer using AI to execute information; they were deciding together how information should be represented for execution. The format did not need to be maximally human-friendly. It needed to preserve semantics while staying efficient for the agent.

Example 3 — a maths app shaped by a curriculum, not a generalisation

When someone close to him needed to practise mathematics, he asked why not build a small learning app. It covers addition, subtraction, multiplication, division and division with remainder for grades one through four, and he refused to ship another simple quiz: together with Copilot he researched spaced repetition, immediate feedback, adaptive difficulty, motivation, cooperative learning and gamification without dark patterns.

During that research the assistant pushed back on one of his own assumptions. He had wanted the app generic for children everywhere; the evidence on curricula moved them to look at what is actually taught, because the order of topics, the operations and the number ranges differ enough that being “universal” from day one was unnecessary. They focused on Switzerland first and aligned the progression to it. Since Switzerland is multilingual, the app ships in German, French, Italian and English, adds cooperative and competitive two-player modes, and when an answer is wrong it explains one route to the solution and brings similar questions back through spaced repetition.

He deliberately chose an architecture without a backend, because there is no reason to collect children's personal data on a server. Data stays on the device and the application can simply be hosted on GitHub Pages. What began as an experiment is now used and shared among friends — it accidentally became a little product.

Interface choice follows the feedback loop

The classic autocomplete experience has dropped out of his daily work; almost everything has moved toward agentic workflows. What he picks depends on how tight the loop must be.

Interface	Use it when	Pattern reported
VS Code	you need a tight visual feedback loop	looking closely at documents, code, presentations or intermediate results and adapting the process as he goes
Coding agent from the terminal	larger, execution-oriented tasks	delegating a piece of work, letting it execute, then inspecting the complete result
Agent driven through GitHub, from a phone	only reviewing and deciding is possible	the JavaLand trip: hand over a task, review the diff, think about the next step, send the next instruction
MCP servers	they buy capability or context cheaply	Context7 for documentation, an integration with his Logseq knowledge base, and an experimented-with Adobe Premiere Pro integration
Plain CLI	a good CLI already exists	often preferred, because it feels more direct and faster

One correction to the mental model matters here: the agent is not a “junior developer” in his framing but a sparring partner — and like anyone joining a project, it must first be brought up to speed. Context is king.

Step tutorial: the review he runs before execution

1. Stop one-shot prompting. For anything non-trivial, understand the problem first; he often explicitly asks the agent to interview him, to surface assumptions and expectations still implicit. A good agent can execute the wrong idea incredibly quickly, and that does not make the detour cheaper.
2. Demand a plan, then review it on four points: are assumptions visible, are verification gates defined, does the approach fit the architecture, and does it avoid unnecessary work.
3. Define task-specific gates, because “Done” should not mean that the model says it is done. For a refactoring: passing tests, proof that all intended files were handled, updated documentation, no leftover TODOs. For the slides: screenshots, visual diffs, animations, PDF output, content completeness. The gates depend on the task; the principle does not — the agent must be able to provide evidence that the definition of done is satisfied.
4. Convert every lesson into a reusable skill. When the agent misreads a convention, a check turns out missing, or he finds a better approach, the skill is updated, so the next run starts with that knowledge. He points to a skill called unlazy that follows the same logic: explicit gates, worked deliberately, completion proven rather than shortcut. His own maintainer-audit skill, inspired by work in the open agent skills community, checks and where appropriate repairs the baseline of a maintained repository across his projects: repository documentation, CI pipelines, Dependabot configuration, CodeQL, consistent cleanup and other standards. The goal is not another audit report to read but a repository pulled back toward baseline automatically. He treats these skills as living engineering knowledge, not static prompts.
5. Put deterministic tools around the probabilistic model. His quality harness wraps Checkstyle, PMD and Spring Modulith architecture checks into a consolidated report the agent can consume, run from hooks in a loop — change, execute checks, read findings, fix, execute again — until nothing is left.
6. Still use the software. He runs the application, interacts with it and decides whether it behaves and looks as expected, sometimes implementing feature by feature precisely because that loop is tighter.

The cost of skipping steps 1 and 2 is concrete: while building his Spring Boot auto-configuration optimiser he initially wanted to support both Spring Boot 3.5 and 4.x, and because of architectural differences both approaches were implemented. Later the 3.5 path was no longer needed, and removing it was painful. Detours are expensive; get the requirements right before you accelerate.

Common misconceptions

Claim you will hear	What the interviews showed
“The agent is a junior developer.”	It behaves as a sparring partner that must be brought up to speed; context is king.
Output is finished when the tool declares it finished.	Verification gates and evidence replace self-reporting, otherwise “Migration complete.” is just a sentence.
Ask for everything at once because “the AI can do it”.	Large generic specifications produce large generic implementations, and cleaning them up can be harder than building smaller increments correctly.
AI is for implementing a solution you already chose.	Use it before building to expand and challenge the solution space — that is how a generic app became curriculum-aligned.
Teams should pause delivery to adopt it.	Coaching happens while business keeps running, one immediate problem at a time.

What this does to the profession

He does not want software engineering students aspiring to become code-producing machines. The valuable profile is a strong problem solver: someone who understands users and stakeholders, finds the real problem behind a requirement, challenges assumptions, understands products and markets, makes architectural trade-offs, thinks critically, works in a structured way and transfers useful solutions between contexts. The model is extraordinarily good at generating possibilities and executing them, but as a human he usually holds much more of the actual context — including what nobody ever documented. So the split he wants is to stay in charge of shaping the solution while the agent takes more execution, which he thinks is putting the engineering back into software engineering. Developers, in his view, need to talk far more about how they use these tools: share the experiments that worked and the ones that didn't, borrow ideas and adapt them to your own context rather than searching for one universal AI development process. On a Friday night, when he wants to try something and no human pair is free, he now has something to challenge an idea with, review an approach with, or use as a very sophisticated rubber duck — but those ideas go back to real people, because human feedback, product understanding and real-world context remain essential.

Frank Delporte: pull requests, bug reports and the silent fifth button

Background kept brief

Computers fascinated Frank Delporte from the time he got a Commodore 64 when he was 11. He took side steps into video production and television work after school, then returned to coding because the video had to be put on DVD and because of the very first websites. Yes, he is that old. Today GitHub Copilot is his companion of choice when evaluating pull requests and investigating bug reports.

The Pi4J incident, in order

1. Pi4J, the library for building Java applications that interact with electronic components on the Raspberry Pi, released V4 in February 2026 with a new plugin using the Foreign Function & Memory API. It had been tested thoroughly before release.
2. Shortly after, someone reported that using 5 input buttons doesn't work as expected: pushing one of the first four configured buttons triggers code execution, while nothing happens with the fifth button.
3. The report is the kind nobody wants, because nothing was visibly broken — no exception, no warning in the logs, just silence where an event should be.
4. It got worse: with the older gpiod plugin, the exact same hardware and the exact same application worked fine, placing the fault inside the new FFM code that sits on top of the Linux kernel's GPIO character device and talks to it through native calls — not the part of a codebase where you expect a quick answer.
5. He assigned the issue to the Copilot coding agent with two file paths as the starting point: the provider class and FFMDigitalInput.
6. About half an hour later there was a pull request carrying an explanation he really did not expect.

Why the fifth watcher never ran

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, which leaves the fifth watcher no carrier to run on. Read that way, the report stops being mystifying — the first four configured buttons behaved, while the fifth one does nothing. Nothing crashed; there was simply nowhere for that watcher to be scheduled, and this is exactly the class of partial failure that is easy to mislabel as a case where events are flaky on the reporter's machine.

Permissions, privacy and compatibility: flags a Software desk would raise

• Privacy by architecture, not by promise: the maths app has no backend because children's personal data does not belong on a server; it stays on the device and is served from GitHub Pages.
• Platform coverage is a test, not an assumption: the Tamboui flows validated on Linux under WSL broke on Windows CMD and PowerShell, which only a shipped build exposed.
• Version breadth costs money twice: supporting Spring Boot 3.5 alongside 4.x meant two implementations, and later deleting the unused path was painful.
• A plugin or API swap can regress silently: FFM over the Linux kernel GPIO path produced no exception and no log line, so monitoring gave no signal at all.
• Model spend is a tunable setting, not a fixed choice: Opus with the 1 million context window for reasoning, lighter token-cheaper models for release notes and documentation checks.
• MCP servers widen both capability and surface area: adopt them when they supply context such as documentation or a knowledge base, otherwise prefer a direct CLI.

FAQ

Do we start with the IDE, the app, or the agent?

Match the interface to the feedback loop you need. Review and debugging stay in IntelliJ IDEA for Vlad Mihalcea; Patrick Baumgartner chooses VS Code when he must watch intermediate results closely, the terminal coding agent for larger delegated work, and the GitHub-driven agent when all he can do is steer from a phone.

Is the biggest model necessary for everything?

No. Reasoning-heavy design work is where Opus with the 1 million context window and Extra High or Max reasoning earns its cost; reports, release notes and documentation verification run fine on lighter models.

How do we keep generated documentation from sounding machine-written?

Build a style skill from your own corpus. One was trained on 65 of my published articles so drafts return in his blog voice, with an LLM effectively learning from 12 years of blogging and reusing the same principles. A second family of skills keeps generated code aligned to existing practices.

What is the minimum proof before accepting agent output?

Task-specific gates with artifacts: passing tests, coverage of every intended file, updated docs, no TODOs, or visual diffs and PDF comparisons for content migration. Self-declared completion is not evidence — “Migration complete.” is a claim.

Should teams chase one shared AI development process?

He advises against it: borrow experiments that worked and failed, then adapt them to your own context.

Action advice for your next sprint

• Pick one deferred task — a migration, an audit, a backlog feature — and run it through a planned, gated agent workflow rather than an ad-hoc prompt.
• Write the definition of done as artifacts before execution, and refuse completion without them.
• Ask the agent to interview you first on any non-trivial change.
• Encode your conventions as reusable skills; update them whenever the agent misreads something.
• Wire Checkstyle, PMD and architecture checks into hooks so the loop runs to zero findings.
• Route models by task, not by habit, to control token cost.
• Ship one early build to a real user: platform and hardware gaps appear only in actual use.
• Log where humans stay accountable — content, versions, dates, meaning, architecture — and keep those decisions off the agent.

Read together, these three accounts describe the same division of labour: fast generation is now cheap, so the scarce work has moved to framing the problem, holding the undocumented context, and producing evidence that a change is safe. Teams that treat the assistant as a sparring partner with a strong execution bias gain the hours; teams that let it declare its own success inherit defects that never log a warning.