Ask experienced engineers how AI has changed their work. Some will describe it as the most enjoyable stretch of their careers, while others feel a decade of expertise slipping in value. Bruno Souza, a Java Champion who has been helping developers with their careers since 1995, hears both kinds of stories, and some of them are hard to hear. One fellow Java Champion recently lost three pieces of his livelihood in quick succession. And in today’s Engineering Leadership feature, Souza shares why he thinks the larger risk for software architects comes from somewhere else, in a habit he calls cognitive surrender.
Souza founded SouJava, the Brazilian Java users society, and co-wrote Developer Career Masterplan with Heather VanCura, published by Packt, which also publishes Deep Engineering. At ARC 2026, Packt’s virtual conference, he laid out his advice for architects, which comes down to keeping the thinking for yourself and giving AI the work you never wanted to do.
This is important now because companies are already making staffing decisions based on what they believe AI can replace. And he grounds his argument in what developers across the industry have been telling him.
Developers are telling two stories
The optimistic accounts that developers give are easy to find. An open source developer with more than twenty years of experience told Souza that AI frees him from the stuff he doesn’t want to do. A community leader who returned to engineering after three years in management put it more strongly. “It is the most fun I ever had in my life as an engineer.” These accounts are optimistic and genuine, but they also suit the marketing that keeps hype cycles running.
Because the harder accounts come from people with just as much experience, they’re harder to dismiss. A developer with twelve years of experience in the field wrote that AI “beats my decade of experience in one hour.” Another, with twenty years behind him, described himself as a “prompt monkey” who rarely writes code anymore and ends each day exhausted from reviewing what the AI produced. And another Java Champion lost a training program, a book deal and one of his oldest clients after each decided AI or internal teams could cover what he offered, which left him struggling to find work. Souza himself shares that story as a reminder that experience alone no longer guarantees the next contract.
Souza doesn’t dismiss either camp. “If you’re worried about your future, it’s not craziness on your part,” he says. Nor does he pretend the transition will be painless. “But the reality is that you’re gonna have to think different for sure.”
And that starts with being honest about which story sounds like yours. When AI absorbs work you never enjoyed, the time it frees is worth reinvesting in harder problems. But when it’s absorbing the work you were proudest of, that’s the part of your role to redesign first, and the rest of Souza’s advice explains how.
More code will need more people
Much of the anxiety developers feel right now, in Souza’s engineering perspective and foresight, comes from a mistake management is making. Managers, directors and even CEOs can now prompt an AI into producing working code, and tragically some conclude they need fewer developers. “I can’t believe that with more code being generated, more software being created, anyone is thinking that we need less developers,” Souza says, calling out what economists know as the lump of labor fallacy, the belief that there’s only a fixed amount of work to go around. It’s the same logic as deciding that more food means fewer cooks, or that more books mean fewer writers.
And the code written by people isn’t going away either. The best alternative to AI-generated code already exists in open source projects that do most of what an engineering team needs, but plenty of teams still build their own frameworks regardless, taking on undifferentiated heavy lifting that often turns into technical debt. This is why code written by people will keep growing alongside the code AI generates.
The truth, however, is also simpler than any market trend. Developers who love writing code will keep writing it.
But none of that protects anyone from a bad call at their own employer, and Souza, being assertive, puts it in simple words. “Your company might be one of those crazy companies. So you might even lose your job. But you will be fine.” Realistically, he’s especially confident about architects, “because a lot of people are looking for architects.”
The practical response is to keep your employer’s strategy separate from your own. If your company is cutting staff on the assumption that AI replaces developers, invest in your network and your reputation outside it, because those come with you when a job doesn’t.
Cognitive surrender is the bigger risk
Souza explains the danger with an experiment from 1931, when the psychologists Winthrop and Luella Kellogg raised a baby chimpanzee named Gua alongside their infant son, Donald. Gua outperformed Donald at most early tasks, because chimpanzees develop faster. But she never learned to speak, and Donald began imitating her food bark instead. The Kelloggs ended the experiment after nine months.
What matters to Souza is which way the learning moved. “AI does not learn with you. It does not improve. If you need a better AI, you train a new model,” he reasons. People keep improving, and the human brain has a capacity that goes far past anything AI can do. “AI gets you from zero to average. Immediately.” Everything above average is still yours to supply.
“The problem that we’re facing right now is when we stop seeing AI as a tool and we start seeing AI as us,” Souza points out, warning that the surrender leads to intellectual decay. “When instead of you using your intellect, instead of you using your imagination, instead of you being you, you let AI be you.” His rule for avoiding it fits in a single line. “AI for you, but never AI as you.”
Sharing a personal example, Souza says his wife ran into the consequences recently, after she had paid for a training course she never received. The support agent kept promising to fix the problem without ever disclosing it was an AI. When she finally reached a person, the company had no record of her request, and it lost her confidence as a customer. All because the company had handed its customer relationship to a system that had no way to keep one.
AI isn’t sentient, and it isn’t supposed to be. But delegating to AI isn’t the mistake, though. Souza considers doing the things you don’t want to do the best use of AI there is, while rejecting the idea that skipping tedious work makes anyone lazy. “When you don’t do something that you don’t wanna do, that’s not laziness.” A carpenter who trades a hammer for a power tool hasn’t become lazy either.
For architects, the boundary falls in a specific place. Use AI to help you define requirements, understand a system and plan what needs to be done, and keep the design decisions and the stakeholder conversations for yourself. “When you stop being an architect, to let AI be the architect, that’s when you start losing,” Souza says. That’s cognitive suicide, committing to the machine’s most probable answer without the judgment to question it.
A practical way to hold that boundary may be to keep a short written list of which parts of your week are AI for you, meaning the tedious work you’d hand off without a second thought, and which parts are you, meaning the judgment calls and conversations your reputation depends on. Consider revisiting it every month or two, because the line drifts when deadlines tighten.
No intelligence in artificial intelligence
Souza’s sharpest argument, that “there is no intelligence in artificial intelligence,” is also his simplest one. He says it’s because AI is “a mathematical calculation. The intelligence is not on the formula. The intelligence is on the people that build the formula.”
By that, he means large language models specifically. AI that analyzes large volumes of data and surfaces trends has existed for decades, and Souza’s own first research project at university used it in 1994, he says. What’s new is software that speaks your language and sounds certain. An LLM will tell you it wrote the code, checked the security and confirmed everything is safe, and then agree with you instantly when you point out that anyone can reach the application without logging in. It tends to agree with you and please you, and its reasoning often stays on the surface.
So treat every confident answer as a draft to be thoroughly tested. Ask the model about the gaps, to understand what would break the design and even what it hasn’t checked. That’s a good starting point for measuring those answers against what you know about the system before accepting any of them.
For teams already worn down by reviewing machine-written code, Sándor Dargó’s guide to reviewing code an agent wrote is a good place to begin.
Architects own the questions
For years, engineering teams asked customers and managers to say exactly what they wanted, and rarely got a clear answer. Now everyone agrees that AI needs full context and a precise picture of the problem. Souza sees an opening for architects in that shift, because the information they always asked for finally has to be written down.
Writing it down still isn’t enough. Sharing his own experiment, Souza says that when he specified a small application as thoroughly as he could and answered every question the AI raised, it still built something different from what he wanted, because parts of the problem weren’t clear enough. “If you just leave to the AI to talk to people, to build the specification, it’s not gonna ask the right questions,” he says.
In one of our recent Engineering Leadership pieces, Cassie Shum argued along similar lines that AI acceleration exposes the friction developers used to absorb, and unclear requirements account for much of it.
That also answers developers who feel lost now that AI writes so much of their code. “A few years ago, if I told you that your value as a developer is the number of lines of code that you write, you’d be offended,” Souza underscores. The value was always in understanding the problem and deciding what should be built.
In practice, that means owning the conversations with the people who will use the system and writing the context yourself rather than letting an agent gather it. Before handing a specification to an agent, read it as one of those users would, and keep a running list of the questions the AI never thought to ask.
Bet on the biggest problem you can see
On career strategy, Souza’s advice is to aim high. “The larger the problem is, the better you’re gonna do in your career,” he says, because larger problems bring more responsibility, more autonomy and more value in the market. The 2038 rollover problem, when 32-bit Unix timestamps overflow, is the kind of challenge he thinks could grow into a career niche, much as the year 2000 bug built careers for the people who fixed it.
Don’t ask AI to imagine that future for you, Souza says, and he’s firm on this point. Because “AI has no notion of the future,” a model left to speculate will hallucinate freely. Form your own view of where the problem lands, and use AI to analyze the data and trends that lead there.
The same thinking applies to people early in their careers. Souza believes the most useful thing senior engineers can do for students and juniors is help them want to build something, because people with that drive learn what they need and use AI as one way of getting there.
So choose one large problem in your domain that will grow over the next five years and start building real expertise in it now. Arriving early to a hard problem is how most architects earn the autonomy they’re after.
Plan for the real price of AI
Souza also warned about the economics behind AI. “Right now, who pays for your AI is the investor,” he says. Every query costs money to run, and unlike the dot-com era, serving more users doesn’t get cheaper with scale. Open source models keep improving, but running one yourself means paying the real cost that large providers currently subsidize.
That isn’t a reason to use less AI today. It’s a reason to know roughly what your team’s AI workflows would cost at full price, and to keep a fallback option evaluated, so that a pricing change slows the work down without stopping it.
Two questions worth answering
Souza builds his career coaching around two questions worth answering in writing. The first is what would have to happen by the end of next year for your career to feel amazing. The second is why you can’t have that right now. The answer to the second is your real obstacle, and it’s usually more specific and more solvable than a general fear about AI.
His own practice is the clearest example of the principle. Everything he publishes is his own work, and he builds relationships with developers directly instead of handing them to a machine. “I use AI to help me do my things and not as me,” he explains, because “AI gets you in the game. But reputation is gonna get you as far as you want.”