Forem: Joaquin Diaz

Context Is Not Memory, It Needs an Engine

Joaquin Diaz — Fri, 17 Apr 2026 13:49:38 +0000

In my previous article, Human Code Review Is Not the Last Frontier, I argued that human code review is not the final bottleneck.

Underneath that argument was something deeper, one of the real bottlenecks in agent-native engineering, the missing context.

Not context in the vague sense people usually mean when they say, "just give the model more information". I mean real engineering context. The kind that tells you whether a change is actually correct or just looks correct for five minutes in isolation. The kind of context that lives in old pull requests, half-forgotten migrations, team decisions, outdated assumptions, scattered docs, local workarounds, and painful experience inside a codebase that has been evolving for years.

That is usually the difference between a change that compiles and a change that actually belongs.

A repository is never just its current code. It also contains what the system is trying to move away from, what is still in progress, which ugly pattern still exists for a reason, which assumptions used to be true but should not be repeated, which workaround only makes sense in one corner of the system, and which apparently harmless area is actually fragile. Humans recover that knowledge over time because they have lived through the system, talked to the people around it, reviewed old changes, and seen things break.

Agents do not.

They only work with what is surfaced to them, and most of the time that context is incomplete, stale, too generic, or trapped in the wrong place. That is why I do not think this problem will be solved by simply adding more notes, writing a better prompt, or relying on a memory feature and hoping it behaves like judgment.

If context is one of the real bottlenecks in agent-native engineering, then it probably needs something more serious.

It needs its own system.

Context Is Not a Sidecar Problem

A lot of current AI workflows still treat context like a sidecar. Something attached to a prompt. Something kept in a rules file. Something the tool "remembers". Something dumped into documentation and hoped to stay fresh.

That can help, I use those things too, but they do not solve the core issue.

The real problem is not whether context exists somewhere. The real problem is whether that context is current, scoped correctly, relevant to the task, and surfaced at the right moment in the workflow.

That is a very different problem, it is not mainly a storage problem, it is a context quality problem, because context has lifecycles.

Context can be global and durable, or narrowly tied to a single repository. It may only matter during a migration, carry enough confidence to shape implementation, or stay weak and temporary because it comes from recent observations that could stop being true next week. Certain context matters most during planning, while other context only becomes important during debugging or validation. And once a transition is over, some of it should stop influencing future work entirely.

Once you look at it that way, context stops being just text, it becomes living information.

And living information needs to be managed, not merely stored.

Why Memory Is the Wrong Mental Model

This is why I do not think context should be treated as memory.

Memory sounds passive, it suggests something you keep around and occasionally recall, something helpful but secondary, something sitting off to the side. That is not enough.

What I am describing is an operational system.

That distinction matters because an operational system participates in the workflow. It can be maintained, revised, ranked, scoped, and delivered when needed. The point is not just to retain context somewhere in the background. The point is to make it usable.

This is also why "more memory" is not automatically better. A pile of remembered notes is still a pile. If context is stale, weak, conflicting, badly scoped, or poorly timed, then surfacing more of it may make the workflow worse, not better.

The challenge is not accumulation, the challenge is usefulness.

Why Raw Files Are Not Enough

This is where the idea starts to become more concrete, I am not talking about saving more notes, I am talking about giving engineering context a canonical system of record.

Not because markdown is bad, but because raw files alone are a weak foundation for something that has scope, freshness, confidence, lineage, version history, review state, conflict states, and natural decay over time.

If context has that kind of lifecycle, then the system behind it should be able to understand things like:

where a piece of context applies
how trustworthy it is
what generated it
whether it conflicts with something newer
whether it is still active
whether it should continue influencing future work
whether it represents a preferred path or a known anti-pattern

Those are not minor details. They are part of what makes context usable.

This is why I think the missing piece is not memory, and not documentation with better search. The missing piece is an engine, a system capable of ingesting, classifying, refining, and retrieving context in a way that matches real engineering work.

The important part is not storage, it is the engine. The storage layer is not the differentiator, the engine is.

Storage matters only because it gives the system structure, but structure alone is not what solves the problem. What matters is what sits on top of that structure.

A useful context system should be able to notice when a new piece of context overlaps with something already known. It should recognize when a previous assumption has started to decay. It should understand that a repository-specific rule should not be treated as a global one. It should learn that a certain implementation path repeatedly gets corrected by humans. It should preserve not only what worked, but also what repeatedly failed or had to be revised.

That last part matters a lot.

A good system should not only remember successful patterns, it should also surface negative knowledge, what to avoid, what keeps breaking, what looks reasonable but repeatedly turns out to be wrong in this specific codebase.

That is one of the biggest gaps in current workflows. Agents are often good at producing plausible work. But plausible is not the same as correct, and it is definitely not the same as locally correct inside a messy, evolving system.

What they are missing is not always capability, they are missing the context that actually matters.

Internally Rich, Externally Simple

One of the most important design principles here is simple: internally rich, externally simple.

Internally, the system should be sophisticated. It should use structured storage, lifecycle management, ranking, revision logic, conflict handling, freshness scoring, and retrieval logic that can adapt to different stages of work.

Externally, though, it should stay simple.

Most agent workflows already consume text extremely well. Prompts, notes, handoff files, planning docs, constraint summaries, migration notes, contextual briefs. That part already works. So instead of forcing every harness, assistant, IDE, or workflow to understand a complicated internal schema, the engine can do the hard work inside and return the result as markdown.

That is the abstraction.

Internally, the system manages context properly. Externally, it delivers one or more markdown artifacts that can be consumed almost anywhere.

That could mean a brief for a quick task, a planning pack for riskier work, migration notes when a system is in transition, recent learnings for debugging, known risks during validation. The exact filenames do not matter, what matters is that the output remains simple enough for almost any workflow to adopt without friction.

That simplicity is not a compromise, it is part of the design.

If every team needs schema awareness, special adapters, and deep knowledge of how the engine thinks, then adoption becomes harder right where the system should be disappearing into the background. The workflow should not need to care how context was stored, promoted, revised, merged, or archived. It should just ask for the right context and receive a clean package.

Why This Matters Now

This matters because the real world is not going to standardize around one assistant, one IDE, one orchestration layer, or one company workflow.

Different teams use different tools, different companies have different processes, different repositories have different levels of entropy, different tasks need different amounts of context at different moments.

So if this idea only works when everything is redesigned around it, then it is already weaker than it should be.

But if the internal system stays rich and the external interface stays simple, then the same engine can plug into planning, implementation, debugging, validation, CI loops, pull request preparation, or longer autonomous workflows without forcing everyone into the same stack.

The workflow asks for context, the engine returns markdown, the agent consumes it.

That is much more realistic.

The Missing Layer

This is the missing layer I was pointing at in the previous article.

When I said human code review is not the last frontier, part of what I meant was that the real frontier is not simply whether agents can generate more code. It is whether they can operate with the kind of context that real engineering work actually depends on.

Not generic context, not bloated context, not stale context, useful context.

Context that knows where it applies, whether it is still true, how strong it is, what it conflicts with, and when it should stop influencing future work. Context that can be maintained instead of forgotten. Context that appears when it matters, instead of arriving as noise.

That is why I think this deserves its own layer.

Not another memory feature, not a prompt trick, not markdown folders pretending to be a system. A real "Context Engine", internally structured enough to manage context properly, and externally simple enough that almost nobody consuming it needs to care how it works.

They just get a usable context package.

And honestly, that is not a small implementation detail, it is the whole point.

Closing Thought

As agents get better at generating code, the bottleneck becomes easier to see. The issue is often not raw capability, it is contextual correctness.

That is why I think context needs something more deliberate behind it, not passive memory, not loose documentation, not a bigger pile of notes, an engine.

Because the difference between work that looks right and work that is right often lives in all the things the code alone does not tell you. And if those things are becoming one of the main constraints on agent-native engineering, then they should not remain scattered across prompts, docs, habits, and human memory.

They should have a real system behind them.

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.