About The Main Thread

The Main Thread is where I work through the things in software development that deserve more than a quick answer.

Java and Quarkus are still a big part of it. But the scope has grown. I write about agentic engineering, AI-assisted development, software architecture, developer tooling, and the sometimes uncomfortable changes happening to the way we build software.

Most articles start with something I want to understand myself. A new API. An architectural idea. A production problem. A tool that looks interesting but needs to prove that it is useful. I build something, break it, read the source or documentation, and try to figure out where the actual boundaries are.

The result is usually code, experiments, and a lot of opinion about what works, what does not, and where I would be careful in a real system.

This is not a publication for learning Java from scratch. It assumes that you already know how software gets built and that you are interested in what is changing underneath it.

Written by a Human. Heavily Assisted by AI.

I want to be very clear about this part: The Main Thread is heavily AI-assisted.

I use transformer models throughout my work. They help me explore ideas, research unfamiliar areas, challenge assumptions, work through code, find alternative designs, structure articles, edit drafts, and sometimes discover a completely different article than the one I originally planned to write.

That does not mean I hand an article topic to a model and publish whatever comes back.

The interesting part for me is the collaboration.

AI can generate options very quickly. It can connect things I would not have connected. It can also be confidently wrong, miss an important constraint, make code look more complete than it is, or turn an interesting idea into very polished nonsense.

So my job changes.

I decide which questions are worth asking. I decide which ideas survive. I run the code. I check the boundaries. I bring my own experience with Java, enterprise systems, developer tooling, and production architecture into the process. And ultimately, I decide what I am willing to put my name on.

That combination of human judgement and machine capability has become part of how I work, and increasingly part of what I write about.

If you are interested in the process behind the articles, I talked in detail about how I combine my own judgement with AI and transformer models in this recording:

Watch: How I work with AI when creating technical content

I don’t see AI assistance as something that needs to be hidden. Quite the opposite. We need more transparency about where these tools are useful, where they fail, and what human responsibility looks like when they become part of serious engineering work.

Who Writes This

I’m Markus Eisele. I’m a Java Champion, developer advocate, speaker, writer, and I work at IBM.

I’ve spent more than 20 years around enterprise Java and the systems built with it. That has included application servers, distributed systems, cloud-native architectures, modernization projects, developer tooling, and now increasingly AI-assisted and agentic software development.

I speak at conferences, work with developer communities, experiment with new technologies, and spend a probably unreasonable amount of time trying to understand what happens when an elegant idea meets an actual production system.

Everything published here represents my personal work and opinions. It does not represent IBM or any other organization I work with.

What You’ll Find Here

A few themes keep showing up.

Java and Quarkus remain the technical foundation. I write about framework internals, APIs, runtime behavior, testing, security, performance, and the small implementation details that suddenly become very important in production.

Agentic engineering has become another major thread. That includes coding agents, MCP, ACP, tools, permissions, memory, evaluation, workflows, guardrails, and the engineering work required when probabilistic systems start changing deterministic systems.

AI and software development goes beyond adding an LLM to an application. I’m interested in what happens to development itself: specifications, reviews, debugging, architecture, developer responsibility, and the boundary between human judgement and generated work.

Software architecture connects all of this. I keep coming back to boundaries, contracts, failure modes, maintainability, and the decisions that make systems easier or harder to change five years later.

And sometimes I simply find something strange or useful and build an experiment around it. Those tend to become some of my favorite articles.

Most hands-on articles include working code. You can find the projects and examples on my GitHub account.

Why The Main Thread

Software development produces an enormous amount of noise.

New models. New frameworks. New abstractions. New claims that something has changed everything.

I’m interested in following one thread far enough to understand what is actually there.

That means spending more time on fewer ideas. Building things. Looking at the trade-offs. Finding the boundaries. And admitting when the result is less impressive, or more interesting, than the headline suggested.

That’s what The Main Thread is for.

Follow the thread. Understand the system.

Stay Connected

User's avatar

Subscribe to The Main Thread

Following the thread through Java, AI, and software architecture.

People