I love data, dashboards, metrics. Always proud of how much data-driven I am. But I’m also a massive pain in the ass for engineering teams.
When I led mobile engineering teams, I started my day in Mixpanel and Crashlytics. Happy paths, UX glitches, conversions, error codes. I wanted to know everything.
Today, leading Platform Engineering, I practically live in Coralogix, Grafana, and a few hand-coded dashboards/status pages. My 50-widgets god views track every error 5xx, slow endpoint and web vitals degradation across hundreds of microservices and microfrontends our organization manages.
I also weaponized AI to generate incredibly detailed, multi-page incident reports for every bug I found. I was incredibly proud of the observability machine I’d built.
The problem? Engineers completely ignored it. This was super annoying - I can point out errors 500/503, not touched for years, even though I escalated that on all angles. I provided everything - logs, stack traces, service details, volume of the issue. 2 pages elaborate with 4 Grafana widgets pointing to a part issue.
I thought I was helping, but in reality, I was just shoveling more cognitive overload onto product engineering teams that were already drowning in a product super growth phase.
Took me some time to realize my failure wasn’t technical—it was deeply psychological. I fell into today’s trap of abundant content generation: I assumed the answer was to build more.
The Additive Bias
In April 2021, a study published in Nature proved exactly how deep this blind spot goes. Researchers gave participants a Lego bridge with uneven support pillars and asked them to stabilize it.
In the observational studies, 78% chose to add elements, while only 20% chose to subtract. Even when subtraction was the objectively superior and faster solution, people still defaulted to adding unless they were explicitly reminded that taking things away was an option.
The study proved that when asked to improve a situation, our brains default to searching for elements to add. We systematically overlook subtractive changes.
In the age of AI, where the marginal cost of creating code, text, and components has dropped to zero, this Additive Bias is dangerous.
We can generate endless reports, connect dozens of APIs, and bolt on new dashboard widgets simply because we can. Yet the true cost is not creation, but consumption. I covered it here:
The Three Mile Island Control Room
To understand what happens when the Additive Bias goes unchecked, look at the Three Mile Island nuclear accident.
As Cliff Kuang points out in his book User Friendly (a must-read if you want to understand UX better!), the 1979 disaster wasn’t caused by incompetent operators; it was a catastrophic failure of information architecture.
The control room was a masterpiece of over-creation. Hundreds of warning lights and alarms. When the core began to fail, everything lit up and buzzed simultaneously. The operators were completely paralyzed by cognitive overload.
Okay, now the confession: is there anyone reading here who doesn’t have such A Three Mile Island control panel in your observability dashboards? Mine happen to be depressingly red almost all the time 😅, even though the product seems to be working well.
And here’s the thing - when every metric is screaming for attention on a massive dashboard, the signal is entirely lost. My dashboards didn’t make my engineers’ lives easier; they just added cognitive weight.
The AI Trap and Hick’s Law
This year, I switched from dashboards to AI-generated incident reports, convinced I was fixing the problem. I have a few of the agentic flows digging through different CLIs.
Example: I have a morning-brief flow that fetches last 24hrs of alerts and spans a few subagents, that run: a) Coralogix CLI to fetch alerts, logs, and traces; b) cloud infra review of terragrunt files (from alert tresholds to identifying owners of the services); c) Github CLI to fetch the source code of affected groups of services.
If something catches my attention, there is a more detailed flow with the same CLIs for triaging the particular alert → tracking the root cause, identifying blast radius or corelating issues with the latest Pull Requests / Deploys.
For each I get the comprehensive summaries of why things were breaking. It’s very detailes (e.g. it brings the list of all CLI calls, so I can reproduce the entire reasoning process). But it is also massive reading block.
If the Nature study explains why we add, Hick’s Law explains exactly what it costs us when we do. Formulated in the 1950s, the law mathematically proves that the time it takes for a person to make a decision increases logarithmically with the number and complexity of choices.
By handing a developer a three-page AI summary, I hadn’t solved their problem.
The cognitive overload problem isn’t something new. There is also another framework NASA-TLX (Task Load Index)—the framework used to measure cognitive strain on astronauts. Looking my reports through the TLX lenses, I’m pretty sure I had actually spiked engineers’ Mental Demand and Frustration Level.
They now had to parse the AI’s logic, verify the evidence, and figure out the fix. The AI had successfully generated content, but it hadn’t reduced human confusion.
Tesler’s Law and the Agentic Shift
The breakthrough came when I stopped trying to generate insights and started focusing delivering value. This is with Tesler’s Law in mind.
Coined by Larry Tesler at Xerox PARC, the law states that every system has an inherent amount of irreducible complexity. You cannot magically make it vanish; you can only shift who has to deal with it.
If you want to simplify the user’s experience, the engineering team (or in this case, the AI agent) has to absorb the complexity.
Today, my agentic flow doesn’t write reports. It gathers the telemetry, correlates the logs, and actually attempts to reproduce the bug—writing and executing simple Node scripts to simulate the failing sequence. Then, it does the most important thing: it synthesizes all of that into a single executive summary attached to a ready-to-merge Pull Request.
I shifted the complexity to the agent, reducing the engineer’s interface down to a single, binary decision: Approve or Reject.
For those who want to verify the agent’s work, there is an appendix attached to the PR containing the raw CLI commands, logs, and prompts. The complex machinery is there if you need it, but it is hidden from the main view.
Less, But Better
Long before software interfaces existed, industrial designers fought this exact battle against over-creation. The functionalist principles of the mid-20th century—championed by Dieter Rams at Braun—serve as a masterclass for modern digital makers.
His core philosophy, Weniger, aber besser (”Less, but better”), is the physical embodiment of Tesler’s Law. Look at Rams’ design for the Braun ET66 calculator. It doesn’t have extra scientific functions exposed on the front. Rams absorbed the complexity of the internal electronics so the user could experience pure utility.
Good design is unnoticeable. It shouldn’t scream for attention with flashy, over-engineered components or massive AI-generated reports. It should act as a quiet, highly efficient tool.
In the age of AI, our major job is to edit, reduce, and simplify. Complexity is not a feature.