DEV Community: Joaquin Diaz

Human Code Review Is Not the Last Frontier

Joaquin Diaz — Mon, 09 Mar 2026 15:31:24 +0000

I found these two articles very interesting: The Self-Driving Codebase and How to Kill the Code Review.

And to be clear, I don't think they are totally wrong, I think they are pointing in the right direction, but I also think they jump too fast from "this is where things are going" to "we are almost there".

That is the part I don't buy.

I'm not anti-AI and I don't think agents are just hype either. I try tools, I use them, I see what works and what not. The progress is honestly better than many people think.

But software engineering in the real world is harder than the clean version of the story, that is my problem with a lot of this conversation.

When people talk about autonomous agents writing software, they often talk as if the main thing left is removing the human from code review. As if once the agents take care of that and humans stop reviewing every diff, then software development becomes mostly an automation problem.

I don't think that is true, I think human code review is not the last frontier, I think it is just the last visible step in a much bigger mess, because most real codebases are a mess.

And I mean that in the most normal, boring, everyday way that anyone with enough years in software has seen many times.

The Reality

Big codebases are full of technical debt. They have different coding styles because hundreds of people touched them over the years, lots of "temporary changes" that were supposed to be improved later and became permanent, dead code because the business changed direction three times, bad abstractions because someone tried to generalize too early, weird edge cases because one big customer needed something five years ago and the company never removed it, missing tests, outdated docs, unclear ownership, and I can go on and on.

So when I read ideas like "review the spec, not the code" or "kill the code review", I get the point, the current review process does not scale well if agents start producing much more code than humans can read, that part is fair. But in many teams, code review is doing more than checking code quality, it is where people bring context back into the change.

The reviewer knows that this ugly part of the system exists for a reason, that another team depends on a strange behavior that nobody documented, that this small looking refactor touches something fragile, which part of the code is annoying but harmless, and which part looks harmless but can break production.

That knowledge is often not written down anywhere, not in the tickets, not in the docs, not in the tests, not in the spec.

A lot of engineering work is not just implementing a clear idea, but discovering what the idea actually means while building it. You start with a requirement, and then you find out:

it was incomplete
it ignored an old system
it breaks an edge case
it creates a performance problem
it conflicts with another team's flow
it sounds simple at the product level but is messy at the data level

So I think some of these arguments assume a cleaner world than the one most engineers actually live in. If we consider that AI currently amplifies any existing structure, we are not in the best of scenarios, and this is where I separate the future from the hype.

The Future

Yes, this is probably the future, agents will keep getting better, human code review as we know it will probably matter less over time.

But that doesn't mean we are close to autonomous software engineering, and even less so in environments where software is hardest: large companies, old systems, regulated industries, critical user facing products, codebases with years of debt and weak ownership. That is a different game.

What works inside a frontier AI company does not automatically work inside a financial institution, that does not mean the frontier companies are faking it (well... at least not all of it), it means their environment is different. They are building the models, shaping the tools, and creating workflows around this new way of working.

But the average company is not in that position. Most companies are not working with clean systems, top tier internal tooling, strong documentation, fast decision making, and teams built around agent workflows. Most companies are still trying to survive their own complexity.

Software Engineering

Writing code is only one part of software engineering, and not even the hardest part. The hard part is working inside messy systems with incomplete context, unclear requirements, old decisions, conflicting constraints, and real consequences if something goes wrong.

That is where things still break down, to me, that is the real frontier, not code review by itself, the real frontier is judgment, context, knowing what matters in this codebase in this company at this moment, knowing when a change is technically correct but still wrong for the system, knowing what to ignore, what to clean up, what to leave alone, and what risk is acceptable.

And that my friends, is what software engineering really is. This is the point that gets lost when the discussion becomes too abstract. Because once you leave the world of demos, mvps, benchmarks, and greenfield projects, software is not just a code problem. It is a history problem, a people problem, a maintenance problem, a tradeoff problem, and I didn't even talk about scalability, maintainability, security and many more important topics.

Where we are

I am not arguing for a conservative view where nothing changes, a lot is already changing, I just think we should be honest about where we really are.

We are getting better at automating code production, we are not yet equally good at automating the deep context that real software engineering depends on.

That is why I don't believe human code review is the last frontier. It's the last place where human judgment shows up before the code lands. A deeper frontier is whether that judgment can be made clear enough, structured enough, and trusted enough that the system no longer depends on humans carrying it in their heads.

Maybe we'll get there, I don't know, or how we'll address the problems I mentioned.

But from where most of the industry stands today, we may be on the way, but we certainly are not there yet, it's not the same thing and it makes a big difference.

My Personal Blog Is Finally Live

Joaquin Diaz — Wed, 18 Feb 2026 17:45:32 +0000

After 2 years writing on Dev.to and Medium, I finally decided to build my own blog.

I enjoy the platforms and they were great for a while, but having full control is always better. It took me some time but it was a nice project to ship, and I had fun building it.

This wasn't just about creating the blog, I took the opportunity to rebuild my personal site joacod.com from scratch with a new look and feel as well.

Tech used

I wanted something very fast, no vendor lock-in, static (SSG), and not tied to any specific frontend tech (React, Vue, Svelte, etc), so the choice was an obvious one, I went with Astro, I love this framework and if in the future I need to extend it or add more client side heavy stuff I can do it, it's very powerful and I've been a huge fan of it for a couple of years now.

Other than that, just plain HTML, Tailwind, and vanilla JS. That's it.

Since Astro joined Cloudflare early this year, it felt like a good idea to deploy it there, but there are multiple deployment options (if I ever want to change that), right now it just works for me, and I get an extra layer of security as a bonus.

Did I use AI to create it?

Well, we are in 2026. If you are not using AI to help and improve your work, you are living under a rock, so yeah, of course I use AI.

I like to test different tools and models, so for this I used a mix of the following:

Claude Code + Opus 4.6 (Anthropic)
OpenCode + GPT-5.3-Codex (OpenAI)

My coding agent of choice is OpenCode, it's such a great project, if you don't know it and you are using something like Claude Code, I'd suggest you give it a try, it's the same approach, but open source, with better performance. You can also use any model you want with it, it has a lot of different providers you can connect to, and it's very easy to get up and running.

I was a user of Claude Code and Anthropic models for the past 6 months, but this month I switched entirely to the OpenCode + GPT-5.3-Codex combo. It may take you some time to get used to Codex if you are coming from Opus, Codex asks many more questions and requests clarifications (which is good), but if you know what you're doing and give precise directions, the results are amazing.

That said, both options are great, and at this point it's just a matter of personal preference.

Now what?

Having the opportunity to make it work exactly how you want is awesome. So I'll be adding more functionality, little fixes, and creating new stuff that sounds cool to build.

I'll continue writing as always, about the things that interest me, as a form of catharsis, or sharing news from the tech world.

The new blog will be the main canonical source, but I'll keep posting each article on Dev.to and Medium as secondary channels.

It was a good start of the year. It is always good to ship something and see it live. If you have suggestions, comments, or improvements, they are always welcome.

Thanks for reading, and see you on the web!

AI in Corporate, Navigating a Sea of Hot Air

Joaquin Diaz — Fri, 16 Jan 2026 13:55:42 +0000

I see several problems in corporate environments and in how AI is being used to speed up development.

On one hand, the more senior devs, who paradoxically are the ones who benefit the most from these tools are resisting. Some out of fear of being replaced, others are stuck with the idea of what an AI from two years ago could do. They don't try new models or tools, and a lot of them don't even know for example what Claude Code is...

On the other side, the processes and methodologies companies use are outdated. They already were years ago, but AI made it even more obvious. So no matter how much we speed things up on the dev side, the real bottleneck is somewhere else, and none of the decision makers are willing to have that conversation.

If we're doing a bit of future telling, the era of small structures and small teams is coming, roles merging, more ownership from start to finish. If you're a dev, learn product. If you come from product or management, learn code. None of these roles are going to exist the way we know them. How long will it take for the change to arrive? No idea. But it's coming, and like always in tech, you've gotta adapt. The time is now.

And finally, stop parroting whatever people say online, including this post. Research, experiment, see how far you can take those ideas you've always had. In my opinion, reality is somewhere in the middle, we're nowhere near the AGI the AI-Bros talk about, but the tools are way better than what the Anti-AI-Bros claim.

Good luck navigating this sea of hot air!

I don't care about the algo

Joaquin Diaz — Wed, 24 Dec 2025 14:42:02 +0000

It's been an interesting year, a little experiment on social media and building some online presence, my approach right now and for the next year is this "I don't care about the algo" not any more.

I started as everybody, investigating what was the best approach in general, but at some point every article or YouTube video about it sounds the same, over and over again. Analyze the different way people talk depending on the platform, for example a post on X got nothing to do with how people post and behave on LinkedIn, hashtags yes or no, don't put external links on posts (that will limit your reach), when starting reply more than you post so people get used to your takes, and every other advice made by the gurus of social media.

Despite some of the advices kind of work at first, the different algorithms and what platforms value most to keep users hooked change over time, and very often. If you want to be up to date with the latest updates you end up worrying more about the new algo than your content or what you want to talk about.

At some point I realized a couple of things. My intention was to be consistent so in order to do that I needed to enjoy what I was doing and doing it my way. Since I was aware of the "magic formulas to make it", when I read a post I recognize that stuff and is usually a sign to stop reading.

Currently most posts or ideas have no original voice at all, it's all the same regurgitated text from different AIs, different models but the same kind of slop.

I talked about my experience refining and editing with AI here, long story short, people want to know what real people think, agree or disagree, share different ideas and make their own conclusions, at least that is what I want.

We really need to make much more emphasis on critical thinking, no shortcuts, have your own opinions, and be ready to change your mind if something just makes more sense or you were missing information, you don't have to be right, you just have to be open to new point of views, and the possibility that you may be wrong about a lot of things.

For all of this, a few months ago I made a decision, I won't care about the algo any more. That had a huge positive effect, I was no longer following a formula, I just wrote things into internet's void, most of the time I don't get any reach at all, but the premise was "I don't care" so no problem, other times I get some interactions and the chance to discuss some ideas or topics, and very few times something hit a nerve and gets many interactions, shares or likes, that is awesome not gonna lie, but again not the objective of it at all, the point is to be able to share my thoughts, get them out of my mind, and it works really good for me in a cathartic and psychological way.

It was a great year, I learned a lot of things, and this is my approach for 2026: I'll keep writing stuff I'm interested in, posting when I feel like doing it, and let the algo be.

Happy holidays to everybody, see you in the future!

AI and the Loss of the Flow

Joaquin Diaz — Wed, 05 Nov 2025 06:49:33 +0000

Let's face it, we write less and less code every day. Software engineering changed for good. That ship has sailed.

And while we swing from "oh no, I'm going to lose my job soon" to "this clanker has no idea, of course I'm absolutely right", depending on the size and complexity of what we're building, we are not noticing what we are really losing.

The Flow

This one's short. Mostly because, despite growing up reading books, most of you now doomscroll your social media drug of choice and probably lost the attention span for more than a few lines of text. So if you made it this far, congrats!

What I actually want to talk about is something different, and honestly, a bigger problem than we think.

Those of you who enjoy programming will get this, back in the pre-AI days, coding felt like a craft. You'd have a problem, understand it, design a solution, go through the specs... and finally, the rewarding part, writing the code.

That moment was special because you'd already thought about it. You could see all the moving parts in your mind and you knew what you were about to build. You'd start typing, and soon enough, you'd enter that magical state a lot of people call "the flow".

It's that pure focus where distractions fade, you're deeply immersed in what you're doing, and time kind of dissolves. It's not about finishing or releasing your project (though that's nice too). It's about that "in the zone" feeling.

But that was the past

Now we just prompt.

It's rare for AI to nail it on the first try. If it does, it's because you wrote a hyper-specific prompt, if not you'll probably have to reword again and again as you catch tiny details that are off. We all love longer context windows, but at some point the slop written starts to multiply.

Sometimes I just bail out of the AI loop and start coding manually, especially when i get tired of arguing with a tool about something I already know how to do.

If you actually use AI at work, you know most of those YouTube demo projects don't even come close to the complexity of a real production codebase.

Anyway, back to the flow

We're losing it.

It's the most automatic, immersive part of our job, and it's slowly disappearing. Sure, AI keeps getting better, and it'll eventually handle more and more of what we used to do manually. But beyond that whole debate, losing the flow means losing a huge part of the joy of programming.

Instead of that deep focus where ideas turn into working code, we now live in a loop of reviews, prompts, tweaks, and retries.

I'm not sure where this is going. Maybe we'll learn to find that sense of flow at higher levels, when designing systems, architecting solutions, or abstracting problems. That can work for some.

I don’t know.

What I do know is that the old way felt better. It was more satisfying. We're removing a crucial part of the craft, a part that made you care deeply about the quality of what you built, as you shaped it, line by line of code.

And don't get me wrong, I’m not against AI. It's an incredible tool. I use it every day. But I can't help noticing that the more we rely on it, the less time we actually spend inside the problem.

We need to regain attention. Or maybe we're doomed to trade joy for efficiency, satisfaction for speed. Maybe the flow was the price we paid for progress.

Anyway, if you're reading this, maybe close your tab, open your editor, and code something today. No AI, no autocomplete. Just you, the problem, and that beautiful silence of being completely lost in it.

Be water my friend.

A New Day, a New Security Attack on npm…

Joaquin Diaz — Tue, 16 Sep 2025 17:48:54 +0000

The number of attacks and vulnerabilities popping up every week in npm is becoming ridiculous, and the problem just keeps growing.

Last week, we had a very serious attack where the account of a major maintainer "Qix" was compromised, and today, once again, another important one, an attack on the tiny-color library, potentially affecting more than 180 packages.

And of course, the most common type of attack is a "Supply Chain Attack".

The risks in the JavaScript ecosystem have always been there, especially with the huge number of dependencies whose origins we don’t fully know. But in recent weeks, we’ve seen more and more news of libraries with millions of downloads being compromised.

The problem is that in JavaScript we often rely on hundreds of packages, and it only takes one being contaminated for the attack to reach your project. You may even be using dozens of packages without realizing it, because they are dependencies of dependencies of something else you’re using.

What is a “Supply Chain Attack”?

A "Supply Chain Attack" is like a modern Trojan horse. Instead of attacking your application directly, they compromise a popular library, which then ends up running inside your application with different objectives. It can even reach CI/CD pipelines, production environments, and more, with countless possibilities for damage or exposure of sensitive data.

Why is it so risky in npm?

High dependency: a single npm install can bring in dozens of indirect libraries you don’t even know about.
Excessive trust: we blindly assume that everything on npm is safe.
Dangerous automation: many CI/CD pipelines update dependencies automatically, opening the door for attacks to spread.

What to do?

Lock versions in your package.json

The caret "^" is your worst enemy. It’s better to update dependencies consciously than to let any “Minor” or “Patch” version install automatically.

Following Semantic Versioning, we have MAJOR.MINOR.PATCH

"library-example": "^6.1.0" // installs Minor and Patch versions

With the caret, any version like 6.1.1, 6.1.2, or 6.2.0 will eventually be installed in your project. If one of those versions is compromised, you’ll be using it without knowing.

"library-example": "6.1.0" // installs only that specific version

Audit your dependencies

Don’t fall into the "install and forget" trap. Dependencies must be reviewed periodically, because even very popular libraries can be compromised.

Check what you install and use tools such as:

These tools detect known vulnerabilities and help you prioritize security patches.

Also, it’s good practice to check the state of a library before installing: when was it last updated? is there activity on GitHub? how many maintainers does it have?

A library that’s abandoned or maintained by just one person is far more vulnerable to being taken over by attackers.

Minimize dependencies

Every new library you add is a potential entry point into your application. Many times, we install a package for very simple tasks, it’s often better to write 20 lines of your own code than to bring in yet another unknown dependency.

Fewer dependencies = less attack surface, fewer updates to monitor, and a more predictable project. Not everything has to come from npm.

Conclusion

In npm, trust is delegated far too easily. Be careful with what you bring into your project, your security depends on it.

Virtual "Team Building" activities are a massive red flag

Joaquin Diaz — Fri, 18 Jul 2025 16:01:13 +0000

Dear execs, HR folks, and managers, please, let’s stop with the virtual team building sessions.

They waste time
They force devs and QAs who are deep into real work to context-switch and lose focus
They’re awkward
90% of the people are just waiting for it to be over
And they never, never, create any real bonding

Just my humble opinion, but here are two things that actually do work

1. Real-life team building activities, in person

Not mandatory. Bonus points if there’s travel involved, even if it’s just for a day or two. The people who show up actually want to be there. When you bring together folks from different teams and roles who may have only interacted virtually for months, conversations happen naturally. Real groups form organically.

2. A good work environment

A healthy workplace, where people collaborate the right way, is actually team building by itself. Some of my closest friendships started like that, just working together every day, helping each other out, bonding over shared interests, games, movies, music, whatever. And again, but very very important, it all happens ORGANICALLY.

Now, why do I say virtual team building is a red flag?

In my experience, these things usually pop up when there are deeper problems on the team:

Unrealistic deadlines
People with weak soft skills being promoted to leadership
A toxic environment where gatekeeping is rewarded instead of collaboration
And the list goes on, you can probably add a few of your own, we all identify this kind of things

If you’re in a leadership role and thinking about starting these virtual bonding sessions, maybe take a step back and look at what’s really going on inside the team. Fix the root cause first.

Let’s be a bit more self-aware. Stop throwing band-aids at deeper issues. And instead, create space for real, meaningful connections to grow.

Unsolicited advice about posting online

Joaquin Diaz — Wed, 16 Jul 2025 17:47:55 +0000

About a year and a half ago, I started being more active on different platforms. The goal was simple, share experiences, news, memes, whatever I felt like, and connect with people in the software and startup world from different corners of the globe.

I've always enjoyed writing. But thanks to impostor syndrome, the pressure to sound "professional", and that english is not my native language, I started filtering my ideas through AI, mainly ChatGPT. I’d write a raw draft, then polish it up and translate it with AI. And it felt like magic, the ideas were mine, but the result was perfectly written, not a typo in sight. Awesome! Right?

Well... not quite. I slowly started noticing something, even though the message was what I wanted to say, it didn’t feel like me, the words were too polished, the vocabulary was different of what i normally use on the day to day, the main ideas were there, but definitely the guy that wrote that wasn't me.

So, I stopped using AI for my posts. I went back to the old school way of doing things, just writing, directly in english, with my own words, editing manually a bit, fixing little things here and there, but more close to a first raw version of my ideas. And what I didn’t expect was how quickly the reach grew, more impressions, more engagement, more people commenting, talking to me on DMs, and actually connecting.

Moral of the story? In this AI driven, hyper curated world where everyone tries to be "professional" and politically correct, we’ve kind of lost our voice and essence, especially on social media. We started to identify when something was written by AI. We read a paragraph, realize it’s just more of the same, and scroll on.

I’m still figuring things out, but I try every day to show up here the same way I am in real life, less smoke and mirrors, more honesty.

Authenticity is going to be the real differentiator in the future we’re walking into.

I don’t want to meet a bot, I want to meet the human behind the screen. So here’s to the imperfections that make us humans, cheers!!

Technical Interviews in the AI Era

Joaquin Diaz — Wed, 25 Jun 2025 18:44:27 +0000

Let’s be real, you don’t need more than 1 hour for a proper technical interview.

The way most companies are doing interviews right now? It’s embarrassing.

They completely miss the point of what makes someone a good software developer. And don’t even get me started on how out of touch they are with the current state of AI.

Want to run an effective interview? Want to find out if someone not only has experience but also knows how to use modern AI tools to boost their work?

Here’s the process. One hour. That’s all it takes.

🔹 First 20 minutes: Let’s talk past projects

Ask about the candidate’s previous experience. Dive a bit into the projects they mention. This alone tells you a lot, what kind of challenges they’ve faced, how deep their experience goes, and how they think about solving problems.

Important: before the interview, send them a starter project (depending on the stack) so they can clone it and have it ready.

🔹 Next 40 minutes: Live coding, but make it real

Now here’s where it gets interesting, build a feature live, inside that starter repo.

But with a twist, let them use AI tools, VS Code with Copilot, Cursor, Windsurf, ChatGPT, Claude, Grok, whatever they want.

Autocomplete, AI prompts, agent mode, copy paste, search on the internet, it’s all fair game.

What matters isn’t if they use AI, it’s how they use it.

As they build:

Ask about the code the AI generates, go deep on the candidate explanations about it.
Look at the way they prompt. Are they treating the AI like magic, or are they in control? Do they give clear instructions about architecture, refactors, patterns?

You’ll quickly spot the difference between someone who leads with intention and someone who’s just hoping the AI does it all for them.

So what’s the catch?

Simple, this kind of interview only works if the interviewer actually knows the craft.

That means real technical experience, and being up to speed with modern AI workflows. If you don’t know how these tools work, you won’t know what to look for.

Conclusion

Cut the nonsense, skip memorized LeetCode problems that won't have any impact on the actual job. Focus on what matters, real world experience and modern tools.

That’s it.

Yes, it really is that simple.

Unlocking Developer Superpowers with Cursor

Joaquin Diaz — Tue, 17 Jun 2025 19:29:44 +0000

As a developer who’s been coding for 15+ years, I’ve recently shared my excitement about AI IDE's in general, and after trying a bunch of them my main editor for some time now is definitely Cursor.

Disclaimer: this is not a paid promotion (in fact I'm the one paying Cursor their Pro Plan), it's just my honest opinion on using it and my thoughts about the experience.

This AI powered code editor, built as a fork of Visual Studio Code, has transformed how I work, and I want to dive deeper into that on this article.

Here’s how I’ve been leveraging Cursor, why it feels like cheating, and why my foundational skills remain key.

Don't Be a Passenger, Take the Wheel

AI won’t drive the project for you. It’s fast, confident, and occasionally dead wrong. I've seen AI output go sideways a hundred different ways.

But with the right instincts, a bit of judgment and some cleanup, it becomes a serious asset (if you stay in control).

Know When to Step In

Cursor agent mode can refactor code impressively. But sometimes it loops endlessly, bloats logic, or misses the point entirely. I’ve tried all the usual fixes: better prompts, reframing the task, feeding it more files. Most of the time? It slows me down.

What works best: recognize when it’s off, stop the loop, fix it manually, finally hit the AI again with clearer intent. A small manual edit often saves more time than battling the prompt, and keeps things flowing.

Spot the Gaps It Can’t Fill

LLMs doesn’t know your architecture the way you do, or why a certain hack was necessary three sprints ago. I’ve seen it confidently suggest changes that would silently break core business logic.

If you know your system, you’ll catch these instantly. If you don’t, you risk shipping bugs the AI helped you write.

Clean Up the Hallucinations

Wrong API calls. Fabricated methods. Wild assumptions about project structure. They’re not rare. AI can sound convincing even when it’s totally wrong.

This is where experience matters most. I don’t trust the output blindly, I debug it, cross check it, and steer Cursor more effectively the next time around.

Why It Feels Like Cheating (If You’ve Got the Skills)

AI code editors can write code, suggest fixes, refactor functions, and answer project specific questions. Sounds great. But here’s the catch: all of that only becomes powerful in the hands of a developer who can tell good output from bad.

The “cheating” feeling doesn’t come from skipping the hard stuff. It comes from accelerating through it, because you can instantly spot when the AI is almost right, and know exactly how to fix it. That’s not bypassing the challenge. That’s using your experience as leverage.

Do it right, and speed of development starts to increase, like a lot. That’s when it starts to feel like cheating.

The Real Edge Is Still Experience

Cursor doesn’t replace your skills, it amplifies them. If you don’t already know what clean code looks like, what patterns to use, or how changes ripple through a system, AI won’t save you. It might even bury you deeper.

Fluency in languages helps you spot subtle errors AI introduces.
Design pattern knowledge lets you structure AI output into something maintainable.
Software architecture awareness ensures your edits fit the big picture.

Without this, you're letting the AI take control while you guess what it’s doing, and that is not a good idea, trust me.

Long story short, Cursor isn’t building my apps. It’s helping me build them faster, cleaner, and with more focus, because I bring the judgment, context, and correction it lacks.

I spend less time rewriting boilerplate, more time refining architecture, reviewing logic, and keeping quality high.

The Future of Software Development

A lot of people are talking about completely replacing programmers, I don't see it, and to be totally honest I think most of those claims are bullshit.

New models aren't growing exponentially like all the AI companies are advertising. These announcements should be taken with caution. Most of the time, their objective is just to raise more VC money.

That said, we cannot deny that AI is here to stay and that many jobs, while not completely replaced, will change radically. I believe they will change in a good way: fewer repetitive or boring tasks, and more focused on solving challenging problems.

The future of software development isn’t man vs machine, it’s collaboration. Tools like Cursor are getting more powerful: inline chat, project wide edits, agent mode. But none of it replaces the craft. It just makes skilled developers with strong foundations even faster.

Learn the basics of the languages you use, learn about design patterns, learn software architecture.

AI isn't magic, but you can significantly increase productivity if you know what you're doing.

The future is now.

Corporate is the Bottleneck, AI Changed the Game

Joaquin Diaz — Thu, 12 Jun 2025 12:43:47 +0000

Working in a corporate company feels like time has stopped, the speed of development is ridiculously slow, they are trying to use AI to improve but the problem is not the developers, it is in the infinite processes and layers upon layers of management.

The agile manifesto was created for developers to work better, corporate transformed it into a tool of control and bureaucracy, let's be honest whatever they are doing is not scrum and much less agile.

Big companies aren't dumb, they understand the problem they're in, but the restructuring needed to fix it is massive and one misstep can backfire, and it is backfiring. The different round of layoffs in most cases very poorly managed, only worsen employee sentiment, with key people fired, many others resigning, and an incalculable loss of real knowledge, they are entering uncharted territories.

It's the time of lightweight startups, the difference is abysmal, the speed is dizzying, corporate is the current champion, confident, poorly trained and pedantic, startups are the challenging underdogs, they are hungry, they have the eye of the tiger, and they are going for the title fight.

The game has changed, the playing field has leveled, the time is now.

Navigating the AI Revolution, Reality, Risk, and the Human Advantage

Joaquin Diaz — Mon, 09 Jun 2025 20:24:37 +0000

Artificial intelligence isn’t coming, it’s already here, transforming how businesses operate, how teams collaborate, and how value is created. AI headlines range from utopian promises to existential panic. But most miss the point.

The rise of large language models (LLMs) and intelligent automation isn’t about replacing humans. It’s about redefining roles, enhancing capabilities, and changing how we think about work. AI is a powerful tool, evolving fast, but far from infallible. Its impact depends on how we use it.

In this article I'll try to cut through the noise. What AI can realistically do? where it struggles? and how humans remain central to this transformation?

I'll also explore how smart adoption (not blind enthusiasm) creates real competitive advantage.

What AI Does Well and Where It Fails

AI is already crushing repetitive, rule based tasks. It can summarize reports, generate basic content, answer customer queries, and surface insights from vast datasets in seconds. These are meaningful gains in speed and scale.

But it can hallucinate, misinterpret, or reinforce bias. Ask it to write a legal brief, and it might sound convincing... but without legal oversight, it could be dangerously wrong. In healthcare, it can flag anomalies in scans, but only a trained professional can interpret them responsibly.

In high stakes domains, law, medicine, finance, engineering, AI is a smart assistant, not a replacement. It thrives on structure, but stumbles in ambiguity. That’s why human oversight isn't optional, it’s essential.

The sweet spot? Let AI do the heavy lifting. Let humans bring judgment, ethics, and nuance.

Competitive Advantage Comes from Strategic AI

AI offers real benefits: faster operations, lower costs, scalable solutions. But it’s not completely plug and play. Without a clear plan, it becomes just expensive tech theater.

Strategic adopters ask better questions:

What are the low value tasks draining our team’s time?
Where could automation introduce risk or erode trust?
How do we combine AI with human strengths, not substitute them?

For example, a logistics company might use AI to optimize delivery routes, boosting efficiency without compromising decision making. A marketing team might use AI to brainstorm content, but still rely on humans for narrative and brand tone.

The goal isn’t maximum automation, it’s meaningful transformation. That requires domain knowledge, critical thinking, and intention.

Cut Through the Hype

AI hype is everywhere. We’ve been here before, remember crypto and the blockchain gold rush?

Most promises faded. A few real use cases stuck. AI is following a similar pattern. The smart move now is to stay skeptical and grounded.

Don't take every claim at face value. Just because a vendor insists their AI product can do something impressive doesn’t mean it’s actually ready for real world use. Always test before you trust. Run small pilots in controlled environments before scaling anything broadly. And stay realistic, AI isn’t magic, it’s math. It has strengths, but also hard limitations.

Hype clouds judgment. Smart leaders focus on outcomes, not trends. They vet, validate, and deploy for real impact, not novelty.

Human Expertise Is the Real Differentiator

If you’ve spent years in your field, you’ve seen what works, what fails, and what never gets documented. That’s priceless, and it’s your edge.

This experience lets you catch what AI might miss: subtle inefficiencies, hidden risks, and clever workarounds. AI can assist, but it shouldn’t call the shots. The real power comes from using AI to sharpen your judgment, not substitute for it. Let it take care of the repetitive tasks so your team can focus on higher impact work.

The pattern is clear, pairing domain expertise with AI muscle is the winning formula.

The Future, Powered by AI, Led by People

The AI revolution isn’t a tsunami wiping out jobs overnight. It’s a wave of change that we can ride (if we’re smart about it). The winners won’t be the loudest adopters. They’ll be the most thoughtful ones.

If you're a leader, your job is to bring clarity, not panic. If you’re a professional with years of experience, your value just went up. If you're starting out, use AI to learn faster, but don’t abandon human skills like curiosity, communication, ethics, and creativity.

The market will evolve, and so will we. But let’s do it with intention, strategy, and a healthy dose of skepticism.

This era will reward those who think clearly, act wisely, and lead with purpose.

The AI revolution needs leaders who think critically, move deliberately, and never lose sight of the human advantage.