DEV Community: Singaraja33

AI is not the next DotCom bubble, it’s just the next layer of life and business themselves

Singaraja33 — Tue, 06 Oct 2026 05:20:06 +0000

Check our Medium page to read the original article: https://luisyanguas22.medium.com/ai-is-not-the-next-dotcom-bubble-its-just-the-next-layer-of-life-and-business-themselves-8bec867f0317

Every IT professional or amateur about its 30’s probably have noticed that every few years a new technology, more or less revolutionary, arrives with enormous promises. The industry gets suddenly excited and a new hype comes along, with companies raising absurd amounts of money and people all around raising predictions that everything is about to change. But normally most of these episodes end up with someone interpreting and saying that the new hype is just another dotCom bubble.

As well as many of the readers of this article, as of 6th October 26 I don’t think that is what is happening with artificial intelligence and everything around it, and the reason for it comes from a vast amount of angles from business to routinary life itself. And while I agree there may be companies whose valuations are unrealistic and there will certainly be AI projects that fail, products that disappear and ideas that turn out to be much less useful than their creators expected, the technology itself is not going away and is here to stay forever. For good and for bad. And that fact is incredibly important for businesses as well as for anyone to adapt it’s life to the change.

The internet went through something similar in the late 90’s, and many peers above their 40’s will remember how when many companies put that “.com” in their names, investors became excited about almost anything involving the web, and enormous amounts of money were invested in businesses that ultimately disappeared. And yes, the bubble burst, but the internet didn’t disappear, quite the opposite. In fact, twenty years later it actually became extremely difficult to imagine running a serious business without it.

I believe AI is heading in a similar direction, although the transformation in our opinion will be even more personal because while internet changed how we communicate, shop, work and consume information, AI is beginning to change how we think, how we create, how we decide and how we interact with technology. And unlike the internet, AI doesn’t necessarily require us to open a browser or learn a new application. It can slowly become part of the tools we already use, and that is a huge differentiator.

In our present world, and in the near future, our whole life and our daily routines will be different…Our email will summarize our messages, our car will anticipate our route, our bank will detect unusual activity, our doctor may use AI to analyze information, our phone will help organize our entire day and most of our companies will use AI to forecast demand, answer customers, analyze documents, write software or make operational decisions. And eventually, we may stop thinking about many of these things as “AI features” and will start understanding them as simply part of everyday life…And that is both exciting and slightly uncomfortable.

Technology in fact becomes particularly powerful when we stop noticing it. Electricity is a good example of it. Nobody talks about the electricity powering their laptop while they are reading this article because electricity is simply there. The exact same could and will probably happen soon with artificial intelligence.
The question for individuals is therefore not whether AI will affect their lives (it will almost certainly will) but the more useful question is whether they will understand enough about it to make good decisions.

And in the midst of all this change, you don’t need to become an AI researcher or even understand how every large language model works, but you probably should understand what AI is good at, where it makes mistakes, what information it should not be given and how it can change the way you work. Those things are truly important. And the same happens for companies, in fact it may be even more important from the moment we understand that for a business, adopting AI should not mean just adding a chatbot to the website and declaring victory.
The real opportunity is much bigger because AI can simply change how a company operates by doing things unthinkable some years ago as automating repetitive processes, helping employees make better decisions, improving customer services, analyzing large amounts of information, optimizing operations and creating entirely new products and services.

But there is a catch in all of this because AI works best when it is connected to the business itself, and while a generic AI tool knows a lot about the world, it doesn’t necessarily know how your company works, your customers, your internal processes, your legacy systems, your pricing rules, your operational constraints or the thousands of small decisions your employees make every day. That is where the next phase of digital transformation becomes particularly interesting.

For any company to sail properly the future business environment, the secret may not simply be that those companies use the most advanced AI models. Instead, it will become almost mandatory that companies do their best job at connecting AI with their existing software, data and business processes, and this is why we believe the coming years will be less about “implementing AI” and more about redesigning businesses around what AI makes possible.

In the near future we imagine, some companies will use AI to make their existing processes faster while others will realize that they can completely redesign those processes, and a smaller number will discover that AI allows them to offer something that wasn’t economically possible before. That is where business models start to change.

Imagine a logistics company that doesn’t simply use AI to predict delivery times, but builds an operation where software continuously evaluates capacity, traffic, customer priorities and costs and recommends the best decisions. Or a financial company that doesn’t simply automate document processing, but creates a service that can analyze thousands of documents almost instantly. Try to visualise a manufacturer that moves from selling a physical product to selling a combination of the product, software, data and predictive services around it…
These are not technology projects in the traditional sense but they are business transformation projects, and this is where I think companies need to be careful because the biggest risk is not adopting AI too quickly but adopting it without understanding what it means for the business, because buying tools is easy but changing processes or changing a business model is harder.

Companies therefore need to start asking uncomfortable questions to themselves…What could our business look like if AI removed half of the repetitive work? What would our customers expect from us if our competitors became significantly faster? Which parts of our business depend on human decisions and which parts are simply legacy processes? What information do we have that could become more valuable when combined with AI? And perhaps the most important question: If we were starting our business today, knowing what AI can do, would we build it in the same way?

Nobody knows exactly what the next ten years will look like and we really think anyone who claims otherwise is probably selling something, but we don’t need to predict the future perfectly, we just need to prepare for a world that is clearly moving in a particular direction, and any of us can easily see how AI is becoming part of how people work, communicate, travel, learn, buy, sell and make decisions. Nobody can deny this.

For individuals, we think the smartest response is curiosity and hunger for knowledge, and for companies the almost unique answer is adaptation. The businesses that thrive in this new era won’t necessarily be those that adopt every new AI tool but the ones that understand their own business deeply enough to recognize where AI can genuinely create an advantage. And that requires more than technology.
It requires people who can look at a business, understand its processes, systems and customers, and work out where technology can fundamentally change the equation.

Because the AI era is not something that is coming but something that has already started, and the question is whether you will be among those shaping that change or among those trying to catch up with it.

Your AI agent needs a passport, a wallet and a boss

Singaraja33 — Sun, 27 Sep 2026 08:50:50 +0000

Access our original article in our Medium: https://luisyanguas22.medium.com/your-ai-agent-needs-a-passport-a-wallet-and-a-boss-081f44aec8b4

Today we all agree that an AI agent is not just a chatbot that gives you an answer, but something way more powerful. An agent in our days can do things like reading information, call APIs, update records, send messages, execute workflows and make decisions all along the way, with a surprisingly simple question coming up: If an AI agent can act like an employee, shouldn’t we be managing it a bit like one?

When a new employee joins a company, a couple of more or less standardized steps follow…He basically first gets an identity, an email address and then someone decides which systems he can access. But it’s always this someone who decides what the new employee is allowed to do, so someone is ultimately responsible for him, and when this employee finally leaves its job, his access is removed and chapter closed.

It sounds boring, of course, but this boring stuff is the foundation of what we’ve always considered as enterprise security.

Now imagine hiring an employee who can work 24 hours a day, every single day of the year without a single holiday, access ten systems simultaneously, make decisions in seconds and potentially launch thousands of actions before anyone notices something has gone wrong…Well, this is actually happening and is called agentic enterprise.

So to go deeper in the issue, we should begin by noticing that the problem is that our traditional security systems were mainly designed around two categories: humans and machines, a place where humans have identities, roles and permissions, and machines have service accounts, API keys and predefined access. But AI agents don’t fit comfortably into either category and they can behave like machines because they operate through software and APIs, but they can also behave differently from traditional software because they decide how to use the permissions they have, and this is for sure a big challenge.

To name just some examples of companies taking action, Microsoft is already introducing dedicated “agent identities” so organizations can identify and govern AI agents alongside other enterprise identities, and IBM has similarly argued that identity is becoming a foundation for securing the agentic enterprise. All this may sound like an infrastructure problem but is actually a business problem.

A real example we recently came along was a company with an AI agent connected to their transport management system. This agent did amazing things like detecting that a delivery was going to be late, checking alternative carriers, comparing prices, finding available capacity, updating the shipments and even sending emails to customers. All of them fantastic things. The issue came with the capacity the agent had to approve carrier changes up to a specific amount of money. This part was badly designed with slightly incorrect instructions so over time the system became prone to misunderstand specific situations and therefore some chaotic scenarios happened that made the whole use of agents a bit question mark.

So suddenly, with AI agents you might find out that your clever automation isn’t just answering a question but is actually spending your money or managing a key fundamental part of your business incorrectly, and this is why the next generation of enterprise AI will require something more sophisticated than simply giving agents access to company systems. They will need boundaries.An agent needs to know who it is.

It needs to know who it is acting for and what it is allowed to access, or what it is allowed to change. And perhaps most importantly, the company needs to know exactly what it did afterwards, because if an employee makes a mistake, you can usually ask them what happened, but with an AI agent, the question becomes much more complicated.

Which user authorized the action? Which agent performed it? Which tools did it use? What information did it access?What instructions influenced the decision? Which system did it change and why?

Recent guidance on agentic AI governance is increasingly focused on precisely this problem because we basically realised that identity alone is not enough and that organizations also need runtime controls over what agents can actually do. Akamai, for example, describes the shift as moving from simply verifying who has access toward governing the behavior of autonomous systems across APIs and workflows.

And speed is also another complicated problem, because while a human employee might accidentally delete one customer record, an AI agent could potentially make the same mistake across thousands of records in seconds, and that is both the magic and the danger of automation. The faster software becomes at taking action, the less useful traditional “we’ll check it later” controls become.

This is why concepts such as least privilege access, approval gates, audit trails, monitoring and real time policy enforcement are becoming increasingly important in AI software architecture. Cisco’s September 2026 research, for example, found that more than half of surveyed enterprises were already running agentic AI systems in production, while more than two thirds said detailed explainability for agent driven actions was important. In other words, companies are already giving AI more autonomy, but now they are also discovering that autonomy needs infrastructure, which brings us back to the passport, the wallet and the boss in the title of this article. The passport is the agent's identity, the wallet represents its ability to spend resources (money, computing capacity, API calls or other valuable things), and the boss is the human or organization ultimately responsible for what the agent does.

That does not mean of course that every AI agent needs an actual credit card and a manager sitting behind it, but in our opinion it means we need to start designing AI systems with the same basic principle we use for employees, one where authority should be explicit and never automated. An agent should not automatically receive every permission available to the person who created it, but it should receive the minimum authority required to perform its job, and that authority should be reviewable, traceable and revocable.

All this becomes even more important as agents start connecting to other agents, a situation where one agent may ask another agent to perform a task, and then that second agent may access another system, which triggers another workflow…Suddenly, one seemingly simple request can create a chain of autonomous actions across an entire technology stack, and that is where software architecture becomes incredibly important.

So the future of AI in business will be about designing the systems around the models. We should create unavoidable barriers as how does the agent authenticate? how does it access company data? which APIs can it call? what happens when it wants to perform a high-risk action? where is the human approval required? how do we monitor it and how do we stop it?

At this point in time these are not theoretical questions anymore but they are becoming part of normal enterprise software development, and perhaps that is the most interesting thing about the current AI revolution. The difficult part may no longer be teaching software how to think, but may be teaching software how much authority it should have when it does.

If your company get this right, you will be able to build remarkably powerful AI systems without simply handing the keys to the kingdom to a machine, because giving an AI agent access to your business is easy, but giving it the right access is purely software engineering.

Sometimes the software you don't build is actually more valuable than the one you do.

Singaraja33 — Mon, 24 Aug 2026 03:02:14 +0000

You can also read the original article on our Medium:
https://luisyanguas22.medium.com/sometimes-the-software-you-dont-build-is-actually-more-valuable-than-the-one-you-do-503f7cc39adf

When we hear about someone developing a new software, there is quite often something that sounds strange...The flow is most of the times very similar. Basically, a company decides it needs a new system and gets together an action plan. They create a list of requirements, start with uncountable meetings and concept designs, and then developers start writing code and adding features as it goes. The project then gets bigger and while usually everyone feels productive, nobody actually stops to ask the most important question: Do we actually need to build all of this?

And even if it might sound like an obvious question, this in practice is one of the hardest and most useful questions to ask for the simple reason that software development has a quite natural tendency towards building new things, and when a development team is hired to create software, this creation process in itself feels like progress when sometimes it's actually not. In fact, some of the best tech decisions are the ones that result in less software, not more.

We can mention many examples about that, but maybe one is in the car industry, when Henry Ford understood something similar more than a century ago when he first introduced the Model T back in 1908. Ford was not looking to create the most customizable car in the world, instead he wanted a car that was affordable, reliable and relatively simple to build. The famous story about customers being able to choose any color “as long as it is black” became a symbol of this philosophy, and the reality was slightly more interesting because Ford's production system deliberately reduced variation because standardization basically made manufacturing much more efficient.

Ford was not selling fewer features because he couldn't imagine more features, he was instead making a deliberate decision about what actually mattered, and that difference is what also applies to our subject and what is incredibly relevant to modern software development.

Today, and specially with the last crazy AI model boom, companies can build almost anything, and even small entrepreneurs can dream with things that just a couple of years back would be financially impossible for them...Cloud platforms are everywhere, APIs make integrations way easier, AI can generate code in seconds and development models allow teams to create quite sophisticated apps faster than ever. The technical limitation is increasingly disappearing at a very high speed, but at the same time what many people don't realise is that the business limitation is actually not.

So instead of being tempted to jump on the development wheel without asking ourselves too much, companies should be asking themselves more than even if they actually need X or Y software or platform, and this is particularly important when developing custom software.

A clear example we often have seen is in the logistics sector. Usually, when companies are looking to build something that improves their business, they kisckstart an very analytical process where they Imagine a large number of features. Advance dashboards, mobile apps, automated notifications, optimisation for routes and trips, customer web portals, document or statistics management, predictive analytics, AI recommendations and a long etc. None of these requests sounds of course unreasonable as they are basically the tools that had traditionally made the great difference traditionally in this industry over the last years, but when you put all those requirements together you suddenly realise that the company isn't building a solution to a specific problem but instead is building an entire software universe around the business, and that is where projects become dangerous.

The more features a system has, the more complicated and expensive it becomes to design, test, maintain, secure and evolve, because basically in a system of this kind every new feature interacts with something else, every integration creates another dependency, every screen eventually needs updating and every workflow has an exception. Complexity has a tendency of multiplying quietly and of course complexity is very expensive, so the company needs to really think twice if that high expense is needed by looking at the cost reduction or the benefits the system generates when compared to its development and running costs.

One of the most common problems in software development is that teams often measure progress by what has been built rather than by what has been achieved. many people see ten or a hundred features or screens as something intrinsically good, or a new mobile app as something better in itself, but what if customers are still waiting two days for an answer? Or what if employees are still copying information between systems or the sales team still cannot see the information it needs? What if the new app saves five minutes in one process but creates three new administrative tasks somewhere else?

The software may be basically technically successful and commercially disappointing, and this is actually not a new problem. Research into software project success has repeatedly shown how difficult it is to define success simply through time, budget and functionality. A project can be delivered according to its original specifications and still fail to create the expected value for the organization, and this is the reason why good software development starts before development.

The most valuable work can happen in conversations where nobody is writing code and where people is wondering things like the real problem they want to solve, who actually has the problem, how often this problem happens, the cost that the specific problem is bringing today, etc. These questions are not signs that a software development company is reluctant to work, it's actually sometimes quite the opposite. They are signs that the company understands the cost of building the wrong thing, and the value of building the correct thing or actually don't build anything at all.

There is another fantastic historical example that came up with Apple and the Iphone...The first iPhone did not contain every feature that smartphones would eventually have later on...Apple made a series of choices about what the product should be and what it actually should not be. The product was great not because it did everything, but because the pieces worked together around a very clear experience. And that is an important lesson for custom software.

A great application does not need to impress everyone in the very beginning, but it needs to solve the right problem extremely well, and this is also where an experienced software development partner can create value that is easy to underestimate.

Clients sometimes think the value of a development company is the developers themselves, but they are not. Developers are essential, of course, but the greater value comes from combining technical experience with business understanding.

A good technology partner can look at a requirement and say they can build that, but a great one can sometimes say that while they actually can build that, they are at the same time not sure you should. And then look into it.
That conversation can save months of development, thousands of hours and a considerable amount of money. And of course it can also lead to a better product.

The irony is that saying “no” to features can actually make a software project more ambitious because it forces everyone to focus on the outcome. Instead of asking for a dashboard, you ask what decision the dashboard is supposed to improve, and instead of asking for an integration, you ask what problem the integration is supposed to eliminate. And those questions can be what actually changes the entire software development process.

All the above is becoming even more important as AI makes software development faster, because when creating software becomes cheaper and faster, the temptation will be to build more of it and companies will get more dangerously confident. More features, more experiments, more internal tools, more automation...But faster development does not automatically create better software, it only allows us to make decisions faster, while good decisions can produce enormous value and bad decisions can produce enormous amounts of software.

The companies that benefit most from technology will not necessarily be the ones that build the most applications but instead it will be the ones that become exceptionally good at deciding what deserves to be built, and sometimes that means developing a sophisticated custom platform, some other times it might mean integrating two existing systems, or sometimes it would be automating a single painful process. But as said, sometimes it might also mean building nothing at all!

The reasons why companies should outsource software development teams, and what they should expect in return.

Singaraja33 — Mon, 10 Aug 2026 02:32:11 +0000

Read the original article on our Medium: https://luisyanguas22.medium.com/the-reasons-why-companies-should-outsource-software-development-teams-and-the-things-they-should-de4eaaf9e16b

How useful or not software development companies are today is a subject that has been debated over and over since the arrival of the AI era, and the whole thing has of course a point.

When we look back to just a decade or less ago, we may realize that when it came to outsourcing software development was mostly about reducing costs. That was maybe the main thing in the mind of most companies management teams.

A company basically had a project and needed developers, but as hiring a full internal team was expensive and slow, that company often looked for an external software development company that could provide the necessary people, build the product and just hand it back smoothly.

That model still exists, but we must admit it is becoming less interesting for the simple fact that today companies do not need another supplier that simply writes code. Instead, companies in our days need technology partners that can understand their business, challenge assumptions, solve difficult problems and turn ideas into software that actually creates value. And that last thing matters more than ever.

Building software is not often the hardest part of a digital project, but building the right software is.
A business owner may know that an internal process is not being efficient, and a sales director may know that their team is losing time because several systems do not communicate with each other. A company might have an old App that has become impossible or very expensive to maintain, and a management team might see an opportunity to use AI but have no idea where to start…All these are purely more business kind of problems before they become technology problems, and this is exactly where experienced software development companies can make a significant difference.

A good development partner doesn’t simply take a list of requirements and turn it into code. A good partner also asks questions. Why does this process work this way? Who actually uses the system? What would happen if something goes wrong? Which part of the problem needs technology or which part needs a change in the process itself? Is the proposed solution really worth building or are you missing the point??

Sometimes the best technical decision is not to build something but to just change the approach, and even if that may sound obvious, it is actually one of the most valuable things an external technology partner can tell a client.

And of course, having an internal software development team can be a great decision for some companies, but it is not always practical because tech projects very often require a combination of skills that are difficult to keep permanently inside a single organization. A good team today needs to dominate things like software architecture, UX, cloud infrastructure, cybersecurity, DevOps, data engineering, artificial intelligence, quality assurance and different programming technologies. A company looking to develop something might need five developers for six months, a cloud architect for three months and an AI specialist for a specific task. And to be honest, building a permanent team around all those needs can be extremely expensive and inefficient if done without the right structure.

The above is one of the biggest advantages of working with an external software development partner, because it is this partner the one that can give you access to a broader pool of knowledge without having to build the entire capability internally. The client basically gets all the flexibility without giving up expertise.

Having understood that, it also needs to be pointed out that one of the most common mistakes when choosing a software development company is to compare providers based just on the number of developers they can offer or the hourly rate they charge, a measure that traditionally has always been there and that at some point it is actually understandable because software development can sometimes feel like a difficult service to compare, so price and number of people often became very convenient metrics to decide X or Y.

But those measures can be misleading because in technology, a team that truly understands the business problem may deliver more value in three months than a way larger team spending a whole period of six months implementing the wrong solution, so the real question should not be “how many developers are you giving us”, but more “how much business value can this team help us create”

The most successful and headache free relationships between clients and development companies tend to evolve over time. In the beginning, everything usually starts with a need for building a web or a mobile App, an internal platform, an integration between systems or a digital transformation initiative…But once the dev team understands the client’s business, something more valuable can happen because it’s is then when the developer starts to understand not only what the company wants to build, but why. And to reach and understand that knowledge is what really matters because it’s exactly where the team becomes familiar with the company’s processes, customers, systems and constraints. Its where the team really understands the decisions behind the architecture and the moment when they understand where technical debt exists and where future opportunities may be.

And it is at that point when replacing the development partner is no longer just a matter of finding another team of programmers, because the client has already accumulated institutional knowledge with that partner.

In the end, the most crucial principle of all should be that software needs to make the business better and should not be valuable just because it is technically sophisticated but because it clearly improves something. It might reduce the time required to complete an operation, eliminate repetitive manual work, help employees make better decisions, give customers a better experience, make previously impossible data available to management or allow a company to enter a new market faster. You name it. And sometimes the result is measured in revenue, some other times it is measured in efficiency, and often it is simply the ability to do something that the company could not do before. But while the tech itself is only the mechanism, what really matters in the very end is the outcome.

Despite of all this theory, the decision challenge is there because AI is already changing how software is designed and developed.and this creates a whole new mindset in managers.
Developers can generate code faster, teams can automate repetitive tasks, prototypes can be created in days instead of weeks, and existing applications can be analyzed and improved more efficiently. This is all an important change that builds.up huge opportunities for companies, but we truly believe it does not eliminate the need for experienced software development teams. If anything, it makes the strategic side of software development even more important because when producing code becomes easier, deciding which code should exist in the first place becomes more valuable than ever before.

All of the core aspects of any new tech (architecture, product thinking, cybersecurity, data management, integration, quality and overall business understanding) still require experience and judgment, and while AI can accelerate development, it definitely cannot decide what success should look like for your specific business.

A strong dev partner should make complexity manageable and help the client understand what needs to happen first, what can wait, what should be simplified and where investment will have the greatest impact. That is where success happens. Ultimately, that is where the real value of external software development is. It is not simply having more programmers or reducing development costs. It is not simply delivering a project.
The real value is in having right team of people who can connect technology with business objectives and take responsibility for turning an idea, a problem or an opportunity into something that works in the real world specifically for you, because the goal should never be to build more software but to build a better business through software.

Agente Swarms. Los equipos de agentes de IA que están cambiando el desarrollo de software.

Singaraja33 — Sun, 09 Aug 2026 08:41:07 +0000

Cuando hace no mucho tiempo aparecieron los primeros modelos de Inteligencia Artificial, hablar de IA y programación era más o menos imaginar a un developer frente a su editor de código, con un copiloto de IA al lado. Poco más. El programador escribía una función, la IA proponía otra, se corregía un error y se generaba algún test...Pero ahora todo eso está cambiando por completo.

La siguiente generación no consiste en tener un agente de IA que programa contigo, sino en tener varios agentes trabajando simultáneamente en un mismo proyecto, o lo que se ha venido a llamar en el argot de nuestro sector "agent swarms", que son básicamente equipos de agentes de inteligencia artificial.

La idea es bastante sencilla de entender. En lugar de pedir a una única IA que te lo haga todo, lo que ahora podemos hacer es dividir un mismo proyecto en diferentes responsabilidades, donde dentro de una misma tarea un agente concreto puede encargarse de analizar los requisitos necesarios, otro puede hacer ocuparse del backend, otro del frontend, otro de las pruebas, y al final otro diferente que se encarga de revisar el código al 100%. Incluso puede existir un agente "coordinador" que distribuya todo el trabajo y decida qué hacer después.

La diferencia respecto al tradicional asistente de programación "de toda la vida" es enorme, porque en este esquema de más arriba, la IA deja de ser una herramienta que simplemente espera nuestras instrucciones y empieza a ser básicamente un equipo completo de trabajo digital capaz de hacer y coordinar casi todo.

Uno de los experimentos más impresionantes al respecto publicados hace poco fue el que hizo Cursor, que estuvo experimentando con este método de agent swarms para trabajar en proyectos de software de gran complejidad.

En una de sus pruebas, el sistema recibió la documentación de SQLite (835 páginas!) y tuvo que construir desde cero una versión en Rust, sin acceso al código fuente de SQLite ni a sus tests.

De lo que se consiguió con el experimento, lo más interesante no fue que se consiguiera avanzar en el proyecto en si mismo, sino la manera o el método en que se hizo. Básicamente, el sistema utilizaba agentes planificadores, generalmente apoyados por modelos más potentes, que dividían el problema en tareas. Después, otros agentes trabajadores, más rápidos y mucho más baratos, ejecutaban esas tareas previamente marcadas.

Es una idea muy parecida a la estructura de un equipo humano tradicional, pero traspasado a la IA...En equipos humanos, también alguien diseña la estrategia y también otras personas ejecutan diferentes partes del trabajo, pero hay una diferencia bastante importante, y es que en el contexto de la IA, una máquina no necesita dormir.

Y además hay otro problema, y es que poner a 100 programadores en una habitación a trabajar no multiplica por 100 la productividad, porque si tenemos a cien o a doscientos agentes trabajando al mismo tiempo, también tenemos cien o doscientas posibilidades de que dos agentes modifiquen el mismo archivo, tomen decisiones incompatibles o hagan exactamente el mismo trabajo. La coordinación básicamente se convierte en el verdadero problema porque al final está el factor humano.

Cursor llegó a experimentar con sistemas capaces de alcanzar alrededor de mil commits por segundo. A esa escala, las herramientas tradicionales de control de versiones dejan de estar pensadas para lo que está ocurriendo.

Por eso los agent swarms están obligando a replantear algo que los desarrolladores damos por sentadoo, y es simplemente la manera en que colaboran los propios agentes sobre el código. Porque ya no basta con escribir código rápidamente sino que hay que saber quién puede modificar qué, cómo se resuelven los conflictos y cómo se transmite el conocimiento entre agentes.

Y otro dato que también es interesante es que no todos los agentes necesitan ser igual de inteligentes, algo de lo que Cursor se dio cuenta al comprobar que utilizar un modelo muy potente para absolutamente todas las tareas resultaba mucho más caro que reservarlo para las decisiones realmente difíciles y utilizar modelos más rápidos y económicos para ejecutar el trabajo, como hemos descrito anteriormente. En una de las configuraciones analizadas, el coste total llegó a variar desde unos 1.500 dólares hasta más de 10.500 dólares, dependiendo de la combinación de modelos.

La lógica es bastante clara, y es que un arquitecto puede necesitar mucha capacidad de técnica para decidir cómo construir una aplicación, pero una vez tomada una decisión concreta, quizá no tenga sentido utilizar el modelo más caro para generar cien pequeños cambios perfectamente definidos. Es exactamente la misma razón por la que una empresa no necesita que su director general escriba personalmente cada línea de código.

El nuevo cuello de botella no será escribir código, y aquí es donde está probablemente la conclusión más importante de todo este asunto. Con los agentes de IA, esa relación empieza a invertirse y empezamos a ver qué el código puede producirse muchísimo más rápido. Lo escaso pasa a ser algo muy diferente, que es básicamente definir bien qué es exactamente lo que queremos construir.

Una especificación que genere confusión o no esté clara puede provocar que diez agentes trabajen durante horas en la dirección equivocada, y al mismo tiempo una buena especificación puede permitir que esos mismos agentes avancen de forma coordinada, por eso el prompt empieza a quedarse pequeño como concepto y el futuro apunta hacia algo más parecido a una especificación de producto que los agentes puedan interpretar, dividir, ejecutar y validar.

Todo esto por supuesto no significa que los programadores van a desaparecer, pero sí que va a cambiar profundamente el trabajo de nuestros equipos.
El developer del futuro tendrá menos protagonismo como "persona que escribe cada línea" y más como arquitecto, supervisor y responsable de las decisiones técnicas.
Tendrá que saber dividir problemas, establecer límites para los agentes, revisar resultados y detectar cuándo una solución aparentemente correcta está tomando un camino equivocado.

La evolución de esto no tiene freno y ya hay muchos investigadores estudiando incluso agentes capaces de mejorar sus propias herramientas, memoria, habilidades y formas de colaboración a partir de experiencias anteriores.

Frente a todo este nuevo escenario, desde luego es impresionante imaginar cómo será un equipo de desarrollo cuando cada desarrollador tenga detrás a decenas de agentes trabajando en paralelo...Lo que sí parece claro es que estamos pasando de una primera etapa en la que la IA nos ayuda a escribir código, a otra mucho más ambiciosa donde es la propia IA quien organiza y ejecuta partes enteras del proceso de desarrollo de software. Todo esto, para las empresas que construyen aplicaciones, productos digitales y plataformas, es un cambio que puede ser mucho más importante de lo que podíamos prever, porque todo indica que el próximo gran salto de productividad no consistirá en tener un programador con una buena IA sino en tener un programador dirigiendo un equipo de IA.

Babel or Jerusalem: The Pope's framework for developers.

Singaraja33 — Thu, 11 Jun 2026 07:23:14 +0000

During Pope Leo's presentation of his first Encyclical text last May at the Vatican, there was a word he used that made many people wonder.

Standing in front of Cardinals, diplomats, and AI top leaders (including Chris Olah, one of the founders of Anthropic), the Pope said that artificial intelligence needs to be "disarmed". He didn't mention it should be regulated, governed or supervised. He said "disarmed", and when talking about such topic and in this specific act, for sure this word was carefully chosen.

He chose the word deliberately, explaining that this moment "needs words capable of attracting attention, awakening consciences and indicating paths forward", and right after he said something else that deserves to sit with every developer and pay special attention to: the Church does not claim technical answers, but brings "a wisdom concerning the human that our present time desperately needs".

That sentence, from a man such as the Pope (a Chief of State and the leader of over 1,4 billion Catholics), addressing an audience that builds the systems in question, is not something we should take lightly. It is an invitation. And the full 245 paragraphs of his Magnifica Humanitas encyclical, on safeguarding the human person in the time of AI, are worth taking seriously not despite the fact that they come from a Pope, but in part because of it.

To this day, it's obvious that the Catholic Church has been thinking about what technology does to human beings for a very long time. It was doing it before the chips came into play, before the algorithms appeared and before the first line of code was ever written, and in fact the very same date Leo XIV chose to sign the encyclical was not accidental. It was May 15, 2026, exactly on the 135th anniversary of Rerum Novarum, the encyclical written by his predecessor and namesake Leo XIII in 1891 in response to the Industrial Revolution.

That previous Encyclical, Rerum Novarum, was surely one of the most consequential documents in the history of social thought. It was written at the exact moment when factory owners were treating workers as interchangeable units of production, when underaged children worked over 14 hours a day, when families were being uprooted from agricultural communities and deposited into urban slums with no safety net, no recourse, and no social or political voice.

Back then, the market, left entirely to its own logic, had begun optimizing for output at the expense of the people doing the work, and then Pope Leo XIII said: "...this is not acceptable, not because markets are evil, but because human beings are not inputs. They have inherent dignity. Their labor is an extension of that dignity, not a commodity. The state, employers, and institutions all carry obligations that the profit motive alone cannot be trusted to honor".

It took decades for those ideas to fully materialize in labor law, workers rights, and social policy, but they eventually did and the world is now measurably better for it. The wisdom basically arrived before the legislation, and the legislation needed the wisdom to know what it was trying to protect.

As it happened to the Pope back then, now Leo XIV looked at AI in 2026 and saw the same shape of problem, moving forward to elaborate a very well built and extremely symbolic Encyclical where the organizing metaphor at its heart is striking in its clarity.

The encyclical frames the choice before humanity not as "AI yes or no" but as Babel or Jerusalem, with Babel meaning centralized power, optimizing for its own expansion, indifferent to the human cost and building something that ultimately fragments rather than connects. Jerusalem, in the other hand, means a shared reconstruction centered on dignity and oriented toward the common good, building something that makes human community possible rather than undermining it.

In any case, the Encyclical does not say AI is Babel, but what it says is that AI can turn into either, and that which one it becomes depends entirely on the choices made by the people building it, funding it, deploying it and governing it right now. Because according to the Pope, the technology is not neutral and it carries the values (or the absence of values), of those who made it. This is the concern that runs through every chapter.

The Encyclical names aspects of AI like job insecurity, manipulation of information, privacy violations, ideological bias and autonomous weapons as specific risks, but maybe the deeper risk underneath all of them is that the acceleration of AI deployment could be outpacing the moral and social infrastructure needed to shape it toward human ends. That the decisions being made this year, mostly by a small number of people and at extraordinary speed, will have consequences that fall most heavily on people who had no voice in making them.

Leo XIV warned specifically that rapid automation could displace workers and reshape labor markets in ways that risk leaving many in "forced inactivity" undermining both human dignity and social stability, in a clear echo of Rerum Novarum that is hard to dismiss as just a coincidence.

So once this is explained, and looking deeper into what this actually means for those of us building with AI, it must be noticed that most developers working on AI products are not trying to build Babel in purpose but instead they are just trying to solve real problems by using the outstanding advantage AI brings. They care about what they make, but the question Magnifica Humanitas puts to them is not if they are good or bad guys, but something much harder: Are the systems you're building designed to answer to the people they affect?

That is the question and this question matters in practice, not just in theory, because an AI system that optimizes for engagement metrics without accounting for the psychological wellbeing of users is not necessarily malicious, but it's just indifferent to a variable it was never asked to consider.

An AI hiring tool that produces discriminatory outcomes isn't evil, it's just a model that learned patterns from data that encoded historical inequity, and nobody built in a correction. An AI system deployed in a low income country that was trained entirely on data from wealthy ones is not necessarily cruel, but it's just misaligned in ways that weren't caught before deployment, and the people who pay the price for that misalignment had no seat at the table when it was designed. And so on.

These are engineering and governance problems and according to what the Pope says they also have engineering and governance solutions. The Pope is not asking developers to pray over their pull requests. He's asking the industry as a whole to take seriously a question that market incentives alone cannot answer. He asks the industry to think about who are their AI's designed for, who might it harm and what would we need to build differently if those people's wellbeing actually constrained our design choices...

The Encyclical's framing is clear and it points out that the challenge is not simply to manage technology, but to shape it with conscience so that it truly serves life, not just the ambitions of a few, and that's not a theological position but it should be a design principle. And it's one that many developers who will be most proud of their work in twenty years time from now are already trying to live by.

Going back to the Industrial Revolution's Previous Encyclical, written in 1891, the wisdom in Rerum Novarum was considered idealistic by the people with the most power to ignore it. Brutal things like child labor laws came anyway, the eight hour workday came anyway, social safety nets came anyway, the market didn't voluntarily generate those protections and the moral argument had to be made clearly enough and persistently enough that it eventually became politically irresistible.

In our own current case, we are still early in that process with AI, the legislation is fragmented and behind the technology, the governance frameworks are still forming, the power is highly concentrated and the people most affected have the least influence. So in line with the previous experience with Rerum Novarum, what Magnifica Humanitas offers is basically a framework for thinking about what we're actually trying to protect before the specific rules get written. It's a reminder that human dignity is not a variable to be weighted against efficiency, that the common good is a real constraint (not a marketing strategy), and that technology shaped without conscience produces outcomes that conscience, arriving later, will spend decades trying to repair.

Developers are not just spectators to that process. They are, in fact, right now making the decisions that will determine which side of the Babel / Jerusalem choice we end up on.

The Pope showed up in person to say so. The co founder of one of the largest AI companies was in the room to hear it. Both of those things, happening simultaneously, feel like a moment worth paying attention to, and we should all create our true opinion.

Sources:

Full Magnifica Humanitas Encyclical text:
Vatican.va
https://www.vatican.va/content/leo-xiv/en/encyclicals/documents/20260515-magnifica-humanitas.html
Analysis for engineers and builders
ExplainX.ai
https://www.explainx.ai/blog/magnifica-humanitas-pope-leo-xiv-ai-encyclical-2026
Historical context towards Rerum Novarum Encyclical Vatican News
https://www.vaticannews.va/en/pope/news/2026-05/pope-leo-xiv-encyclical-magnifica-humanitas-ai.html
AI Regulation and facts
https://luisyanguas22.medium.com/the-truth-about-ai-regulation-power-and-the-real-winners-behind-all-of-it-da9c0367c3d5

www.translockit.com

The guy managing a 2,1 trillion USD fund thinks AI might be a bubble, and he can be partially right.

Singaraja33 — Wed, 03 Jun 2026 05:40:49 +0000

Nicolai Tangen is the man behind Norway's sovereign wealth fund, a kind of mega fund owned by the small but oil ultra rich country and which owns approx 1,5% of every publicly listed company on this planet. To put this in perspective, we talk about approximately 7.200 leading companies across 60 countries.

When a guy like this wakes up in any given morning, before he had his first coffee, the needle of his 2,1 trillion might be moving up or down by a number of geopolitical tensions, currency fluctuations, interest rate decisions or earning surprises in industries he doesn't even particularly follow.

His job at the wheel of this giant is basically to see things coming before they arrive, and calculate the outcomes of any chosen investment or industry the fund is invested in, so when Tangen jumps into an interview saying that an AI bubble is one of the two greatest threats to global markets right now (the other according to him is geopolitical fragmentation), it is worth taking seriously.

About a month and a half ago, his fund formally identified that a potential AI bubble would be a major risk scenario that could potentially erase 35% off the fund's value in a worst scenario case, an along interviews where he participated between last year and this one, Tangen has been consistently saying that the concentration of capital into AI related stocks is creating, in his own words, "a risk we have never seen before".

He thinks that basically the market may be running ahead of what the technology can actually deliver in the near term, and by checking his funds investments anyone can see that he is definitely not a technophobe making this argument from ignorance. In the contrary, he has spent years (in his own words) "running around like a maniac" to get his 700 staff to use AI in their daily work.

His fund actually right now uses large language models, including Claude, to analyse every new equity investment on the day it enters the portfolio, generating daily risk assessments in real time, and a very big number of his employees code their own AI tools. So Tangen is a genuine believer in what the technology does, but his concern goes way further and is about what the market is actually pricing in. That differentiation (between the technology and the valuation), is for him the key of everything.

If we are to give a true analysis, the concentration argument is quite hard to dismiss when we see things like seven single companies now representing roughly a third of the entire SP500. Another indicator is the Shiller CAPE ratio, a inflation oriented measure that has historically preceded major corrections and that now sits around 38 to 40, levels only exceeded at the dotcom peak of 44.
We can clearly see that the market is pricing in a future where AI delivers transformational returns at a speed and scale that, looking at enterprise adoption data, is not yet materializing.

And maybe the part of Tangen's argument that is most interesting is what he describes as a structural trap, with him explicitly saying that even if he believed AI valuations were stretched, he could not simply sell out of the AI companies because they are already too large a share of the market that for a fund his size, reducing exposure to giants like Nvidia, Microsoft or Apple would mean moving markets against himself (basically selling into a decline he helped starting)

He is, according to his own words, an investor with "skin in the game" in a way that it even affects his own investing behavior. That is an uncommon and honest admission from someone in his position, and it also points to a systemic fragility that most optimistic arguments quietly diminished.

The enterprise adoption data gives Tangen's caution some realistic sense too, as despite extraordinary capital investment, most of the productivity gains from AI are still showing up in individual measurements rather than in corporate earnings at the scale the current impressive valuations imply. The MIT study finding that 95% of enterprise AI pilots fail to scale is not a detail that trillion dollar valuations should be able to ignore indefinitely.

In any case, there are also points on Tangen's speech that might be incorrect or at least incomplete, because there is a problem with the bubble analogy that we already explored in a previous article a few weeks ago: The companies at the center of the AI rally cannot be compared with those of the Dotcom era, simply because they are generating cash at a scale that has no historical precedent, not even close.

Well known companies like Apple, Microsoft, Alphabet, Amazon and Meta combined for roughly 350 billion USD in free cash flow in their most recent fiscal years, with Nvidia alone marking a net income exceeding 120 billion USD in 2026. These are not speculative bets on future revenue that may never materialize, as it clearly was in the case of previous tech crashes. They are simple audited financial statements from the most profitable enterprises in the history of capitalism.

But the infrastructure argument is also something that the bubble narrative struggles to fully explain, when we see companies like Microsoft independently committing more than 80 billion USD to AI infrastructure, Alphabet 85 and Meta between 115 and 135 billion USD. These are accounting decisions funded by existing free cash flow, not leveraged bets financed by faithful or blind investors.

The companies building AI capacity and infrastructure have among the strongest balance sheets in the entire equity market, and are setting their decisions not by guessing but by building with a financial cushion that no Dotcom company ever had.

And finally there is the adoption curve itself, a factor where Tangen is also conservative but where we should be confortably positive about when we see that enterprise AI deployment is still, as of now in mid 2026, in measurable very early stages, with companies like Gartner projecting that 40% of enterprise applications will integrate AI agents by end of 2026, up from less than 5% in 2025. If that curve materializes, even if it's on a 50% basis of what Gartner expects, the earnings growth that would justify current valuations hasn't happened yet. It's just coming.

In any case, what makes Tangen a more interesting voice than most market commentators (apart from all his professional validations) is that he doesn't claim certainty. Actually, when he presented his fund's results back in early 2026, he said openly that it was "very difficult to gauge right now whether there was an AI bubble". So this means he is basically not anticipating the crash but instead he is flagging the risk, managing the uncertainty and being open about the limits of his own visibility. So his vision as a whole might make sense and is actually the correct response to the situation, leaving aside other superbullish or crash anticipating arguments.

The most clear version of Tangen's argument is not just a vague "AI is a bubble", but he is more meaning that the concentration of capital in AI related companies, combined with a mismatch between current valuations and earnings realization, creates a correction risk that is larger than most people are pricing in. That is a serious and defensible position that doesn't come as a prediction but as a risk assessment from someone who, by the nature of his job, is paid to think about risk.

And to defend his opinion, a 30-35% correction in AI related equities would not be crazy because the history of transformative technologies is full with periods of genuine overvaluation followed by painful corrections followed, eventually, by the technology delivering on most of its original promise.

Internet did change everything but when we look back we realise that it took a decade longer than 1999 suggested it would, and most of the companies that were going to lead that change didn't exist yet when the bubble exploted.

AI probably will change everything too. Whether the companies currently priced to do so will be the ones that deliver it, and whether that delivery will happen on the timeline the market is currently pricing is a question that even the man managinf one of the largest funds in the world says he really cannot answer, which means the rest of us should probably be thinking about that too.

Sources:

AI bubble as a risk scenario (35% fund loss)

Bloomberg, March 2026:
https://www.bloomberg.com/news/articles/2026-03-18/norway-s-wealth-fund-warns-of-ai-bubble-and-geopolitical-risks

Bloomberg video, April 28, 2026 (markets, AI and China):
https://www.bloomberg.com/news/videos/2026-04-28/norway-s-tangen-on-markets-real-estate-ai-and-china-video

"Managing $2 Trillion: AI Bubbles & Contrarian Investing", February 2026:
https://www.youtube.com/watch?v=zyvuM3J9QqQ

Seven IT giants owning 1 third of the SP500:
https://luisyanguas22.medium.com/seven-it-companies-now-own-a-third-of-the-sp500-heres-what-this-actually-means-for-developers-2803c43cf093

IPE — testimony to Norwegian parliament on "unprecedented concentration risk", May 2026:
https://www.ipe.com/news/nbims-tangen-warns-lawmakers-of-swfs-unprecedented-big-tech-concentration/10136514.article

CNBC — fund using Claude AI to screen investments + AI is "deflationary and positive" quote, April 2026:
https://www.cnbc.com/2026/04/28/norway-sovereign-wealth-fund-oil-iran-war-anthropic-claude-ai-invest-stocks.html

The incredible transformation of modern software by AI:
https://translockit.com/en/article/the-incredible-transformation-of-modern-software-development-by-artificial-intelligence

www.translockit.com
Luis Carlos Yanguas Gómez de la Serna

Magnifica Humanitas: How the Pope walked into the room full of AI engineers and said what few else dared to say

Singaraja33 — Wed, 27 May 2026 01:12:06 +0000

Check our short article in Future Forem on Pope Leo XIV and his last encyclical "Magnifica Humanitas" 👇🏻

Just two days ago, in the morning of May 25th, something absolutely unusual happened in the Vatican's Synod Hall. HH. Pope Leo XIV walked into a room filled with cardinals, diplomats and also some top guys from the AI industry, and personally presented his first encyclical. That fact alone was historically unprecedented as it was the first time in history when a Pope himself attended the launch of his own documents. The encyclical was called Magnifica Humanitas ( Latin for "Magnificent Humanity"), and he said was addressed not just to Catholics but to "every person of goodwill"

The timing was most probably not accidental when we realise that, despite not having been widely commented, Leo XIV signed it on May 15th, the very exact 135 anniversary of Rerum Novarum, the landmark 1891 encyclical in which his predecessor and namesake Leo XIII responded to the dehumanization caused by the Industrial Revolution.
The message embedded in that date is impossible to miss, and drove the minds of everyone to the fact that we are right now living through another revolution of equal magnitude, and the Church has something urgent to say about it.

The document was written originally in English and to read it in that language was specially interesting as the powerful message was better perceived, as it happens when we, non native english speakers, watch an American movie in its original version. It's opening words set the tone with strong clarity, saying the following: "Humanity, created by God in all its grandeur, is today facing a pivotal choice, either to construct a new Tower of Babel or to build the city in which God and humanity dwell together"

That is not a metaphor chosen carelessly, because what Leo XIV most clearly argues throughout Magnifica Humanitas is that technology is not our enemy (the encyclical is explicit that AI is neither "a force antagonistic to humanity" nor "inherently evil"), but it is equally explicit that technology is never neutral. It takes on the characteristics of those who devise it, finance it, regulate it and finally use it, which means that the question is not whether AI is good or bad in the abstract.

The question is what vision of the human person is embedded in the data, the models and the decisions being made right now, mostly by a very small number of people and at extraordinary speed.
This is where the encyclical becomes specifically important for those of us who build technology for a living.

The Pope argues that "a more moral AI" is not enough if that morality is determined only by a few. He calls for active political and social involvement capable of "slowing things down when everything is accelerating". Not to stop progress but to ensure that communities still have the chance to participate, ask questions and shape the future that is being built in their name.

Sitting in that room at the Vatican, listening to the Pope, was Christopher Olah, one of the founders of Anthropic which as we all know is one of the most powerful AI companies on earth, and a man who describes himself as not a believer. After the presentation, Christopher said he was grateful to the Church for "taking this work of discernment seriously" and even issued his own call: "We need moral voices that the incentives cannot bend"
That sentence, from an AI engineer at a Papal encyclical launch, says something profound about where we are.

For anyone building software, developing AI systems and making the daily decisions about what to optimize for and what to leave behind, Magnifica Humanitas is a reminder that every technical choice carries a moral weight because the human being on the other end of the product is not just a user metric. They are, in the Catholic tradition, made in the image of God. Unrepeatable and irreducible to simple data.

Despite its probable errors, nobody can deny that the Church has been thinking about human dignity for two thousand years. It was thinking about it way before the algorithm, before the chip, before the first line of code was ever written. That continuity of thought, and the insistence that no amount of efficiency justifies the erosion of what makes us human, is exactly what AI development needs more of right now.

And the Pope showed up in person to say it. That, only in itself, is very worth paying attention to.

Sources:

Full text of the encyclical:
https://www.ncregister.com/cna/full-text-magnifica-humanitas

Vatican News
https://www.vaticannews.va/en/pope/news/2026-05/pope-leo-xiv-encyclical-magnifica-humanitas-ai.html

NPR:
https://www.npr.org/2026/05/25/nx-s1-5828375/pope-leo-to-weigh-in-on-the-perils-and-promises-of-artificial-intelligence

EWTN:
https://ewtnvatican.com/articles/pope-leo-xiv-unveils-magnifica-humanitas-ai

www.translockit.com

Magnifica Humanitas: How the Pope walked into the room full of AI engineers and said what few else dared to say.

Singaraja33 — Wed, 27 May 2026 01:07:24 +0000

And the Pope showed up in person to say it. That, only in itself, is very worth paying attention to.

Sources:

Full text of the encyclical:
https://www.ncregister.com/cna/full-text-magnifica-humanitas

Vatican News
https://www.vaticannews.va/en/pope/news/2026-05/pope-leo-xiv-encyclical-magnifica-humanitas-ai.html

NPR:
https://www.npr.org/2026/05/25/nx-s1-5828375/pope-leo-to-weigh-in-on-the-perils-and-promises-of-artificial-intelligence

EWTN:
https://ewtnvatican.com/articles/pope-leo-xiv-unveils-magnifica-humanitas-ai

www.translockit.com

We reviewed many AI project failures, and this is the pattern most of them clearly show.

Singaraja33 — Mon, 25 May 2026 03:02:42 +0000

Check out our Dev.to article on the reason why a majority of AI initiatives stall, and the reason to do things properly 👇🏻

In one of our previous posts we talked about the importance of the experienced developer behind any serious AI project, and now we would like to dig more on the reason why most AI project failures happen.

To put it simple, today anyone with enough experience can confirm that by trusting the development of our ideas and projects fully into AI autonomous systems and models, what we will probably obtain as a result is a cascade of automated fixes, each one making the underlying problem slightly worse and none of them understanding the dependencies that connected everything together. The main reason behind that situation is just because AI models are designed for perfect conditions, but production is very rarely done under those "perfect conditions".

Just in 2025, the freshest year we can see statistics from, global companies invested hundreds of billions in AI initiatives. By the end of that year, estimations show that approx 80% of all that huge investment had produced no measurable results (not just low returns or disappointing returns, but literally no results), and in an analysis by The RAND Corporation, it was seen that across more than 2.400 enterprise AI initiatives, 80,3% of them failed to deliver their intended business value. And what is maybe more alarming is that these numbers have barely moved in three years, despite better models, better tooling and dramatically more organizational awareness of the problem.

Everyone in the industry knows the failure rate is high, but the question is that very few people can tell you exactly why in a way that's actually useful. So here is what the data actually shows and what the minority that succeeds is consistently doing differently.

Maybe the pattern that keeps repeating the most is simply how we think about the intrinsical risks on AI projects themselves. In a study done among 140 company AI implementations, it was seen that only 23% of failures were caused by model performance, data quality problems or integration complexity. The rest (77% of them), came down to simple strategy and organizational decisions that had nothing to do with the technology itself...Read that again: 3 out of 4 AI project failures are not technical failures but purely organizational ones.
This means the model worked, the data was good enough and the integration was achievable, but despite of it all the project itself still failed because nobody had agreed on what success looked like or because the team behind the project treated AI as an IT project rather than a business transformation, or because the team behind was not actually prepared to change how it operated around the technology it had just deployed.

This is crucially important, because it means that the most common response to AI project failure (picking a better model, hiring more data guys, switching outsourcing) is basically solving the wrong problem. The issue was never primarily in the code.

The specific failure that appears in the data with strong regularity deserves its own name, and is called "demo to production" collapse and means that many AI systems fail mainly during the transition from pilot to production. The model might perform very well in a controlled environment, impressing everyone in the room and with budgets easily approved. But then when the rollout begins and the real world conditions arrive is when inconsistent data come up from systems that don't talk to each other cleanly, edge cases the demo never encountered appear and the whole thing stalls.

S&P Global found that only 48% of AI projects make it into production at all. Of those that do, the average journey from prototype to production takes eight months. Big companies abandoned an average of 2 AI initiatives in 2025, at an average cost of 7,2 million USD million per abandoned initiative.
Gartner puts a specific number on the data problem that sits underneath most of these failures, and is that 60% of AI projects that lack AI ready data will be abandoned by the end of this year 2026. Maybe more interestingly, McKinsey's 2025 research found that companies achieving significant AI returns were twice as likely to have invested in data workflow redesign before model selection. Not after, before. This simply means that companies that succeed build the foundation first and choose the model second, and the companies that fail do it the other way round, because the model is the exciting part, and foundation work is not.

To solve all this and get to clear optimal results, leadership is fundamental and plays a key role, and according to other findings 84% of AI project failures are basically leadership driven. Not engineering driven and not data driven, but just provoked by a failure in the leadership of the project itself. And this is a symptom that repeats not only in our industry but across other industries as well. To say it clear, most projects lack clear and measurable success metrics from the start because they are normally approved on the basis of strategic intent rather than defined outcomes. Teams tend to treat AI as a technology project when it is actually a business transformation, which means the people with the authority to change workflows and incentives need to be involved before it becomes too late.

Companies that consistently succeed share a specific characteristic, and this is that they generally define what success looks like in clear and measurable terms before a single line of code is written. Instead of concluding that "we want to use AI to improve customer service", they normally say "we want to reduce average customer query resolution time from 8 minutes to 3 minutes, with a customer satisfaction score above 4,5, within 90 days of deployment" That way of deciding and that leadership generates several things simultaneously: it builds a clear alignment on what is actually being built, and it means that when something goes wrong in production (and something always goes wrong) the team knows exactly what they're trying to get back to.

The previous RAND analysis we mentioned also identifies a specific profile on the minority of AI projects that deliver their intended value, and the pattern is consistent enough to be useful.
They build observable systems from day one. The successful teams log inputs, outputs, latencies and metadata from the beginning, turning what would otherwise be a black box into an clear system they can analyse in full. And even if doing this might feel like overworking in the early stages, it is actually the only thing that makes debugging in production manageable when problems arrive, and as we said, problems always arrive.

The teams that skip that previous efforts spend then months trying to reconstruct failures they could have diagnosed in minutes if initial phases were done properly. Those teams don't get to understand that maybe the most reliable AI systems in the data are human AI collaborations, and that while the AI handles volume, humans handle exceptions. This is not just a compromise or a temporary measure until the AI gets better, but it is the architecture that works in practice, across industries and consistently. Fully automated AI systems without explicit human review points fail at strongly higher rates than hybrid systems, because they can't recognize when they've missed something important.

Another recent study on March 2026, just two months ago, found an engineer using Claude to fix a condition in a payment processing platform. The AI's solution looked elegant to his eyes and passed all initial tests. It introduced 12 new bugs, leading to severe system failure. The AI didn't understand the concurrency models or production load patterns that made the original code fragile. The fix cost a lot of money in lost revenue and engineering time...AI is genuinely extraordinary at generating code that works in isolation, but as we mentioned in previous articles, it is not good at understanding the historical context, the outages, the edge cases, the undeclared dependencies and all those things that shapes what a system actually needs to survive in production.

Teams that succeed with AI share a characteristic that sounds almost insultingly simple: they choose their AI application based on where it fits a genuine, measurable business problem, not based on what the technology is theoretically capable of. "Let's use AI" is not a strategy, what looks like a strategy is "Let's automate the specific part of our customer onboarding process that currently takes 4 days and costs us 30% of customers before they reach activation".

The main risk of doing things wrong is what analysts are calling AI Capital Risk, basically meaning the exposure created when significant capital is committed to AI initiatives before structural readiness is validated. And the structural readiness question is not primarily technical but is instead organizational, architectural and strategic. That means that the most valuable resource for an AI project is not, despite what the vendor landscape might suggest, a better model or a faster compute cluster. It is experienced analysis about which problems are worth solving, how to structure a system that will survive production conditions, how to define success in ways that survive organizational changes and how to build the foundation that the technology actually requires before the technology gets selected.
The teams that have seen the failure modes and learned what the data took three years and a lot of spending to confirm, bring something that no tool, no model and no amount of internal enthusiasm can substitute for: the accumulated knowledge of what actually breaks and how to design around it before it breaks on you.

The gap between a project that impresses everyone in the demo and a project that delivers measurable value twelve months later is not simply a gap in technology but a gap in the analysis applied to every decision made in the first couple of days or weeks, and this gap is where only the 19,7% of cases live.

If you're in the early stages of an AI project and want an honest assessment of where your structural risks actually are (before the expensive part begins) at Translock IT we'd be glad to talk. The conversation costs nothing but the alternative might cost considerably more.

Sources:

RAND Corporation — analysis across 2.400+ AI initiatives
https://www.pertamapartners.com/insights/ai-project-failure-statistics-2026

MIT — 95% of GenAI pilots fail to scale
https://www.wiseback.com/why-ai-projects-failed-2025-and-2026-cx-strategy/

RAND + MIT + McKinsey + Gartner — comprehensive synthesis
https://labor411.org/411-blog/report-80-of-ai-projects-fail-overall-with-84-of-the-failures-caused-by-leadership/

S&P Global — 42% of companies scrapped most AI initiatives in 2025
https://www.folio3.ai/blog/ai-project-failure-rate-stats

Gartner — 60% of AI projects without AI-ready data abandoned
https://talyx.ai/insights/enterprise-ai-implementation-failure

McKinsey 2025 — organizations with AI returns invested in data first
https://quicklaunchanalytics.com/bi-blog/why-80-of-ai-projects-fail-before-they-start-its-your-data-foundation/

Stratify Capital 2026 — AI Capital Risk framework + structural failure analysis
https://www.stratifycapital.ai/ai-project-failure-rate

Case $47k AWS outage + case $13,540 payment endpoint (Claude race condition)
https://altersquare.io/ai-not-suited-for-architecture-decisions-no-knowledge-of-past-failures/

McKinsey Global AI Survey 2026 — 73% ROI failure rate
https://www.aigovernancetoday.com/news/enterprise-ai-spending-crisis-2026

Valuebound 2026 — architectural and organizational failure patterns
https://www.valuebound.com/resources/blog/ai-projects-fail-enterprises-2026-reality-check

www.translockit.com
Author: Luis Carlos Yanguas Gómez de la Serna

Very interesting analysis on why most AI projects simply fail, and the key to avoid that 👇🏻

Singaraja33 — Mon, 25 May 2026 02:57:06 +0000

Singaraja33

May 25

We reviewed many AI project failures, and this is the pattern most of them clearly show.

#aiprojects #ai #softwaredevelopment #translockit

8 min read

We reviewed many AI project failures, and this is the pattern most of them clearly show.

Singaraja33 — Mon, 25 May 2026 02:54:48 +0000

Sources:

RAND Corporation — analysis across 2.400+ AI initiatives
https://www.pertamapartners.com/insights/ai-project-failure-statistics-2026

MIT — 95% of GenAI pilots fail to scale
https://www.wiseback.com/why-ai-projects-failed-2025-and-2026-cx-strategy/

RAND + MIT + McKinsey + Gartner — comprehensive synthesis
https://labor411.org/411-blog/report-80-of-ai-projects-fail-overall-with-84-of-the-failures-caused-by-leadership/

S&P Global — 42% of companies scrapped most AI initiatives in 2025
https://www.folio3.ai/blog/ai-project-failure-rate-stats

Gartner — 60% of AI projects without AI-ready data abandoned
https://talyx.ai/insights/enterprise-ai-implementation-failure

McKinsey 2025 — organizations with AI returns invested in data first
https://quicklaunchanalytics.com/bi-blog/why-80-of-ai-projects-fail-before-they-start-its-your-data-foundation/

Stratify Capital 2026 — AI Capital Risk framework + structural failure analysis
https://www.stratifycapital.ai/ai-project-failure-rate

Case $47k AWS outage + case $13,540 payment endpoint (Claude race condition)
https://altersquare.io/ai-not-suited-for-architecture-decisions-no-knowledge-of-past-failures/

McKinsey Global AI Survey 2026 — 73% ROI failure rate
https://www.aigovernancetoday.com/news/enterprise-ai-spending-crisis-2026

Valuebound 2026 — architectural and organizational failure patterns
https://www.valuebound.com/resources/blog/ai-projects-fail-enterprises-2026-reality-check

www.translockit.com
Author: Luis Carlos Yanguas Gómez de la Serna