DEV Community: Singaraja33

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

Almost anyone can build an App in 2026, but here's the part nobody mentions

Singaraja33 — Fri, 22 May 2026 02:48:33 +0000

Our article on Dev.to on Vibe Coding, setting up Apps and the need of experienced developers today 👇🏻

When anyone starts trying to vibe code on a project for the first time, it's quite typical that after typing something like "build me a project management app with a nice dashboard and user authentication" they become amazed on how with just such a simple prompt they can see in front of their eyes a fully functional application assembling itself. And not only that, but also the app buttons work, the overall layout looks clean and they can actually click around in it quite properly. The whole thing took just a couple of minutes and without the need of writing a single line of code.

That feeling is now happening, it's real and the market has rewarded it if we just look at the numbers and realise that vibe coding tools have attracted over a billion USD in venture capital in 2025 alone. Lovable, a well known platform we've written about before and that was funded by a simple Nordic young guy, hit 200 million USD in annual recurring revenue. Cursor's parent company was valued at 9,2B USD, with Bolt hitting 2,1B. With this data at hand, we can clearly see that these are not just experimental tools with a handful of geeky users.

As we approach the end of May 26, in this exact moment approx 60% of vibe coding users are not developers. So yes, as mentioned in the title, almost anyone can build an app now, but the question that we hear less often is: What kind of app exactly? What happens at the parts the demos never show?
Let's start by giving credit to the sides that deserve it, because the capabilities are impressive in ways that of course matter a lot.

To start with Bolt.new, this platform runs entirely in the browser through WebContainers technology that requires no installation, no local setup and even no terminal. You simply describe an application in plain English or Spanish and it generates and runs the code live. Designers who have never opened a terminal are building prototypes in it right now.

v0 from Vercel had 2 million users generating React components and full landing pages from just text descriptions by the first quarter of this year alone. Lovable targets full stack web application generation with Supabase as the default backend, and has become the mandatory tool for people who want to test an immensely valuable thing as whether an idea is worth pursuing before spending money on a development team.

The productivity numbers for experienced developers using these tools are also real, with some statistics saying that AI coding tools have boosted individual developer output by almost 80% on average, measured by lines of code shipped. GitHub Copilot now has around 2 million paid subscribers and 20 million total users, and approximately 40% of all code written in the world today has become AI generated.

The workflow used by many in the industry is also quite common, with most starting with Bolt or Lovable to prototype fast, and then moving to Cursor or Claude Code for production level refinement. And this is absolutely changing how software gets built today, in ways unimaginable just a few years ago.

All those tools and ways of coding have brought to a way easyer, much quicker and incredibly cheaper reality things like rapid prototyping, idea validation and internal tools. And that is a meaningful democratization and definitely not hype.

Now, having said all of that, we should also explain the part that the product walkthroughs reliably skip, and we should understand that getting from 0 to 90% of an app might be quite easy with vibe coding, while getting from 90% to 100% (handling edge cases, authentication that doesn't have vulnerabilities, payment processing, real deployment, production database design, or error states for every scenario a real user will eventually stumble into) is where things get complicated in ways that simple prompts don't easily resolve.

Karpathy himself, the man who actually invented the term "vibe coding" and is maybe among the most technically capable person you could imagine using these tools, discovered this very early when right after building his own app with vibe coding, he wrote that it was "exhilarating and fun as a local demo but a bit of a painful slog as a deployed, real app". So if Andrej Karpathy himself finds the last 10% a challenging part, it's worth sitting with that for a moment.

The security picture is also worth looking at, and just about a year ago, in May 2025, a study found security vulnerabilities in 170 out of 1.645 apps built with Lovable (apps that real users were actually using and trusting with their data), and some critical security flaws were also identified on Lovable's generated code. These are not random and lonely cases, but are more of a structural consequence of using tools that optimize for getting something working quickly rather than getting something secure reliably, and we should be aware of that.

Several developers who have tested these platforms on stress and at scale have also noted the same pattern, reaching to the conclusion that vibe coded apps work fantastically well for prototypes but "have patterns you will regret at scale" They basically experienced that the code that gets you to a demo often makes your life way harder when you try to grow beyond it. Not because the app is bad, but because it was simply not designed with growth in mind, it was designed to exist.

Very interestingly, a study published mid last year found that while AI coding tools boosted average developer output by 76%, experienced developers using AI assistance were paradoxically 19% slower than when they worked without it (even though those same developers believed they were working 20% faster, according to the study)
The explanation for this is what actually matters, because it was found out that those experienced developers knew when the AI had gotten something essentially wrong. When that happened, they just stopped, backtracked, rethinked the structure and catched the vulnerability before it shiped. And it was that process of oversight and correction that was taking a lot of time, a time that didnt show up as productive in metrics but absolutely shows up in whether the application works correctly in production.

This paradox captures something essential about what expertise actually does in software development, because it clearly shows that it is not primarily about being able to write code, but about knowing when the code is wrong, why it is wrong, what the consequences of that wrongness will be six months from now and how to fix it in a way that doesn't create three new problems. A non technical user prompting Lovable has no mechanism to do that check because he lacks expertise, and when they see something that appears to work they just ship it. The problems arrives later in security audits, in production failures, in scaling walls and in technical debt that accumulates invisibly until it becomes impossible to ignore.

The honest synthesis and the conclusion we can extract from all the above is that vibe coding tools have created a true new capability tier that didn't exist only three years ago. Today, a small team or even a single person with limited technical experience can build and validate a product idea at a speed and cost that previously required a full engineering team, and that matters a lot for founders, for product teams or for internal tooling at companies that can't justify a dedicated developer or a team of developers. But that capability tier has a ceiling, and that ceiling arrives at the moment when the product starts to matter, when real users are depending on it, when security vulnerabilities have real consequences and when the architecture decisions made in the first minutes sprint start constraining everything that follows.

We live in a tech phase where the companies that use vibe coding tools most effectively treat them for just exactly what they are, basically extraordinary tools for speed and validation, but not replacements for engineering basis. Those companies know that the prototype gets built fast, but then it must be the professionals the ones who arrive to evaluate whether the foundation is worth building on, refactor what needs refactoring, harden what needs hardening and design the system that will actually scale.

This is also, frankly, why specialized software development companies have never been more relevant rather than less. The market is now full of beautifully looking products built by excited non technical teams who got to 90% faster than ever before and are now staring at the 10% that requires actual expertise. And the demand for that expertise at the moment, applied to real production systems, is actually higher than it has ever been.

For development firms that know what they're doing, the era of vibe coding is not a threat but a pipeline, and many creative entrepreneurs can today just set up very quick and cheap companies to develop apps at very low costs and relying on experienced subcontractors for the more technical side of their initiatives.

As a brief of the above explained tools, we could brief as follows:

1- For non technical guys or teams out there validating an idea, Lovable and Bolt.new are the clearest starting points. Both run in the browser, require no setup and can produce functional full stack applications from natural language descriptions within minutes. Lovable handles more complex app generation and Bolt prioritizes raw speed and is excellent for proof of concept work.

2- For teams with some technical experience who want AI assistance in a real development environment, then Cursor is the most interesting tool, valued at around 9 billion for reasons that are obvious the first time you use its Composer feature on a complex codebase.

3- GitHub Copilot remains the most widely adopted AI coding tool overall, with so many people around the globe as paid subscribers and integration across every major IDE.

4- For frontend and UI generation specifically, v0 from Vercel produces React components of a quality that impresses even experienced frontend developers.

And for anything that will carry real user data, handle payments, operate at scale or be built to last beyond the initial prototype phase, our strong recommendation is to keep bringing in people who have done it before, because the most clear thing the vibe coding era has clarified is not that developers are becoming obsolete, but that getting something working and getting something right are still two meaningfully different things. One of them is now much faster than it used to be, and the other still takes what it always took. Time and knowledge.

Vibe Coding, la nueva forma de desarrollar software

GPT Images, designing without designers
Translock IT
Luis Yanguas Gomez de la Serna

Almost anyone can build an App in 2026, but here's the part nobody mentions

Singaraja33 — Fri, 22 May 2026 02:42:51 +0000

As a brief of the above explained tools, we could brief as follows:

3- GitHub Copilot remains the most widely adopted AI coding tool overall, with so many people around the globe as paid subscribers and integration across every major IDE.

4- For frontend and UI generation specifically, v0 from Vercel produces React components of a quality that impresses even experienced frontend developers.

Vibe Coding, la nueva forma de desarrollar software

GPT Images, designing without designers

Translock IT
Luis Yanguas Gomez de la Serna