DEV Community: DIAMANTINO ALMEIDA

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

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

Harsh ・ Mar 14

#ai #career #webdev #javascript

[Boost]

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

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

DIAMANTINO ALMEIDA ・ Mar 5

#leadership #ai #webdev #career

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!

Dealing with Discussions Practical Tips for New Engineering Managers

DIAMANTINO ALMEIDA — Mon, 24 Nov 2025 21:05:54 +0000

Prepare for the Discussion
Facilitate Inclusive Discussions
Keep Discussions on Track
Handle Conflict Constructively
Close the Discussion Effectively
Post-Discussion Follow-Up
Common Pitfalls and How to Avoid Them
Tools to Improve Discussions
Real-World Scenarios and How to Handle Them
Continuous Improvement
Final Thoughts

1. Prepare for the Discussion

Set Clear Objectives

Define the goal of the discussion and share it with your team beforehand.
Example:

"Our goal today is to decide on the best approach for reducing API latency. We’ll review three proposals and choose one by the end of the meeting."

Share an Agenda

Create and share an agenda at least 24 hours in advance.
Pro Tip: Use collaborative tools like Google Docs or Notion.

Gather Context

Review relevant documents, code, or previous discussions to ensure you understand the topic.

2. Facilitate Inclusive Discussions

Encourage Participation

Call on people directly.
Use round-robin to give everyone a chance to speak.
Leverage async communication for introverts.

Manage Dominant Voices

Politely interrupt if someone dominates the conversation:

"Thanks for your input, Jamie. Let’s hear from others before we dive deeper."

Active Listening

Paraphrase: "So what you’re saying is…"
Ask clarifying questions: "Can you elaborate on that point?"
Summarize key takeaways.

Watch for Non-Verbal Cues

Address confusion or disengagement:

"I notice some of you look unsure. Let’s pause and clarify."

3. Keep Discussions on Track

Time Management

Stick to the agenda and allocate time for each topic.

Parking Lot for Off-Topic Items

Jot down tangents to revisit later:

"That’s an important point about our CI pipeline, but it’s not on today’s agenda. Let’s add it to the parking lot."

Decision-Making Frameworks

Pros/Cons List
Dot Voting
Consensus Building

4. Handle Conflict Constructively

Conflict Is Normal

Disagreements are healthy. Focus on managing them productively.

Focus on the Problem, Not the Person

Redirect conversations to technical trade-offs:

"Let’s focus on the technical trade-offs rather than who suggested what."

Use "I" Statements

Encourage team members to express views without blame:

"I feel concerned about this approach because of X."

Take a Break if Needed

Suggest a short break if emotions run high:

"Let’s pause for 5 minutes and regroup."

5. Close the Discussion Effectively

Summarize Key Points

Recap decisions, action items, and next steps:

"To summarize:

We’ve decided to implement Option B.

Alex will draft the proposal by Friday.

Jamie will review the security implications."

Document the Outcomes

Send a follow-up email or message with the summary.

Gather Feedback

Ask your team for feedback on the discussion:

"How did today’s meeting go? What could we improve next time?"

6. Post-Discussion Follow-Up

Check in with Individuals

Follow up one-on-one with disengaged or frustrated team members.

Address Unresolved Issues

Schedule follow-up discussions for tabled topics.

Celebrate Progress

Acknowledge the team’s effort:

"Great job today! We made a tough decision, and I appreciate everyone’s input."

7. Common Pitfalls and How to Avoid Them

Pitfall	Solution
Lack of Preparation	Share an agenda and gather context beforehand.
Dominant Voices	Actively manage participation.
No Clear Objective	Define and communicate the goal.
Ignoring Conflict	Address disagreements constructively.
No Follow-Up	Document decisions and assign action items.

8. Tools to Improve Discussions

Tool	Purpose
Google Docs/Notion	Collaborative agendas and note-taking.
Slack/Teams	Async input and follow-ups.
Miro/Mural	Visual brainstorming and decision-making.
Trello/Asana	Tracking action items and deadlines.

9. Real-World Scenarios and How to Handle Them

Scenario 1: The Endless Debate

Solution:

Set a time limit.
Use a decision-making framework.
Make the call as the manager if needed.

Scenario 2: The Silent Team Member

Solution:

Reach out one-on-one.
Assign them a topic to present.
Use async tools to gather input.

Scenario 3: The Heated Argument

Solution:

Pause and acknowledge tension.
Redirect to facts and technical trade-offs.
Follow up individually if needed.

10. Continuous Improvement

Reflect on Your Facilitation

Ask yourself:

Did we achieve our objective?
Did everyone contribute?
What could I do better next time?

Learn from Others

Observe how other managers facilitate discussions.

Invest in Training

Consider workshops on facilitation, conflict resolution, and emotional intelligence.

Final Thoughts

As a new engineering manager, focus on guiding discussions, ensuring inclusivity, and creating an environment where the best ideas emerge. Master these skills, and your team will thrive.

DEV Community: DIAMANTINO ALMEIDA

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

The bargain nobody signed

This was not an accident

The right to be useful

[Boost]

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

Harsh ・ Mar 14

[Boost]

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

DIAMANTINO ALMEIDA ・ Mar 5

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

What the internet actually is

The dependency trap

The people telling you not to think

What this means if you build software

The only honest question

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

The Myth of the Savior

Trust is the Ultimate Low-Latency Network

The Soul of the Work

How to Start the Refactor

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

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.

[Boost]

Remember Your First Computer Book?

Richard Pascoe ・ Feb 13

Why Your Best Work Requires Zero Velocity

The Myth of the Optimized Engineer

The Ethics of Impact

Knowledge as Agency

The Slow Tech Movement

Your Friday Protocol: Reclaiming the Human

1. The Analog Buffer

2. The No-Verdict Audit

3. The Physical Signature

Legacy over Velocity

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

The Harsh Reality: The Middle is Disappearing

The "Cheap Labour" Trap

How to Break the Paradox: Your 2026 Survival Guide

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

2. Embrace the "AI-First Residency" Mindset

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

A Message of Motivation: The Pendulum Always Swings

My Advice to You

The Bottom Line

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

💡 Get the "Other Side" of the Hiring Table

👨‍💻 Who am I?

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

The Role of an AI Lead: Beyond Algorithms

Why Focusing on People Still Matters in AI

1. AI is Built by Humans, for Humans

2. Collaboration Drives Innovation

3. Ethical AI Requires Human Judgment

How an AI Lead Can Manage Their Team Effectively

1. Foster a Culture of Psychological Safety

2. Prioritize Continuous Learning

3. Balance Autonomy with Accountability

4. Lead with Empathy and Emotional Intelligence

The Future of AI Leadership: Human-Centric Innovation

Key Takeaways for AI Leads:

Final Thoughts

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

Why AI in Coding is a Game-Changer

The Risks of Over-Reliance on AI in Coding

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

2. Over-Reliance Erodes Your Coding Skills

3. Client Trust is on the Line

4. Ethical and Security Blind Spots

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

1. Treat AI Like a Junior Developer

2. Use AI for Brainstorming, Not Final Code

3. Study the Code It Generates

4. Keep My Core Skills Sharp

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

Final Thought: What’s Your Approach?

Dealing with Discussions Practical Tips for New Engineering Managers

Table of Contents