AIApplications Field Notes: GitHub Copilot Workflows for 3 Java Champions in Java Delivery

AI-assisted coding becomes useful when application teams can see where a tool sits in a workflow, which decisions stay human, and which evidence proves the output can ship. This AIApplications field guide summarizes how three experienced practitioners used GitHub Copilot on production Java, open source, teaching, and embedded work. It is organized for enterprise employees, product managers, and digital project leads who need practical patterns, not model theory.

Practical snapshot of the 3 Java Champions

Vlad Mihalcea, Patrick Baumgartner, and Frank Delporte are Java Champions with over a decade in Java. Their shared view is that GitHub Copilot can accelerate execution, but humans still own context, verification, maintainability, and accountability. The GitHub Copilot app is one interface; the more important asset is a disciplined workflow around it.

Checklist: what an AIApplication workflow needs before writing code

• Define the task: feature, migration, test, bug report, or documentation.
• State the constraints: existing code style, architecture, security, and what must not change.
• Choose the interface: IntelliJ IDEA for review and debug, VS Code for visual feedback, or terminal coding agent for delegated execution.
• Choose the model: Opus with the 1 million context window for deep analysis, lighter models for simple reports or documentation checks.
• Set a definition of Done: evidence must show tests, visual output, architecture rules, and missing documentation are handled.

Vlad Mihalcea: turning a delayed feature into a two day application

Vlad Mihalcea used GitHub Copilot across Hypersistence Utils and Hypersistence Optimizer while analyzing, designing, and implementing features. One delayed feature was a web application showing Optimizer event history, so users can trace performance work to application performance. He had expected weeks; with Copilot he built an application that will ship in the next Hypersistence Optimizer version in two days.

He uses GitHub Copilot in IntelliJ IDEA during code review and debugging. He treats the AI code assistant as speed for investigations and prototypes, while he reviews plans and generated code. Some AI answers are acceptable, but unsatisfactory responses require intervention.

For writing, he created skills so generated text resembles his own work. He says the skill captures his voice from 65 of my published articles, so a draft comes back sounding like my blog instead of like a language model. It lets the LLM learn from 12 years of blogging and provide examples that follow the same principles, such as expressiveness, testability, and simplicity.

He also selects model type by operation. For thorough thinking he uses Opus with the 1 million context window and Extra High or Max reasoning; for reports, release notes, or documentation verification he uses lighter models with fewer tokens.

Patrick Baumgartner: coaching teams while delivery continues

Patrick Baumgartner works while normal business must keep running. You cannot stop everything for six months to transform. He starts with immediate problems, current state, target state, and measures, then moves step by step.

Depending on the situation, that can include Software Craft practices such as TDD, refactoring, continuous delivery, and XP; architecture and modularisation with Spring Boot, Spring Modulith, and Spring Security; container optimization for Java and Spring Boot; or agentic engineering.

Three very different examples

He shared three very different examples that changed his view of GitHub Copilot.

Slide migration: delegate execution, not responsibility

The first migration covered around 900 teaching slides across 15 presentations from Reveal.js to Marp. The decks contained code, animations, and interactive JavaScript examples that had already been tested by students.

A manual migration would likely have taken a week or more. Instead, he and Copilot analyzed material, defined the target, made a migration plan, set constraints, provided examples, and protected what must remain intact. They moved from structural changes to details.

Verification was central. They generated screenshots from Reveal.js and Marp, compared them visually and algorithmically, placed decks side by side to check animations, and compared generated PDFs. Evidence meant the agent could not merely claim Migration complete.

The full migration took roughly eight to ten hours. Content, teaching intent, and meaningful changes stayed his responsibility. Copilot could fix a typo; content, versions, dates, or meaning were discussed.

Tamboui terminal UI: reproducible feedback loops

A second example involved a terminal UI application built with Tamboui. It worked perfectly on Linux under WSL, but he had forgotten that someone might run it directly in Windows CMD or PowerShell.

A real user found that the Enter key was ignored in some forms. Copilot helped convert feedback into reproducible UI tests. On Linux, Copilot navigated the application with tmux. The collaboration taught him psmux, which allowed similar flows in PowerShell.

After reproducing and fixing locally, they traced the issue into Tamboui and submitted an upstream fix that was merged.

The test descriptions grew too large for context, so he asked Copilot to redesign representation. It proposed compact arrow notation: step → step → input, with critical detail only. The representation preserved semantics while being efficient for the agent.

Math learning app: challenge assumptions before building

When someone close to him needed math practice, he considered a small app. It covers addition, subtraction, multiplication, division, and division with remainder for grades one through four.

He wanted more than a quiz. With Copilot, he researched spaced repetition, immediate feedback, adaptive difficulty, motivation, cooperative learning, and gamification without dark patterns.

Copilot challenged one original assumption. He initially wanted the application to be universal for children everywhere. Research shifted attention to actual school curricula because topic order, operations, and number ranges differ. They focused on Switzerland first and supported German, French, Italian, and English.

The app includes two-player modes, explanations for wrong answers, and spaced repetition with similar questions. He chose no backend so children's data stays on device; the app can be hosted on GitHub Pages.

Usage patterns that fit AIApplications teams

Patrick Baumgartner has moved from classic autocomplete to agentic workflows. He uses VS Code for tight visual feedback loops and the terminal coding agent for delegated execution. During roughly a four-hour journey to JavaLand, he steered an agent from his phone while exploring a Maven plugin that optimizes which Spring Boot auto-configurations are loaded.

By arrival, he had a working Maven plugin, CI pipeline, performance tests against a sample application, and reports showing whether the optimization worked. He was not trying to write Java on his phone; he was reviewing, deciding, and steering while the agent executed.

He uses MCP servers when they add useful context, such as Context7 for documentation, Logseq integration, and experiments with Adobe Premiere Pro. If a good CLI exists, he may prefer CLI because it is direct and fast.

Step-by-step tutorial for using Copilot in an application task

1. Ask the agent to interview you and surface assumptions.
2. Request a plan with visible assumptions, verification gates, architecture fit, and no unnecessary work.
3. Execute in small increments while running deterministic checks.
4. Prove Done with evidence: tests, screenshots, visual diffs, CI, and architecture reports.
5. Encode the lesson as a reusable skill so future runs start closer to your baseline.

Tips for teams that ship software with AI

He recommends stopping one-shot prompting. For non-trivial work, ask the agent to interview first and uncover implicit assumptions. A good agent can execute a wrong idea quickly, and detours are expensive.

He learned this on the Spring Boot auto-configuration optimiser. He initially wanted to support Spring Boot 3.5 and 4.x, but architectural differences made maintaining both painful. After removing the 3.5 path, the lesson became clear: get requirements right before accelerating.

Once intent is clear, a plan should show visible assumptions, verification gates, architecture fit, and avoidance of unnecessary work.

Verification gates must be task-specific. For refactoring, gates may include passing tests, proof that all intended files were handled, updated documentation, and no TODOs. For slide migration, gates included screenshots, visual diffs, animations, PDF output, and content completeness.

He cites a skill called unlazy: create explicit gates, work through them, and prove completion instead of taking shortcuts.

He maintains his own Agent Skills. When an execution reveals a convention misunderstanding, missing check, or better approach, he updates the skill so the lesson is reused. A maintainer-audit skill checks repositories for documentation, CI pipelines, Dependabot configuration, CodeQL, cleanup, and project standards. It brings repositories toward a baseline, not merely generating a report.

He also puts deterministic tools around probabilistic models. His quality harness wraps Checkstyle, PMD, and Spring Modulith architecture checks, producing a report the agent consumes. From hooks it iterates change, execute checks, read findings, fix, and execute again until clean.

He still runs the application and decides whether behavior and appearance match expectations. Sometimes he implements feature by feature for a tighter feedback loop. Asking for everything at once because the AI can do it is usually a bad idea; large generic specifications create large generic implementations that are hard to clean.

He also likes the idea of AI as a sparring partner. On a Friday night, when he wants to experiment and no human pair is available, he uses it to challenge an idea, review an approach, or act as a very sophisticated rubber duck.

Common misconceptions about Copilot in application work

• Misconception: Copilot is a junior developer. Better model: a sparring partner that needs context.
• Misconception: speed alone validates output. Better gate: evidence from tests, screenshots, deterministic checks, and review.
• Misconception: one universal process fits every team. Better practice: share what worked and what failed, then adapt ideas to context.
• Misconception: AI removes human responsibility. Better rule: delegate execution, not ownership.

For him, software engineering students should not aim to be code-producing machines. They need problem solving, user understanding, stakeholder discovery, assumption challenging, architecture trade-offs, critical thinking, structured work, and transfer between contexts. AI is good at generating possibilities and executing, while humans know undocumented context. He wants to shape solutions and let agents execute more. He says AI puts engineering back into software engineering.

Frank Delporte: from Commodore 64 curiosity to Pi4J debugging

Frank Delporte became fascinated with computers at age 11 after getting a Commodore 64. Side steps into video production and television led back to coding when video needed to be put on DVD and early websites appeared.

Recent use of GitHub Copilot

For Frank Delporte, GitHub Copilot helps evaluate pull requests and investigate bug reports. A notable case involved Pi4J, the library for Java applications that interact with electronic components on a Raspberry Pi. In February 2026, V4 released a new plugin using the Foreign Function & Memory API. It was tested thoroughly before release, then someone reported that 5 input buttons did not work as expected. Pushing one of the first four configured buttons triggered code execution, while nothing happened with the fifth button.

It was the kind of report nobody wants: no visible break, no exception, no warning in the logs; the fifth button was simply silent. The practical symptom was that events are flaky in appearance, while the real failure was deterministic: the fifth one does nothing. Worse, the older gpiod plugin, the exact same hardware, and the exact same application worked fine. The problem was in new FFM code, which sits on top of the Linux kernel GPIO character device and talks through native calls.

He assigned the issue to the Copilot coding agent and supplied two file paths as starting points: the provider class and FFMDigitalInput. About half an hour later there was a pull request with an unexpected explanation.

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. A virtual thread blocking inside a native call cannot be unmounted from its carrier thread, so it stays pinned for the whole 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 cannot get a carrier, so the fifth one does nothing.

Action advice for application teams

• Start with a narrow task, not a broad transformation.
• Use Copilot as a sparring partner on a Friday night, then bring decisions back to human review.
• Encode repeatable practices as skills, gates, and deterministic checks.
• Measure results by evidence: tests, visual diffs, reports, CI, and maintained code.

For application teams, the lesson is not that GitHub Copilot replaces engineers. It is that Java teams can move from idea to working software faster when they control context, verification, ownership, and reuse.