TL;DR: An in-memory H2 database and an embedded broker only prove that your code works against something like production. Testcontainers gives JUnit tests a real PostgreSQL and a real Kafka in Docker. With Spring Boot’s @ServiceConnection, it takes about ten lines of config.

Generated AI image by Google Gemini Nano Banana

Introduction

We’ve all had this build: every test is green, the pipeline is fast, and the team ships with confidence. Then the first deploy hits a real PostgreSQL instance and falls over with ERROR: column "metadata" is of type jsonb but expression is of type character varying.

The tests weren’t lying, exactly. They were answering a different question. H2 told you your code works against H2.

I spent a long stretch of my career in Australian banking, where that gap matters a lot. A test that passes in memory and fails in production isn’t a flaky test. It’s an incident report. So as part of my Java comeback series, I’ve been rebuilding my integration-testing habits around Testcontainers: real infrastructure, started in Docker, managed by JUnit.

In this post, we’ll replace H2 and the embedded Kafka broker with the real thing. Whether you’re maintaining a Spring Boot service or just tired of “works on my H2,” you’ll find patterns you can apply on Monday.

Generated AI image by Gemini Nano Banana

TL;DR — Experienced engineers don’t lack ideas. We have backlogs of half-finished repos that life got in the way of. AI agents now make it realistic to finish them, but only if you can tell what’s actually done. I asked an agent to audit all 70 of my own GitHub repos against hard evidence of agent work, not my memory and not README vibes. It came back with 40 repos carrying receipts, 30 without, and an honest list of leftovers that didn’t fit the story I wanted to tell. Below is the protocol, the prompt, the real numbers, and why a classified inventory beats a highlight reel — whether you have a career break or just one evening a week.

Over twenty-plus years of software engineering, I’ve amassed, to date, over 70 (not 60 - as per my original post claim earlier in the year) personal repos on GitHub. (Yes, that many — and that’s with forks excluded, plus my private repos mentioned in this article)

Scroll through them and you can read my career like tree rings. Plenty started life as learning side projects: a new language, a framework I wanted to get my hands on, a kata to keep my skills from going rusty. Others were genuine pet-project ideas of my own, the kind I was properly excited about the night I typed git init.

The trouble is how many of them stopped halfway.

Not because the ideas were bad. Because life happened. A demanding day job, family, and all the commitments that come with both. Every evening on the laptop was an evening not spent on something (or someone) else. For most of my career, the advice for staying sharp was some version of just build things — good advice for a 23-year-old’s calendar. Somewhere past the twenty-year mark, it quietly turns into a trade: self-learning versus lifestyle. Lifestyle usually won, and rightly so. The half-finished repos just kept piling up.

And suddenly.

TL;DR: Jev is a genuinely useful, very fast decision component you can wire into an agent loop for routing, triage and gating — but it isn’t a coding model, it isn’t a new form of AI, and it isn’t “193x” anything by default. Learn the narrow job it does well, and let the rest of the noise go.

Generated AI image by Google Gemini Nano Banana

Introduction

If your LinkedIn or X feed looked anything like mine during September, Jev was everywhere. “Jev just killed LLMs.” “Swap your coding agent’s brain for Jev and save 400x.” Carousels, reels and threads — many from accounts that, as far as I could tell, had never made a single API call to it.

I’ve been writing a series on the disciplines forming around AI agents — context, harness, loop and graph engineering, etc. My rule for that series has been simple: separate what changes how we build from what only changes what we post about. So before forming an opinion on Jev, I went to the primary sources: TypeSafe’s own documentation, their published failure modes, and the handful of independent benchmarks that actually showed their working.

In this post, we’ll set the record straight on what Jev is and where it fits in LLM-driven agentic coding. Whether you’re building agent harnesses or just wondering if you’ve missed something big, you’ll leave with a practical filter.

TL;DR: AI has made us faster, but speed without reps quietly erodes the skills we need to supervise the code AI writes for us. Platforms like CodeCrafters give you a structured, test-driven way to rebuild real systems — Redis, Git, SQLite, a shell — with your own hands. Treat it as the gym your engineering craft now needs.

Generated AI image by Google Gemini Nano Banana

Introduction

Here’s a small, uncomfortable experiment. Open a blank file, switch off your AI assistant, and write a TCP server that speaks just enough of the Redis protocol to answer PING with PONG. No autocomplete. No chat window. Just you, the docs, and a terminal.

If that made you hesitate even slightly — you’re not alone, and it’s not a character flaw. It’s atrophy.

Back in April, I wrote Dont Let AI Dull Your Software Engineering Edge', which was about how you prompt — forming a hypothesis before asking, tracing generated code instead of accepting it. That post was about using AI well. This one is about the other half of the equation: deliberately spending time without it, so the muscles AI can’t exercise for you stay strong.

By the end of this post, you’ll understand:

TL;DR: Last month I published a nine-discipline roadmap for restarting my Java journey. This is the receipt. awongCM/ecommerce-api is a Spring Boot 3.5 / Java 25 ecommerce API where every discipline on that table — from Optional chains to sealed types, virtual threads, ZGC, GraalVM native image and a Spring AI triage consumer — is a file you can open, a test you can run, or an honest “not measured” row in the architecture doc. Here’s the walkthrough, the code, the gotchas that bit me, and the gaps I refused to paper over.

Generated AI image by Google Gemini Nano Banana

Introduction

In My Java Comeback post, I did the thing engineers do when they want to be held accountable: I published a plan. Nine disciplines, three delivery phases, and a capstone at the end that would prove disciplines 1 through 8 worked together rather than as nine separate weekend tutorials.

Plans are cheap. So here is the capstone: awongCM/ecommerce-api — a production-shaped REST API for an ecommerce store. Register, browse a catalogue, fill a cart, check out, get charged, receive an order-created event downstream.

Two honest notes before we start.

TL;DR: Loop engineering taught one agent how to keep going without you in the room. Graph engineering is what happens once there’s more than one agent — and someone has to decide who talks to whom, in what order, and who’s allowed to see what.

Generated AI image by Google Gemini Nano Banana

Introduction

In my last article, I wrote about loop engineering — the outer cycle that lets an agent run to completion without you steering it turn by turn. Wrap a task in a trigger, a verifiable goal, a real verifier, and stop rules, and you have something that can run unattended for hours instead of minutes.

That post assumed one agent. One loop, one harness underneath it, one job.

TL;DR: You’ve learned to shape what goes into the model. You’ve learned to build the harness that lets it act safely. Now comes the layer that decides when the agent is actually done — and who’s really driving between now and then.

Generated AI image by Google Gemini Nano Banana

Introduction

In my last article, I wrote about harness engineering — the runtime scaffolding that turns a model into an agent: tool calling, guardrails, state tracking, evaluation. If you’ve built one of those, you already have an agent that can act safely inside a single task.

But there’s a question harness engineering doesn’t answer: who decides what the agent tries next, and when it stops trying?

TL;DR: I’m restarting my Java journey — but this time with a phased, deliberate roadmap instead of just picking up where I left off. Here’s the plan: seven core disciplines I’m rebuilding from the ground up — syntax and core APIs, design patterns, Spring Boot and microservices, JVM internals and performance tuning, concurrency and parallelism, modern language features, and cloud-native architecture — followed by three phases that turn the learning into something real and provable.

Generated AI image by Google Gemini Nano Banana

Introduction

My last post here was a tribute to The Java Story documentary — a trip back to my university days and the pioneers who shaped the language I first fell in love with. Writing it did something I didn’t expect: it left me wanting to build in Java again, this time with career capital behind it instead of academic capital.

TL;DR: With the right AI-assisted workflow, an experienced full-stack engineer can pick up a completely unfamiliar tech domain — for me, that was React Native/Expo mobile development — and ship a working, polished product. The tooling didn’t do the work for me, but it collapsed the learning curve enough that domain expertise stopped being a gatekeeper.

Generated AI image by Google Gemini Nano Banana

Introduction

A few months now, I’ve been working on my personal finance tracker lived inside Glide — a no-code app builder that got me from idea to “something I could use” for my own needs. It did its job. But every time I wanted a slightly different chart, a different navigation pattern, or just a UI that didn’t feel like a template, I hit a wall. Glide is great for speed; it is not great for control.

I’ve been using Glide mobile app for several years keeping track of my expenses and I thought it does pretty good job. A simple mobile app that I ‘built’ without actual mobile development experience. Until its major constraints starting to surface which irked my mobile experience when Glide decided to make unannounced changes to its UI template - without my consent 💢🚫🤬. I’ve been meaning to move away from Glide app platform since then. I really want to own the entire mobile development process by myself.

With AI - it handed me that opportunity.

TL;DR: A documentary reminded me that Java was the first language that made programming feel like magic — and twenty-five years later, I finally sat down to say thank you.

Generated AI image by Google Gemini Nano Banana

Introduction

A few of my old Java engineering community contacts shared the same link this week: The Java Story, the official documentary tracing thirty-plus years of the language from a secret set-top-box project called “Oak” to the backbone of enterprise computing as we know it today. I didn’t expect it to hit me the way it did. I watched it the way you watch an old family video — a lump in the throat you weren’t prepared for, at footage of people you never met but somehow still feel like you grew up alongside.

Because I was there too, in my own small way. Not in the room at Sun Microsystems, obviously. But in a university computer lab, almost a quarter of a century ago, when Java had just landed in the curriculum and none of us really understood what we were holding. I remember the hum of the CRT monitors, the smell of instant coffee, the quiet thrill of a program finally compiling after an hour of chasing a missing semicolon. That memory has stayed with me longer than most things from that era of my life have any right to.

This post isn’t a tutorial. There’s no code to run, no gotchas to debug. It’s a love letter — to the language that made computer science feel like wonder before it ever became my career, and to the pioneers who are still, three decades on, quietly carrying it forward.