Software Development Field Notes: 3 Java Champions on Making GitHub Copilot Deliver Real Java Work

Field notes for the ItInsightsWorld Software Development desk, written by James Hartley. Feedback and questions: contact@itinsights.com.

Raw generation speed settles almost none of the hard problems in software delivery. The parts that decide whether a change survives review are context, evidence and ownership — and none of them transfer to the model.

Three practitioners below show what that looks like in day-to-day engineering. Vlad Mihalcea, Patrick Baumgartner and Frank Delporte are 3 Java Champions, each with over a decade of experience in using Java, and each points GitHub Copilot at a different surface: library code inside Hypersistence Utils and Hypersistence Optimizer, a coaching practice spanning teaching material and terminal tools, and hardware-facing open source such as Pi4J. Their tooling differs; their discipline converges.

The structure here is built for readers who ship code: three case files, a harness comparison, a runnable workflow, the misconceptions that keep costing teams time, an FAQ, and a short action list.

Case File 1 — Vlad Mihalcea: A Postponed Feature Becomes two days of Work

Where the tool actually went in

Copilot entered his loop during the analysis, design and implementation of features across Hypersistence Utils and Hypersistence Optimizer. The clearest data point is a web application that exposes Optimizer event history, so users can watch performance improvement work turn into measured application performance. He had postponed it for a long time and had budgeted weeks of effort. Treating the session as onboarding a new team member changed the shape of the task: the app is scheduled to ship in the next version of Hypersistence Optimizer, and implementation took two days instead of weeks.

Harness choice and review policy

Asked whether he works with the IDE plugin or the GitHub Copilot app, he stays with GitHub Copilot in IntelliJ IDEA, because the tool sits where the work already happens — reading source during a review, or stepping through a debug session. The value concentrates in two activities: investigation speed, and throwaway prototypes for features that still need validation. Every plan and every generated hunk is still reviewed. The goal was productivity, not replacement; the model is frequently right, and the unsatisfactory answers are exactly where his time goes.

Custom skills as voice and convention memory

He writes his own skills so that generated text passes as something he typed 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,” he said. “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.”

His other skills encode a maintenance bias. Years as a software engineer taught him that people spend far more time maintaining code than creating it, and that stability matters most for products already in use. So the instructions tell the model to mimic the practices already present in the codebase, in line with the principle of least astonishment, rather than inventing cleaner-looking ones.

Routing work by model instead of defaulting

One practical tip: change the model type to match the operation. For thorough thinking he runs Opus with the 1 million context window and Extra High or Max reasoning. For lighter jobs — generating reports, release notes, verifying documentation — he switches to models that consume fewer tokens.

Case File 2 — Patrick Baumgartner: Coaching Teams While Business Keeps Running

His engagements start from a constraint no roadmap can wish away: you cannot stop everything for six months to “transform.” He joins a team mid-flight, so the sequence is fixed — solve the immediate problem together, understand where the team currently stands, define where it wants to go and how it will know it is improving, then move there step by step.

Depending on the starting point, that becomes Software Craft practices such as TDD, refactoring, continuous delivery and XP; architecture and modularisation with Spring Boot, Spring Modulith and Spring Security; optimising Java and Spring Boot applications for containers; or, increasingly, agentic engineering. The constant is deciding with the team rather than for it. He does not want a group that depends on him; ideally it stops needing him after a while, except as a sparring partner. That preference explains why this generation of tools interests him — he likes working with people, learning, experimenting and solving problems, and AI is another very powerful instrument for exactly that.

three very different examples

Patrick Baumgartner shared three very different examples, each of which rearranged how he thinks about working with GitHub Copilot.

Migrating around 900 teaching slides

The first was moving around 900 teaching slides across 15 presentations from Reveal.js to Marp. The material was not simple: many slides carry code, animations, and interactive examples where he changes JavaScript live while teaching. Students had already battle-tested the decks, so the flow worked — and losing one small piece could break the story he tells in the classroom.

By hand the job would have taken a week or more; realistically, its tedium might have meant never doing it. Instead they analysed the existing material, defined the target, produced a migration plan, established constraints, provided examples and stated what had to remain intact, then worked from the big structural changes down into the details.

Verification did the heavy lifting. Screenshots of the Reveal.js and Marp versions were generated and compared both visually and algorithmically; a small application placed the two decks side by side for manual animation checks; the generated PDFs were compared as well. The agent could not merely announce “Migration complete.” — evidence backed the work. Total effort: roughly eight to ten hours. Content, teaching intent and every meaningful change stayed his responsibility; a typo could be fixed automatically, but changes to content, versions, dates or meaning were discussed. The lesson he took from it: delegate execution, not responsibility, while you own the result.

A terminal UI with Tamboui

The second example was a terminal UI application built with Tamboui. It worked perfectly in Linux under WSL — and he had completely forgotten that somebody might run it directly in Windows CMD or PowerShell. A real user did, and discovered that the Enter key was simply ignored in some forms.

He is a strong believer in shipping software early, because you learn from how people actually use it. Copilot helped turn that feedback into reproducible UI tests: on Linux it navigated the application with tmux, and working alongside it taught him about psmux, which let him run the same flows in PowerShell. After reproducing the problem and creating a local fix, they traced the real cause into Tamboui itself; he submitted an upstream fix, which was merged.

Along the way the test descriptions grew too large for the available context, so he asked Copilot to help redesign how the tests were represented. Instead of verbose tables of identifiers, names and repeated descriptions, it proposed a compact arrow notation — step → step → input — with extra information only where it mattered. That surprised him: they were not just executing information with AI, they were jointly deciding how information should be represented for execution. The representation did not have to be maximally human-friendly; it had to preserve the semantics while staying efficient for the agent.

A math learning app for Switzerland

The third example was a small learning app, built because someone close to him needed to practise mathematics. It covers addition, subtraction, multiplication, division and division with remainder for grades one through four — and he did not want 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 tool challenged one of his original assumptions. He had wanted the application to be generic for children everywhere; the research pushed them toward the actual school curriculum, because topic order, operations and number ranges differ enough that chasing a “universal” version immediately was unnecessary. They focused on Switzerland first and aligned the progression accordingly; since Switzerland is multilingual, the app ships in German, French, Italian and English. It offers cooperative and competitive two-player modes; a wrong answer brings an explanation of one way to solve it, and similar questions return through spaced repetition.

The architecture deliberately has no backend: there was no reason 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 began as an experiment is now used and shared among friends — it accidentally became a little product. The takeaway: do not only use Copilot to implement your solution; use it as a sparring partner to expand and challenge the solution space before you build.

How he runs the work

Classic autocomplete is behind him; almost everything now runs as agentic work, and the interface he picks tracks the feedback loop he needs. VS Code is for tight visual loops, when he wants to look closely at documents, code, presentations or intermediate results and adapt as he goes. For larger execution-oriented tasks he uses the coding agent from the terminal, where he is comfortable delegating a whole slice, letting it run, then inspecting the complete result.

The most instructive session happened while travelling to JavaLand. He had been exploring an idea for a Maven plugin that optimises which Spring Boot auto-configurations are loaded. Over roughly a four-hour journey he steered the agent from his phone: giving a task, reviewing what it had done, thinking about the next step, sending the next instruction. By arrival he had a working Maven plugin, a CI pipeline, performance tests against a sample application, and reports demonstrating whether the optimisation actually worked. He had not tried to write Java on his phone; he had reviewed, decided and steered while the agent executed.

MCP servers enter only when they add a useful capability or context: Context7 for documentation, an integration with his Logseq knowledge base, and an experimental Adobe Premiere Pro integration. He does not adopt MCP because he can — where a good CLI exists, he prefers the CLI, because it feels more direct and faster. And the agent is not a “junior developer” in his mental model; it is a sparring partner that, like anyone joining a project, first needs to be brought up to speed. Context is king.

What this changes about the profession

He would not want students training to become code-producing machines. The durable skills are problem solving: understanding users and stakeholders, discovering the real problem behind a requirement, challenging assumptions, understanding products and markets, making architectural trade-offs, thinking critically, working in a structured way, and transferring useful solutions between contexts. The model is extraordinarily good at generating possibilities and executing them; as a human he usually knows far more of the actual context — including everything nobody ever documented. So he keeps shaping the solution and hands more execution over, which is why he describes AI as putting the engineering back into software engineering.

Case File 3 — Frank Delporte: Evaluating Pull Requests and Chasing a Silent Bug

From Commodore 64 to the first websites

Computers fascinated him from the time he got a Commodore 64 when he was 11. After school he took side steps into video production and television work, then returned to coding because that video had to be put on DVD and the results had to appear on the very first websites.

Pi4J, V4 and the unresponsive fifth button

GitHub Copilot has become his companion of choice when evaluating pull requests and investigating bug reports. The most instructive case involves Pi4J, the library that lets you build Java applications to interact with electronic components on the Raspberry Pi. In February 2026, V4 was released with a new plugin built on the Foreign Function & Memory API. It had been tested thoroughly before release, yet shortly afterwards someone reported that using 5 input buttons doesn’t work as expected: pushing one of the first four configured buttons triggers code execution as expected, while nothing happens with the fifth button.

This is the kind of report nobody wants. Nothing was visibly broken — no exception, no warning in the logs; the fifth button was simply silent. Worse, with the older gpiod plugin the exact same hardware and the exact same application worked fine, which placed the fault in the new FFM code sitting on top of the Linux kernel’s GPIO character device and talking to it through native calls. That is not the part of a codebase where you expect a quick answer.

He assigned the issue to the Copilot coding agent with 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 he 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, which leaves the fifth watcher with nothing to run on.

Two lessons for any team debugging hardware or native layers: a report whose symptom reads as “events are flaky” can still be perfectly deterministic — in this case, press it five times and the fifth one does nothing. And the root cause lived in a place where the reasoning was about scheduler capacity rather than business logic, which is exactly the kind of blind spot a second pair of eyes is for.

How the Three Setups Compare

Dimension	Vlad Mihalcea	Patrick Baumgartner	Frank Delporte
Daily harness	GitHub Copilot in IntelliJ IDEA during review and debug sessions	VS Code for tight visual loops, terminal coding agent for execution, coding agent on GitHub for remote steering	Copilot coding agent for pull requests and bug reports
Main workload	Features in Hypersistence Utils and Hypersistence Optimizer	Team coaching, teaching slides, terminal UIs, small products	Raspberry Pi hardware libraries
Context strategy	Custom skills trained on his own articles and repository conventions	Brought-up-to-speed sparring partner; MCP only when it beats a CLI	Two file paths as the entry point, then read the explanation
Evidence of done	Reviews every plan and generated change	Screenshots, visual diffs, animation checks, PDF output, CI, performance tests	Reproducible test, local fix, merged upstream change
Model routing	Opus with the 1 million context window for deep work, lighter models for release notes	Interface chosen by the feedback loop, not by habit	Delegates investigation, keeps the judgement

Step Tutorial: Running an Agentic Task Without Losing Control

1. Stop one-shot prompting. For anything non-trivial, understand the problem before execution starts; he often asks the agent to interview him first, to surface assumptions and expectations that are still implicit.
2. Get requirements right before you accelerate. A good agent can execute the wrong idea incredibly quickly, and that does not make the detour cheaper. His own case: a Spring Boot auto-configuration optimiser built to support both 3.5 and 4.x, where the 3.5 path later had to be removed and doing so was painful.
3. Review the plan against four questions. Are assumptions visible, are verification gates defined, does the approach fit the architecture, does it avoid unnecessary work?
4. Define task-specific gates. “Done” should not mean that the model says it is done. For a refactoring the gates might be passing tests, proof that all intended files were handled, updated documentation and no TODOs left behind; for the slide migration they were screenshots, visual diffs, animations, PDF output and content completeness. The gates change per task; the principle does not — the agent must be able to produce evidence that the definition of done is satisfied. A skill he came across, unlazy, follows the same idea: build explicit gates, work through them deliberately, and prove completion instead of taking shortcuts.
5. Descend from structure to detail. Analyse existing material, define the target, write the plan, declare constraints, supply examples, state what must remain intact — then move from the big structural changes into the details.
6. Wrap the probabilistic model in deterministic tools. He runs a quality harness around Checkstyle, PMD and Spring Modulith architecture checks that produces a consolidated report the agent can consume, executed from hooks so the loop becomes change → execute checks → read findings → fix → execute again, until no findings remain.
7. Promote every lesson into a reusable skill. When the agent misunderstands a convention, a useful check was missing, or a better approach appears, update the skill so the next run already carries it. One example, maintainer-audit, checks and where appropriate fixes what a maintained project should have: repository documentation, CI pipelines, Dependabot configuration, CodeQL, consistent cleanup and other standards. The goal is not another audit report to read; it pulls the repository back toward the baseline automatically.
8. Build in small increments. 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. He still runs the application, interacts with it, and sometimes implements feature by feature because the feedback loop is tighter.
9. Keep ownership explicit. Automatic typo fixes are fine; content, versions, dates and meaning are discussed with the human who owns the result.
10. Carry the findings back to people. On a Friday night, when he wants to experiment and no human pair is available, the model becomes a very sophisticated rubber duck — but human feedback, product understanding and real-world context remain essential. Teams should 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 setting.

Common Misconceptions About AI-Assisted Java Work

• The agent is a junior developer you supervise. All three treat it as a sparring partner and executor — powerful, but only after context is loaded.
• Faster generation means someone else owns the result. Responsibility does not move with the keystrokes: he keeps teaching intent, architecture and every meaningful change.
• One model, one setting, all tasks. Deep reasoning and release notes have different costs; routing between Opus with the 1 million context window and lighter models is a normal engineering decision.
• Adoption is a project you can schedule. No team can pause delivery for six months to “transform.”; improvement starts with the problem in front of the team and moves step by step.
• New code is the scarce resource. Maintenance outweighs creation, so the highest-leverage instruction is often to imitate the existing codebase rather than improve on it.
• More plugins, more MCP servers, better output. A direct CLI usually beats an integration you added because it exists.
• A completed task is a verified task. Screenshots, diffs, CI, architecture checks and merged tests are what turn a claim into evidence.

FAQ

Should we start with IDE autocomplete or an agent?

Start where your feedback loop is shortest. Vlad Mihalcea keeps GitHub Copilot in IntelliJ IDEA because review and debugging already happen there. Patrick Baumgartner has moved almost entirely to agentic workflows, choosing VS Code when he needs to see and adapt intermediate artefacts, and the terminal when he wants to delegate a whole slice.

How much time does this actually save?

From these accounts: a web application estimated in weeks became two days; a migration that would have taken a week or more finished in roughly eight to ten hours; a bug report nobody wanted turned into a pull request in About half an hour. The savings land on tedious, well-specified work, not on judgement.

What belongs to the human?

Everything that is not documented: intent, architectural trade-offs, product understanding, and the decision about what “good” looks like before the agent starts.

Can AI set scope for a product?

It can challenge it, which is often more valuable. On the Switzerland learning app, research with Copilot overturned his wish to make the content “universal” and redirected him to the real curriculum.

What breaks first when teams get this wrong?

Trust in “done.” An agent reporting “Migration complete.” without visual diffs, tests and comparison output is the failure mode to design against.

Action Advice: What to Change This Sprint

• Pick one postponed task with a clear definition of done and run it end to end, timing the result against your own estimate.
• Write three verification gates for your most common task type before you prompt, and make the agent satisfy them with evidence.
• Capture one custom skill this week — a voice, convention or maintenance rule — so generated output matches your repository.
• Route models by operation: heavy reasoning on Opus with the 1 million context window, light text work on cheaper models.
• Put deterministic tooling around the model: style, static analysis, architecture rules and CI in one loop the agent can read.
• Share two experiments with your team — one that worked and one that did not.

None of this makes the hard parts of engineering easier. It moves effort: away from typing and toward framing the problem, insisting on proof, and staying answerable for what goes out the door. That is the practice 3 Java Champions converge on, and it is the one worth copying into your own delivery process.