DEV Community: Luís Takahashi

The Software Entropy in the AI Era

Luís Takahashi — Wed, 14 Oct 2026 19:01:39 +0000

TL;DR: I ran an experiment with AI-augmented development. In one month we produced 400k+ lines of code, 150 features, 240 fixes and 50 refactors, then the entropy accelerated and the velocity collapsed. What normally takes years of accumulated technical debt across multiple teams happened in weeks.

Hi there, my name is Takah, I'm a Principal Software Engineer from Brazil. In the past months I've been conducting a few experiments on how to adapt our SDLC and explore new ways of working with AI, both enabling non-engineers to code in our repos and also enhancing every guard-rail, guideline and common market standards to support this type of workflow.

What Is Software Entropy?

But let's circle back to the title of this article: what is Software Entropy? First of all, what is entropy? I'll freely give one interpretation that entropy, borrowed from thermodynamics, is the natural tendency toward disorder or uncertainty in a system, and what is exactly software entropy? I'd say its the natural tendency of any given software and system to disorder, when new features are being added, new modules, new fixes, quick-wins, a hacky solution to fix or deliver something in time, or to prevent another incident, regardless of the most architectural pre-definition and future-proof hexagonal multi-flexible, composable and any other blazingly fast buzzword you wanna add, it's impossible to predict and prevent all use-cases beforehand, that's why entropy always end up happening.

Software entropy is not a bug, it's a fundamental property of any system that grows. The question is never if it will happen, its how fast, and whether you have the mechanisms to manage it.

What Does AI Have to Do With Software Entropy?

And what AI has to do with Software Entropy? Like i said one of the experiments i did was me a Software engineer and 2 other designers, which we had the challenge of developing a whole new experience of a chat and we wanted to leverage the AI ecosystem at its maximum.

So first, before any line of code, i aligned the scope, contracts, and overall architecture of the project:

Tech stack
Repository setup, code structure, architectural guidelines
AI guidelines: agents, skills, context files for testing, styling, developing new features, feature-branches

And after the initial setup we had, and helping them setup their own setup with claude, our internal ai-proxy, repository, vpns, etc we started developing. And at the beginning it was awesome. The guidelines and setup were satisfactory, features seemed to be right, we were adding one feature after another with autonomy, tests, coverage, and apparently following the project guidelines.

But whats the problem?

The Turn: Week Three

After 3 weeks we had a codebase with more than 400k lines, dozens of features, animations, micro-interactions that would maybe take several sprints to be made if they were handcrafted by a team of engineers. But at this moment things started to break down:

Each feature velocity started to decline
New behaviours that interacted with previous states started to skyrocket race-conditions
One new feature broke 3 other working ones
A simple feature that previously took a few hours now took days

And we had to circle back and analyze what was happening.

The guidelines and guard-rails that were previously added were not enough, because even with a strict guideline saying to our models and setup: "Use X technology or Y Architecture or Z state management tool in this way," the probabilist nature of LLMs still were delusional.

We had several features that reimplemented different state machines, did full animations, sound, charts from scratch while it was already solved in a sibling part of the application, and one of the signs were the codebase growth, it was exponentially growing in number of lines and files.

To give you a sense of the scale, in roughly one month we accumulated:

150 features added
240 fixes applied
50 refactors performed, with refactors as large as removing more than 50k lines of code in a single one

And I'm not alone in this, the data from 2026 tells the same story across the industry. The 2025 DORA State of AI-assisted Software Development report found that a 25% increase in AI adoption is associated with a 7.2% decrease in delivery stability, because AI allows developers to generate code much faster and it often leads to larger batch sizes, which are slower to review and more prone to creating system instability. New Relic's 2026 State of AI Coding report, which surveyed 200 technology leaders, found that while 94% of them rate AI-generated code as higher quality at review time, 78% report more incidents once it ships and 82% experienced at least one production failure tied to AI-generated code in the past six months. They call this agent debt, the rapid accumulation of unvetted architectural logic that triggers production incidents down the line. And a systematic review of 34 studies covering 2,847 developers found that technical debt principal increased by 1.8 person-days per 1,000 AI-generated lines of code, with the debt ratio doubling within 6 months without mitigation.

The Fix: Tightening the Guard-Rails

To fix that we had to do several fixes, refactors, and with each fix and refactor to strictly tighten the guard-rails, tests, and add custom deterministic tools to truly ensure that the code was following each guideline. In practice this meant:

AI guard-rails in agents: direct instructions, specific skills and context files that enforced architectural patterns
Deterministic tools: lint rules, pipeline validations and custom checks that verified architectural conformance before merge
Strict refactoring cycles: regular mandatory refactoring capacity to reduce the debt principal
Expert oversight: a specialized developer actively enhancing the guidelines, understanding what to use, what not to use, how to fix, and correcting the AI to follow new strict rules

In the end result the AI usage was a success, within a month we developed something that would take months to be made handcrafted, but at what cost?

If a specialized developer was not present enhancing the guidelines, understanding what to use, what not to use, how to fix, and actively enhancing its guard-rails this codebase was doomed to failure. Or maybe a full refactor or depriorization due to the effort of maintaining it.

The Exponential Decline of the Codebase

So whats my conclusion? All that happening within a month its the same thing i saw happening during years of a codebase, it normally takes months of multiple developers, teams, and technical debts accumulated to reach the same level of entropy and disorder where each new feature was breaking 3 others. What I'm calling the exponential decline of the codebase is not just a metaphor, its what happens when the rate of entropy generation outpaces the rate of human oversight by an order of magnitude.

The IEEE Computer Society puts it bluntly: "Standing between such problematic AI output and other downstream disasters? Software engineers. The value of engineers with the software lifecycle knowledge needed to guide and oversee AI assistants and their output is immeasurable."

The arXiv paper "Beyond the 'Diff'" defines agentic entropy as "a systemic drift that traditional code diff-based and HCXAI methods fail to capture, as they address local outputs rather than global agentic behaviour," and notes that "functional checks (e.g., confirming that the code runs) can thus mask deeper architectural violations and security gaps, producing an illusion of rapid progress while drift accumulates beneath the surface."

The AI era is awesome, but without proper follow-up and deep specialized people understanding whats being written and which software engineering strategies, architecture and design patterns to follow, it will exponentially increase the software entropy. Gartner predicts that by 2029, 60% of organizations will adopt smaller software engineering teams at scale, up from 15% in 2026. But smaller teams with AI does not mean no engineers, it means engineers with different skills, architects, overseers, guard-rail builders. The ACM Technology Policy Council's TechBrief on vibe coding warns that it "often skips over core engineering practices that ensure systems are secure, reliable, and maintainable," and their lead author Simson Garfinkel says it directly: "It's making developers dramatically more effective, but it's also introducing security vulnerabilities, increasing technical debt, and producing code that can be difficult to maintain."

A Reflection for Engineering Leaders

If you're a manager, head of engineering, VP or CTO reading this, i want you to reflect on a few things:

How are you aspiring your org to be? Are you designing for a future where AI does the coding and engineers do the oversight, or one where engineers use AI as a tool while retaining architectural ownership?
Where are your gaps? Do you have mechanisms to detect software entropy as it accumulates, deterministic guard-rails and not just guidelines, engineers who can recognize when the AI is drifting from architectural intent?
Whats your oversight model? The data from New Relic shows that 62% of technology leaders report their teams trust AI-generated code enough to ship it to production without line-by-line manual verification, is that a risk you're willing to take?

My Disclosure on AI

In that way, i don't dislike Agentic Coding, neither the idea of non-engineers coding, my conclusion is that the current state of ai tools are not ready yet to be driven by full Ai enthusiasts, software engineers are going to exist, this is the new normal we should not fear Ai we should embrace these new tools and understand how we could be more productive and have more time to focus in new strategies, features, design patterns, career, our mental and physical health and our familly not only delivering more value to our shareholders.

The illusion that a single person with AI can replace a team of engineers is just that, an illusion. What we experienced in one month is what happens when you remove the expertise from the loop. The entropy accelerates, the velocity collapses, and the cost compounds. Software engineers are still necessary, the question is, are we building organizations that know how to use them?

⚔️ Cross micro frontends communication 📦

Luís Takahashi — Sat, 10 Oct 2020 23:23:53 +0000

In this article, I'm going to explain some ways to communicate between multiple applications and a particular way that I have chosen to use in my current project and work.

If you are not familiar with the micro frontends concept and architectures I suggest you take a look at these amazing articles:

There are several reasons for choosing a micro frontend architecture, maybe your app has grown too much, or new teams are coding on the same repo/codebase, but one of the most common use cases is the decoupled logic of certain domain of an App.

Following this logic, good architecture is one in which micro frontends are decoupled and do not need to frequently communicate but there are some things that micro frontends might share or communicate like functions, components, some logic, or state.

Sharing code

For functions, components and common logics could be placed on a third package and imported on each app.

And for creating a package there are several approaches I won't dive deep into it, but I'll leave you some examples:

Sharing state

But what about a shared state? Why would someone need to share state between multiple apps?

Let's use a real-world example, imagine this e-commerce:

Each square represents a micro frontend with a specific domain or functionality and could be using any framework.

Adding some content we notice some parts of the app that might need to share some data or state like:

Both item detail and suggested items might need to communicate and inform the cart when an item has been added
The suggested items could use the current items in the cart to suggest another item based on some complex algorithms
Item detail could show a message when the current item is already on the cart

If two micro frontends are frequently passing state between each other, consider merging them. The disadvantages of micro frontends are enhanced when your micro frontends are not isolated modules. this quote from single-spa docs it's awesome, maybe the suggested items could be merged with item detail but what if they need to be indifferent apps?

Well for those use cases I have tried 5 different modes:

Web Workers
Props and callbacks
Custom Events
Pub Sub library(windowed-observable)
Custom implementation

Comparison table

✅ 1st-class, built-in, and simple
💛 Good but could be better
🔶 Tricky and easy to mess up
🛑 Complex and difficult

Criteria	Web workers	Props and callbacks	Custom Events	windowed-observable	Custom implementation
Setup	🛑	✅	✅	✅	🔶
Api	🔶	💛	💛	✅	🔶
Framework Agnostic	✅	✅	✅	✅	🔶
Customizable	✅	✅	✅	✅	🔶

Web Workers

I have created an example to illustrate a simple communication between two micro frontends with a dummy web worker using workerize-loader and create-micro-react-app also known as crma to setup the react micro frontends.

This example is a monorepo with 2 micro frontends, 1 container app, and a shared library exposing the worker.

Worker 📦



let said = [];

export function say(message) {
  console.log({ message, said });

  said.push(message)

  // This postMessage communicates with everyone listening to this worker
  postMessage(message);
}

Container app

The container app is sharing the custom worky web worker.



...
import worky from 'worky';

window.worky = worky;

...

You should be thinking 🤔

But why don't you import this worky on every micro frontend?

When importing a library from the node_modules and using it in different apps every worker.js will have a different hash after bundled.

So each app will have a different worker since they're not the same, I'm sharing the same instance using the window but there are different approaches.

Microfrontend 1️⃣



const { worky } = window;

function App() {
  const [messages, setMessages] = useState([]);

  const handleNewMessage = (message) => {
    if (message.data.type) {
      return;
    }

    setMessages((currentMessages) => currentMessages.concat(message.data));
  };

  useEffect(() => {
    worky.addEventListener('message', handleNewMessage);

    return () => {
      worky.removeEventListener('message', handleNewMessage)
    }
  }, [handleNewMessage]);

  return (
    <div className="MF">
      <h3>Microfrontend 1️⃣</h3>
      <p>New messages will be displayed below 👇</p>
      <div className="MF__messages">
        {messages.map((something, i) => <p key={something + i}>{something}</p>)}
      </div>
    </div>
  );
}

Microfrontend 2️⃣



const { worky } = window;

function App() {
  const handleSubmit = (e) => {
    e.preventDefault();

    const { target: form } = e;
    const input = form?.elements?.something;

    worky.say(input.value);
    form.reset();
  }

  return (
    <div className="MF">
      <h3>Microfrontend 2️⃣</h3>
      <p>⌨️ Use this form to communicate with the other microfrontend</p>
      <form onSubmit={handleSubmit}>
        <input type="text" name="something" placeholder="Type something in here"/>
        <button type="submit">Communicate!</button>
      </form>
    </div>
  );
}

Pros ✅

According to MDN The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.

Cons ❌

Complex setup
Verbose API
Difficult to share the same worker between multiple micro frontends without using a window

Props and callbacks

When using react components you could always lift the state using props and callbacks, and this is an awesome approach to share small interactions between micro frontends.

I have created an example to illustrate a simple communication between two micro frontends using crma to set up the react micro frontends.

This example is a monorepo with 2 micro frontends and one container app.

Container app

I have lifted up the state to the container app and passed messages as a prop and handleNewMessage as a callback.



const App = ({ microfrontends }) => {
  const [messages, setMessages] = useState([]);

  const handleNewMessage = (message) => {
    setMessages((currentMessages) => currentMessages.concat(message));
  };

  return (
    <main className="App">
      <div className="App__header">
        <h1>⚔️ Cross microfrontend communication 📦</h1>
        <p>Workerized example</p>
      </div>
      <div className="App__content">
        <div className="App__content-container">
          {
            Object.keys(microfrontends).map(microfrontend => (
              <Microfrontend
                key={microfrontend}
                microfrontend={microfrontends[microfrontend]}
                customProps={{
                  messages,
                  onNewMessage: handleNewMessage,
                }}
              />
            ))
          }
        </div>
      </div>
    </main>
  );
}

Microfrontend 1️⃣



function App({ messages = [] }) {
  return (
    <div className="MF">
      <h3>Microfrontend 1️⃣</h3>
      <p>New messages will be displayed below 👇</p>
      <div className="MF__messages">
        {messages.map((something, i) => <p key={something + i}>{something}</p>)}
      </div>
    </div>
  );
}

Microfrontend 2️⃣



function App({ onNewMessage }) {
  const handleSubmit = (e) => {
    e.preventDefault();

    const { target: form } = e;
    const input = form?.elements?.something;

    onNewMessage(input.value);
    form.reset();
  }

  ...
}

Pros ✅

Simple api
Simple setup
Customizable

Cons ❌

Difficult to set up when there are multiple frameworks(Vue, angular, react, svelte)
Whenever a property changes the whole micro frontend will be rerendered

Custom Events

Using Synthetic events is one of the most common ways to communicate using eventListeners and CustomEvent.

I have created an example to illustrate a simple communication between two micro frontends, this example is a monorepo with 2 micro frontends and 1 container app using crma to set up the react micro frontends.

Microfrontend 1️⃣



function App() {
  const [messages, setMessages] = useState([]);

  const handleNewMessage = (event) => {
    setMessages((currentMessages) => currentMessages.concat(event.detail));
  };

  useEffect(() => {  
    window.addEventListener('message', handleNewMessage);

    return () => {
      window.removeEventListener('message', handleNewMessage)
    }
  }, [handleNewMessage]);

  ...
}

Microfrontend 2️⃣



function App({ onNewMessage }) {
  const handleSubmit = (e) => {
    e.preventDefault();

    const { target: form } = e;
    const input = form?.elements?.something;

    const customEvent = new CustomEvent('message', { detail: input.value });
    window.dispatchEvent(customEvent)
    form.reset();
  }

  ...
}

Pros ✅

Simple Setup
Customizable
Framework agnostic
Micro frontends don’t need to know their parents

Cons ❌

Verbose custom events api

Windowed observable

In this new era of "micro" services, apps, and frontends there is one thing in common, distributed systems.
And looking at the microservices environment a pretty much popular communication mode is pub/subs queues just like the AWS SQS and SNS services.
Since every micro frontend and the container are at the window, I decided using the window to hold a global communication using a pub/sub implementation, so I created this library mixing two concerns pub/sub-queues and Observables, called windowed-observable.

Exposing an Observable attached to a topic to publish, retrieve, and listen to new events on its topic.

Common usage



import { Observable } from 'windowed-observable';

// Define a specific context namespace
const observable = new Observable('cart-items');

const observer = (item) => console.log(item);

// Add an observer subscribing to new events on this observable
observable.subscribe(observer)

// Unsubscribing
observable.unsubscribe(observer);

...

// On the publisher part of the app
const observable = new Observable('cart-items');
observable.publish({ id: 1234, name: 'Mouse Gamer XyZ', quantity: 1 });

In this library there are more features like retrieving the latest event published, getting a list with every event, clearing every event, and more!

Using windowed-observable on the same app example:

Microfrontend 1️⃣



import { Observable } from 'windowed-observable';

const observable = new Observable('messages');

function App() {
  const [messages, setMessages] = useState([]);

  const handleNewMessage = (newMessage) => {
    setMessages((currentMessages) => currentMessages.concat(newMessage));
  };

  useEffect(() => {  
    observable.subscribe(handleNewMessage);

    return () => {
      observable.unsubscribe(handleNewMessage)
    }
  }, [handleNewMessage]);

  ...
}

Microfrontend 2️⃣



import { Observable } from 'windowed-observable';

const observable = new Observable('messages');

function App() {
  const handleSubmit = (e) => {
    e.preventDefault();

    const { target: form } = e;
    const input = form?.elements?.something;
    observable.publish(input.value);
    form.reset();
  }

  ...
}

Feel free to take a look and also use it ❤️

Pros ✅

Simple api
Simple setup
Pretty much customizable
Namespace events isolation
Extra features to retrieve dispatched events
Open source ❤️

Cons ❌

This library depends on the window so anyone can change its implementation

Custom implementation

After all of these examples you could also merge some of them and create your custom implementation, using your abstractions encapsulating your app needs, but these options could be tricky and easy to mess up.

Conclusion

There is no perfect or best solution, my suggestion is to avoid hasty abstractions and tries to use the simplest solution like props and callbacks if it does not suit to your needs try the other one until it feels good!

You can dive deep in those examples in this repository.

Comment below which one you prefer and why 🚀