DEV Community: DIAMANTINO ALMEIDA

The Hammer and the Weapon: Why the AI Tools You Approve Are Never Neutral

DIAMANTINO ALMEIDA — Thu, 23 Apr 2026 12:05:00 +0000

A note before you read. I used AI to pressure-test the argument in this essay. Not to write it. To challenge it. I will tell you where it surprised me and where it failed me, because that is the honest way to write about this subject.

When I use the word AI in this essay I am not acknowledging that these systems are intelligent. I am using the word the industry uses, because that is the word that has conquered the conversation. What we are actually talking about is an advanced deep learning model. Extraordinarily capable at pattern recognition, statistics, and probability. Not thinking. Not understanding. Not intelligent in any meaningful sense of the word. There is no academic consensus on what intelligence actually is, and there is certainly no evidence that these models possess it. The word AI is a marketing decision. It was chosen to make the technology feel inevitable, significant, and human. I use it here because refusing to use it would make the essay harder to read. But I want you to know that every time I write AI in this essay, I am describing a very powerful statistical engine. Nothing more. The intelligence is in the room. It is in you.

There is a carpenter I know who has been doing the same work for thirty-one years.

He is not sentimental about his tools. He replaces them when better ones arrive. He adopted computer-aided design software in the nineties when most of his peers were still hand-drawing. He uses laser measuring tools now, humidity sensors for the wood, a digital system for tracking grain and cut sequences that would have taken him three hours of calculation to do manually. Each of these things made him more capable. More precise in the places where precision serves the work. More efficient in the places where efficiency creates time for the things that require judgment.

He told me last year that he has never felt threatened by a tool.

I asked him what he would feel threatened by.

He thought about it for a while. Then he said: a machine that makes decisions about the wood.

Not a machine that helps him make decisions. A machine that makes them. That looks at the grain and the humidity reading and the customer's specification and produces an output without him in the room. A machine that does not need him to understand what it is doing because the understanding is no longer required.

He said: the moment the understanding leaves the room, I am not a carpenter anymore. I am a machine minder.

He said it without drama. As a simple statement of what the distinction actually is.

I have been thinking about that distinction ever since.

Two Things That Look the Same

The word AI is doing too much work in almost every conversation being had about it right now.

It is covering, under a single label, two fundamentally different things that have opposite implications for the humans inside the systems deploying them.

The first thing is AI as a tool. A hammer that amplifies what a person can do. The radiologist whose AI system flags the scan anomaly she might have missed after six hours on shift. The engineer whose AI assistant catches the specification error in the third-layer dependency. The teacher whose AI tool identifies which three students in her class of thirty are falling behind before she would have noticed in the normal rhythm of the term. In each of these cases, the human remains in the room. The human still makes the decision. The human still holds the responsibility. The tool has made the human more capable without making the human less necessary.

The second thing is AI as a weapon. A system deployed not to amplify what people can do but to remove the people from the equation. The radiologist whose hospital has replaced her diagnostic role with an automated system and kept one radiologist per three hospitals for sign-off on liability purposes. The call centre that has eliminated its workforce and deployed a conversational AI that handles ninety-two percent of customer interactions without a human ever entering the exchange. The content platform that has automated the judgment calls that editors used to make and removed the editors.

In both cases the technology is, in narrow technical terms, similar. Pattern recognition, large-scale training, inference from prior data. What is different is the intention behind the deployment. Who the system is designed to serve. Whether the human in the chain is being amplified or replaced.

This distinction is not new. It was named clearly in the early days of computing by people who were paying close attention. The question was always whether automation would free humans from the tedious to do more of the meaningful, or free companies from the human to extract more of the profit. Both were possible. The direction was never determined by the technology. It was determined by who owned it and what they were trying to maximise.

Fifty years later, we have the answer. The direction was the second one. Not because the first was impossible. Because the second was more profitable.

The Inconvenience of Having a Self

A colleague of mine who works in HR at a large technology company described a conversation she had in an executive meeting last year.

They were discussing a new AI system for customer support. The system was good. It handled the standard query range with accuracy the human team could not match on a bad day, and came close on a good one. The cost per interaction was, by any measure, significantly lower.

Someone in the room asked about the team. The hundred and forty people currently doing the work the system would do.

The response from the executive leading the session was, in her telling, one of the most clarifying things she had heard in fifteen years of corporate life.

He said: the problem with people is that they have needs.

He did not mean this as a cruelty. He was describing, matter-of-factly, what the business case document showed. People have wages. People have benefits. People have sick days and parental leave and the occasional conflict with a manager and the occasional decision to leave for a competitor. People require training. People require management. People have rights that create liability. People, in aggregate, are a source of risk and cost that the AI system does not introduce.

The AI system does not unionise. It does not ask for a raise when the company has a record quarter. It does not develop a grievance about the direction of the organisation. It does not need to be motivated or recognised or given a reason to stay. It does not have a family situation that occasionally makes it less available. It does not have a perspective on whether what it is being asked to do is right.

The executive was not describing a preference for machines over people. He was describing the logic of a system that treats humans as cost centres and machines as assets, and then making a decision that the logic made obvious.

The hundred and forty people were inconvenient. Not as individuals. As a category. As the kind of thing that has needs.

This is the actual agenda of replacement-focused AI. Not progress. Not efficiency for the benefit of the people the organisation serves. The elimination of the inconvenience of human dignity from the cost structure of the enterprise.

What Augmentation Would Actually Look Like

Augmentation, genuine augmentation, has a set of characteristics that are recognisable and measurable. You can check whether it is happening.

The human remains in the decision. Not as a rubber stamp on a machine output. As the actual decision-maker, informed and made more capable by the tool. The surgeon who uses AI assistance to identify candidates for a particular procedure still decides whether the procedure happens. Remove the human from the decision and you have crossed the line from tool to replacement.

The productivity gains circulate to the people doing the work. If AI makes a team twice as productive, and the team stays the same size, the humans are working half as much or earning twice as much or some combination. If productivity doubles and headcount halves and wages stay flat, the augmentation framing was a lie. The benefit went to the shareholders. The cost went to the hundred people who lost their jobs.

The human capacity for the work grows, not shrinks. Genuine augmentation means the doctor who works with AI diagnostic tools over a decade becomes a better doctor. The engineer who works with AI design assistance develops a more sophisticated sense of what the tool gets right and wrong. The human grows inside the tool relationship, not around it.

The understanding stays in the room. This is what the carpenter was pointing at. When the machine makes decisions, the human loses access to the knowledge of why those decisions are correct. Over time, that knowledge cannot be recovered. When the machine fails, or when the situation falls outside the training data, there is nobody left who knows how to handle it from first principles.

By these four checks, most of what is being deployed under the name of AI augmentation is not augmentation. It is replacement, staged gradually, dressed in the language of tools and assistance and freeing humans for higher-value work. The higher-value work never quite materialises. The lower-value humans are gradually removed. The cycle continues.

The Carpenter's Line

Let me go back to the carpenter and the line he drew.

The moment the understanding leaves the room, I am not a carpenter anymore.

He was not talking about job security. He was talking about the relationship between a person and their craft. The knowledge that lives in hands and judgment and years of accumulated experience. The understanding that cannot be described in a training dataset because it is not declarative. It is procedural, embodied, built into the way his hands move and the way his eyes read the surface of a plank.

A machine that assists him retains his access to that understanding. He uses the tool. He remains the carpenter.

A machine that replaces his judgment removes his access to it. Not immediately. But the muscle that is not used atrophies. Within a generation of workers trained to operate the machine rather than understand the wood, the embodied knowledge is gone. Not recoverable from a manual. Not downloadable from a database. Gone.

This is the loss that does not appear in the business case for automation.

Every domain of human expertise contains this knowledge. The nurse who knows from the way a patient is breathing that something is changing before any monitor has registered it. The teacher who knows from the quality of silence in a classroom that something happened in the corridor before the lesson. The journalist who knows from the way a source is answering that the source knows more than they are saying.

This is not mysticism. It is pattern recognition of a specific kind. Pattern recognition that is embodied, contextual, and dependent on the human being present and genuinely responsible for what happens next. Remove the responsibility and you remove the attention that builds the knowledge.

The Test Nobody Is Running

Here is a question that is almost never asked in the boardroom presentations about AI deployment.

What happens when it fails.

Not fails in the narrow technical sense. Fails in the deeper sense of encountering a situation that falls outside the training data. A context that has changed. A case that is genuinely novel.

I have been in organisations that replaced significant portions of their customer-facing workforce with AI systems and then experienced a crisis. A product recall, a regulatory change, a viral incident that generated an unusual pattern of customer contact at unusual emotional intensity. The AI handled the standard queries. The novel situation, the one that required judgment and empathy and the capacity to say "I understand this is not what the script says but here is what I am going to do for you," the system could not navigate.

There were almost no humans left who knew how to navigate it either. Not because the humans who had been displaced were incapable. Because the humans who remained had been operating in a system that handled the judgment calls for three years, and the judgment muscle had atrophied accordingly.

The business case showed the savings from the headcount reduction. It did not show the liability from the capability reduction.

This is a systemic failure of how we evaluate AI deployment. We measure what we can measure. The cost savings are measurable. The knowledge destruction is not, until it manifests as a crisis.

The augmentation version of this story is different. The organisation that deploys AI to assist its workers rather than replace them retains the embodied knowledge. The workers who are made more capable by the tool remain capable when the tool fails.

This is not a sentimental argument. It is a resilience argument.

Where This Is Already Happening

In healthcare, diagnostic AI is being deployed in contexts where the radiologist who used to read the scan is no longer reading it. The AI reads it. A doctor in another country signs off on the output. The local radiologist has been replaced. Not assisted. Replaced. When the system is wrong, and it is wrong with the specific blindspots of its training data, there is nobody left in the local chain who can identify the error before it becomes a harm.

In journalism, automated content generation is replacing reporters covering local news. City council meetings, planning decisions, local court proceedings. Stories that require a journalist to be present, to build relationships, to understand the context well enough to know which fact matters and why. This work is being eliminated. Not because AI does it better. Because it is cheaper to not do it.

In education, AI tutoring systems are being deployed as replacements for teaching staff in underfunded districts. The thirty students in the room are now working with a screen. The teacher who knew which three were falling behind before the test, who knew when the silence in the room was productive and when it was stuck, that person has been replaced by a system that is cheaper and does not require benefits.

The students in those districts are not getting better education with fewer teachers. And the substitution of AI for teachers is happening where the children of parents with less power have no choice but to accept it.

These are not edge cases. They are the current direction of deployment, in the places where the people affected have the least power to resist it.

What Refusing Looks Like

You can refuse replacement-focused AI. Not by rejecting the technology. By insisting on the four characteristics of genuine augmentation and refusing to accept deployments that fail them.

A worker whose role is being automated can ask: am I still in the decision? If the answer is no, that is not augmentation. The company is replacing you, not assisting you. You are entitled to say so.

A leader approving a deployment can insist that the productivity gains are distributed to the people whose work generated them. Not as charity. As a condition of approval.

A technologist building these systems can refuse to build the replacement version. This is not a small ask. It has career consequences. It also has the consequence of being able to look at the work and know what it was for.

A citizen can demand that the governments with the regulatory authority to intervene use it. The EU AI Act creates the legal framework. Enforcement requires political pressure from people who understand what is being deployed and are willing to make it politically costly not to act.

The choice between the hammer and the weapon is not made once, in a single boardroom decision. It is made thousands of times, in thousands of smaller decisions, by thousands of people who have varying degrees of power over the direction of the deployment.

Every one of those decisions is a leadership act. Or a failure of one.

The carpenter said: the moment the understanding leaves the room, I am not a carpenter anymore.

He was describing a threshold.

We are standing at it.

What we choose here is what we will have chosen when it is behind us.

Originally published in Leadership as a Verb on April 21, 2026.

This is the final essay of a four-part series. The Prequel names the system. A Delusional Ape asks whether we want the direction. Who Are You Without the Title asks the personal question. This essay names the specific choice being made right now and what refusing it looks like.

They Did Not Accidentally Make Work the Answer to Who You Are

DIAMANTINO ALMEIDA — Thu, 26 Mar 2026 10:16:41 +0000

This is an excerpt. Read the full essay at newsletter.diamantinoalmeida.com

A young designer told me she had built an interface without understanding a single thing about the data it was pulling. She could make it beautiful. She had learned to use the tools with genuine skill.

She had no idea what the system was doing.

I asked if that concerned her.

She said everyone works this way now.

That sentence has stayed with me.

The bargain nobody signed

At some point in the last fifty years, Western societies made a bargain with work. Not explicitly. Not with signatures. The way most consequential bargains are made — quietly, through a thousand small decisions that each felt reasonable and only reveal their shape when you step back far enough to see the whole.

The bargain: give us your hours, your loyalty, your identity. We give you purpose, status, and a story you can tell about who you are.

Now AI is arriving to automate the tasks that were, for many people, the last remaining justification for the trade.

The bargain is breaking.

This was not an accident

Productivity culture needed your identity. Not as a side effect — structurally.

A worker who derives self-worth from their output, who feels genuine anxiety when not being useful, is a worker who does not question the pace. Who does not ask whether the hours they are giving are proportionate to the value they are receiving.

The discomfort with stillness that I watch in engineering teams is not a personality trait. It is a residue. What three years of working inside a system that measures your value in throughput does to a person who was never given permission to value themselves outside of it.

The designer was not replaced because she was not good enough. She was displaced because the system she was trained to serve never needed her to understand it. It needed her to operate it. And operating it is now cheaper done by a machine.

The right to be useful

A human without agency — without the weight of personal effort — is a ghost in their own life.

True leadership in the age of AI will not just be about protecting incomes or titles. It will be about protecting the right to be useful. Choosing the inefficient path of human understanding over the seamless path of machine automation — not because it produces a better output, but because it produces a better human.

The system made work the answer to who you are. It was never supposed to be.

What replaces the bargain is the only genuinely important question in technology right now.

This is an excerpt from a much longer essay that traces the system that built this problem — the dismantling of civic life, the Mediterranean cultures that kept a different answer alive, and what leadership actually owes the people inside the displacement.

Read the full essay: They Did Not Accidentally Make Work the Answer to Who You Are

Diamantino Almeida writes Leadership as a Verb — personal essays for tech leaders carrying questions they cannot ask inside their own organisations.

[Boost]

DIAMANTINO ALMEIDA — Wed, 18 Mar 2026 13:10:20 +0000

Harsh

Mar 14

90% of Code Will Be AI-Generated — So What the Hell Do We Actually Do?

#ai #career #webdev #javascript

129

Comments 113

7 min read

[Boost]

DIAMANTINO ALMEIDA — Sat, 14 Mar 2026 23:46:40 +0000

DIAMANTINO ALMEIDA

Mar 5

You Don't Need to Know How It Works — And That's Exactly the Problem

#leadership #ai #webdev #career

Comments

3 min read

You Don't Need to Know How It Works — And That's Exactly the Problem

DIAMANTINO ALMEIDA — Thu, 05 Mar 2026 13:00:00 +0000

This is not a post about AI. It is a post about what happens to people who never ask why.

I was at a protest when someone told me the internet should be a human right.

He was holding a four thousand pound laptop. Coffee in one hand. Earbuds in. Passionate, articulate, certain.

I asked him what the internet actually is.

He described Facebook. YouTube. Speaking to friends.

I said: that is the world wide web. What is the internet?

He looked at me. Then he said: what is the world wide web?

I got scared. Not because he did not know. Because he was screaming about a thing he had never once tried to understand.

What the internet actually is

The internet is infrastructure. Physical cables, servers, routing systems that cost billions to build. The world wide web sits on top of it. The web is the passenger. The internet is the road.

None of this is complicated. It takes about ten minutes to understand. But most people who depend on it daily have never spent those ten minutes.

The gap between using something and understanding it is becoming one of the most dangerous gaps we have. And we are widening it deliberately. Not through malice. Through design.

The dependency trap

Think about the person who has never changed a tyre. The tools are in the boot. They came with the car. But they have never once been curious enough to try.

The phone you are holding is not a phone. It is an attention system, engineered to be as frictionless as possible. Not for your benefit. Because friction creates conditions for thought, and thought creates conditions for demand, and demand is expensive.

The easier the tool is to use, the less you need to understand it. The less you understand it, the more dependent you become. The more dependent you become, the more useful you are to the people who built it.

That is not a coincidence. That is a business model.

The people telling you not to think

I have heard tech leaders say you no longer need to think for yourself. That AI will do it. That coding will be irrelevant by end of year.

I want to be precise. A large language model predicts the next word based on patterns in human text. Extraordinarily capable. Not thinking. The distinction matters, because the people telling you AI will replace your judgment are often the same people who benefit most from you believing it.

The more a technology is positioned as inevitable, the more urgently you should ask who benefits from that inevitability feeling settled.

This is not paranoia. This is the minimum condition for being a free person in a technical world.

What this means if you build software

Every time we optimise for engagement over understanding. Every time we make a product simpler in a way that removes agency rather than friction. We are widening the gap.

There is a difference between removing unnecessary complexity and removing the conditions for thought. Most of us have stopped asking which one we are doing.

The real question is not: does this product work? It is: what kind of relationship does this product create between the person using it and their own capacity to question the world?

Most products being built right now are answering that in one direction. Toward dependency.

The only honest question

The man at the protest was not stupid. He was the product of a system designed to make understanding unnecessary.

We built that system. Some of us maintain it every day.

So the question is not whether your users understand what you are building. The question is whether you have ever stopped to ask if you want them to.

This is an adapted excerpt from a longer essay on dependency, digital literacy, and what shared leadership demands of tech builders. The full essay is here. Leadership as a Verb publishes every Tuesday — free.

Why Distributed Leadership is More Efficient than Command-and-Control

DIAMANTINO ALMEIDA — Wed, 18 Feb 2026 20:42:58 +0000

Visit: diamantinoalmeida.com

I write a weekly newsletter for tech leaders at newsletter.diamantinoalmeida.com.

I'll admit, I spent a decade of my life being a professional reminder.

I thought that was the job. I thought that being a "Senior Leader" meant being the person who watched the clock and checked the boxes. I believed that if I didn’t have my eyes on every line of code and every ticket in the board, the whole ship would sink.

I called it "High Performance." I called it "Maintaining Standards." But if I am honest with you, it was actually just a very polite form of fear.

I was afraid of being irrelevant. I was afraid that if the team could move without me, the company would realize they didn’t need me. So I built a system where I was the bottleneck. I was the center of the wheel. Every decision had to pass through my desk. Every "deliverable" had to have my stamp on it.

I thought I was being a hero. I realize now I was just a wall.

If you are leading a technical team today, you probably feel the weight of the "Metallic Cold." You feel the pressure to move faster. You feel the constant demand for more speed and more output. The industry tells us that the way to get there is through better metrics and tighter control.

But I am here to tell you that the "Foreman" mindset is the least efficient way to build software. Command-and-control leadership is a relic of a factory age that has no business in a room full of creative engineers.

Here is the truth I had to learn the hard way. Distributed leadership isn’t just a "nice" way to treat people. It is the only way to stay human while building something that actually lasts.

The Myth of the Savior

We have a "Hero" problem in tech. We reward the person who stays up until 3:00 AM to fix the production bug. We celebrate the lead who jumps into every PR to "save" the code.

I used to be that person. I loved the rush of being the one with all the answers. I thought my sacrifice was a gift to my team. I thought I was protecting them from the pressure.

But by being the hero, I was actually stealing their growth.

When you lead from a place of control, you create a team of "Users." They wait for your instructions. They wait for your approval. They stop thinking for themselves because they know you will eventually do the thinking for them.

This is incredibly inefficient. It creates a system where the speed of the entire team is limited by the speed of one person's brain. That person is usually tired, stressed, and disconnected from the actual work.

I felt that weight every single morning. I would look at my calendar and see a grid of other people's priorities. I was in debt to my own title. I had become the very thing I hated. I was a manager who didn’t actually know how to build anything anymore.

To fix it, I had to do something terrifying. I had to let go.

Trust is the Ultimate Low-Latency Network

In engineering, we spend a lot of time trying to reduce friction. We optimize our pipelines. We refactor our code. We look for the shortest path between a thought and a deployment.

The greatest source of friction in any team is a lack of trust.

When you have a command-and-control structure, you are introducing a massive amount of latency into every decision. An engineer has an idea. They have to wait for a meeting. They have to explain the idea to a manager who hasn't touched the codebase in months. The manager has to check with another manager.

By the time the idea is approved, the spark is gone. The engineer is just "executing a task" instead of "solving a problem."

Distributed leadership—or what I like to call "Growing a Garden"—is about removing that latency. It is about pushing the power to make decisions down to the people who are actually touching the soil.

When a team owns their own work, they move at a speed that no manager can force. They aren't working to satisfy a metric on a wall. They are working because they care about the ripple effect of what they are building.

Trust is not a soft skill. It is a technical advantage. It is the fuel that allows a team to heal its own gaps. If you have to "enforce" a system, the system is already broken. A good team should be like a forest. It should grow and adapt and sustain itself without a foreman standing over it with a clipboard.

The Soul of the Work

The corporate world tells us that management is about "making things happen."

But if we are honest, it often just means making sure people stay in their seats. We treat the office—even the digital one—like a factory floor. We measure our worth by the length of our feature list. We think that if we move fast enough, we can outrun the feeling that we are just middle-men for an algorithm.

I am sitting here looking at the sunlight on my desk and remembering that I am more than a series of successful deployments. My team is more than a velocity chart.

When you shift to a distributed model, you are finally acknowledging the humanity of the people you lead. You are saying: "I trust your reasoning. I trust your conscience. I trust you to care about the water, not just the ship."

This changes the air in the room. It stops being about "surveillance" and start being about "stewardship."

We are accountable for the ripple effect we create. That ripple effect doesn't just stop at the code. It touches the families of our engineers. It touches the way they feel when they close their laptops at the end of the day.

If your leadership style makes people feel like machines, you are failing them. Even if you hit every date. Even if your "optimization" is perfect. You are failing because you are creating a "Metallic Cold" that will eventually burn everyone out.

How to Start the Refactor

If you are tired of being the hero, you can start the refactor today. It doesn't require a new framework. It doesn't require a change in your Jira settings.

It requires you to be brave enough to say "I don't know."

The next time a team member brings you a problem, don't give them the solution. Even if you have it. Even if you know exactly which file needs to be changed. Instead, ask them a question: "What do you think we should do?"

Then, do the hardest part. Stay quiet.

Let the silence sit in the room. Give them the space to step into their own leadership. You might have to watch them struggle for a moment. You might even have to watch them make a mistake. But that struggle is where the growth happens. That is where a "Resource" becomes a "Partner."

I help tech leaders stop hiding behind their titles and start looking at the water. I believe our job isn't to build machines out of people, but to grow gardens out of teams.

We are the architects of a legacy that goes far beyond software. We are building the culture that our children will eventually work in. Let's make it a culture that breathes. Let's make it a place where the sunlight can reach the floorboards.

Stop measuring the ship. The water is more important.

The Patch: The "I Don't Know" Script

If you want to start sharing the weight of leadership, try this in your next meeting.

When someone asks you for a decision that you usually make alone, say this:

"I have some thoughts, but I'm worried my perspective is too far from the code. I want to trust your intuition on this. What does your gut tell you is the right path forward?"

Then, listen. Don't correct. Don't "optimize." Just listen. You are planting a seed. It will take time to grow, but the fruit is worth the wait.

I write about tech leadership, shared ownership, and staying human in a machine-driven industry. If this resonated, you can find more of my work at newsletter.diamantinoalmeida.com.

I’ve been thinking lately about how we treat our minds like machines that need a software update. We try to read faster, work faster, and even rest faster. But human insight doesn't scale. It needs the friction of a slow afternoon to actually take root.

DIAMANTINO ALMEIDA — Fri, 13 Feb 2026 13:50:49 +0000

[Boost]

DIAMANTINO ALMEIDA — Fri, 13 Feb 2026 12:37:41 +0000

Remember Your First Computer Book?

Richard Pascoe ・ Feb 13

#discuss #community #learning

Why Your Best Work Requires Zero Velocity

DIAMANTINO ALMEIDA — Fri, 13 Feb 2026 12:32:12 +0000

Visit: diamantinoalmeida.com

I write a weekly newsletter for tech leaders at newsletter.diamantinoalmeida.com.

I am planning to spend this Friday evening doing something that has no measurable ROI.

I have a stack of old letters and a fountain pen that needs cleaning. I’ll probably spend an hour just on the ink. No goals, no shipping, no "results." Just the quiet satisfaction of a tool being cared for by a human hand.

To some of you, that sounds like a waste of sixty minutes. To others, it sounds like a luxury you can’t afford. But if you have spent your week inside the "efficiency cult" of modern software development, you know exactly why I am doing it.

We are living through the era of Digital Slop. We are being told:

If we aren’t using AI to summarize our meetings, we are falling behind.
If we aren't using Copilot to finish our functions, we are inefficient.
If we aren't "shipping at the speed of thought," we are obsolete.

But I’ve been around long enough to see the crash that follows the rush. I am a Humanist Architect, and I am here to tell you: Tech without soul is just a slow-motion collision.

The Myth of the Optimized Engineer

In the tech industry, we have a specific kind of dysmorphia. We treat our brains like CPUs and our lives like a CI/CD pipeline.

We look for "hacks" to sleep better so we can work harder.
We look for "hacks" to read documentation faster so we can ship sooner.

We have optimized the humanity out of the craft.

When you spend your entire week chasing velocity, you stop being a creator and start being a component. You become a user of models, a passer of tickets, a cog in a machine that values "more" over "better."

The problem with moving fast is that it creates a specific kind of blindness. When you are running at full speed toward a cliff, "efficiency" is just a metric that tells you how much sooner you’ll fall.

The Ethics of Impact

We need to stop asking "How much did we ship?" and start asking "Whose life did we actually improve?"

If our success is measured only by the number of PRs merged or the share price at the end of the quarter—while we leave a wake of stress, burnout, and buggy, thoughtless software—then we have failed.

Software isn't just code. It is a social contract. We shape the lives of the people who build it and the people who use it. When we rush, we break that contract. We ship "digital slop" because we are moving too fast to actually taste what we are making.

Management is about resources. Stewardship is about the guardianship of something precious. As engineers, we need to stop being managed and start being stewards.

Knowledge as Agency

There is a dangerous idea floating around right now: that because AI can generate code, human learning is becoming obsolete. I reject that entirely.

Understanding the "why"—the math, the nature of the systems, the physical reality of the hardware—is the only thing that keeps us from smashing into the wall. When we outsource our thinking to a model, we aren't becoming more powerful. We are becoming more dependent.

The Slow Tech Movement

We need a "Slow Tech" movement, modeled after the Slow Food movement. We must reject the "fast food" of buggy, thoughtless software.

Moving fast is a vanity metric.
Moving in the right direction is leadership.

Your Friday Protocol: Reclaiming the Human

I want to challenge you to try a "Zero Velocity" practice. This isn't a productivity tip; it’s a survival strategy. For the next month, I want you to perform these three steps every Friday afternoon.

1. The Analog Buffer

Before you close your laptop, don't jump straight into the next digital stream. Sit for 20 minutes with a physical object. A book, a plant, or even just the view out your window.

2. The No-Verdict Audit

Look back at your week. Find the moment that felt the most "metallic"—the meeting where you felt like a resource. Write down what happened in three sentences on a piece of paper. Do not try to solve it. By naming it, you take away its power.

3. The Physical Signature

Do one thing with your hands that has a physical result. Cook a soup, clean a fountain pen, or fix a door hinge. In a world where our work disappears into the cloud, we need to feel the resistance of the physical world.

Legacy over Velocity

We are building the infrastructure of the future. Do you want them to look at your work and see a pile of optimized failures? Or do you want them to see the work of a human who cared?

A Final Thought
This Friday, the goal is zero velocity. I’m going to clean my pen. I’m going to watch the ink flow into the converter. I’m going to remember that I am a craftsman, not a component.

The world will still be there on Monday. But I will be different. I will be rested. I will be grounded.

How do you plan to spend this Friday?

I help tech leaders stop chasing blind efficiency and start building for human impact. If you want to move away from the "efficiency cult," join me on *Substack** for more reflections on stewardship, legacy, and the human spirit in tech.*

The Junior Developer Paradox: Why 2026 Feels Like the End of Entry-Level Tech (And How to Survive It)

DIAMANTINO ALMEIDA — Wed, 07 Jan 2026 12:10:39 +0000

The "Golden Age" of the junior developer is over.

If you are a self-taught coder, a recent bootcamp grad, or a CS student looking at the 2026 job market, you’ve likely noticed the silence. You’ve sent out 200 applications. You’ve mastered React, Python, and even a bit of Rust. You’ve tailored your LinkedIn.

And yet, the only thing hitting your inbox is a "Thank you for your interest, but we’ve decided to move forward with a candidate who has more experience."

Except the "candidate with more experience" isn't always a human. Sometimes, it’s a Senior Engineer with a fleet of autonomous agents doing the work that used to be reserved for you.

The Harsh Reality: The Middle is Disappearing

In the old world (circa 2022), companies hired juniors as an investment. You were "cheap labor" that would eventually become "expensive talent." You did the boilerplate, the unit tests, and the small bug fixes.

Then came 2024–2025. AI agents became capable of handling 80% of those "junior tasks" instantly and for the price of a subscription. Suddenly, the "investment" of a human junior developer looks—to a short-sighted CFO—like a liability. Why hire a human who needs 6 months to onboard when a Senior can prompt their way through a feature in an afternoon?

This is the Junior Developer Paradox: Companies want Senior Engineers, but they are refusing to build them by hiring Juniors. We are eating our own seed corn.

The "Cheap Labour" Trap

Let’s be honest: many companies are currently using AI to maximize short-term profits at the expense of long-term technical health. They are chasing a "Lean Engineering" dream where a team of three "10x Engineers" plus AI replaces a department of thirty.

But here is the secret they aren't telling you: Those Senior Engineers are burning out. They are spending all their time "vibe coding"—reviewing AI-generated garbage and duct-taping complex systems together. The technical debt being created right now is astronomical. And that, my friends, is where your opportunity lies.

How to Break the Paradox: Your 2026 Survival Guide

If you try to compete with AI on speed, you will lose.
If you try to compete with AI on syntax, you will lose.
You must compete on Systems Thinking and Human-Centric Value.

1. Stop Being a "Coder," Start Being an "Orchestrator"

In 2026, knowing how to write a for loop is like knowing how to use a pencil. It’s expected, but it’s not the job.

The Shift: Show that you can manage the AI. Your portfolio shouldn't just be "I built a Todo list." It should be "I used an AI swarm to build a complex system, and here is how I audited the code for security and architectural integrity."
The Edge: Prove you understand why the code exists, not just how it runs.

2. Embrace the "AI-First Residency" Mindset

If companies won't give you a residency, create your own.

Build a project that is "too big" for one person. Use AI to help you build it, but document your decision-making process.
Write about the hallucinations you caught.
Show how you refactored an AI’s messy logic into a clean, scalable architecture.

Companies aren't looking for someone who can write code; they are looking for someone who can fix the mess the AI leaves behind.

3. The "Human Skills" are the New "Hard Skills"

Communication, empathy, and business alignment are no longer "soft skills." They are the only skills AI can't replicate.

Can you talk to a product manager and translate their "vibe" into a technical spec?
Can you explain to a CFO why a specific piece of technical debt is a ticking time bomb?
Action: Get involved in Open Source. Not just for the code, but for the collaboration. The ability to navigate a complex human organization is what makes you "Senior-lite" before you even have the title.

A Message of Motivation: The Pendulum Always Swings

It feels bleak right now. I know.

But history shows us that whenever a technology makes something "cheap" (like code), the value of the human judgment surrounding that thing skyrockets.

We are currently in a "Wild West" phase where companies think they don't need you. They are wrong. By 2027, the companies that neglected their junior talent will be facing a catastrophic "Senior shortage" and a codebase they can't maintain.

Your job is to be the person who is ready when they realize their mistake.

My Advice to You

Lower the ego, raise the curiosity: Don't be afraid to take "low-level" roles in QA, Support, or Integration. These are the front lines of seeing where AI fails.
Learn the "Boring" stuff: Everyone is learning LLM prompting. You should learn Security, Database Internals, and Compliance. These are the areas where companies are terrified to let AI run wild. Be the "Safe Pair of Hands."
Network like it’s 1995: Since the digital front door (LinkedIn/Job Boards) is guarded by AI bots, you need to go around the back. Meetups, coffee chats, and niche communities (like MentorCruise) are where the real hiring happens.

The Bottom Line

The Junior Developer Paradox is real, and it is unfair. But it is not a dead end; it’s a filter.

The developers who survive 2026 won't be the ones who memorized the most LeetCode. They will be the ones who learned to lead themselves, lead the tools, and lead the conversation.

Don't stop building. The world doesn't need more code; it needs more leaders who understand code.

What are you doing to stay relevant in the age of AI?

Let’s discuss in the comments. I’m a Senior Leader and Advisor, and I’m seeing this from the "other side" of the hiring table. I want to hear your struggles—and your wins.

💡 Get the "Other Side" of the Hiring Table

Most juniors are guessing what CTOs want. I spend my days advising those same CTOs. If you want to know exactly how to position yourself as a "Safe Pair of Hands" in an AI-driven market, I offer 1:1 sessions to help you break through the noise.

🚀 Grab a spot on my calendar

👨‍💻 Who am I?

I’m Diamantino Almeida, and I’ve spent my career at the intersection of high-growth engineering and strategic leadership.

From scaling technical teams to advising CTOs and Founders, my focus is on "Leadership as a Verb"—the idea that leading is an active, evolving practice, not a static title. Having navigated the shifts from manual infrastructure to cloud, and now to Agentic AI, I’m dedicated to helping the next generation of engineers find their footing in a world that is moving faster than ever.

Beyond advisory, I’m an active Top global 9% *mentor on *MentorCruise, where I help developers and leaders bridge the gap between "writing code" and "delivering business value."

Why Focusing on People Still Matters in the Age of Artificial Intelligence

DIAMANTINO ALMEIDA — Sun, 14 Dec 2025 13:33:36 +0000

Artificial Intelligence (AI) is transforming industries, automating workflows, and redefining what’s possible in technology. Yet, as AI systems grow more sophisticated, the role of an AI Lead the person responsible for guiding AI projects and teams becomes increasingly complex. While technical expertise is essential, the most effective AI Leads understand that people, not just algorithms, drive success.

In this blog, we’ll explore:

The evolving role of an AI Lead in modern organizations
Why focusing on people is just as important as focusing on technology
Practical strategies for managing an AI team effectively
How to balance technical leadership with human-centric values

The Role of an AI Lead: Beyond Algorithms

An AI Lead is more than just a technical expert. They are strategists, mentors, and bridges between technical teams, business stakeholders, and end-users. Their responsibilities include:

Technical Oversight: Ensuring AI models are accurate, scalable, and aligned with business goals.
Team Leadership: Managing data scientists, engineers, and analysts while fostering collaboration.
Stakeholder Communication: Translating complex AI concepts for non-technical audiences.
Ethical Stewardship: Ensuring AI systems are fair, transparent, and aligned with ethical standards.

However, the most impactful AI Leads recognize that technology alone doesn’t solve problems people do. A high-performing AI team requires trust, collaboration, and a shared sense of purpose.

Why Focusing on People Still Matters in AI

1. AI is Built by Humans, for Humans

AI systems are only as good as the people who design, train, and deploy them. A team that feels valued, motivated, and aligned will produce better results than one that is disengaged or siloed.

Example: Google’s AI Principles emphasize human-centered design, ensuring that AI benefits society rather than just optimizing for efficiency.
Key Insight: AI Leads must prioritize team culture, psychological safety, and continuous learning to foster innovation.

2. Collaboration Drives Innovation

AI projects often require cross-functional teams data scientists, software engineers, product managers, and domain experts. Without strong interpersonal skills and collaboration, projects can stall due to miscommunication or conflicting priorities.

Example: OpenAI’s success with models like GPT-4 wasn’t just about technical brilliance it required effective teamwork, feedback loops, and iterative improvement.
Key Insight: AI Leads should encourage open dialogue, knowledge sharing, and constructive feedback to keep teams aligned.

3. Ethical AI Requires Human Judgment

AI systems can inadvertently reinforce biases, invade privacy, or make unethical decisions. An AI Lead must ensure that human values guide AI development.

Example: IBM’s AI Ethics Board reviews projects to prevent harmful outcomes, proving that human oversight is irreplaceable.
Key Insight: AI Leads should implement ethics reviews, bias audits, and transparency checks to maintain trust.

How an AI Lead Can Manage Their Team Effectively

1. Foster a Culture of Psychological Safety

Teams perform best when they feel safe to ask questions, admit mistakes, and challenge ideas.

Actionable Steps:
- Encourage blameless post-mortems after failures.
- Hold regular retrospectives to discuss what’s working and what isn’t.
- Model vulnerability by admitting your own uncertainties.

2. Prioritize Continuous Learning

AI is a rapidly evolving field. An AI Lead should invest in upskilling their team through workshops, conferences, and mentorship.

Actionable Steps:
- Allocate time for research and experimentation.
- Create a knowledge-sharing culture (e.g., internal tech talks, documentation).
- Support certifications and advanced training for team members.

3. Balance Autonomy with Accountability

AI teams need freedom to innovate, but they also need clear expectations and accountability.

Actionable Steps:
- Set SMART goals (Specific, Measurable, Achievable, Relevant, Time-bound).
- Use Agile methodologies (e.g., Scrum, Kanban) to track progress.
- Provide constructive feedback without micromanaging.

4. Lead with Empathy and Emotional Intelligence

Technical skills alone won’t inspire a team. An AI Lead must understand individual motivations, strengths, and challenges.

Actionable Steps:
- Hold 1:1 meetings to discuss career growth and well-being.
- Recognize achievements publicly to boost morale.
- Address burnout by promoting work-life balance.

The Future of AI Leadership: Human-Centric Innovation

The most successful AI Leads will be those who balance technical excellence with human-centric leadership. As AI continues to evolve, the need for collaborative, ethical, and empathetic leadership will only grow.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human one verb at a time.

Key Takeaways for AI Leads:

People first, technology second AI is a tool, not a replacement for human judgment.
Foster collaboration break down silos and encourage cross-functional teamwork.
Prioritize ethics ensure AI systems are fair, transparent, and beneficial to society.
Invest in your team continuous learning and psychological safety drive innovation.

Final Thoughts

The best AI Leads don’t just build intelligent machines they build intelligent, motivated, and ethical teams. By focusing on people as much as algorithms, they create AI systems that are not only powerful but also responsible, inclusive, and impactful.

Question for Reflection:
How can you, as an AI Lead, ensure that your team remains human-centered in an increasingly automated world?

AI in Coding: A Powerful Tool, But Not a Silver Bullet

DIAMANTINO ALMEIDA — Wed, 03 Dec 2025 21:30:11 +0000

My Love-Hate Relationship with AI in Coding

I love using AI for coding. It helps me write scripts faster, debug issues quicker, and even learn new programming concepts by studying the code it generates.

But here’s the thing: AI isn’t perfect. And if we rely on it too much especially in production or client-facing work—we risk serious problems.

In this post, I’ll share my personal experience with AI in coding, the risks I’ve seen, and how I balance AI assistance with my own skills. If you’re a developer, a tech lead, or just someone curious about AI’s role in programming, this is for you.

Why AI in Coding is a Game-Changer

Before diving into the risks, let’s talk about the benefits. AI has transformed how I work in several ways:

Faster Prototyping – Need a quick script to test an idea? AI can generate it in seconds.
Automating Repetitive Tasks – Writing boilerplate code? AI handles it, so I can focus on logic.
Learning New Concepts – AI can explain complex topics in simple terms, making it easier to pick up new languages or frameworks.
Debugging Help – Stuck on a bug? AI can suggest fixes or point out where things might be going wrong.

For me, AI is like having a junior developer who never sleeps—always ready to assist, but still needing guidance.

The Risks of Over-Reliance on AI in Coding

But—and this is a big but—AI isn’t a magic solution. Here are the real risks I’ve encountered (and why you should be careful too).

1. The "Black Box" Problem: You Don’t Always Know What’s Inside

AI-generated code can work perfectly… until it doesn’t.

I’ve seen cases where AI introduces subtle bugs or inefficiencies that only appear under specific conditions. Since AI doesn’t explain why it wrote the code a certain way, debugging becomes a nightmare.

Example:
Once, an AI-generated function worked fine in testing but failed in production because it didn’t handle edge cases properly. It took hours to trace back and fix—time I could have saved if I’d written it myself with full understanding.

Lesson: Always review AI-generated code like you would a junior developer’s work. Don’t assume it’s perfect.

2. Over-Reliance Erodes Your Coding Skills

If you let AI write all your code, you risk losing your ability to think critically.

Coding isn’t just about typing syntax—it’s about:

Understanding systems
Anticipating edge cases
Making smart trade-offs

AI can’t replace that human intuition—at least, not yet.

Example:
Early in my career, I relied too much on copy-pasting Stack Overflow answers. Later, I realized I hadn’t really learned how to solve problems—I’d just memorized solutions. AI can create the same issue if we’re not careful.

Lesson: Use AI as a learning tool, not a crutch. Study the code it generates, understand why it works, and improve it.

3. Client Trust is on the Line

In client work, reliability is everything. If an AI-generated solution fails, it’s your reputation that suffers—not the AI’s.

Clients don’t care how the code was written—they care that it works every time.

Example:
A colleague once used AI to generate a payment processing script. It worked in tests but failed in production, causing delays and frustration. The client didn’t blame the AI—they blamed us.

Lesson: Never ship AI-generated code without thorough testing. Treat it like unproven third-party code.

4. Ethical and Security Blind Spots

AI doesn’t always follow best security practices or consider ethical implications.

I’ve seen AI suggest:

Insecure shortcuts (like hardcoding passwords)
Inefficient algorithms (that slow down performance)
Biased logic (if trained on flawed data)

As developers, we’re responsible for catching these issues.

Example:
An AI once suggested a database query that was vulnerable to SQL injection. If I hadn’t reviewed it, that could have been a disaster.

Lesson: Always audit AI-generated code for security and ethics.

My Approach: Using AI as a Collaborator, Not a Replacement

So how do I use AI without losing my skills or risking mistakes? Here’s my strategy:

1. Treat AI Like a Junior Developer

It’s fast and helpful, but needs supervision.
Always review, test, and refine its output.

2. Use AI for Brainstorming, Not Final Code

Great for exploring ideas or generating drafts.
But I never use raw AI code in production without changes.

3. Study the Code It Generates

If AI suggests a solution, I ask: Why does this work?
This helps me learn and improve my own skills.

4. Keep My Core Skills Sharp

I still write code from scratch sometimes.
I solve problems manually before asking AI for help.

The Bottom Line: AI is a Tool, Not a Replacement

AI is incredibly powerful, but it’s not a substitute for:
✔ Human judgment
✔ Critical thinking
✔ Experience and expertise

The best developers won’t be those who rely most on AI—they’ll be the ones who use it wisely while keeping their own skills sharp.

Final Thought: What’s Your Approach?

How do you use AI in coding? Do you see it as a helper, a risk, or something in between? Let’s discuss in the comments!