DEV Community: Mánu Fosela

The Hardest Part Isn't AI. It's Us

Mánu Fosela — Mon, 17 Aug 2026 09:41:03 +0000

In the first article I talked about how AI is shifting our work toward a higher level of abstraction: increasingly less focused on writing the how and more on deciding what we want to achieve. In the second, I tried to answer the inevitable question: if we’re going to delegate more and more work to agents, how do we do it without having to blindly trust them? My answer was to build governance systems around them: external rules, verification mechanisms, guardrails and orchestration.

In this one, I want to address something just as important, if not more so: how to lead this change. Because we can solve those two problems perfectly and still fail.

Get comfortable, because this article is long.

Companies don’t change when we install a tool, or when we adopt a different way of working. They change when the people working in them change and their culture, or part of it, changes too, not because the company loses its essence, vision, mission or values, but because it evolves. And this is where we probably enter the most complicated part of the game.

Writing code is starting to become the easy part

Right now, and even more so in the future, it increasingly looks like “writing code” is going to be the easy part. Careful! I’m not saying that developing software is easy. Not even close. I’m saying exactly the opposite. Writing the code is becoming the part we can delegate most easily. The hard part is starting to move somewhere else.

Understanding what needs to be done. Understanding the domain. Designing it. Choosing between alternatives. Knowing what consequences a decision might have. Measuring it. Testing it. Operating it. Maintaining it. Knowing whether it actually solves the problem we wanted to solve. And above all, being able to look at something an AI has built, verify that it works perfectly and say: “This works, but it’s wrong”. And even more importantly, being able to explain why.

DISCLAIMER: the following example is there to illustrate what I mean in the simplest possible way. Software engineering scholars, please refrain from nitpicking it. Don’t look at the finger. Look at the moon.

For example (JavaScript code). Imagine you come across this:

  function isDigit(value) {
    if (value === 0) return true;
    if (value === 1) return true;
    if (value === 2) return true;
    if (value === 3) return true;
    if (value === 4) return true;
    if (value === 5) return true;
    if (value === 6) return true;
    if (value === 7) return true;
    if (value === 8) return true;
    if (value === 9) return true;
    return false;
  }

It works. You give it a value and it tells you whether it’s a digit. It can perfectly pass every test we’ve defined.

And yet, almost anyone with some experience will probably stare at it for a few seconds and think: “Do we really need ten ifs to express this?”.

I’m sure that while you were reading it, you were already thinking of another way to do it. Maybe even several. And we’d probably end up debating which one is better.

Well, that’s exactly what I’m talking about.

Not that this function is going to break production or that it is objectively incorrect. It is deliberately a ridiculously simple example. I’m talking about that ability to look at a solution that works and ask yourself whether it is a good solution, whether it expresses properly what we want to do and whether there is a better way to solve it. A solution can satisfy every criterion we’ve checked and still be badly designed. It can do unnecessary work. It can introduce coupling we don’t need. It can add absurd complexity. It can introduce a decision today whose cost we won’t see until we have to modify, operate or maintain that part of the system. It can be insecure. It can work and still be shit.

That’s judgment. And it’s something we’ve so often seen AI lack, precisely because it has been trained on all the code in the whole damn world, where we upload every kind of code imaginable.

In the first article I said that our work is shifting upwards. I think this is one of the places it’s shifting to. And if that is going to become one of the main sources of value of a software engineer, another problem immediately appears: how do we help those who already have that judgment move it into this new way of working, and how do we train those who don’t have it yet? That is one of our biggest challenges. And it isn’t technological. It’s human.

“You’re taking away what I love doing: programming”

Put yourself in the shoes of someone who has spent five, ten, fifteen or twenty years programming. Depending on when they started, they probably didn’t choose this profession only because it paid well, although we have lived through a “golden age” in which many people moved into software development because there was plenty of work and it paid well, and many of them also discovered their passion thanks to that. Most people who program do it because they enjoy programming. Not necessarily outside working hours too, although quite a few of us do ;)

What we tend to have in common is that we enjoy facing a problem. Thinking of a solution. Writing a function that is efficient and elegant at the same time. Finding an abstraction. Removing twenty lines and turning them into five while somehow making the code more readable. Building something useful for someone else. Looking at something you’ve just finished and thinking: “I am God”. Let’s ignore those other occasions when we think we chose the wrong profession and are completely useless at this :P

Then the first traces of AI appear. Autocomplete. Suggestions for methods, functions, classes. We start asking it for larger pieces, with varying degrees of success. We start using it to get past the blank page. To write tests for us. It finds bugs and saves us hours of debugging. But it’s still an assistant. A helper. Support.

And then someone comes along telling you about the wonders of agentic development, that AI can write the code, and tells you that, if everything evolves the way it seems to be evolving, programming the way we have until now will gradually become less necessary. Well. I wouldn’t exactly expect people to jump for joy.

I think one of the things we do wrong when talking about AI adoption is minimising this. We treat it as resistance to change. Irrational fear. People who “don’t want to adapt”. And part of it may be that. But another part isn’t. Mainly for two reasons: disappointing experiences with “the technologAI” and a very real sense of loss. The feeling of becoming a secondary actor. Of losing the thing you’re good at and that gives you identity. Even of becoming expendable.

Grief

If you’ve spent years building a professional identity around something and that something starts to change, there is a kind of grief involved. I think we need to say it. Something is lost. Something dies a little bit inside our “soul”. Because in all likelihood we will gradually write less code manually. Many of the things that give us professional satisfaction today will slowly stop being part of our everyday work. Pretending that isn’t happening doesn’t help.

But I don’t think craftsmanship disappears either. I think some of that craftsmanship also moves upwards and some of it, the more romantic part, will continue “weaving by hand” every line of code when efficiency, quality or the problem itself justify it. The pleasure of writing an especially efficient and readable line of code may turn into designing an especially efficient and scalable architecture. Finding a simple way to solve a complex problem. Defining an acceptance criterion that catches twenty incorrect solutions. Spotting a consequence nobody else had noticed. Being able to look at five proposals generated by agents and understand which one makes sense and why. Or even realising that we’re perfectly building something nobody actually needs.

Most of us will gradually stop being craftspeople of code. But we may become another kind of craftsperson: of products, systems and impact. And that doesn’t happen automatically because someone gave us access to Claude or Codex. We have to help people make that transition.

Understanding doesn’t mean accepting that someone stands still

This is where, for me, an idea I’ve tried to apply for years when leading people comes in. You can perfectly understand why someone is afraid, why they feel threatened, or why they don’t want to abandon a way of working they master or feel comfortable with. And at the same time clearly tell them that they need to explore it, consider the new paradigm and accompany them while they do it. Those positions aren’t contradictory. Understanding doesn’t mean lowering expectations. Neither does supporting someone.

In the way I understand leadership, which I call affective leadership, I build relationships with the people I lead and put emotions at the same level as objective considerations, so I don’t avoid uncomfortable conversations. I initiate them when they are necessary, because allowing a problem to fester isn’t caring for someone either. If I believe someone may be left behind professionally, my responsibility isn’t to reassure them by saying nothing is going to change. It’s to help them prepare for the change.

And I don’t think the answer is to tell someone “adapt or you’ll be left behind” either. That’s not leadership. That’s dumping the problem on them and leaving them alone. Leading this transition means explaining where I think we’re going, listening to where each person is, what they think and feel, understanding what they need and building a path so they can get there. But the destination can’t disappear from the conversation just because talking about it is uncomfortable.

Don’t evangelise by selling “magic”

I also think there’s a common mistake among those of us who adopt these tools early. We get excited and start evangelising.

“This is insane!”
“I’m ten times faster”
“I barely program anymore”
“I did in one afternoon what used to take me a week”

It may be true. I’ve experienced it myself. But then somebody tries exactly the same tool, has a horrible afternoon and thinks you’ve sold them bullshit. Because we forget the details. How many hours did you spend experimenting and failing before you got there? How many prompts, specs, skills, “MCPs”... did you try and discard? In other words, what price did you pay to get where you are? (pun very much intended)

And there will be bad days too. The agent will stubbornly insist on some absurd solution. A model update will change something that worked. The context will be wrong. The provider will go down. Something will get through controls you thought were sufficient. None of that invalidates the direction. It means we’re working with a technology that is still evolving at a brutal pace.

If we promise “magic”, every failure destroys trust. If we explain that we’re building a new way of working that still has problems, every failure can become an opportunity to learn. We don’t need believers. We need engineers experimenting, learning and building judgment around this new way of working. And we also need to understand that not everyone is at the same point. For someone who feels they’re training the thing that’s going to “take their job”, experimenting with all this can be extremely uncomfortable.

You don’t leave the office on Friday as a code craftsperson and come back on Monday morning having changed professions. We’d be making a mistake if we thought someone who has spent fifteen years developing in a certain way is going to change because we install a tool, give a talk and write a “Notion” explaining that now we’re AI-first. The transition has to happen while working.

First, without a doubt, we need to build the governance structure, which serves both AI and humans. An environment that guarantees nobody can screw things up. Then maybe you delegate the things that bring you the least value. Then a small implementation. Then a whole task. You start reviewing plans before the agent writes anything. You start worrying less about exactly how a particular function was implemented and more about whether the complete solution makes sense. Little by little, you stop being inside every line and start sitting above the system. And one day you realise you’ve spent hours developing software without writing much code at all, and that the code it generated meets all the requirements for quality, efficiency, security... just like your best code.

That change shouldn’t be imposed as a surrender. We should help each person discover where their value lies now. A senior who has spent fifteen years programming has an enormous amount of knowledge and experience that isn’t stored in their fingers. It’s in all the shit they’ve been through. In those migrations that went wrong. In that wonderful architecture that six months later nobody knew how to maintain. In that optimisation nobody actually needed. In that ridiculous bug that reached production and nobody spotted. In that technically perfect product or feature that nobody used. That is exactly what we can’t afford to lose when we delegate writing code to AI. We need to apply that judgment to what AI produces.

The problem is that we have to learn while still delivering

This is, for me, one of the most interesting organisational problems. We have to adopt a new way of developing software, but the company can’t stop developing software while we learn. We can’t say: “For the next six months we’re not shipping anything because we’re training everyone on AI”. We have to do both at the same time. Learn and deliver. Accepting that is no small thing.

For a while, we may have to accept a percentage drop in productivity while trying to learn how to become dramatically more productive. And that’s something the company has to accept if it doesn’t want to be left behind. Someone will reasonably ask: and how do I know whether that bet is paying off? Not by the number of tokens we’re spending or the number of lines we’re writing. You start seeing it when more work reaches production with fewer errors. That’s the signal that we’re learning to become more productive, rather than merely faster. And for that, you should already be measuring the impact you have now so you can compare it with the impact you’ll have later.

And I think platform engineering and developer experience teams play a fundamental role here. If your company doesn’t have them yet, you’re already late :P

And during the process we’ll get things wrong. We’ll try tools that we abandon two weeks later. We’ll build processes that are too complicated. We’ll swing too far in the opposite direction. We’ll come back. And we’ll encounter another problem: the technology we’re trying to learn isn’t standing still. While we move forward step by step, models improve, tools change and agents acquire new capabilities. Something that was considered good practice six months ago — well, let’s say six weeks now — may stop making sense.

That’s why I don’t think adoption can be based mainly on traditional training. We can’t think: course → certification → now you know AI. The unit of learning has to be the work itself. Real cases. Real projects. Real experiments. And mechanisms that allow what one person learns today to spread to the rest of the team tomorrow. Knowledge governance.

How do we build judgment?

And now we come back to what I said at the beginning. If writing code is becoming the easy part and a growing share of an engineer’s value is shifting toward judgment, a pretty f...reaking hard question appears: how do you acquire judgment? Because nobody is born knowing how to look at a solution and say “this works, but it’s wrong”.

Traditionally we’ve acquired it by doing. Programming. Making mistakes. Seeing the consequences. Getting reviews. Maintaining our own decisions years later. Discovering why something that looked so elegant was actually stupid. Working alongside people who knew more than us. Putting in hours, coffees and pizzas. Debating. Doing hackathons.

And then the inevitable question about juniors appears. How do we train juniors if traditionally a junior learned by programming, making mistakes, receiving reviews and accumulating experience until becoming senior, but now an AI is going to execute a large part of that work?

I think we’re asking the wrong question. Because what turns someone into a senior isn’t having written enough lines of code. It’s having acquired judgment. A senior isn’t someone with five years of experience. It’s someone capable of avoiding a mistake before it happens and recognising a problem before it lands on top of them. Five, ten or fifteen years of just any kind of experience don’t make you senior. It’s a very particular kind of experience that hardens that layer of seniority, the kind that teaches you when a solution makes sense and when it doesn’t. What questions to ask. How to detect that something apparently correct doesn’t fit. To understand that every decision has a price, what you gain and what you give up. To understand that there are almost never silver bullets capable of killing the “werewolf”.

And so the interesting question becomes a different one: how does a junior acquire judgment if AI is executing a large part of the work? I think the answer is right in front of us and we’re not seeing it. We can’t see the forest for the trees.

The washing machine

This happened to me during these holidays with a washing machine. We were staying in an apartment and there was a fairly analogue washing machine from a brand I didn’t know, with programs numbered from 1 to 8. I needed to use it. Program 3? 5? 7? No idea. So I did what many of us would probably do today. I took a photo and sent it to ChatGPT. It recognised the washing machine and the model. It asked what I wanted to wash, I explained what clothes were in the load and it recommended a program.

If I’d been alone, I would have used that program. No further questions. Why? Because I’m the junior when it comes to laundry in our house. Generally speaking, I handle cooking and shopping. My wife handles the laundry. So I lack mileage, in other words, I don’t have judgment. I have some knowledge: I know the basics of washing programs, separating clothes, adding fabric softener and which one we prefer... But I lack judgment. Standing in front of that washing machine, I didn’t have enough experience.

Fortunately, my wife was there, and in that domain she’s the senior. And she didn’t simply accept the first answer. She said:

“But I want the clothes to come out like this. Did you tell it that?”
“How long does that program take? Wow! That seems like a lot”
“What temperature does it wash at?”
“Do you know the water here is really hard?”

She questioned the solution. Added context. Made me debate with the model. Compared its answer with what she knew from experience. From having “broken” laundry loads. And eventually, we arrived at another program that fitted what we actually wanted better. And the clothes came out perfectly!

That was the difference between junior and senior. I had an answer. She had the judgment to evaluate the answer.

Now imagine she hadn’t been there. I would have used the first program ChatGPT recommended, taken the clothes out and thought: “This hasn’t come out the way I expected”. What would I have done next? Gone back to ChatGPT. Explained what happened. Asked why. It would agree with me and apologise, obviously. We’d compare alternatives. And probably on the next wash, or twenty washes later, we would eventually have reached the same conclusion my wife arrived at by asking a few questions. With one small difference. I would have had to break a few laundry loads to learn it. And after enough loads, I would have had more judgment than before.

Well, I think that’s how we need to train juniors too. We need to let them do laundry. A junior needs to do things. They need to make decisions. They need to make mistakes. They need to see the consequences. They need to ask AI, try its answer and discover that sometimes something that sounded perfectly reasonable doesn’t produce exactly the result they expected.

We need to let them use AI from day one. Not teach them for years how to work the way we did in the pre-AI era, only to then explain how to stop working that way. That’s absurd. It makes no sense.

How many times have we seen the joke “another day without ever using the least common multiple”. And although we know that some knowledge and learning can appear useless while still helping us “furnish the mind”, we need to find the balance, carefully select what is useful and what will simply leave people feeling that they’ve learned something they’ll never use. We should be able to justify every thing we teach without AI, even when right now it looks like “wax on, wax off” (The Karate Kid, 1984) and they don’t understand why; soon enough they should be able to see that they’ve internalised useful things that help them build judgment. For example, learning how to really debug: reading a stack trace, forming a hypothesis about why something is failing and testing that hypothesis. Today you can ask an agent to do that too, but that is exactly the muscle you’ll later use to judge whether what AI did is actually right or merely looks right. It’s pure “wax on, wax off”: it seems useless until the day you look at a solution with all the tests green and know it’s wrong.

And we need to teach them how to work with AI. But that doesn’t mean leaving them alone in front of an agent. It means teaching them to ask better questions. To challenge answers. To request alternatives. To understand why one option is better than another. To spot missing information. To verify the result. To debate and learn alongside them. And above all, let them break laundry loads. In environments where breaking a laundry load is cheap. Controlled projects. Scoped tasks. Development environments. Systems where mistakes are detected early. With people around them who have more judgment and can help them understand not only that something is wrong, but why.

The governance system I talked about in the previous article also serves this purpose: allowing us to make mistakes without every mistake ending up in production. It doesn’t just protect the software. It can also become a learning environment.

They also need to understand the rules

There’s another source of learning that I think is particularly important. If we’re going to build systems where AI works under certain rules, juniors should know those rules. Not simply obey them. Understand them. Why do we do TDD? Why have we decided that a review should be performed by a model from another family? Why do we limit the size of a PR? Why was this architectural decision made this way? Why this dependency and not that one? What alternatives were there? What do we gain? What do we sacrifice? And we should debate those things with them and let them propose and experiment with their own alternatives alongside us.

Because those rules are, to a large extent, accumulated judgment. They’re decisions made after years of mistakes, experiences and lessons learned. Explaining them means transferring part of that judgment. But we also need to explain something even more important: those rules may be wrong. They’re not commandments. They need to be questioned. They are decisions made in a particular context at a particular moment. And context changes.

Maybe that’s exactly why we need juniors more than ever

There’s an interesting paradox here. We could think that if AI can do much of the work we traditionally assigned to junior profiles, we’ll need fewer juniors. I think that’s a huuuuuuge mistake. Because if we stop bringing juniors in, the obvious question is: where are the seniors going to come from in five or ten years?

But there’s another reason. The juniors we train now may have an advantage that we seniors don’t have, and I’ve already seen this with my own children, who are moving toward the industry. We accumulate judgment. But we also accumulate habits. Ways of doing things. Decisions that worked for years. And a dangerous tendency to think: “We’ve always done it this way because it works”. Seniors have a tendency to rest on their laurels. And at the speed things are moving now, you can’t even afford a quick nap. In the past, that might have been relatively cheap. Technology could change a lot, but certain paradigms could last for years. Now some things change practically month by month.

And this is really fucking hard. We’ve always said you need to stay up to date, but what’s happening now is frantic. In a way, we’ve all become “juniors” again: learning, experimenting and questioning continuously. Eternal juniors. No rest for the warrior.

The people who are starting now and those who come after them, who learn from the beginning by working with AI and who we teach to build judgment, may be precisely the ones best positioned to question our own rules:

“Why do we do this this way?”
“Does this restriction still make sense?”
“This model can now do something it couldn’t do before”
“Why are we still keeping this manual step?”

And maybe they’re right. That’s why we need to teach them our rules. But we also need to teach them to question those rules.

That’s why we need juniors. Always. And that’s why I think companies should deliberately continue bringing juniors in and training them. Spend resources on it. Take vocational training and university interns and later bring them into the company. Create internal onboarding and training programmes. Give them projects where they can work inside an AI governance environment from day one, accompanied by people with more judgment and inside systems where making mistakes is cheap. We don’t need juniors to do the boring tasks seniors don’t want to do. AI will increasingly do those better. We need them for something much more important. To build the next generation of people with judgment. Because if the work shifts upwards, we also need to teach the next generation how to work up there.

I’m genuinely worried about building an entire system where AI writes the code and eventually having nobody left capable of governing that AI and applying the necessary judgment. So let’s burn this into our brains: judgment isn’t installed. It’s built. Question by question. Decision by decision. Mistake by mistake. Laundry load by laundry load.

Not everyone will move at the same speed

Not everyone will move at the same speed, and we need to accept that there will be differences. Some people have already been working this way for months. Others are just starting. Someone will remain sceptical until they see data. Someone else will move too fast and we’ll have to hold them back. Another person will discover a way of working nobody had anticipated. We don’t need everyone to move at exactly the same pace. We need everyone moving in the same direction. Diversity with a shared goal.

And we need to turn individual learning into team learning. Because in a transition this fast, we can’t depend on three people who independently figured out how to work well with these tools. What one person learns has to spread through the rest of the team. And tomorrow we need to be willing to throw part of that learning away because the conditions have changed again.

And the challenge also changes for those of us who lead

All of this changes what those of us leading engineering teams need to do too. Buying licences isn’t enough. Saying we’re AI-first isn’t enough. Measuring how many developers use Copilot or how many tokens they spend isn’t enough.

We need to help each person understand where their value is shifting. For someone who has spent fifteen years writing code, we need to help them understand that their experience doesn’t disappear just because someone else writes the lines: we need precisely that experience to judge what the agents produce. And for someone who doesn’t yet have that experience, we need to create opportunities to build it. We need to create spaces where experimentation is cheap. Allow bad days. Share what we’ve learned. Prevent the person moving fastest from looking down on someone who’s only just getting started, and also prevent someone who refuses to move from turning their fear into a reason that paralyses other people or the company itself, and make them aware when that is happening.

We’ll also have to change what we recognise and reward. If we continue considering the best engineer to be the person who produces the most code while at the same time asking agents to produce the code, we’ve created a completely contradictory system. And please don’t measure AI adoption by who spends the most tokens. No. Maybe we need to start recognising much more the person who realised something shouldn’t be built at all. The person who prevented a bad architecture. The person who found a vulnerability. The person who got an agent to solve a difficult problem well while spending very few tokens. The person who taught five colleagues something they’d learned. The person who was able to explain why a solution that apparently worked was actually wrong. That’s engineering too. It probably always was. Writing code simply took up so much space that we couldn’t see it.

And yes: standing still isn’t an option either

This is probably the most uncomfortable conversation. Not adopting these tools doesn’t mean preserving your current position, because the rest of the world doesn’t stand still with you. The bar moves. And there is also a generation coming for whom this transition won’t even exist. A developer starting a few years from now probably won’t have to “learn how to develop with AI”: it will simply be how they learned to develop. Just as someone who started using Git never had to experience the transition from copying folders called project_final, project_final_good, project_final_now_really_final... For them, version control simply existed. Something similar will happen with agents.

I don’t think we should use that as a threat. But we shouldn’t hide it just to avoid an uncomfortable conversation either. Leadership also means explaining that the world is changing before the change runs you over.

Summary and conclusions

Over the last few years, we’ve talked endlessly about AI as a productivity tool. How to write code faster. How to build more features. How to produce more with less. That’s already becoming too narrow. The real opportunity is much bigger: it’s about changing which part of the process machines do and which part we do.

And if that happens, writing code will increasingly become less of what defines a software engineer, because writing code is starting to become “the easy part”. The hard part will be knowing which code deserves to exist. Understanding the problem. Designing the system. Knowing the domain. Choosing between alternatives. Measuring. Verifying. Understanding the consequences. Keeping it alive. And being able to look at something generated by AI, see that it compiles, that the tests are green, that it apparently does exactly what you asked it to do and say: “No. This works, but it’s wrong”. That’s judgment.

And I think one of our biggest challenges over the next few years won’t be getting our teams to learn how to use AI. It will be helping those who already have that judgment move it to this new level, while making sure those who don’t have it yet can build it in a world where they will probably write less and less code themselves.

AI can write the code. We need to develop the people capable of knowing what is worth building and when what has been built is wrong. And that has to be led, always with affection.

Delegating to AI Means Governing the Environment

Mánu Fosela — Thu, 13 Aug 2026 15:54:17 +0000

In the previous article, I argued that AI isn't simply changing the tools we use to develop software, but shifting our work to a new level of abstraction. In this one, I want to address the problem that immediately follows: if we're going to write less and less code directly and agents are going to produce an increasingly larger part of it, how the hell do we know whether what they code is actually right?

Because the answer obviously can't be “trust the AI, it's very smart”.

Even though I personally develop code with AI today with practically no review, I don't blindly trust AI. Just as I don't blindly trust an engineer on my team. I don't even blindly trust myself.

Blind trust is a security hole. And not blindly trusting someone doesn't mean distrusting them, it means having mechanisms to prevent their mistakes, or mine, from causing problems.

That's why we've spent decades building mechanisms and methodologies around software development to detect, and avoid as much as possible, our mistakes. XP. Scrum. Tests. Code reviews. Pair Programming. CI. Static analysis. Permissions. Observability. Environments. Containers. Auditing...

The question, therefore, shouldn't be whether we can trust an AI. The question should be what system do we need to build so we can use it without needing to blindly trust it?

It's not deterministic

One of the first objections is usually that if you ask it the same thing twice, it generates two different pieces of code.

True.

But if you give the same task to two different programmers, or to the same programmer with enough time in between, we'll very probably get two different implementations too, depending on the complexity of what we're asking.

And if we've never required two developers to produce exactly the same code, why do we expect AI to produce exactly the same code from the same request?

Isn't it enough for the result to satisfy the requested requirements?

That it does what it's supposed to do. That it passes all kinds of tests. That it satisfies the acceptance criteria. That it meets security requirements. That it respects certain constraints.

The problem appears when we keep evaluating the writing process while this new level of abstraction increasingly forces us to evaluate the result against a contract.

And when I say contract, I'm not talking about a huge spec telling the agent how it has to build every single thing. I'm talking about the conditions the result must satisfy and having mechanisms that can verify them.

We haven't reached compiler-level reliability yet, and I don't know whether we ever will, or even whether we need to. What is happening is that agents are becoming more capable and we're giving them more and more autonomy.

And the more autonomous they become, the less sense it makes to think we'll be able to control them by constantly looking over their shoulder.

Rules can't live inside the agent

This is, for me, one of the important parts.

A rule written only in a prompt isn't a rule. It's a request.

You can have an AGENTS.md, a skill or whatever you want telling it never to do a certain thing. It helps enormously. I use them, obviously. But we've already seen that the agent forgets them more often than we'd like, sometimes interprets them incorrectly, can even lose that information among the ever-growing amount of context it's handling, or simply finds another way to achieve what it was trying to do.

And that last one isn't theoretical.

While experimenting with all this, I configured a mini PC with Ubuntu to run a model's CLI. I removed the rm command from the system so it wouldn't be able to delete anything.

Then one day I discovered that it had deleted files. How? I couldn't believe it. I asked, and it explained that since rm didn't work, it had used rsync --delete.

I was surprised and scared at the same time.

I had prevented it from using rm. And even though I had explicitly told it never to delete a file without my approval, at one point it realized it had made a mistake and needed to rebuild a structure, so it decided it needed to delete things. It interpreted my prohibition as meaning it shouldn't delete anything critical and that, given the context it had, it could decide that deleting those files wasn't going to cause any problem. After all, it was code that hadn't existed before and that it had created itself, right?

It disobeyed an instruction in order to achieve its goal.

That's why important restrictions have to live outside the agent, in mechanisms it doesn't control. Hooks. CI. Permissions. Tests. Mutation tests. Policies. Gates...

If I want every change to have tests, I can tell it to do TDD. But I also have to verify that those tests exist, that they run and that they actually pass.

If I don't want any change to get in without review, I can't let the same agent decide that “this time” the review isn't necessary.

If I want a security vulnerability to block a change, no second agent should be able to casually decide “well, it doesn't look that serious”.

If I want all work to be traceable, it can't depend on an agent remembering to create a ticket afterwards.

Important rules have to become mechanisms.

Not good intentions.

The agent can decide how to solve the problem. What it shouldn't be able to decide is whether it can bypass the mechanisms that determine whether that solution is acceptable.

Orchestrating isn't governing

And here I think we're usually mixing two different problems.

One is how we orchestrate agents. Who writes. Who researches. Who reviews. How we share context. How several agents work in parallel. Which model we choose for each task.

We can have one writing, another from a different family reviewing, and a third arbitrating when they disagree. We can even launch the same task to several models and then choose between the solutions that satisfy our conditions.

This already looks much more like building an artificial team than using a programming assistant.

But there's another different problem: who governs those agents?

Who establishes the rules? Who decides which actions are allowed? Who checks that they were actually followed? Who prevents an agent from granting itself an exception?

Orchestration gives capability.

Governance gives guarantees.

And we need both.

What about specs?

For a while it seemed that the answer to AI development was the prompt engineer.

It lasted months.

Then the idea emerged that development with agents was going to be about writing better specs. Right?

If the AI made mistakes, it was because we hadn't specified clearly enough what we wanted. So we started writing increasingly detailed documents explaining which endpoints to create, which classes to use, which structure to follow, which cases to handle...

I think that's also starting to become “the past”.

If today I tell a good frontier model “build me a REST API to access my recipe database”, and it has access to the repository, the database and the project context, I don't need to explain that I probably need to list recipes, retrieve one, create one, modify one or delete one, or how to do any of that.

It will explore. It will understand the schema. It will look at how the rest of the project is built, its stack, its style, the conventions we use, even previous conversations we've had, and it can make many of those decisions by itself surprisingly well.

If I've also told it that we work with TDD, that APIs must be documented and that it should generate a Postman collection, I don't have to repeat that in every request either.

But, and here we go back to the beginning of the article, telling it something is one thing and guaranteeing that it does it is another.

Instructions guide.

The environment governs.

That changes where we put our effort again.

I don't need to translate my need into an almost technical specification first so that the AI can then translate that specification into code.

I can express the intention at the highest possible level, my need, my desire, my idea, nothing more: “I want to access my recipes through a REST API”.

It's practically the same thing I do as a manager when I ask a senior engineer. I don't have to specify the details, because they know how we work, they know the conventions, the rules and the context.

The detailed spec was, in a way, another layer of human translation between the idea and the code. And AI is starting to eat that layer too.

What doesn't disappear, and actually becomes more important, are the rules, the constraints and the definition of what really matters.

Are we moving to RDD? Rules-Driven Development? Are they going to start selling us courses on how to govern agents?

Of course 😝

Jokes aside, one thing is telling the agent exactly how to build the solution, which is something I don't do with a senior engineer either, and another very different thing is giving it enough context to make good decisions. A senior engineer can work from a high-level request because they know the domain, understand the product, know how the team works and have references they can use to compare their decisions. And if they don't know something, they know where to look or who to ask.

The same should happen with an agent. If it has access to the domain, the code, the documentation, previous decisions, examples and the team's rules, I increasingly need less to turn my need into a detailed implementation spec.

What is still necessary is defining the conditions that any solution must satisfy. Those can live in team agreements, a playbook, a developer kit, ADRs, architecture rules, security criteria or verification mechanisms.

Fewer specs doesn't mean less context. It means stopping using the spec as a manual translation layer between the need and the implementation.

That's where we're getting to, if we're not already there.

Less implementation specification. More intention. More available context. More mechanisms around it.

Governance also has a cost

But here's another problem I don't think we've solved yet.

Guardrails work, but many times they work after the agent has already smashed into them.

It already happens to me.

One of my rules may say that I don't want PRs larger than 200 lines.

The agent knows it.

And even so, far too often, it ends up trying to create a PR with more than 200 lines.

The hook blocks it.

Perfect.

Governance worked.

But now the agent has to go back. Redo part of the work. Split it. Maybe create another file. Reorganize imports. Divide the PR. Run things again.

And all of that consumes tokens.

A lot of them.

The final result may comply perfectly with the rules, but we got there in an obviously inefficient way.

The system is safe, but the agent has been banging its head against the walls until it found the right path.

And this happens because the rules that live in the model's context don't have the same weight as the real restrictions that live outside it. The model may “know” that a rule exists and still forget it during execution.

I use tools to try to reduce token consumption, such as RTK or Squeezr, but you're only optimizing one part of the problem.

The underlying problem is still there.

Building better guardrails isn't enough. We need agents to get better at understanding and maintaining those constraints throughout the work so they don't waste time, tokens and money attempting solutions that we already know the system is going to reject.

I think this is one of the areas where companies building models and agents have a huge amount of room for improvement.

Because fully delegating development doesn't just require the result to be correct.

Getting there also has to be reasonably efficient.

Do we have to do everything with frontier models?

And this efficiency problem leads me to something else.

If we're going to have agents working, reviewing, arbitrating, retrying after hitting a guardrail and handling increasingly large amounts of context, always using the most powerful frontier model for absolutely everything doesn't seem particularly smart either.

Or cheap.

I think companies should seriously start considering running their own models in their infrastructure too.

And individuals as well.

Not necessarily to replace Claude, Codex or whatever frontier model happens to be the one next week. But to complement them.

There are tasks a local model can do well enough. Repetitive tasks. Classification. Context retrieval. Some reviews. Simple generation. Work involving code that, for security reasons, you don't want leaving your infrastructure.

And when the task requires more capability, when the local model can't handle it, when it gets stuck or when you need someone to come to the rescue, you escalate to a frontier model.

Just as I wouldn't put my best engineer on absolutely every task in the team simply because they're the best engineer.

We have to find the balance.

Which model we use for what. What stays inside. What goes outside. When it's worth paying more and when a smaller model is enough.

And this reinforces again the idea that we're not heading towards “using an AI”.

We're heading towards building teams of AIs, each one doing what makes the most sense for it, under a common set of rules that none of them controls.

How do I see this governance?

After thinking about it a lot, experimenting and taking a few hits along the way, I more or less know what my ideal framework looks like for developing software with AI without having to blindly trust it, but still having enough governance guarantees.

I want to start by telling the model what I'm trying to do, at the highest level possible. My need, my idea, the problem I want to solve. Sometimes I may even give it a pile of documents that have been written about the idea, for example, a role-playing game with its rules, its objective, its cards... And once I give it that high-level instruction and some details, I want it to generate a first plan.

That plan I do want to review. Me as an engineer, other engineers if necessary, or even other agents from different families that challenge it, look for problems, suggest alternatives and debate the decisions with it.

Once the plan is approved, I want the system itself to turn it into an actual working plan. Epics. Tasks. Dependencies. Estimates. Acceptance tests. Everything initially generated by AI, but something we can discuss, correct and complete with it before starting.

In other words, I don't want to write a huge spec myself telling it how to do things. I want to express what I need and discuss with the AI the plan it proposes to achieve it.

And once that plan is approved, then yes, let the machinery start.

Let an orchestration of agents pick up the tasks. Let them architect when architecture is needed. Let them code. Let other agents review. Let them debate when they disagree. Let us pit several models against the same problem and run tournaments if it makes sense. Let there be specific security reviews. Let tests, mutation tests, static analysis, SonarQube or SonarCloud, linters and all the tooling we consider necessary run.

But all of that inside an environment that doesn't depend on the agent remembering our rules.

Pre-commit and pre-push hooks. CI gates. Permissions. Real limits. Policies that prevent certain things from happening even if the agent wants to do them.

The agent can decide how to get there.

The system decides where it is allowed to go.

And I want incremental updates on every merge to main to keep the codebase RAG up to date, plus a full reindex on every release so that when we deploy software, the system's own knowledge is refreshed as well. And also update the wiki and the documentation so that the next agent that arrives isn't working from how the system looked three months ago, but from how it looks now.

And that RAG, that wiki, that task board, all of it should be inspectable by the engineer, so it can be corrected or understood.

For me, that's the framework.

Human intention. A generated and debated plan. Decomposed and verifiable work. Teams of specialized agents executing it. Other agents reviewing and challenging it. Deterministic tools checking it. External guardrails preventing them from stepping outside the rules. And knowledge updated after every change.

Not trusting that the agent will do it right.

Building an environment where it's very difficult for it to do it wrong and even harder for an error to reach production.

And even then, it will make mistakes.

That's why we need to build a governance system for our agents.

The compiler from decades ago

Today's AI still isn't that modern compiler we trust without practically ever looking at what it generates.

It's more like the compiler from decades ago. Good enough to change the profession. Not good enough to blindly trust.

And that's precisely why I think we're making a mistake when we conclude that we should keep manually reviewing every line.

The answer should be something else: learning to build better systems around it.

Systems that limit. And verify. And block. That allow mistakes without causing a disaster.

But also systems that are efficient and don't force the agent to discover the rules by smashing into them again and again.

Because the goal shouldn't be to make AI never make mistakes.

We can't even achieve that with humans. I wish.

The goal should be that when it makes a mistake, the system detects it before it matters. And, if possible, before it burns through a few million tokens discovering it.

And even if we solved all of this, we'd still be left with probably the hardest problem.

Getting an engineer to actually want to work this way.

Because changing the tools is one thing.

And telling someone who has spent years programming that part of what defines their profession, and something they probably love doing, is no longer going to be done by them is something very different.

And CI doesn't fix that.

This new path has to be led.

The Shifting Role of the Software Engineer

Mánu Fosela — Tue, 11 Aug 2026 09:43:26 +0000

This is the first of three articles about how I see AI adoption in software development within companies and how I'm pushing it forward at TRIBBU, my company.

First, I want to talk about the change itself: what's happening to our work and why I think we're facing a change in the level of abstraction. In the second one I'll talk about how we can govern software development carried out by agents. And in the third, probably the most complicated one, about how to lead people through this transition.

Because technology will probably be the easy part.

We're living through a “turbulent” yet exciting period with the arrival of what we somewhat incorrectly call artificial intelligence into our lives.

Although I think software development is where its adoption has gone deepest, little by little it's making its way into every discipline and more and more people are using it to make their day-to-day work easier and better.

It's true that some people use it to do their work for them. Often badly, especially when that work requires judgment.

And it's also true that if an AI can do your work because that work doesn't require judgment, then your job will, sooner or later, be replaced by AI.

But that's not what I want to talk about.

I want to focus on how to lead the transition towards software development with AI inside companies.

And here I see two different problems.

One is how to “evangelize”, more than convince, how to get them to convince themselves, to “convert”, and get developers to see the enormous benefits it can bring, leaving behind bad past experiences caused by using it without judgment or knowledge.

The other one, much more complicated in my opinion, is how to do it well.

Because right now there's a lot of ignorance, very little accumulated experience and, above all, a huge disparity of opinion about how far we're willing to stop doing what until now we considered our job: writing code.

I'm going to address both problems, but I want to start with the how.

Because I think that if we can answer the how properly, solving the first problem will be much easier.

It will be easier for a programmer to accept delegating an increasing part of their work to an AI if they can trust the system through which they do it.

Because let's not fool ourselves: feeling that something artificial is beginning to do what you've spent years doing, what you're good at and, even worse, what you probably love doing, is hard. Very hard.

But denying the evidence, what's happening, won't make it stop happening. Let's not be like little children who cover their faces and think nobody can see them.

And let's be aware that an AI-native generation is taking shape, and we are responsible for training and educating it.

This generation won't be made up of developers who first learned to program and then incorporated AI into their work. That's us.

They will learn to develop with it from day one.

And those who don't adapt will be overtaken, much sooner than we think.

When Was the Last Time You Looked at Assembly?

Let me start with a question, and I hope the metaphor and the distance between the two things are clear.

When was the last time you looked at the assembly generated by your compiler to check that it was managing registers, memory or loop efficiency properly?

Probably never.

And yet there was an entire generation of programmers who did. Who had to.

Because early compilers generated worse code than a good assembly programmer could write. Trusting them blindly was simply reckless.

Those programmers were right at that moment.

The ones who were wrong were those who turned that temporary distrust into a permanent identity.

Those who ten years later were still arguing that a good programmer had to write assembly while the rest of the world had moved up one level of abstraction.

I think we're already inside that same kind of moment with generative AI.

I'm not saying it's exactly the same.

In fact, there are huge differences, as I said at the beginning.

But conceptually, I see that we're facing another leap in abstraction.

Until now we've been incorporating tools that helped us program. Editors. IDEs. Autocomplete. Frameworks. Stack Overflow. Copilot...

All of them, in one way or another, allowed us to write code more easily or more quickly, with fewer errors or by failing earlier.

But we were still writing the code.

With agents, something different is starting to happen. More and more, we're moving away from saying “I want to write this code” and starting to say “I want this to happen”.

This changes absolutely everything.

Because the leap we're trying to make isn't simply from one tool to another, no. We're moving, with all the obvious differences, from assembly to the compiler, except this time the leap is several orders of magnitude bigger. An exponential leap.

A compiler receives high-level code and generates low-level code. And yes, I know, following deterministic rules and within a bounded space. True. That's why I call it an exponential leap, because we're moving into an enormously more open space.

But we're getting an AI to receive an idea, a need, a specification, some constraints or a conversation and produce software.

And as I've already said, there's vastly more space between one thing and the other, and therefore vastly more things that can go wrong.

And this is precisely one of the big differences compared with a compiler. A compiler is deterministic and verifiable. An agent isn't. It can make mistakes in subtle, plausible and difficult-to-detect ways.

And the skeptic who says that the verification problem hasn't been solved is right. It hasn't.

That's why I'm not saying that we can stop verifying what AI does. I'm saying that verifying it by reading every single line it generates can't be the solution either.

We Get Carried Away With AI

At first the experience is spectacular. You ask it for a function. It does it.

You ask it for an endpoint. Same thing.

You explain a small feature and it changes four files, creates the tests and apparently everything works.

And you think: “Holy shit.”

Then you take another step. You give it something bigger. It starts touching things. Changes others. Interprets something differently from what you expected. Suddenly something doesn't add up. You tell it to fix it. It fixes that and breaks something else. You explain the new problem. It tries again. And shortly afterwards you have a mountain of useless, incomprehensible, unfixable and unmaintainable code.

And you don't even really know when exactly it started fucking everything up.

That's when a phrase we've heard quite a lot appears:

“That's where you can tell whether you really know the fundamentals. If you know how things work, you can review what the AI has done and fix it.” Well, yes. Up to a point.

Because let's be honest. There comes a point where not even Uncle Bob would understand a fucking thing about what it has done.

And, besides, there's a much more important problem.

If an AI can produce code much faster than I can read it, trying to control that AI by reading everything it generates simply doesn't scale.

Some people talk about knowledge debt. But I don't think that's quite it. I think we're mixing two different things.

It's like accepting the compiler but insisting on reviewing all the assembly it generates afterwards. It makes no sense. Especially with today's processors, whose assembly code very few humans are capable of understanding.

Or, at least, it can't be the final solution.

The fact that reviewing the code no longer scales doesn't mean the verification problem has been solved. It means exactly the opposite: we need another way to solve it.

Even more so as agents keep getting better and we give them more and more autonomy.

We need rules. A harness. Guardrails. External mechanisms that the agent doesn't control and that allow us to let it work without constantly looking over its shoulder.

Not to tell it exactly how it has to do things. We don't need that anymore. We need to set the limits, prevent certain actions and check that what it delivers meets what we expect.

But I'll talk about that in the second part.

Having the Tool Doesn't Mean Getting Value From It

And here another confusion appears that I see quite often.

Having access to a tool is one thing and knowing how to get value from it is something very different.

Today practically anyone can open ChatGPT, Claude, Copilot or any other agent and ask it to build something.

That doesn't mean anyone can build a good product.

In the same way that having an IDE doesn't make you a developer, having an AI capable of writing code doesn't automatically make you capable of creating software that delivers value.

If writing code had really been the only barrier to creating good products, by now we should be seeing a massive explosion of disruptive applications.

And I honestly don't see it.

What I do see is a lot of vibe coders paying for advertising to try to sell, again and again, variations of the same worn-out product.

Because code was never the product. The user doesn't want or need our code.

They don't want our hexagonal architecture, our patterns, our framework or to know whether we use microservices or monoliths.

They want to solve a problem.

Code was, and still is, the means to achieve that. Or one of them.

The difference is that this means has just become dramatically cheaper and more democratized.

AI is making it extraordinarily cheap to plant software (a brilliant analogy from the great eduferro).

But planting isn't the same as having a good garden.

Someone still has to decide what to plant, when to plant it and what for. Then it has to be watered, pruned, fertilized, whatever no longer serves a purpose has to be removed, and it has to be adapted when conditions change.

Because software isn't something you build and finish. It's a living thing that evolves, and neglecting it is a great way to end up with a garden bed full of shit.

Someone has to understand the problem. Know what's worth doing and what isn't. Choose between alternatives. Prioritize. Make decisions with incomplete information. Validate. Change their mind and iterate.

And, above all, have judgment to know whether what we've created actually delivers any value.

The barrier to creating software is falling.

The barrier to creating value, not necessarily.

Our Work Is Shifting

That's why I don't think the conclusion is that AI is going to replace software development.

I think our work is shifting, because that work, as it exists today, will be replaced.

One level up.

If before we spent a large part of our effort telling a machine how it had to do something through a programming language, increasingly we'll spend more effort defining what should happen, why, under what conditions and how we can know whether the result is correct.

That requires judgment.

Probably much more than we needed to implement many of the tasks we do today.

And this, for me, is where the truly important change lies.

We're not stopping developing software.

We're starting to stop being necessarily the ones who write every single line of it.

And the Window Won't Stay Open Forever

Every change in abstraction level opens a window of opportunity.

It happened with version control, for example. With CI. With cloud. With infrastructure as code.

For a while, those who adopted it well had a huge advantage over those who said: “We're fine like this.”

Then it stopped being an advantage. It simply became the normal way of working.

I think we're in one of those windows now.

Except this time everything is happening much faster.

Not adapting doesn't mean standing still. It means falling behind.

Because while you keep working the same way, the bar for what we consider normal productivity keeps moving, but this time at a speed that makes it increasingly difficult to jump onto the train once it's already moving.

Today, knowing how to work well with agents is a competitive advantage. Tomorrow it will simply be part of the job.

But as I said before, first we have to solve an important problem, because if we're not going to review every single line produced by an AI...

how the hell do we know whether what it has done is actually right?

That's what the second part will be about.

Karajan v3.0.0: a local-first multi-agent orchestrator that conducts AI CLIs like an orchestra

Mánu Fosela — Wed, 03 Jun 2026 22:46:30 +0000

karajan-code@3.0.0 is on npm. nvm install 22.22.1 && npm i -g karajan-code@3 and you're done.

Why I built Karajan

I love coding with AI. What I don't love is babysitting it.

If you've spent any time with Claude Code, Codex, or Gemini, you know the loop:

You describe what you want.
You watch the model work.
You catch it skipping tests, hallucinating an API, or touching the wrong layer, even with a solid CLAUDE.md/AGENTS.md and SKILLs in place.
You stop it, correct it, relaunch it.
Repeat.

Fine for a one-off change. Doesn't scale to a real project with a known plan, real tests, and a real quality gate. You end up being the human stuck in the middle of an async loop you can't pause, retry, or measure.

I wanted something different. A tool where I describe what I want once and, from there, a set of AI agents (a coder, a reviewer, a tester, a SonarQube gate, a security auditor) run the loop themselves and ping me when it's done. Reproducibly. Locally. Using the subscriptions I already pay for.

That tool is Karajan.

The name is a nod to Herbert von Karajan, the conductor who never played a single instrument but imposed a unified vision on dozens of musicians until they sounded like one. Karajan didn't replace the musicians: he coordinated them under a single guiding intent. Karajan Code does the same with your AI agents: none of them is in charge, all of them converge under a single baton that arbitrates and unifies.

What Karajan actually is

Karajan is a local-first multi-agent orchestrator written in vanilla JavaScript on Node 22.

You describe a task (in a markdown file, a user story, or directly on the command line) and Karajan runs a role-based pipeline over it:

task
  → triage      (classifies complexity, decides route)
  → researcher  (reads existing code)
  → architect   (designs the change)
  → planner     (breaks it into steps)
  → coder       (writes code and tests)
  → SonarQube   (static analysis as a gate)
  → tester      (runs the real test suite)
  → reviewer    (independent agent reviews the diff)
  → security    (security pass)
  → commiter    (commit, push, opens PR)

Each role is a CLI agent. The coder can be Claude, the reviewer can be Codex, the tester can be Aider. Karajan doesn't call /v1/messages: it spawns claude -p, codex, gemini, aider, opencode as child processes and reads their stdout/stderr. That single architectural decision unlocks two things:

Zero API cost. Your existing Pro / Plus / Max subscriptions do the work. No new bills.
Multi-provider routing. A powerful coder + a strict reviewer + a cheap triage agent = the right model for each role, with automatic fallback when one hits its quota.

The whole system is TDD-first by default. The coder writes tests alongside the code, the tester runs them for real, the reviewer sees the diff. If something fails, the reviewer feeds back to the coder and the loop iterates, bounded by maxIterations and maxIterationMinutes so it can't spiral.

A few more pieces worth knowing:

MCP server. Karajan ships as an MCP server, so you can drive the full pipeline from inside Claude Code, Cursor, Codex, or any MCP host. kj_run, kj_plan, kj_code, kj_review, kj_audit, kj_rag_query: full pipeline access without leaving the conversation.
Solomon, the AI judge. An independent role the Brain orchestrator consults when there's a real dilemma (security vs. deadline, two reviewers disagreeing). Not on every loop; only when the Brain can't decide deterministically.
Story Board. A small local web dashboard at http://localhost:4000 showing every user story, every session, every plan, every RAG metric. The single source of truth for the team.
Local RAG. Each project gets its own embedded code index (~/.karajan/rag.db). The pipeline retrieves real code before planning, so the architect sees what already exists. Six embedding providers (Ollama, OpenAI, Voyage, Cohere, Mistral, local ONNX). Tree-sitter-based chunkers for JS, TS, Python, Rust, Go, and Java.
kj audit. A deterministic-first audit command: dead code, unused dependencies, complexity growth, security findings (OSV, Semgrep, SonarQube), accessibility hints, Web Performance budgets, and an AI Harness Scorecard run via Docker that gives an objective 0-100 score for "how AI-friendly is this repo right now." Keeps a per-project history and draws sparkline trends.

What v3.0.0 brings

v3.0.0 is a runtime alignment, not a feature drop.

Node 20 hit EOL on 2026-04-30. The Active LTS line is Node 22. Three of Karajan's dependencies independently bumped to majors requiring Node 22+: lint-staged 17, commander 15, and better-sqlite3 12.10. Rather than publishing four staggered minors patching each constraint separately, v3.0.0 bundles the runtime bump with the dep majors that depend on it.

Migration is a single command:

nvm install 22.22.1 && nvm use 22.22.1
npm install -g karajan-code@3
kj doctor    # checks runtime + HW + tooling

If you were already on Node 22+ and your ~/.karajan/ works, nothing changes. No public API changes: kj run, kj plan, MCP tools, role templates, RAG, Story Board, audit, telemetry, all intact. Existing sessions, plans, RAG index, and audit history are forward-compatible; nothing to migrate by hand.

Why a major with no API changes?

Semver. Bumping the minimum Node version is a breaking change for downstream consumers: an install that worked on Node 20 now hard-fails. That alone qualifies, and the three dep majors on board each qualify on their own semver. Cutting a single v3.0.0 surfaces the runtime change once instead of four times.

The release also brings documentation polish: a new footprint and hardware requirements section in the README so you know what you're getting into before installing. kj itself is 5.2 MB on npm and ~/.karajan/ runs around 40 MB. Ollama (optional, 6.55 GB), SonarQube (optional, 1.47 GB), and the qmd cache (optional, ~2.2 GB) are the heavy optional layers. Three profiles: Minimal ~250 MB, Recommended ~8.5 GB, Full ~11 GB.

v1 to v3: how Karajan grew

Karajan didn't start as a multi-agent orchestrator. It started as a shell script.

v0.x: One script. task → claude → diff → codex review → done. Hardcoded to two agents. No retry, no cost tracking, no SonarQube, no test integration. It worked, roughly, on a Tuesday afternoon.
v1.0 to v1.1: Quality gates and roles. SonarQube became a mandatory step between coder and reviewer. The TDD policy meant any code change required a test change. Then the monolithic script became a role-based pipeline: BaseRole, BaseAgent, 12 configurable roles, review profiles, Solomon escalation, budget tracking.
v1.2 to v1.3: MCP server and extensibility. The MCP server made Karajan callable from inside any MCP-speaking AI agent. The plugin system let users wrap their own CLIs as Karajan agents without forking. Planning Game integration connected the pipeline to project management. Git automation closed the loop with auto-commit, auto-PR, auto-rebase.
v1.4 to v1.7: Resilience. Rate-limit detection across all supported CLIs. Automatic fallback when the primary coder hits its quota. Smart model selection mapping triage complexity to model tier (trivial → Haiku, complex → Opus). Interactive checkpoints replacing the brittle hard timeout. In-process MCP execution so subprocess SIGKILLs stopped killing agents mid-work.
v1.40 to v1.46: Sovereignty, OpenSkills, parallel stories. The pipeline learned to defend its own decisions against host AI overrides (pipeline sovereignty guard). OpenSkills brought domain knowledge to coders, reviewers, and architects. Parallel user stories ran independent stories concurrently in git worktrees. First SEA binaries appeared: kj running without Node installed.
v1.50 to v1.58: Telemetry, domain knowledge, i18n, WebPerf. Telemetry (opt-out, no code or personal data) to finally measure what was happening. Domain knowledge files (DOMAIN.md) injecting business context into every role. i18n letting the pipeline speak EN or ES end to end. Web Performance as a first-class quality gate (Core Web Vitals via Chrome DevTools MCP, inspired by Joan Leon's WebPerf Snippets).
v2.0: Karajan Brain. A central AI orchestrator deciding routing, enriching feedback, suggesting direct actions, and compressing outputs between roles. Solomon moved from "every loop" to "real dilemmas only." Tester and security became blocking gates. The proxy subsystem (which never worked well under SSE/WebSockets) was dropped in favor of RTK for token savings.
v2.x: The "I use this daily" phase. Too many releases to list, but the highlights: stack-aware audit (v2.9.0), Docker/shell installer (v2.10.0), Story Board hardening (v2.13.0), plan adherence scoring + golden tasks (v2.12.0), shared team Story Board (v2.31.0), editable config UI (v2.30.0), multi-language RAG with AST chunkers for Python/Rust/Go/Java (v2.34.0), retrieval quality harness (kj rag eval, v2.34.0), and the AI Harness Scorecard golden metric integrated into kj audit (v2.32.0-v2.33.0).
v3.0.0: Runtime alignment. No new features. Node 22 baseline, three dep majors, one migration command, zero public API change. The story of "boring releases that buy you a year of headroom."

That arc, compressed: a shell script → a role-based pipeline → an orchestrator with a brain → a local-first, MCP-driven, RAG-powered, multilingual, multi-provider, test-first team tool. The same idea throughout: many different AI agents, one baton that makes them converge.

Getting started

Install:

nvm install 22.22.1 && nvm use 22.22.1
npm install -g karajan-code@3

Smoke test:

kj --version           # 3.0.0
kj doctor              # checks Node, agents, Docker, SonarQube, RAG...

Initialize a project:

cd your-repo
kj init                # autodetects stack, suggests agents, scaffolds .karajan/

Run a task:

kj run "Add a /healthz endpoint with a unit test that returns 200" \
  --coder claude --reviewer codex

Or from inside Claude Code / Cursor / any MCP host, just call kj_run.

Open the Story Board:

kj board start         # http://localhost:4000

That's the loop. Describe what you want. Let the orchestra play.

Where to find it

npm: karajan-code
Docs: https://karajancode.com/docs
Repo: github.com/manufosela/karajan-code
License: AGPL-3.0
Author: @manufosela, built in the open.

If you try it and something surprises you (good or bad), I want to know. Open an issue, reach out on GitHub, or reply here.

I’ve tried RTK and it saves a lot of tokens, but I think Squeezr is on another level.

Mánu Fosela — Sun, 05 Apr 2026 16:37:21 +0000

Sergio Ramos Vicente

Apr 5

I was burning through AI tokens without realizing it. Here's how I fixed it.

#ai #tooling #opensource #claude

3 min read

Over-Architecting in Web Design

Mánu Fosela — Thu, 10 Oct 2024 05:01:23 +0000

I recently read a post by @justinfagnani on X that says:

"Lit is not a framework. The browser is the framework."

This got me thinking about how we've been building for the web in recent years.

For quite some time now, if you know HTML, CSS, and JavaScript, you really don’t need a framework to build web applications. At most, you might use some libraries to simplify certain tasks, but even these are gradually being incorporated into the platform itself, like routing or state management.

Our focus, however, has shifted towards learning frameworks, and now meta-frameworks, which do make it easier to build web environments. They optimize pages, automatically generate necessary files like sitemaps.xml, optimize images, remove unused CSS, bundle, minify, and optimize JavaScript. They’re effective, yes. But they don't adhere to the standard.

Meta-frameworks like Astro let you use standards, but they don’t exactly make it easy. Instead, they streamline using other frameworks or their own components in a more user-friendly, non-standard format to "simplify" component creation. They also employ techniques to facilitate SEO, loading, and indexing—depending on how you’ve implemented them.

To me, this approach has two major issues:

Cognitive overload: Developers must learn to manage not only the framework itself but now also the meta-framework and its set of tools, which often adds unnecessary complexity to project architecture.
Detachment from the standard: Focusing on frameworks means we’re not investing time in understanding the latest developments in the web itself, which are substantial. CSS, for example, is making a huge leap forward with features like container queries. Meanwhile, JavaScript and HTML are also evolving, with HTML potentially introducing a new <select> element that will allow HTML and CSS within <option>, opening new and more flexible ways to create rich selectors.

In many frameworks, though, these innovations are implemented through their own components, so to developers, it can seem like these new features are framework inventions instead of standard advancements.

I remember a few years ago, when these meta-frameworks were just emerging, a developer excitedly told me, “They’ve invented SSR (Server-Side Rendering); now we can generate HTML on the server, creating static pages.” I looked at him in surprise. He insisted, thinking I was just as impressed with this “novelty” saying, “Isn’t it incredible? What a fantastic idea.” The irony was that SSR has been around since the early days of the web.

Today’s web developers, those studying web development and entering the field, often lack historical context. They don’t know how web development originally worked. They don’t understand the reasons we moved from server-side rendering to client-side rendering and started using frameworks. Somewhere along the line, when “Ajax” gained popularity, we lost our way—probably driven by the desire for standards to cover everything we needed, while big companies fought to impose their own criteria, tags, and languages in the browser (I still remember Microsoft’s infamous VisualBasicScript).

Frameworks aren’t the problem. Not at all. They added power and value to web development. They allowed us to create applications for everyone, spurring the rise of hundreds of thousands of web developers and bootcamps.

Frameworks and meta-frameworks aren’t the issue; they even helped democratize web development, enabling millions to create applications and fueling the bootcamp boom. But as the web platform matures and standards become more robust, framework creators have business incentives to retain and promote their tools. They’re not going to say, “Stop using my framework; you can do everything with standards now.” Plus, migrating applications built with these frameworks to the standard is nearly impossible, especially since, in my experience, most lack E2E or functional tests to ensure that migration maintains the original behavior.

So, why aren’t we investing in tools that help us leverage today’s standards?

There isn’t a meta-framework that “forces” you to use the standard, making it easier in the process.

We need solutions that help us organize our projects efficiently and assist with build and optimization tasks if we want to do SSR, CSR, SSG, ISR, Hydration, create MPAs or SPAs. But we should be fully aware of our needs and the pros and cons of each choice. These tools should optimize images, JavaScript, CSS, and generate only the necessary files. They should allow the use of libraries that stick to the standard and adequately cover the platform’s remaining gaps. They should optimize and support SEO, loading, and indexing, facilitate testing, and harness the platform’s power.

It’s time to reduce over-engineering and excessive architectural design in our web projects. Let’s keep learning, not just how to use a framework, but also how to appreciate and apply the incredible advancements in web standards.

No excuses.

Desarrollo Web y Web Components

Mánu Fosela — Tue, 29 Dec 2020 01:04:19 +0000

Disclaimer

Lo que vierto en este post es mi opinión. Mi punto de vista. Mi percepción. Desde mi experiencia y mis sesgos. Y sobre todo desde mi ignorancia en muchos campos.

Sobre mi y mis inicios como desarrollador

Llevo programando para la web desde 1997.
A parte de HTML, CSS y Javascript, he pasado por varios lenguajes: CGIs en C, ASP, JSP, PHP, Java, Perl y Ruby si no recuerdo mal. Algunos durante unos meses otros durante años.
He trabajado con bases de datos MSSQL, MySQL, Oracle, IBMDb2 y MongoDB.
Y he trabajado con servidores IIS, Apache, Tomcat y Nginx.
Desde siempre Windows (era un mal necesario) y Linux (era un suplicio a principios de siglo)

He visto cómo hemos pasado de que un desarrollador/equipo web fuera responsable de todo a la especialización más exquisita.
Aprendí a hacer testing, TDD, metodología XP y pair programing en 2007. Hacia 2008 con el boom de Javascript y Jquery, empecé a especializarme más en Javascript, aunque no fue hasta 2010 cuando pasé a ser “oficialmente” FrontEnd Developer, a pesar de que mis dotes de diseño dejan mucho que desear.
Y dejé de tocar la parte back y configuración de servidores. Dejé de subir a producción por FTP y empecé a usar control de versiones con CVS y Subversion.

Luego empezaron a aparecer librerías como Backbone y arrancó el boom de los frameworks del front, las llamadas AJAX y el desarrollo de APIs que alimentaban esos frontales “mágicos”

Por cierto, AJAX empecé a usarlo hacia 2007 cuando existía ¡¡desde 2002!! Y yo usando iframes ocultos, leyendo información y cargándola en la página principal, una “guarrada”... pero es que antes era otra epoca ;)

En 2015 me enganché a los web-components, con Polymer en su versión 0.8 y a la espera de que los ansiados estándares vieran su primera versión que no llegó hasta 3 años después.
Y aunque siempre he probado, y hecho alguna aplicación que otra, en todos los frameworks típicos, nunca me han entusiasmado en exceso.
Sí. Mola. Facilitan. Ahorran tiempo (una vez les coges el punto). Unifican los grandes desarrollos. La curva de aprendizaje puede venir hecha al incorporarte a un equipo. Y sobre todo hacen mucha “magia” que se puede traducir en desarrollo mas rápido y menos dolores de cabeza, pero ¿necesitaba usarlos?

Empiezo la polémica

Creo que en los proyectos grandes donde he trabajado, o he visto trabajar desde que ejerzo como manager, está plenamente justificado el uso de un framework, pero ¿Y en un blog? ¿Y en una web de contenidos? ¿Y en algunos juegos? En internet veo muchas webs que son contenidos y creo que no necesitan un framework para desarrollarlas.

¿Que se pueden usar frameworks? Correcto. ¿Que no penaliza? Bueno, depende. A nivel de lo que es una página web, solo hace falta hacer “botón derecho” (lo siento no uso Mac), “ver código fuente de la página” y ver en dicho código fuente “atrocidades” que ni DreamWeaver en sus mejores momentos…
Porque o bien no hay contenido, ya que se genera dinámicamente, y por tanto es contenido invisible a los crawlers de los buscadores, o bien lo que se escupe aparece “ofuscado”, cuando una web de contenido, justo lo que se tiene que leer perfectamente es el contenido, con sus tags HTML, usando la semántica de las etiquetas HTML (cuantos años luché al principio por una web Semántica)
O eso creí entender allá por 1997 cuando leí mi primer libro de HTML.

Y lo de que no es necesario usar un framework para generar contenido como un blog parece que se están dando cuenta la comunidad.
Por eso ¿Qué está pasando últimamente? Que alguien “descubre” el SSR (Server Side Rendering)
Y empiezan a aparecer frameworks sobre los frameworks para hacer lo que se hacía desde siempre, generar el contenido de la página desde en el servidor y que el navegador haga la petición y le envíe dicho contenido, eso sí, ahora usando toooooda la lógica del framework sobre otro framework. Volvemos a los inicios, pero complicándolo.
¿Por qué? Quizás porque lo no sabemos hacer de otra manera. Es lo que nos han enseñado.

Nos enseñan a usar algunas herramientas, pero no nos enseñan a pensar cuándo se deben usar dichas herramientas.
Como se suele decir: “Te enseñan a usar un martillo y todo son clavos”
¿Te enseñan el framework AcojoJS? Todo son aplicaciones con AcojoJS. Sin pararnos a pensar si es la solución idónea para nuestro problema. Funciona, ¿no?

Quizás porque no nos enseñan más.
Quizás porque no nos ponemos a pensar.
Quizás porque va todo tan deprisa que nos falta tiempo para aprender.

Porque aprendemos a usar un martillo, es decir a programar, y ¡ale! a clavar todo lo que pille, aunque sea un tornillo o un cristal.

Y es cierto. Aprendes lo suficiente para usar ese martillo con suficiente destreza. Pero nada más.
Aunque seamos conscientes de que la caja de herramientas es gigante y la cantidad de herramientas casi infinita, nos quedamos con nuestro martillo.

Pero sobre todo, creo que no se fomenta el buscar soluciones adecuadas a los problemas, si no a usar nuestra solución a cualquier problema.
Es decir, adaptamos problemas a nuestras soluciones, complicando más el problema.

Esto me pasó en uno de mis equipos, cuando nos plantearon un proyecto en el que teníamos vía libre para utilizar lo que quisiéramos. Greenfield Project lo llaman.
Pregunté:

¿Qué usamos? Todos al unísono:
Vue! Vue! Vue!

Mi pregunta era para implicar al equipo en el análisis del problema y buscar la solución adecuada, que facilitara el trabajo y la entrega a tiempo.
Pero mi sorpresa fue mayúscula cuando con un mínimo de información sobre el proyecto, todos pedían a Barrabás, en este caso Vuerrabás :P
Menos mal que en este caso no hice como Poncio Pilato, aunque si me lleve un Soponcio Parrato :P

Este es solo un claro ejemplo de a lo que nos conduce el mundo del desarrollo actual, del que me siento parte y responsable.

WebComponents

Y ya metidos en faena, quiero también reivindicar a los denostados, en algunos círculos, web-components estándar, incluidos en muchos frameworks, pero sin pertenecer a ninguno.

Y sobre todo quiero plantear mi disconformidad con el uso que se hace de ellos con el “Atomic Design”, es decir, crear componentes atómicos, que pueden usarse solos o como parte de un componente de orden superior, conocidos como “moléculas”. Y que estos últimos a la vez puedan conformar “organismos” de componentes…

No se. Me chirría. Siempre he visto los web-components como etiquetas HTML, como un <UL> o un <TABLE> o <DIV> solo que “haga más cosas”. Igual que crearon el tag <VIDEO>, que es realmente el concepto de un web-component aplicado: permite insertar vídeo en la web de manera sencilla, con su controlador del vídeo, la pantalla de vídeo, admitiendo diferentes formatos y fuentes…

Y veo bien web-components que aporten “cosas” que no hay. Un lector de QR. Un campo de formulario para votar con estrellas. Un reloj digital. Un calendario. Un menú. Hay mil ejemplos de necesidades.

¿Pero es un componente un ente formado por un <h1>, un <h2> y un <IMG> donde además ninguno de los 3 elementos tiene que aparecer siempre, pudiendo incluso llegar a ser solamente uno de ellos…?

El argumento suele ser “es que se repite”, “es que así es flexible”, “es que si no ¿cómo lo hacemos?”

Pues puede ser un componente web, cierto. Pero también puede no serlo. Si usas un framework quizás no te quede más remedio. O si no te han enseñado a cómo hacerlo sin que lo sea.

Bajo mi punto de vista, si usas web-components y estás generando páginas estáticas, aunque se alimente el contenido de una base de datos, al fin y al cabo, ese ente de <h1><h2><img> es simplemente una plantilla HTML.

Y puedo tener plantillas con combinaciones de esos 3 elementos, si realmente se llaman a todas las combinaciones de los mismos, porque si no, emplear tiempo en tenerlo “por si acaso” es tontería. Ese es otro de los grandes problemas del mundo del desarrollo que da para otro post.

Volviendo al problema planteado. Creo que siempre y cuando sean una simple presentación de tags HTML agrupados, sin ninguna funcionalidad, es una simple plantilla.
Si tuviera funcionalidad, entonces sí podría tener sentido que fuera un web-component. O si tuviera un diseño especial, que pueda chocar con el diseño global y necesite encapsular dicho diseño, también podría ser un web-component.

Es decir, creo que un web-component, la razón de crearlo es cuando:

Se puede reutilizar.
Tiene una presentación que no existe ya en un tag HTML
Tiene una funcionalidad que le da entidad y sentido.
Tiene una parte de su presentación/diseño abstraído del entorno donde se use.

Si no cumple alguno de esos puntos, debo analizar si realmente necesito diseñar un web-component o tengo alguna alternativa.

Y siguiendo esta premisa, por lo tanto para mi no tiene sentido un web-component no visual, que solo aporte funcionalidad, como a veces he visto los llamados “data managers”.

Para mi eso es un tag HTML que ya existe. Se llama <script>. Creo una “librería” con la funcionalidad que necesito. El API que he convenido. Y todo el que lo necesite lo usa. No veo la necesidad de hacerlo mediante un web-component.

Comunicación entre web-components.

Otra "unpopular opinion". Siempre se dice, yo de hecho lo he preguntado en alguna entrevista, ¿Cómo se comunican los componentes? Y quien se lo sabe, repite el mantra: “De padres a hijos mediante propiedades, de hijos a padres mediante eventos”

Bueno, desde el “Atomic Design” quizás ese mantra sí tiene sentido.
Pero si concibes los web-components cómo “tags” autónomos, que pueden convivir y estar anidados dentro de otros, pero independientes, la comunicación debería ser siempre mediante eventos. O mediante prospección.

O sea, aunque puede haber dependencias entre web-components, como la hay en un <table> con un <tr> y este con un <td> o un <ul> con un <li>. Pero realmente puedes usarlos por separado, aunque su funcionamiento no sea el esperado o no sea correcto.

Soy más partidario de un “Phenotypic Design” para los web-components. Es decir, diseñar los web-components basándonos en el conjunto de características visibles como resultado de la interacción entre su tipo y el medio.

Los tags HTML están clasificados por su tipo: Fundación, Formato, Formulario, Marco, Imagen, Audio, Enlace, Lista, Tabla, Estilo, Meta información y Programa.
¿Por qué no seguir esta clasificación y ampliarla para los web-components si es necesario?

Usando el concepto de “parientes” he visto siempre que ineludiblemente terminamos acoplando componentes padres, madres, hijos, sobrinas, abuelas y tíos todos entre sí, como buena familia. Pero ese no es el fin de los web-components, ya que solemos perder re-utilización fuera de la “familia”, creando verdaderas “mafias”.

Un web-component, por estar anidado dentro de otro no tiene porque crear una relación padre-hijo. Para mi tienen que crear una relación simbiótica. Y las hay de muchos tipos. Pueden ser un alga-hongo, creando un web-component de más valor. Árbol-ardilla, donde uno usa al otro para darle “cobijo”.
Creo que aporta una visión más amplia, menos limitante, donde es más fácil de mantener la individualidad, y por tanto la re-utilización de web-components en diferentes entornos, aplicaciones o webs.

Indexabilidad de los web-components

Otro tema que me ha preocupado siempre es que la encapsulación que hace el shadow DOM en los web-components que hace que su contenido no sea indexable y por tanto desaparece al darle a “ver código fuente de la página”, siendo invisible para los crawlers.

Pero esto creo que también es por un mal uso que le estamos dando a los web-components.

Si tengo por ejemplo un web-component de un menú de navegación, que al final puede ser un tag <nav> al que le hemos dado una funcionalidad especial en base a unos requisitos, incluso diferente en diferentes resoluciones pantalla, y al que le hemos dado un diseño concreto.
¿Por qué no utilizar el light-dom, es decir, el dom dentro del web-component, leer este en el ciclo de creación del mismo, y pintarlo conforme a los requisitos que necesitamos?
Estaríamos dando el contenido al crawler y encapsulando maquetación, diseño y funcionalidad. ¡Voila!

Porque otra aberración que veo bastante por ahí es pasar información a un web-component mediante un json ¡¡¡que insertamos como atributo!!!
¿Por qué no generar esa información en el light-dom con HTML semántico, indexable y accesible y luego “darle forma” en el web-component?

Es cierto que puede penalizar algo el tiempo de renderizado, pero no más si lo que tienes que leer es un json o una lista de elementos como atributo para pintarlos.
Y ademaś existen técnicas para poner un “loader” o añadir una animación de fade-in después del primer renderizado.

Por otro lado, si metemos el contenido del web-component en el light-dom, en el remoto caso de que no funcionara javascript, incluso podríamos asegurarnos de que la página tuviera contenido ya que el light-dom se renderiza, aunque probablemente se verá como “HTML feo” al no cargar el CSS de los componentes y no tener CSS para esos elementos HTML del light-dom.

Ejemplo de componente nav-list
En el repo de git se puede ver la evolución según versiones.

Mis conclusiones

No nos enseñan a buscar soluciones a los problemas, sino a usar las soluciones que conocemos ante cualquier problema.
Crear un web-component cuando:
- Se puede reutilizar.
- Tenga una presentación que no existe ya en un tag HTML
- Tenga una funcionalidad que le da entidad y sentido.
- Tenga necesidad de abstraer presentación/diseño del entorno donde se use.
Relación entre componentes simbiótica frente a la “familiar”
Comunicación entre componentes mediante eventos.
“Phenotypic Design” frente a “Atomic Design”
Utilizar el light-dom cuando sea posible, para insertar contenido al web-component y hacerlo indexable

Y si has leído hasta aquí ¡gracias! :)
Nos vemos por la comunidad.

Javascript Proxy: algunos usos prácticos

Mánu Fosela — Sun, 20 Sep 2020 01:10:05 +0000

Este post está basado en una mezcla de la traducción de los post del blog de Arbaz Siddiqui, y el blog de Eslam Hefnawy, javascrip.info
y del post en español de TodoJS y por su puesto de la documentación oficial en MDN

Introducción a Proxy

En términos de programación, proxy es cualquier entidad que actúa en nombre de alguna otra entidad. Un servidor proxy se encuentra entre un cliente y un servidor y actúa como cliente para el servidor y viceversa. El trabajo de cualquier proxy es interceptar las solicitudes / llamadas entrantes y reenviarlas en sentido ascendente. Esta intercepción permite que el proxy agregue lógica y cambie el comportamiento de las solicitudes entrantes y salientes.

El proxy Javascript es algo muy similar, se encuentra entre su objeto real y el código que intenta acceder a este objeto.
Nos permite hacer metaprogramación dinámica (metaprogramación: programas que escriben o manipulan otros programas).

Va a permitirnos interceptar las operaciones con objetos y sus propiedades de tal forma que podemos redefinir el comportamiento para cada una de estas acciones

De acuerdo con los documentos web de MDN:

El objeto Proxy se usa para definir comportamientos personalizados para operaciones fundamentales (por ejemplo, búsqueda de propiedades, asignación, enumeración, invocación de funciones, etc.).

Terminologías

Hay tres términos que necesitamos saber antes de poder implementar un proxy:

Objetivo (target)

Target es el objeto real que nuestro proxy interceptará. Este puede ser cualquier objeto de JavaScript.

Manejador (handler)

El manejador es un objeto donde viven todas las trampas.
Cada elemento de este objeto tiene como valor una función que implementa una trampa.

Trampas (trap)

Las trampas son métodos que interceptarán la llamada al destino cuando se llama a una propiedad o método. Hay muchas trampas definidas que se pueden implementar.
Los métodos que se pueden usar como trampas son:

Object methods:

getPrototypeOf()
setPrototypeOf()
isExtensible()
preventExtensions()
getOwnPropertyDescriptor()
ownKeys()

Property getters/setters:

has()
get()
set()
deleteProperty()

Function methods:

apply()
construct()

Ejemplo básico:

//movie is a target
const movie = {
    name: "Pulp Fiction",
    director: "Quentin Tarantino"
};

//this is a handler
const handler = {
    //get is a trap
    get: (target, prop) => {
        if (prop === 'director') {
            return 'God'
        }
        return target[prop]
    },

    set: function (target, prop, value) {
        if (prop === 'actor') {
            target[prop] = 'John Travolta'
        } else {
            target[prop] = value
        }
    }
};

const movieProxy = new Proxy(movie, handler);

console.log(movieProxy.director); //God

movieProxy.actor = "Tim Roth";
movieProxy.actress = "Uma Thurman";

console.log(movieProxy.actor); //John Travolta
console.log(movieProxy.actress); //Uma Thurman

El resultado de la ejecución del código anterior será:

God
John Travolta
Uma Thurman

En este ejemplo, nuestro objeto target era movie, implementamos un manejador con dos trampas: un get y un set.
Agregamos la lógica de que si estamos accediendo a la clave director, deberíamos devolver la cadena en God en lugar del valor real.
Del mismo modo, agregamos una trampa en el método set que interceptará todas las escrituras en el objeto de destino y cambiará el valor a John Travolta si la clave es actor.

Las posibilidades son infinitas

Casos de uso del mundo real

Aunque no es tan conocido como otras características de ES2015, Proxy tiene muchos usos.
Veremos escenarios del mundo real donde podemos usar proxies.

Validaciones

Como podemos interceptar las escrituras en un objeto, podemos hacer una validación del valor que estamos tratando de establecer en el objeto.

Por ejemplo:

const handler = {
    set: function (target, prop, value) {
        const houses = ['Stark', 'Lannister'];
        if (prop === 'house' && !(houses.includes(value))) {
            throw new Error(`House ${value} does not belong to allowed ${houses}`)
        }
        target[prop] = value
    }
};

const gotCharacter = new Proxy({}, handler);

gotCharacter.name = "Jamie";
gotCharacter.house = "Lannister";

console.log(gotCharacter);

gotCharacter.name = "Oberyn";
gotCharacter.house = "Martell";

La ejecución del código anterior dará como resultado lo siguiente:

{ name: 'Jamie', house: 'Lannister' }
Error: House Martell does not belong to allowed Stark,Lannister

En este ejemplo, restringimos que el valor permitido para la propiedad house solo pueda ser una de las casas permitidas. Incluso podemos usar este enfoque para crear objetos de solo lectura, todo lo que necesitamos hacer es lanzarlo dentro de la trampa set.

Efectos secundarios

Podemos usar proxies para crear efectos secundarios en una propiedad de lectura / escritura. La idea es activar alguna función si se accede o se escribe una propiedad en particular.

Por ejemplo:

const sendEmail = () => {
    console.log("sending email after task completion")
};

const handler = {
    set: function (target, prop, value) {
        if (prop === 'status' && value === 'complete') {
            sendEmail()
        }
        target[prop] = value
    }
};

const tasks = new Proxy({}, handler);
// ...otras tareas que al final llevan a poner un estado...
tasks.status = "complete";

La ejecución del código anterior dará como resultado el siguiente resultado:

sending email after task completion

Aquí estamos interceptando la escritura de la propiedad 'status' y si status está completa, estamos ejecutando una función de efectos secundarios.

Almacenamiento en caché

Como podemos interceptar el acceso a las propiedades del objeto, podemos construir en cachés de memoria para devolver solo valores de un objeto si no ha caducado.

Por ejemplo :

const cacheTarget = (target, ttl = 60) => {
    const CREATED_AT = Date.now();
    const isExpired = () => (Date.now() - CREATED_AT) > (ttl * 1000);
    const handler = {
        get: (target, prop) => isExpired() ? undefined : target[prop]
    };
    return new Proxy(target, handler)
};

const cache = cacheTarget({age: 25}, 5);

console.log(cache.age);

setTimeout(() => {
    console.log(cache.age)
}, 4 * 1000);
setTimeout(() => {
    console.log(cache.age)
}, 6 * 1000);

La ejecución del código anterior dará como resultado el siguiente resultado:

25
25 // a los 4 segundos
undefined // a los 6 segundos

Aquí hemos creado una función que devuelve un Proxy. El manejador de ese Proxy primero comprueba si el objeto ha caducado o no. Podemos ampliar esta funcionalidad para tener TTL basados en cada clave.
Otra aproximación puede ser usar ese TTL para pedir a una API (fetch) los datos una vez caducado.

Observar cambios en objetos

Como podemos interceptar el acceso a las propiedades del objeto, podemos crear nuevos elementos en DOM y renderizarlos cuando detectamos que una propiedad cambia o si se añade una nueva.

// NOTA IMPORTANTE!! 
// En el DOM tenemos un div con id=“salida”
//
function render(prop) {
  const salida = document.getElementById("salida");
  if (!document.getElementById(prop)) {
    const div = document.createElement("div");
    div.id = prop;
    salida.appendChild(div);
  }
  document.getElementById(prop).innerText = observables[prop];
}

handlerObservables = {
  set: function (observable, prop, value) {
    Reflect.set(observable, prop, value);
    render(prop);
    return true;
  },
  deleteProperty(observable, prop) {
    const elem = document.getElementById(prop);
    elem.parentNode.removeChild(elem);
    Reflect.deleteProperty(observable, prop);
    return true;
  }
};

const object = {};

const observables = new Proxy(object, handlerObservables);

observables["prueba"] = "valor";
// observables['otro'] = 'otro valor';
// delete observables['prueba'];

Si añadimos al objeto observables nuevos elementos, estos se irán añadiendo en el DOM dentro de la capa con id salida.
Si eliminamos del objeto elementos, estos se irán eliminando también del DOM.

Data binding

El enlace de datos suele ser difícil de lograr debido a su complejidad. El uso de proxies para lograr un enlace de datos bidireccional se puede ver en algunas “librerías” MVC en JavaScript, donde un objeto se modifica cuando el DOM sufre un cambio.

En pocas palabras, el binding de datos es una técnica que une varias fuentes de datos para sincronizarlas.

Supongamos que hay un con el id de username.

<input type = "text" id = "username" />

Digamos que se desea mantener el valor de esta entrada sincronizado con una propiedad de un objeto.

const inputState = {  id : 'nombre de usuario' , valor : '' }

Es bastante fácil modificar el valor de inputState cuando el valor del input cambia escuchando el evento ‘change’ del input y luego actualizando el valor de inputState. Sin embargo, lo contrario, actualizar el input cuando el valor de inputState se modifica, es más complicado a priori.

Un Proxy puede ayudar a lograrlo.

const input = document.querySelector('#username');
const handler = {
    set: function(target, key, value) {
        if (target.id && key === 'username') {
            Reflect.set(target, value);
            document.querySelector(`#${target.id}`)
            .value = value;
            return true;
        }
        return false;
    }
}

const proxy = new Proxy(inputState, handler)
proxy.value = 'John Doe'
console.log(proxy.value, input.value) 
// 'John Doe' will be printed for both

De esta manera, cuando haya cambio en inputState, el input reflejará el cambio que se ha realizado.
Combinado con escuchar el evento ‘change’, esto producirá doble data binding simple de input e inputState.

Si bien este es un caso de uso válido, generalmente no se recomienda por performance.

Convertir un array de objetos en agrupable

Este quizás sea el ejemplo más complejo, donde se anidan dos Proxy para poder agrupar por el campo que indiquemos.

Partimos del siguiente json con datos sobre características de procesadores:

const procesadores2020 = [
 {
   "procesador": "Athlon 200GE",
   "nucleos": "2",
   "hilos": "4",
   "frecuencia-min": "3.2GHz",
   "frecuencia-max": "3.2GHz",
   "precio": "66.18 €"
 },
 {
   "procesador": "Core i3-9100F",
   "nucleos": "4",
   "hilos": "4",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "67.99 €"
 },
 {
   "procesador": "Ryzen 3 3100",
   "nucleos": "4",
   "hilos": "8",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "3.9 Ghz",
   "precio": "105.58 €"
 },
 {
   "procesador": "Ryzen 5 2600X",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "136.35 €"
 },
 {
   "procesador": "Core i5-10400F",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "2.9 Ghz",
   "frecuencia-max": "4.3 Ghz",
   "precio": "149.89 €"
 },
 {
   "procesador": "Ryzen 5 3600",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "200.80 €"
 },
 {
   "procesador": "Ryzen 7 2700X",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.7 Ghz",
   "frecuencia-max": "4.3 Ghz",
   "precio": "207.59 €"
 },
 {
   "procesador": "Core i7-10700K",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.8 Ghz",
   "frecuencia-max": "5.1 Ghz",
   "precio": "384.90 €"
 },
 {
   "procesador": "Ryzen 7 3700X",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.4 Ghz",
   "precio": "309.95 €"
 },
 {
   "procesador": "Core i9-10850K",
   "nucleos": "10",
   "hilos": "20",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "5.2 Ghz",
   "precio": "486.00 €"
 },
 {
   "procesador": "Ryzen 9 3900X",
   "nucleos": "12",
   "hilos": "24",
   "frecuencia-min": "3.8 Ghz",
   "frecuencia-max": "4.6 Ghz",
   "precio": "443.90 €"
 },
 {
   "procesador": "Ryzen 9 3950X",
   "nucleos": "16",
   "hilos": "32",
   "frecuencia-min": "3.5 Ghz",
   "frecuencia-max": "4.7 Ghz",
   "precio": "758.87 €"
 },
 {
   "procesador": "Ryzen Threadripper 3970X",
   "nucleos": "32",
   "hilos": "64",
   "frecuencia-min": "3.7 Ghz",
   "frecuencia-max": "4.5 Ghz",
   "precio": "2099.00 €"
 }
];

Si queremos poder agrupar por los campos de los objetos del array este sería el código.

const groupable = (collection) => {
 // Comprueba que la colección sea un array
 if (!(collection instanceof Array)) {
   throw new TypeError("The input collection is not an Array");
 }

 let grouped = {};
 Object.defineProperty(collection, "groupBy", {
   configurable: true,
   enumerable: false,
   writable: false,
   value: {}
 });

 return new Proxy(collection, {
   get(target, property, receiver) {
     if (property === "groupBy") {
       return new Proxy(target[property], {
         get(target, property, receiver) {
           // si la propiedad a agrupar no existe devolver []
           if (!collection[0].hasOwnProperty(property)) {
             console.log('no encontrado')
             return [];
           }
           // caso contrario, agrupar por la propiedad
           const output = {};
           collection.groupBy[property] = {};
           grouped[property] = {};
           collection.reduce(function(acc, cur) {
             if (!Array.isArray(acc[cur[property]])) {
               acc[cur[property]] = [];
             }
             acc[cur[property]].push(cur);
             return acc;
           }, output);
           grouped[property] = {...output};
           return grouped;
         }
       });
     }
     return Reflect.get(target, property, receiver);
   }
 });
};

const datasource = groupable(procesadores2020);
console.log(datasource.groupBy['hilos']);
console.log(datasource.groupBy['frecuencia-max']);

Cuando declaramos el array como “groupable” llamando a la función con el mismo nombre y pasandole el array, lo primero que hace es crear una nueva propiedad llamada “groupBy”, convirtiendo el array y devuelve un Proxy que intercepta el get del array.
Podemos decir que hemos ampliado los métodos del array.

De esta manera si llamamos a cualquier propiedad 0, 1, 2… devolverá el objeto correspondiente a esa posición.
Si llamamos a groupBy nos devuelve otro Proxy que tiene otra trampa en get de manera que a partir del campo que recibe, recorre el array y los agrupa por el campo pasado y devuelve el array agrupado.

Esta manera es la manera de añadir funcionalidad a objetos de javascript sin tener que tocar su 'prototipo'.

Por ejemplo, en String tenemos el método toLowercase() y toUppercase() pero no tenemos el método capitalize(). Si queremos añadir a String el método capitalize podemos hacerlo modificando la cadena protypica del tipo primitivo string:

   String.prototype.capitalize = function() { 
     const str = [...this]; 
     str[0] = str[0].toUpperCase(); 
     return str.join(''); 
   }

   console.log('buenos días'.capitalize()); // Buenos días

De esta manera, todos los String que se creen a partir de esa declaración tendrán un nuevo método 'capitalize' que convierte la primera letra en mayúscula.

Si esto lo hacemos mediante Proxy, al no ser String un objeto sino un tipo primitivo, tenemos que convertir el String en Object, con lo que perdemos los métodos de String:

const addCapitalize = function(value) {
  const arrStr = [...value];
  arrStr.capitalize = function() {
    arrStr[0] = arrStr[0].toUpperCase();
    return arrStr.join(''); 
  }
  return new Proxy(arrStr, {
    get(target, property, receiver) {
      let value = new String(arrStr.join(''));
      if (property === 'capitalize') {
        value = target[property];
      }
      return value;
    }
  });
}

const saludo = addCapitalize('buenos días');
console.log(saludo.capitalize());
console.log(saludo.toUpperCase()); // ERROR: perdemos el resto de métodos de String...

Con lo que está no parece ser la manera de ampliar métodos en tipos primitivos.

Inconvenientes de los Proxies

Si bien los proxies son bastante “mágicos”, hay algunos inconvenientes con ellos por que debemos tener cuidado.

El rendimiento puede tener un impacto drástico cuando se usan muchos proxies y, por lo tanto, debe evitarse al escribir un código donde el rendimiento sea crítico.
Dado un objeto, no hay forma de saber si se trata de un objeto Proxy u objetivo.
Por último, los servidores Proxy no necesariamente conducen a un código muy limpio y fácil de entender.

Conclusión

Los proxies son increíblemente poderosos y se pueden usar y abusar para una amplia gama de cosas.