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.

TL;DR: Six months ago I published a Copilot-specific model guide. Almost every name on it has since been superseded. This mid-year update widens the lens beyond GitHub Copilot to every environment — Cursor, Codex, Windsurf/Devin, Claude Code, or a raw API — and gives each current model the same exhaustive best for / when to use / trade-offs / pro tip treatment. It covers the closed-source frontier (Anthropic, OpenAI, Google, xAI) and the open-weight surge (GLM, DeepSeek, Kimi, Qwen, MiniMax, Nemotron, Mistral) that has, this year, become genuinely production-grade.

Generated AI image by Google Gemini Nano Banana

Introduction

Back in January I wrote a guide to GitHub Copilot’s model picker — GPT-5, the early Claude 4 lineup, Gemini previews, and which to reach for when. That post aged in weeks, which six months on feels like the whole point of writing about this space.

Since then: Anthropic shipped Sonnet 5 and Opus 4.8, launched a new top tier (Fable 5), and had to pull that top model off the market for three weeks under a US export-control order before restoring it. OpenAI iterated through GPT-5.4, 5.5, and the GPT-5.6 “Sol / Terra / Luna” family, and merged its Codex and general-purpose stacks into one model. Google shipped Gemini 3.5 Flash but scrapped and rebuilt its next flagship from scratch. xAI turned Grok into a coding-first model co-trained with Cursor. And a cluster of open-weight labs — Z.ai’s GLM, DeepSeek, Moonshot’s Kimi, Alibaba’s Qwen, MiniMax, and NVIDIA’s Nemotron — closed the gap on the frontier to single benchmark digits while running at a fraction of the cost.

This time the post is not Copilot-specific. If you’re in Cursor, Codex, Windsurf, Claude Code, or straight through an API, the same models and trade-offs apply — only the interface changes. The discipline is the same as January: match the model to the task, not the task to whatever’s newest. There are just a lot more models now.

Generated AI image by Google Gemini Nano Banana

Introduction

You’ve learned to write better prompts. You’ve learned to structure context. Now it’s time to think about what turns a model into an agent — and what keeps that agent under control once it’s running.

What Is Harness Engineering?

In my previous article, I mentioned context engineering quite a bit and how it’s important for developers to master in this AI era we’re in. If you’ve spent time on context engineering, you already understand one truth: the quality of what you give an AI model matters as much as the model itself.

Harness engineering is the discipline that comes next — and it’s a bigger shift than it first sounds.

Context engineering answers what do I put in the prompt? Harness engineering answers a different question: how does the model actually act — calling tools, tracking state across steps, staying inside guardrails — and how do I control that?

Generated AI image by Google Gemini Nano Banana

Introduction

“Prompting is easy. Getting reliable behavior from an AI system is hard.”

If you’ve ever built or worked anything serious with LLMs, you’ve already discovered the truth:
hallucinations, drifting answers, and inconsistent behavior are not bugs — they are symptoms of bad context.

Here’s a number that should change how you think about this: developers in 2026 can fully delegate only 0–20% of tasks to AI agents — even though those agents are completing an average of 20 autonomous actions per run. The bottleneck isn’t model intelligence. It’s context quality.

In 2026, the most important AI skill for developers is no longer prompt engineering.
It is context engineering.

This post explains what that really means, and how developers can build AI systems that are predictable, grounded, and production-grade.

Generated AI image by Microsoft Bing Image Creator

Introduction

Practical prompts to stay cognitively sharp while using AI tools every day.

Earlier in the year, one of my personal breakthroughs working with AI is to help accelerating my learning and picking up new skills faster than I would spend hours and hours digesting tech documentation from engineering community blogs, manuals etc. That’s what I love all things about AI. It’s essentially an enhanced Google search - but running on steroids that we all come to accustomed this new ways of software engineering learning mastery.

But as I use it more and more, I also start to notice that it’s not just a tool that helps me learn faster. It can also be a tool that helps me learn less. When I reach for AI before forming my own hypothesis, accept generated code without tracing it, or skip the “why” and go straight to the fix — I’m not using AI as a tool. I’m outsourcing the thinking that makes me an engineer. Over time, debugging intuition, design judgment, and first-principles reasoning all quietly degrade.

So the lingering question beckons - are AI coding tools accelerating your learning and fulfilling your engineering curiosity? Or are they quietly replacing them altogher? The difference comes down to how you prompt.