I can't express with enough words how happy I'm to join the amazing group of @Java_Champions!

I need to say thank you to the global @java community for being so good to me since the day one.

Thank you also to my fellows from @soujava: it wouldn't be possible without you!

#java

Don't study programming anymore. Don't study software engineering. Just study AI.

That's by far the worst career advice you can get today if you're a software engineer or want to be one.

A lot of people think that because AI took over the code, software engineering is solved. And unfortunately even some engineers haven't figured this out yet.

Code is a relevant part. But it's this much of software engineering.

Software engineering means understanding some product, often a lot of product. Understanding your user. Understanding the context that product lives in. Understanding how your application interacts with every other component around it: the architecture, the components it talks to, the protocols involved.

Software engineering means pulling out of the user, often with forceps, what they actually want.

Someone might say:
- "But that's the product manager's job."

Right. And the product manager still has to pass it to the engineer.

So picture a game of telephone from the user to the product manager to the engineer. You still have to pull it out of that person and turn it into something actually usable, a real product, something that exists.

If you really want to fail as a software engineer, follow that advice.

I started out very skeptical about AI. ChatGPT launched at the end of 2022, 2023 was all hype, and I didn't care. People close to me were saying:
- "Look how cool this is."

And I was like:
- "I don't know, I don't see the value yet."

Mid 2023, Yara Mascarenhas from TDC sent me a long audio, five minutes, about launching what is now TDC Summit AI. She wanted my opinion. I told her it was too niche, too specific. Good thing she didn't listen to me. The event is gigantic today.

What changed for me was October 2023. I wasn't there, but at Devoxx Belgium they presented LangChain4j, the big engine for integrating Java with AI models. That's when I connected the dots. I can write code with what I already know of Java and connect it to an AI model. Back then nobody talked much about generating code with AI, but I got it: I can take everything I've done in almost 30 years and use AI to multiply it.

I checked my history. I only created my ChatGPT subscription in February 2024. A few months later I spoke at the first TDC AI summit about LangChain4j. Once I connected things, I went all in.

For a long time I felt I wasn't an early adopter. Then I saw a chart of AI adoption in the world. People using AI agents to build things are a fraction of a fraction of a fraction. If you're starting with agents now, you're an early adopter for humanity.

You don't have to be first. And you don't have to adopt something if you don't see value in it, as long as you actually went and checked. Once you see the value and don't go after it, that's when you're dropping the ball.

A while back I ran a workshop with a group of entrepreneurs and most were still only using chat. If you're just getting started, you're not behind.

@elderjava LangChain4j was my entry point too. What clicked for me was that an AI service is just a Java interface returning a record, so model output hits the type system before it hits business code. Thirty years of validation and testing habits still apply.

@gagu_sh That’s it! 🔥🔥🔥

I don't know about you, but I've cursed at a few AIs for giving me wrong answers. And cursing is kind of an idiotic move. I know because I've done it.

Why idiotic? Because it isn't lack of technical capability or lack of information. It's hallucination. And from the model's point of view, hallucination isn't exactly an error. The model generates that answer because it's plausible. It does probabilistic processing and, probabilistically, that answer is plausible, even if it's wrong.

And the funny part is, every time it happened to me, I'd think:
- "Man, I already told it that's not it. I already wrote what to do."

And it keeps drifting.

A lot of people try to fix this in the prompt. For simple cases, that helps. In a complex task or a big, complex codebase, the prompt alone helps very little.

So there are two ways.

First, the basic one, for simple and medium cases: a structure of context files. In your AGENTS.md or CLAUDE.md you point to where the context for this project lives. What it is, what it does, conventions. Nothing super evolved.

Second, for big projects and big contexts, code or not: RAG, Retrieval Augmented Generation. It takes those documents, maybe the same context files, and vectorizes them. Turns that context into a vector space, basically a bunch of numbers we can't read. That becomes part of the agent's context when it calls the model, much more refined, much more pre-chewed. And the model tends to give much more precise answers.

So instead of cursing at your agent, give it a file structure that improves the context, or for more complex scenarios, think about a RAG.

Novo AI-JAIL 3 no ar!

aijail.io/configure/

Não tem como ter certeza de tudo que um agente vai fazer, ele tem acesso ao seu PC inteiro. Então, melhor jogar ele dentro de um PRISÃO e controlar exatamente o que ele pode ou não pode acessar.

Antes precisa configurar isso com do. Agora eu fiz um TUI pra deixar mais intuitivo, especialmente pra quem está usando pela primeira vez.

Além disso também adicionei hooks de integração, pra funcionar melhor integrado ao AI-MEMORY ou qualquer outra ferramenta que quiserem integrar.

A while back Matt Pocock interviewed Uncle Bob, the author of Clean Code and Clean Architecture.

Uncle Bob had drawn a lot of attention for posting that he doesn't read the code generated by his AI agents. Reactions were extreme. On one side, a lot of people saying:
- "That's right, no need to read it."

On the other:
- "Are you crazy? The clean code guy doesn't read code anymore?"

What caught my attention: he's taking everything that was good practice when we wrote code by hand and applying it as rules for the agents. Rules in the sense of actually limiting the agent. Hard, deterministic constraints. Not the "just ask nicely and the AI does it" people talk about. He puts the agent inside a harness.

Then he said something like this: with all that harness, a routine the agent would write in 5 to 10 minutes now takes an hour.

Maybe you're thinking:
- "So the agent is slowing him down?"

And then he adds:
- "That same code is still two to five times faster than I'd be."

He gives up a big chunk of the agent's raw speed to add constraints, and still gets two to five times his human productivity. Mathematically that makes total sense to me. And he still reads by sampling, picks random pieces to check it's not going off the rails.

We can't chase productivity for productivity's sake. For a tool only I use, something that won't face the internet, I don't even care what the agent is writing.

When it's open source, for a client, for my students, anything other people will touch, I want all the care, and his approach made a lot of sense to me.

One more for the series of nonsense said in times of AI: SaaS is dead.

This isn't for you if you built an ERP or a CRM for your company because what's on the market didn't satisfy you or was too expensive. That's fine, you should do that. If you pulled it off, be happy with your CRM.

But it's very naive to think that reshapes the whole SaaS market. A market worth hundreds of billions of dollars a year.

Take one of the biggest SaaS companies on the planet: SAP. You really think me building my little CRM for my tiny business makes me part of a trend that takes down SAP? It makes no sense.

And look at SAP. Partnership with Anthropic. Partnership with OpenAI. I'm not sure, but I imagine with NVIDIA too. They're plugged into every big AI player right now.

So while you're doing something super cool on your local platform, you think they didn't already have that tool you've been using for months? Long before the market? And that they aren't building into their own products the things that will keep them alive for more decades?

Don't let the AI dazzle make you think you found the pot of gold at the end of the rainbow.

What worries me most is people falling for the con of whoever says the technology is going to die, when the market is just growing. Demands are growing, a lot of it because of AI. People now see they can build things they'd never build out of laziness, and now we need more people building, more tools and more companies taking part.

Maybe you've felt lost about what to choose in tech. Programming or infrastructure? Backend or frontend? This language or that one?

Those are legitimate doubts. And what causes that confusion usually isn't the lack of information. It's the excess. We're drowning in feeds, shorts, fast information. And it gives you countless possibilities that are all viable, all make sense.

So what do you do?

The framework that works for me is looking at people who got where I want to get. But careful, because we usually look only at the surface. That person made a lot of money, I want to make a lot of money, so I'll listen to them.

The question that has to come first: do you want to do what that person does?

Someone made a fortune opening supermarkets and butcher shops. Great, admirable, not what I want to do. First filter: people in my field. That one is very successful, but in infrastructure. Let me look for software engineers, which is my case.

That gives you direction on what you consume.

Every now and then I clean up who I follow. Sometimes I unfollow people whose content I even like, because it isn't helping me get closer to where I want to go.

If you're confused about decisions and paths, select better who you're listening to and following. You'll probably clear a lot of garbage out of the way too.

That old system of yours, the one many call legacy, isn't a barrier to using AI. It's probably one of the biggest opportunities you have to use it.

The longer you go without upgrading, migrating, refactoring, the harder it gets. Bringing an app from Java 8 to Java 25 is much harder than going 8 to 9, 9 to 10, 10 to 11. In the Java world, if you upgrade every version, there's usually almost no work at all.

Why is the big jump hard? Lots of refactoring, lots of testing, lots of exploration, issues, external dependencies. So people and companies give up: it's running, it's working, leave it alone.

Now you have a tool that can explore endlessly, as long as you can pay for it. It doesn't get tired, doesn't sleep, isn't ashamed of getting it wrong and fixing its own mistake. And you can keep it minimally safe: work on a branch, in a worktree, without deleting everything.

And you don't upgrade because running on something newer is cool. Newer versions give you more integrations, more security patches, more tools in the ecosystem. In Java, often just switching the JVM gives you a performance gain without rewriting a line of code.

I'm doing this myself right now with several of my blogs, sites and pages that run my business on old platforms. I'd know how to do it, but I'd never propose doing it, it's a hell of a job. I started with an audio conversation with an AI, it interviewed me, proposed things. I wrote the spec, the implementation plan, it broke in the middle, we fixed it, and it's moving.

That difficulty dropped a lot. Look at what you have sitting on an old version and never migrated because it was too hard.

@elderjava Agree on the upgrade cliff. On Java agents I treat a major JVM jump as a harness job: branch worktree, Surefire golden module list, and a merge gate that fails if the agent skips the regression suite. Exploration is cheap; a silent green on a half-migrated tree is not.

@gagu_sh Totally agree! 👏👏👏

I see a lot of people still using AI chat when they could be using an agent. And because of one simple change, they're getting much worse answers than they could.

AI went public through chat. ChatGPT, end of 2022. I like to say OpenAI threw AI into the fan. Nobody had ever seen anything like it.

In 2025 the agent wave came, and at the end of 2025, early 2026, models took a jump in intelligence and agents completely changed the game.

Here's what I keep seeing. I ask a dumb question in a chat, I get an answer. I take the same question to the agent of the same AI, Claude, Codex, GitHub Copilot, whichever, and the answer gets absurdly better. More detail, more depth, more possibilities.

Why? Function calling. Tool calling.

In chat, the tools are very limited. Internet access, sometimes file or PDF generation. In agent mode it has access to many more tools. Depending on what you ask, it writes code on the spot to help it answer you. That changes everything.

A while back I ran a workshop with a group of entrepreneurs. I surveyed them first and most were still on chat. One of my main goals was to get them out of chat mode and into agent mode.

On your computer it's simple. Install Claude Code or the ChatGPT desktop app, switch the tab, point it at an empty directory so if it deletes something it won't hurt you, and ask your question from there. Then compare.

A lot of people are worried AI will take their job. That's not the biggest risk. The biggest risk is AI taking our thinking. Stealing our ability to think.

A while back someone asked me the dumbest thing I'd ever heard about AI. I told them it was someone I saw claiming:

- "You just have to ask nicely and the AI does it right."

I even joked:

- "It's like your mom or your grandma."

You ask with a bit of charm and they do what you asked.

Then someone commented, and they were not joking:

- "That's true, the AI doesn't know anything, you're the one who knows."

What's behind that? Do you think you know more than AI? It's not just me. You know much more than AI. Everyone does.

- "No way, AI has infinite content."

Walk into a library. That content is infinite too. Put the whole library in a database, still infinite. And you still know more.

A friend told me:

- "There's no intelligence in artificial intelligence."

It's probabilistic. Incredible, powerful, probabilistic so well done it looks intelligent. It isn't.

People who really know this stuff keep saying AI made creating things so easy that now the question is what to create. AI will give you endless ideas. Ask it to give you ideas all day and it will. But the decision of what's worth building is still mine and yours. That's the intelligence.

Knowing isn't the amount of data in our brains or in the AI's infinite storage. It's turning that into creative things, things that solve someone's problem, things probabilistic analysis will never get right.

People are creating infinite stuff on the internet with AI. How much of it is relevant? A tiny bit. And that tiny bit is worth a lot of money.

So don't outsource to AI what only you have and it doesn't: intelligence.

The hardest thing in any software engineering project, believe it or not, isn't technical.

It isn't learning architecture, knowing design patterns, how to distribute the components, the load of that application in production, security. Those things are extremely important, obviously, more or less complex depending on the project. But they're not the hardest thing you'll deal with.

The hardest thing is knowing what's worth doing and what isn't.

Any medium or large project has infinite demands. I worked for years in small companies too, and the demands were infinite. I left, and the demands stayed infinite. I still talk to people there, same project, same infinite demands. A friend of mine calls this the infinite game: career, the software industry, work in general.

So if the big question is defining what needs to be done, we need to dedicate ourselves to choosing our next battle. Our next demand. What we do next.

That's also why, a while back, I decided to start a series of 365 videos. 27 years as a developer, 10 creating content, and the structures I built to condense ideas started restricting me more than helping. I wanted to just open the camera and talk, and think out loud while I record.

@elderjava Same! The architecture I can usually figure out.

Knowing what's actually worth doing? That's the part nobody teaches you in the tutorial. It comes from reps and reps only.

@tomreilly_ai Yep! Nothing beats the “battlefield”.

@elderjava A question I’d put next to every candidate is “What gets pushed back if we do this now?” It’s easy to call two requests high priority in isolation. Naming the work each one displaces makes the choice much easier to explain to the people waiting.

@ziyouzhixu Nice! 🔥🔥🔥

Java is a language that arrives late to things. Let me prove it: lambdas, records, virtual threads, generics. Many other languages had them long before.

Now you might be thinking:

- Elder, are you trashing Java?
- Quite the opposite. To me this is one of Java's big advantages.

Before I tell you why, think of a company that's an expert at arriving late: Apple. It wasn't the first to launch a tablet, or a smartphone like the iPhone, or an iPod. It always got there later. And what's the advantage of arriving later? You get to avoid the mistakes others made.

A great friend of mine says Java has always been a production language.

- Yeah, but every language is a production language.
- True, every language is made to put things in production. But not every ecosystem has the culture of looking at production before shipping something. In Java that was always priority number zero.

The practical consequence? Lambdas, records, virtual threads, generics, and plenty of others went in without bugs in production. You won't find stories of "wow, records blew up in prod because they got the implementation wrong."

I've been at this for 27 years and I don't think Java will ever race to ship something before other ecosystems. And to me that's a career lesson too. Do I really need to rush to be the first to do something? I don't know. Looking at a language with over 30 years in the market, still evolving like no other, I think they know what they're doing.

@elderjava Java lambdas had numerous bugs when they first arrived. Mostly affecting compilation or developer experience, not production

@antonkeks Interesting… I've been working with Java since 2002, have spoken with thousands of Java developers every year, and have never heard anyone talk about bugs in lambdas.

You are literally the first one!

@elderjava @grok I can only speak for myself; I've been a developer in corporate America for ~30 years and for the past 15 years every Java application I've come across has been legacy in maintenance mode.

@kozmob808 @grok Well… 80% of a developer's career is about maintaining code… 🤷‍♂️

@poutine_ca @elderjava So wrong in so many ways. Have you ever worked with Java? Even 10 years ago there was already JDK 8 which has been released in 2014 and generics have been introduced in JDK5 (2004)..

@elderjava late doesn't mean safe by default: virtual threads can still overwhelm database connection pools

@sebuzdugan Check Semaphore.

Maybe this happened to you. You're the one who delivers the most on the team, ships the most to production, solves everything. And when recognition comes, someone else gets it.

We usually look for someone to blame. My boss doesn't see me. That guy is a suck-up. The company looks at the wrong things.

After almost three decades, and going through this myself a few times, I realized: it wasn't exactly my fault, in the sense that I did something wrong. I failed to give visibility to my work.

- So I have to talk every time I do something?
- Yes, you do.

The company is looking at numbers, deliveries, projects. Not necessarily who did it, how, why that decision was right. You're responsible for giving visibility to your work.

In my mentorship conversations people worry: people will think I'm showing off. It depends on how you do it. Send a periodic report. Friday, macro topics of what you delivered this week, on Slack, email, whatever, to your lead, your manager. Then monthly highlights. Quarter, semester, year. No pull request details. Highlights.

People are taking care of their own lives. Usually not out of malice. Everyone is busy.

And if it doesn't help you where you are, it helps in your next interview. The recruiter asks for a cool project you did this year, and you remember, because you reported all of them.

Same when you negotiate a raise. "Because I've been here a long time" is a terrible argument. "I deserve this raise because in the last year..." and then your highlights.