User unregistration sounds simple until you look at the rest of the system.

In a booking application, “delete this user” is never just one DELETE endpoint. It touches active bookings, foreign keys, historical reads, cache state, and the uncomfortable question every senior team eventually has to answer: is this really a hard delete, or is it deactivation, anonymization, or something in between?

That is why I like the workflow Alex Soto shows in the latest video. He does not start by asking IBM Bob to write the feature. He starts by asking it to map the regression impact before implementation. That is a much better use of an assistant.

Use the Agent Before the Feature Code

I still think the basic rule is simple: use AI to go faster on work you understand already. If you hand core business logic to a model and hope for the best, you are outsourcing the part you still need to own.

Impact analysis is different. Here the agent helps you read the shape of the system, collect likely break points, and build a regression plan before the feature branch gets noisy. In this case, “shift-left” just means you do the regression thinking before you touch the code that will trigger it.

That matters because deletion flows are where business rules stop looking like CRUD. One missing constraint check and you get orphaned rows, broken history screens, or a second-order production issue that only shows up after cleanup jobs or cache refreshes run. Efficient. Also bad.

Why IBM Bob Fits This Job

It’s not IBM Bob’s magic that makes this work: It is context.

Bob runs against the workspace, so it can inspect the actual resources, entities, and services in the application. That gives it a real basis for the regression plan. It is reading the model you are about to change, not guessing from a paragraph of pasted code.

That is the difference. A browser chat can still help, but a workspace-aware tool can follow relationships across the codebase. For something like user unregistration, that is where the interesting bugs live.

The Prompt Is Small on Purpose

Alex starts with a constrained prompt:

“Act as a tester. Identify the areas of the system that should be included in regression testing after changes are made to add the unregistration of a user. Don’t implement anything.”

Don't implement anything keeps the session focused on analysis. Once an assistant starts writing code too early, it tends to collapse design, impact analysis, and implementation into one optimistic blob. That is fine for demos. It is much less fine when a deletion rule can invalidate half your booking flow.

What a Good Regression Plan Should Surface

Because Bob can inspect the workspace, it can point at actual system boundaries that deserve tests before the first delete path is implemented. In this example, the report highlights the kind of things I would expect a senior developer to check immediately:

* Active booking rules. What happens if the user still has a live reservation, an open payment flow, or another stateful process attached to the account?

* Database integrity. Do deletes cascade, fail fast, orphan records, or silently leave history in a shape the rest of the system no longer understands?

* Historical read paths. Can past bookings, reports, and audit views still load after the user record changes or disappears?

* Cache and derived state. If user data is cached, indexed, or copied into another read model, what gets invalidated and when?

* API behavior. What does the endpoint return when the user has already been unregistered, cannot be removed, or does not exist anymore?

This is where the workflow earns its keep. The assistant is not replacing engineering judgment. It is helping you build the list you will review anyway, only faster and with fewer blind spots.

The Senior Java Questions Start After the First Report

A regression plan is a good start. It is still only a start.

If I were taking this feature forward, I would want the team to answer a few more questions before implementation:

* Is “unregister” really delete? In many systems the right answer is soft delete, anonymization, or status change because legal retention, reconciliation, or audit rules still apply.

* Where is the transaction boundary? If one part of the removal fails, what rolls back, and what can be left half-done?

* What is the concurrency story? If one request unregisters the user while another creates or confirms a booking, which invariant wins?

* What happens on the second call? Idempotence matters here. A repeated delete should not create fresh damage.

* Which tests belong at which level? Some checks belong close to the domain model. Others need @QuarkusTest, HTTP assertions, persistence wiring, or a packaged-app check with @QuarkusIntegrationTest.

That last point is worth calling out. A lot of teams mix regression planning with test implementation planning and then get a giant bag of tests with no clear boundary. I would rather make that mapping explicit up front.

Turn the Report Into Proof

The report is useful because it changes what we test first.

For a change like this, I would usually split the work into a few layers:

* business-rule tests around the unregister decision itself

* persistence tests for relationship handling and transaction rollback

* @QuarkusTest coverage for the HTTP and CDI wiring

* packaged-app checks with @QuarkusIntegrationTest when the deployment shape matters

After that, continuous feedback matters more than one big test run at the end. Quarkus continuous testing is a good fit here because the regression plan will usually touch multiple paths, and you want quick confirmation while the model is still moving.

Coverage still matters, but later. First make sure the dangerous branches are tested. Then measure what you actually covered.

Further Reading

* Quarkus: Testing Your Application for @QuarkusTest, transactions in tests, mocks, and @QuarkusIntegrationTest.

* Quarkus: Continuous Testing if you want fast feedback while the unregister flow is still changing.

* JUnit User Guide for the current programming model, extension model, and test organization options once the regression plan becomes a real suite.

* JaCoCo Coverage Counters if you want branch, instruction, and complexity numbers to reflect the paths that actually matter.

* IBM Bob if you want to try the workspace-aware analysis workflow Alex uses in the video.

If your unregister flow goes through JPA or Hibernate relationships, read the deletion and orphan-handling rules in the ORM documentation for the exact version you run. That is one of those areas where small mapping details decide whether cleanup is correct or catastrophic.

Why I Like This Pattern

I like this workflow because it uses the assistant where assistants are actually useful: reading a codebase, building a candidate regression map, and giving you a sharper review checklist before implementation starts.

You still need to decide the delete semantics. You still need to own the transaction model. You still need to write the tests that prove the feature is safe.

But you do not need to build the first regression checklist from memory every single time. Let the tool help there. Save your energy for the decisions that still need an engineer.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.the-main-thread.com