HackerNoonModify

2026-04-28 23:55:33

A dashboard got called “wrong” in one of my meetings, and for a minute I thought we had a data issue.

We didn’t. The refresh had run, the SQL hadn’t failed, the chart was pulling from the right table, and the totals were exactly what the logic told them to be. But finance was looking at one number, operations had another in a spreadsheet, and the dashboard was showing a third. Same business, same week, same metric name, different answers.

That was the moment I realised:

:::info Most dashboard fights are not really about dashboards.

:::

They are about data definitions people thought were right but weren’t. Everyone says they want one source of the truth, but the truth usually falls apart much earlier than the visual layer and is it differs from team to team, when one team defines revenue by booking date, another by completion date, and nobody thinks that difference is important enough to document until they visually see it.

That is why I’ve become a lot more skeptical of complaints like “the dashboard is wrong.” Sometimes it is wrong. More often, it is doing exactly what it was built to do, and the real problem is that nobody agreed properly on what the number was supposed to mean in the first place.

Why this happened

Most KPI logic starts life in a messy way. It begins with a reasonable business question like how many active customers do we have, what was revenue last week, what is our conversion rate, then somebody writes a query, somebody else copies it into a report, someone downstream changes one filter, and within a few months a metric that sounded quite simple has split into three unofficial versions.

Nobody plans for that to happen, it just does. I didn’t either. Marketing team counted customers by login, Finance counted them by transaction and Operations excluded paused accounts. Revenue gets defined one way for finance and another way for operations because both definitions are useful for different purposes. Then eventually, all of them ended up on different dashboards with the same label.

:::info At that point, the dashboard was not doing analytics anymore. It is hosting a never-ending argument.

:::

The part nobody admits

Professionals love to say they want “one source of truth” but what they usually mean is “one source of data.” That is not the same thing.

:::warning You can have one warehouse, one pipeline, one BI tool, (as in my case) and still have a mess on your hands if nobody agreed on the logic between the raw data and the metric shown to the business. That gap is where trust breaks and ambiguity creeps in.

:::

You see it when someone asks why the dashboard does not match a spreadsheet. You see it when a stakeholder says, “That’s not how we define churn.” You see it when a weekly report gets derailed by ten minutes of metric debate before anybody even talks about what changed.

The problem isn’t that people are too picky, it’s that the KPI was never stable enough to survive ‘change’ with the business.

\

A simple test I use now

I simply use four blunt questions now.

When a KPI keeps causing trouble, I ask:

\

1. What exactly are we counting? Customer, order, account, session, product, case, day? If the counting unit is fuzzy, the KPI is already unstable.
2. What gets excluded? Refunds, test accounts, cancelled records, internal traffic, duplicate rows, partial periods. If exclusions are not explicit, expect fights.
3. What date are we using? Booking date, event date, invoice date, resolution date, payment date. Half of KPI confusion comes from time logic that never got written down properly.
4. Who owns the definition? Not who built the query. Who has the authority to say, “This is the definition, this is when it changed, and this is the one version other reports should reuse.”

If those four questions do not have sharp answers, the metric is not ready for a dashboard.

What this looks like in practice

Let’s take completed revenue as an example

All product teams are excited by the sound of it but almost nobody means the same thing when we say, ‘completed revenue’

Here is a simple version of how I would define it in code if I wanted the logic to be clear enough that people could argue with the definition, not the dashboard.

\

with base_orders as (
    select
        order_id,
        customer_id,
        completed_at::date as order_day,
        gross_revenue,
        coalesce(refund_amount, 0) as refund_amount,
        status,
        is_test_order
    from fact_orders
),
 
kpi_ready_orders as (
    select
        order_id,
        customer_id,
        order_day,
        gross_revenue - refund_amount as net_revenue
    from base_orders
    where status = 'completed'
      and is_test_order = false
),
 
daily_completed_revenue as (
    select
        order_day,
        count(distinct order_id) as completed_orders,
        sum(net_revenue) as completed_revenue
    from kpi_ready_orders
    group by order_day
)
 
select *
from daily_completed_revenue
order by order_day;

\ That query is not too clever; it is useful because it makes the assumptions visible.

:::tip Completed means status = 'completed'. \n Revenue means grossrevenue - refundamount. \n Test orders are excluded. \n The grain is daily, based on completed_at.

:::

Now somebody can disagree properly. They can say, “We should use invoice date instead,” or “Refunds should be reported separately.” Fine, that is a real business discussion. What they should not be doing is discovering those assumptions accidentally after the dashboard is already live.

Dashboard layer

This is the flow I keep seeing:

The complaint lands at the dashboard layer because that is what people see but the damage usually happened in the KPI definition layer.

That is the layer that decides:

• what counts
• what gets filtered out
• what date matters
• which edge cases are included
• whether the same metric name means the same thing everywhere

If that layer is weak, the dashboard has no chance. It can only display the confusion more neatly.

The measurable result

I did not measure success here by prettier charts or fewer comments about formatting.

The real metric is how often the number gets challenged. A useful result statement for this kind of story is:

:::info After moving disputed KPIs into a shared logic layer and forcing reports to reuse the same calculation path, metric clarification threads dropped by [X%] over [Y weeks], and recurring review time fell by [Z hours] per month.

:::

That is the outcome that matters, less debate, less rework and faster decisions.

2026-04-28 23:50:30

What happens when an AI agent signs off on a wire transfer before a human can review it?

In 2026, that question is no longer hypothetical. Enterprise finance teams are watching agents rebalance positions, execute payments, and move capital at machine speed across digital asset rails. The compliance and audit infrastructure they inherited was built for static workflows and human operators. It was never designed to keep up.

\ W3.io, the New York-based platform led by enterprise blockchain veteran Porter Stowell, has announced the launch of what it describes as the first control platform for agent-powered finance, live on the Avalanche network. The platform is already processing more than 200,000 workflows per day across five enterprise verticals. The Avalanche Foundation has made a strategic investment in W3 to accelerate adoption. Terms of the investment were not disclosed.

\

The accountability gap

The thesis behind W3 is structural. Most enterprise controls were designed around the assumption that a human operator stands between intent and execution. Approval queues, dual-signoff requirements, and post-transaction audit trails all assume a clock running in human time. AI agents do not respect that clock. They execute thousands of decisions per minute, each one a transaction that creates downstream exposure for the enterprise that deployed them.

\

The cost of this mismatch is paid in two places. Compliance teams either slow agents down to a pace they can supervise, defeating the productivity case, or they let agents run and accept blind spots in the audit trail. Both are losing positions. W3 is betting that the right answer is neither, and that a programmable control layer can preserve agent speed while keeping humans in command of the rules.

\

Why Avalanche, and why now

The choice of Avalanche as the launch network reflects where institutional capital has actually deployed. The network supports more than 70 live Layer 1 blockchains processing roughly 40 million daily transactions across enterprise, institutional, and public sector deployments in more than 50 countries. Its institutional footprint includes BlackRock, JPMorgan, Citi, KKR, Apollo, and Franklin Templeton.

\

\ \ For the Avalanche Foundation, the investment is a category bet, not a product bet.

\ According to Chief Investment Officer at the Avalanche Foundation, Matias Antonio,

"Agent-powered finance is going to be one of the most consequential shifts in how money moves. We invested in W3 because they are building the control infrastructure this category needs, and we are actively connecting them to the institutions that need it most."

\ That ecosystem also defines the problem W3 is trying to solve. Each of those institutions has built or integrated its own compliance, custody, settlement, and payments infrastructure. None of them ships a complete stack. An enterprise that wants to operate on digital asset rails today faces months of custom integration work just to assemble the components it needs to run a single workflow. The cost and complexity have kept all but the largest balance sheets on the sidelines.

\

What the platform actually does

W3 aggregates modular financial services across payments, custody, compliance, settlement, and storage into unified workflows. Partners on the platform include Circle, Paxos, Stripe, MoonPay, Privy, Pyth, Chainalysis, and Storj. The architectural claim is that a partner integrates once with W3 and becomes available inside every workflow on the network. A new integration that previously required months now takes hours.

\

\ CEO of W3.io, Porter Stowell, explains,

\

Agents are moving money faster than enterprise controls can follow. We built the platform that lets finance teams keep pace without giving up oversight. One integration connects a business to every financial service on the network. That is what agent-powered finance looks like in production, and we are shipping it.

\

What this means for institutional adoption

The implication for enterprise treasurers and risk officers is concrete. The cost barrier that has kept mid-market institutions out of digital asset infrastructure was never about the underlying rails. It was about the integration work required to connect those rails to the financial controls a regulated entity actually needs to operate. If W3's platform model holds at scale, the question shifts from whether mid-market institutions can afford to build agent-powered workflows to whether they can afford not to.

\ The harder question is governance. Liability for an agent-executed transaction does not disappear because the workflow was assembled in an afternoon. Auditors, regulators, and enterprise risk officers will eventually ask who carried the decision rights at the moment an agent moved capital, and on what authority. W3's design places that question at the center of the platform rather than at the edge. Whether the rest of the institutional stack is ready to answer it is a separate matter.

\ W3 is in production with enterprise clients across five verticals. Additional integration partners are expected to come online in the coming weeks, with each new partner expanding the range of financial products enterprises can build and deploy on Avalanche without custom development. The category did not exist eighteen months ago. Whether agent-powered finance becomes a durable institutional layer or a phase will depend less on the agents themselves and more on whether the control infrastructure underneath them holds.

Don't forget to like and share the story!

\ \

2026-04-28 23:44:46

\ When we started to work on microfrontend migration on one of our projects, the architecture looked great on paper (like always): one host shell, several remote apps, and teams could deploy independently on their own timelines.

But in practice it wasn't so clean. One part kept getting on my nerves: actually mounting remote React components inside the host. Each microfrontend came with the same glue code. Load the remote bundle, create a React root, render the component, keep track of the mounted instance, push updated props into it when the host re-renders and clean up listeners on unmount. And do not forget to handle load failures. It wasn't especially hard code. But it was just the kind of code nobody wants to repeat.

Another problem is type safety which had a habit of disappearing exactly where I wanted it most. Inside the remote, TypeScript understood the component props perfectly. But at the host boundary, that often collapsed into unknown and as any. If a remote added a required prop or renamed an existing one, the host usually did not find out from the compiler. After doing this a few times across different projects, I decided the pattern deserved a real abstraction instead of one more copy-pasted wrapper.

What I Wanted

It should be part of my toollkit package and should't be really hard. Something much more practical. The goal was simple:

• remove repetitive host-side boilerplate
• keep prop types across the host/remote boundary
• work with separate bundles and separate React roots
• avoid shared stores, global registries, and code generation
• fit into an existing Module Federation setup without changing how remotes are versioned or deployed

That idea transformed to @mf-toolkit/mf-bridge

The Base

The package has two parts: one wrapper on the remote side, and one host component that takes care of the integration.

On the remote side, you define the entry once:

import { createMFEntry } from '@mf-toolkit/mf-bridge/entry'
import { CheckoutWidget } from './CheckoutWidget'
export const register = createMFEntry(CheckoutWidget)

On the host side, you render the bridge where the remote should appear: \n

import { MFBridgeLazy } from '@mf-toolkit/mf-bridge'

<MFBridgeLazy 
register={() => import('checkout/entry').then(m => m.register)} 
props={{ orderId, userId }}
fallback={<CheckoutSkeleton />}
/>

That’s all. With MFBridgeLazy, the host doesn’t have to deal with all the hassle of loading things on demand, setting up the root, updating stuff, cleaning up, or handling event listeners — the tool does it all. Plus, because the register function has clear types, the host can automatically figure out what props the remote component needs.

If the remote component suddenly needs a new prop, you’ll see a TypeScript error right away during development, not after the app is already live and causing problems.

How Prop Updates Travel

This was the part I wanted to keep as boring and predictable as possible. \n Once a remote component is mounted, it lives in its own React root. That means the host cannot simply re-render it as if it were a normal local child. The host still needs a way to send updated props into that remote tree every time its own state changes. \n There are plenty of ways to solve this: shared stores, shared context, global event buses, custom registries. I wanted the smallest possible mechanism that stayed local to each mounted microfrontend. \n So `mf-bridge` uses the one thing both sides already share: the mount element.

When the host re-renders with new props, the bridge dispatches a `CustomEvent` on that specific DOM element. The remote listens to events on that same element and re-renders with the new props. That is it. \n I like this approach for a few reasons. \n First, it is naturally isolated. If you have several microfrontend slots on the same page, each one has its own mount element, so updates do not bleed across instances. \n Second, it does not need a shared module graph or global state container just to move props around. \n Third, it keeps the contract very explicit: the host owns the mount point and the props, and the remote owns how it renders them. \n Internally, the package wraps this in a small typed DOM event bus, but consumers do not really need to think about those details.

Why This Helped More Than Just Saving Lines of Code

The obvious benefit is less boilerplate. If a page has five remote slots, I no longer end up with five slightly different wrappers all doing the same lifecycle work.

But the bigger benefit is moving problems earlier in the process.

Before this, the host/remote boundary was often exactly where type information got blurry. That made one of the most important contracts in the system feel surprisingly fragile. A remote could evolve, and the host would not always know it had fallen out of sync.

With mf-bridge, prop inference flows from the remote entry to the host usage. That changes the feedback loop. A contract mismatch becomes a compile-time problem instead of an incident report.

There is also a reliability benefit in the lifecycle handling. The package takes care of the repetitive, easy-to-forget parts:

• lazy loading with a fallback UI
• clean mount and unmount behavior
• prop streaming on re-renders
• listener cleanup
• error handling when the remote fails to load
• optional preloading and retry behavior
• optional hooks for setup and teardown on the remote side when you need DI or per-mount initialization

None of these features are individually groundbreaking. The value is that they come together in one small, reusable bridge instead of being re-implemented in every host wrapper.

The Cases I Wanted to Be Sure About

When the basic version start to work, I spent a bit more time on some of scenarios that usually make microfrontend wrappers fragile.

One of that cases was multiple instances of the same remote on a single page - widget in the main content area, a compact version in a sidebar, or the same remote mounted in a few different places. I wanted to make sure what updates stayed local to the exact mount point instead of leaking. Using the DOM element itself as the transport turned out to be a very practical way to preserve that isolation.

Another important case was failed loading. I did't want the host to end up with a blank hole in the UI just because a remote bundle failed on the first attempt. That is why the bridge supports fallbacks, preloading, and retry behavior. I think that kind of thing that makes an integration feel solid. \n And sure we should not forget about what happens when the problem is rendering. If a remote drops during render, I do not want that failure to destabilize the whole host page. So error handling became part of the design too: we keep the failure contained to the mount point, surface the error to the host, and make recovery possible when new props arrive. Then there is setup and unmount - that case covered too

Where It Fits Compared to React.lazy or Portals

This package is not a replacement for React.lazy, and it is not trying to be cleverer than React.

If your component lives in the same bundle and the same React tree, React.lazy is still the natural tool. If you just want to render into a different DOM node inside the same tree, portals are great.

mf-bridge is for the awkward case those tools do not cover well: a component living across a Module Federation boundary, loaded from a separate bundle, mounted into its own React root, but still expected to behave like a first-class part of the host page.

That is the gap I wanted to close.

A Small Package, Not a New Platform

I also cared quite a bit about keeping the package lightweight. It has zero production dependencies and uses the browser's native CustomEvent API for prop streaming. In practice, that means less surface area, fewer moving parts, and one less utility layer to debug when something goes wrong.

The goal was never to build a microfrontend platform. It was simply to remove a recurring nuisance and make the host/remote boundary feel safer.

Sometimes that is enough to justify a package.

I published it as @mf-toolkit/mf-bridge

Repository, docs, and examples: github.com/zvitaly7/mf-toolkit

If you are working with Module Federation and you already have a small pile of hand-written wrappers around remote React components, this may save you some time. And if you have solved the same problem in a completely different way, I would genuinely be curious to compare notes.

\ \

2026-04-28 23:32:23

Roma, Italy, April 28th, 2026/CyberNewswire/--RaccoonLine, a decentralized VPN built on VLESS protocol and peer-to-peer node infrastructure, today published its ranking of the top 5 decentralized VPNs available in 2026. The report evaluates RaccoonLine, Mysterium, Sentinel, Orchid, and Deeper Network across six criteria: protocol quality, DPI resistance, privacy architecture, token economics, platform support, and hardware availability.

Key Findings

• VLESS protocol, used by RaccoonLine, provides stronger resistance to deep packet inspection than WireGuard or OpenVPN, making it more reliable in countries with active censorship infrastructure
• Mysterium holds the largest established node network in the dVPN segment, built over eight years of operation since its 2018 founding
• Sentinel is the most active open-source framework for developers building on decentralized VPN infrastructure
• Node operators earn cryptocurrency tokens across all five networks reviewed. RaccoonLine pays ROCC tokens with no GPU or specialized hardware required
• All five products in the ranking have active networks and real user bases as of 2026

How the Ranking Was Built

"We evaluated each product the way a privacy-conscious user would," said German Melnik, product CMO. "Protocol matters because a VPN that gets blocked in your country is not useful. Token economics matter because the incentive model determines whether the network grows or stagnates. And honesty about weaknesses matters because users making real decisions need accurate information, not marketing copy."

\ The ranking used six criteria: node network size and geographic coverage, protocol quality and DPI resistance, privacy architecture (whether no-log is structural or policy-based), token economics and node operator compensation, platform support across desktop and mobile, and hardware availability for whole-home coverage.

The Top 5 Decentralized VPNs in 2026

#1 RaccoonLine - Best Overall dVPN in 2026

RaccoonLine ranks first based on its combination of modern protocol design, token economics, and built-in decentralized file storage. It runs on VLESS protocol with Wandering Flow routing, a dynamic path-switching mechanism that cycles traffic through the P2P node network continuously. Traffic produced by this combination resembles standard HTTPS rather than identifiable VPN traffic, which makes it harder to filter by DPI systems.

Node operators earn ROCC tokens for sharing bandwidth. Setup requires no specialized hardware: a stable internet connection and a machine running the node software is sufficient. RaccoonLine also includes built-in decentralized file storage (DFS), extending privacy protections to file access beyond browsing. A dedicated dVPN router for whole-home network protection is currently in development.

Honest assessment: RaccoonLine is a newer network. Its node count is smaller than Mysterium's established infrastructure. Users who prioritize raw exit node volume over protocol quality will find Mysterium's larger network an advantage.

• Protocol: VLESS with Wandering Flow routing
• Token: ROCC
• Platforms: Windows, macOS, iOS, Android
• Best for: Users in censored regions, crypto traders, privacy-focused users, passive income seekers

#2 Mysterium - Most Established dVPN Network

Mysterium has operated since 2018, making it one of the longest-running projects in the decentralized VPN space. It runs on WireGuard protocol with residential IP nodes and compensates operators in MYST tokens. The node network is large and geographically distributed, with multiple third-party applications built on top of its infrastructure.

The main limitation is protocol choice. WireGuard is fast and well-tested but has a recognizable traffic signature that DPI systems in China, Iran, and UAE can identify. Mysterium's blog has not published updates since 2022, which raises questions about development momentum. For users who need a proven node network above all else, Mysterium remains the most established option.

• Protocol: WireGuard
• Token: MYST
• Best for: Users who want a large, battle-tested node network with residential IPs

#3 Sentinel - Best Open-Source Option

Sentinel is a dVPN framework built on Cosmos blockchain. It is open-source, which means developers can build their own applications on top of the Sentinel node network. The framework supports both WireGuard and V2Ray protocols. The DVPN token compensates node operators. Sentinel has maintained consistent development activity between 2024 and 2026, and its AI data layer (Scout) positions the project beyond pure VPN use cases.

The main weakness is complexity. Sentinel's ecosystem of third-party apps is wide but inconsistent, and the technical setup requires more knowledge than RaccoonLine's unified product. Non-technical users will find the onboarding friction higher than other options in this ranking.

• Protocol: WireGuard / V2Ray
• Token: DVPN
• Best for: Developers and technically advanced users building on dVPN infrastructure

#4 Orchid - Most Flexible Payment Model

Orchid uses a micro-payment lottery model on Ethereum. Users pay per byte of bandwidth consumed through randomized small transactions that reduce on-chain fees. The standout technical feature is multi-hop routing: traffic passes through multiple independent nodes before exiting, so no single node operator can connect origin and destination.

Orchid's development activity has been limited since 2022 and the community is smaller than Mysterium or Sentinel. The per-byte payment model creates friction for users unfamiliar with managing OXT token balances. For users who specifically need multi-hop anonymity, Orchid's architecture delivers it. For general use, the simpler onboarding of RaccoonLine or Mysterium is more practical.

• Protocol: Multi-hop (custom)
• Token: OXT (Ethereum)
• Best for: Users who require multi-hop anonymity and are comfortable with Ethereum-based payments

#5 Deeper Network - Best Hardware dVPN

Deeper Network's core product is the Deeper Connect device, a physical router that handles all dVPN functions at the hardware level. Every device connected to the home network gets protection without requiring app installation on each one. DPR tokens reward the bandwidth the device contributes to the network.

The hardware-first approach has real advantages for users who want whole-home coverage without software configuration. The main drawbacks are the higher upfront cost of the device and limited protection for users who need mobile coverage away from home.

• Protocol: Custom (Deeper proprietary)
• Token: DPR
• Best for: Users who want a physical device for whole-home protection with minimal software setup

Comparative Overview of Leading dVPN Models

• Most complete feature set in one product: RaccoonLine
• Largest proven node network: Mysterium
• Open-source developer framework: Sentinel
• Multi-hop anonymity: Orchid
• Plug-and-play hardware coverage: Deeper Network

"The decentralized VPN market is more mature than most people realize," German Melnik, product CMO said. "All five products in this ranking have working infrastructure and real users. The differences come down to protocol choices, token economics, and what each network prioritizes. We published this ranking because we think the space benefits from clear, honest comparisons rather than promotional content that avoids the tradeoffs."

About RaccoonLine

RaccoonLine is a decentralized VPN built on VLESS protocol and peer-to-peer node infrastructure. Node operators earn ROCC tokens for contributing bandwidth to the network. The product includes built-in decentralized file storage and clients for Windows, macOS, iOS, and Android. A dedicated dVPN router is currently in development. More information is available at raccoonline.com.

Press Contact

RaccoonLine Communications

raccoonline.com

Contact

CMO

German Melnik

Raccoonline.com

[email protected]

:::tip This story was published as a press release by Cybernewswire under HackerNoon’s Business Blogging Program

:::

Disclaimer:

This article is for informational purposes only and does not constitute investment advice. Cryptocurrencies are speculative, complex, and involve high risks. This can mean high prices volatility and potential loss of your initial investment. You should consider your financial situation, investment purposes, and consult with a financial advisor before making any investment decisions. The HackerNoon editorial team has only verified the story for grammatical accuracy and does not endorse or guarantee the accuracy, reliability, or completeness of the information stated in this article. #DYOR

2026-04-28 23:27:39

IT professionals (like any sane person) want to get rid of mindless tasks: automate testing, speed up releases, and reduce coding errors. So when AI agents appeared on the scene — not just suggesting how to write a function, but actually performing some tasks — my team of 90 developers couldn’t ignore the opportunity.

Our product combines IIoT technologies, machine learning, artificial intelligence, and cloud solutions. Its goal is to detect deviations in industrial equipment performance and prevent failures. In this column, I’ll share our experience using AI agents in developing and supporting this product, along with thoughts on which tasks are worth delegating to them — and which are not.

A bit of theory: the difference between LLMs and AI agents

LLMs, like ChatGPT or GitHub Copilot, have become standard tools for developers, including my team. They help write code, explain errors, and generate documentation. LLMs respond only to prompts: a person asks a question, evaluates the answer, and decides how to use it. They’re like an intelligent “autocomplete” with deep context, but not an autonomous executor.

AI agents, by design, go further. They don’t just generate code or text — they perform tasks almost autonomously: planning sequences of actions, working with repositories, CI/CD, APIs, maintaining context, and even interacting with other agents or humans. If Copilot merely suggests how to fix an error, a Copilot Agent can create a branch, make changes, run tests, and open a Pull Request. The idea is that an agent isn’t just a tool — it’s almost like a teammate who can actively participate in development.

Where agents actually help developers

Gartner analysts predict that by 2026, over 40% of enterprise applications — CRM, ERP, cybersecurity systems, analytics, data tools, and more — will include built-in AI agents that automate developers’ repetitive tasks, from updating libraries to analyzing logs.

But it’s important to understand not just what agents can do, but where their use truly delivers real gains in development speed, quality, and stability. Below are the key areas where my team successfully uses agent systems, and where they genuinely save a lot of time.

\

• Prototyping. The biggest impact for us comes from creating demo projects with AI agents. Recently, we needed a web app that, after uploading photos of factory equipment, would generate a full structure of that equipment. Using Replit Agent, I built this app in 2–3 hours. Its design wasn’t very polished, and it was a bit slow, so optimization was needed. But it was already a working product that could be presented to someone and used to validate a business idea — and that was genuinely impressive.

\

• Code generation. Tasks that used to take hours can now be partially delegated to a digital teammate. In our case, this involves repetitive actions, like writing unit tests for a new set of API endpoints. Importantly, the agent adapts to the project’s context, architecture, and coding style. But a human must provide very precise instructions for code generation. For example: “Create a model–repository–service–DTO–controller for a table (with schema description or just the name if the agent has database access), implement the following business logic (list of actions), and follow the project’s style and context”.

\

• Testing and quality assurance. AI agents can automatically create test scenarios based on requirements or change history, run them in CI pipelines, and collect reports. In my team, tests are a mandatory tool for developers. When writing tests become routine — fast and confident — I strongly encourage the use of AI agents. In my estimation, they save 30–50% of an experienced developer’s time. It’s important to remember: if you write a bad test, the agent will also produce a bad test. Agents excel at quickly generating positive test cases — verifying that functions work correctly. Negative test cases, where bugs need to be found, in my view, should not yet be fully delegated to agents.

\

• Automation of routine engineering tasks. We integrated GitHub Copilot Agent to automate code reviews and optimize code in daily workflows. We also use it to translate algorithms from one language to another and reintegrate them. From our experience, GitHub Copilot Agent works very well with Node, TypeScript, and JavaScript, reasonably well with Python, but poorly with PHP. Another example of a routine task that can be delegated to an agent is fixing errors during file updates. Agents integrated into IDEs like VSCode handle this effectively.

\

• Code maintenance and refactoring. AI systems in this area are meant to act as intelligent inspectors: they analyze the codebase, identify duplicate fragments, unused dependencies, or potential bugs, and then autonomously create Pull Requests with suggested changes. From our experience, when using agents in their standard configuration (automatic mode, no additional settings), GitHub Copilot Agent performs worse at code optimization compared to Claude or Codex Agent. Even with the latter, some errors still need manual correction.

Most mistakes are related to the programming languages used by the team. For example, in languages with so-called “magic methods” and no strict typing, like PHP (__call, __get, __set, __invoke), the agent may misinterpret variable scope or assume a variable will be created automatically. Errors can also occur when generating signatures for magic methods, such as incorrect parameter typing or redundant iterations.

In strictly typed languages like Go or C, most errors involve return types — returning a value instead of a pointer, or using the wrong type altogether. Additionally, AI agents still struggle to correctly handle inter-package dependencies, such as selecting the latest safe version of library X that is fully compatible in quality and dependencies with library Y.

Why full autonomy is still far off

Unlike LLMs, AI agents have memory, understand sequences of actions, and can plan steps to achieve a goal. But this only works when the agent is adapted to a specific team’s workflow. Initially, it “learns” the project structure, templates, and developers’ habits, and only then can it take some independent steps.

However, this autonomy is very limited. In small companies, the situation may differ, but in the enterprise, there’s no question of AI agents being fully autonomous. Large organizations must follow information security standards — ours being ISO/IEC 27001. According to this standard, nothing goes into production without human validation. Violating this could result in losing certification — and with it, B2B clients who can no longer trust you with their data.

So, despite bold claims, agents function as assistants, not full-fledged specialists. They integrate into IDEs, CI/CD, repositories, and monitoring systems, but remain part of the team workflow rather than independent entities. I’m convinced that every agent still needs a human manager.

2026-04-28 23:12:23

Most engineering teams do not set out to manage infrastructure. They start with a product idea, a customer need, or a business problem.

Infrastructure enters the picture as a means to an end. Servers need to be provisioned. Databases need to be configured. Networks need to be secured. At first, this work feels necessary and even empowering. It gives teams control.

But over time, that control turns into a burden.

What begins as a few Terraform scripts or cloud console clicks evolves into a growing layer of responsibility.

Teams find themselves maintaining deployment pipelines, debugging networking issues, rotating credentials, patching systems, and responding to incidents unrelated to their product logic.

This is the hidden tax of infrastructure. It is not a line item in your budget, but it is paid every day in engineering time, cognitive load, and lost focus.

Infrastructure is not a one-time cost

A common mistake teams make is treating infrastructure as a setup task. Something you “get right” once and move on from.

In reality, infrastructure is a continuous system. It changes with scale, traffic patterns, security threats, and team structure.

Every component you introduce adds a long tail of operational work. A load balancer is not just a load balancer. It requires configuration tuning, monitoring, failover planning, and periodic upgrades. A database is not just storage. It brings backup strategies, replication concerns, indexing decisions, and performance tuning.

Even with infrastructure-as-code tools, the maintenance burden does not disappear. It becomes codified, but it still exists. Engineers must review changes, manage state, handle drift, and respond when things break.

The cost compounds quietly. It shows up in slower delivery cycles, longer onboarding times for new engineers, and increased risk during deployments. It is not visible in sprint planning, but it is always there.

The cognitive load problem

One of the most underestimated aspects of infrastructure management is cognitive load.

Modern systems are complex. Distributed architectures, microservices, container orchestration, and multi-region deployments all introduce layers of abstraction that engineers must understand.

When a team owns its infrastructure, every engineer becomes partially responsible for this complexity. Even if you have dedicated platform engineers, application developers still need to understand enough to debug issues and deploy changes safely.

This context switching has a real cost. An engineer working on a feature must also think about container resource limits, networking rules, observability gaps, and failure modes. Instead of focusing on business logic, they are juggling operational concerns.

Cognitive load slows teams down. It increases the chance of mistakes. It makes systems harder to reason about. And it reduces the time engineers spend on the work that actually differentiates your product.

Reliability is harder than it looks

Running infrastructure in production means owning reliability. This includes uptime, latency, data integrity, and incident response. Many teams underestimate how difficult this is to do well.

High availability is not just about redundancy. It requires careful design, testing, and ongoing validation. Failover mechanisms must be exercised. Monitoring systems must be tuned to detect real issues without creating noise. Incident response processes must be defined and practised.

When something goes wrong, the cost is immediate and visible. Engineers are pulled into debugging sessions. Customers are affected. Business metrics drop. Postmortems are written. Action items are created, which often add more infrastructure complexity.

Over time, teams build layers of safeguards and tooling to improve reliability. But each layer adds more to manage. The system becomes harder to change. The risk of unintended consequences increases.

This is the paradox of self-managed infrastructure. The more you invest in reliability, the more complex your system becomes, and the more effort it takes to maintain that reliability.

Security and compliance never stand still

Security is another dimension where the hidden tax becomes clear. Threats evolve constantly. Best practices change. Compliance requirements grow more stringent.

When you run your own infrastructure, you are responsible for staying ahead of these changes. This includes patching systems, managing access controls, encrypting data, auditing logs, and responding to vulnerabilities.

Even small gaps can have serious consequences. A misconfigured permission, an outdated dependency, or an exposed endpoint can lead to breaches. The cost of prevention is an ongoing effort. The cost of failure can be catastrophic.

Compliance adds another layer. For teams in regulated industries, infrastructure must meet specific standards. This often requires documentation, audits, and controls that go beyond basic security practices.

All of this work is necessary, but it does not directly contribute to your product’s value. It is part of the hidden tax you pay for owning infrastructure.

The illusion of control

One of the main reasons teams continue to manage their own infrastructure is the belief that it gives them control. They can customise everything. They can optimise for their specific needs. They are not dependent on external platforms.

While this is true in theory, in practice, the level of control is often overstated. Most teams do not need deep customisation at the infrastructure level. They need reliability, scalability, and predictable behaviour.

The control you gain comes at the cost of responsibility. Every customisation must be maintained. Every optimisation must be monitored. Every deviation from standard patterns increases the risk of issues.

In many cases, teams end up recreating capabilities that are already available in managed platforms. They build internal tooling for deployment, scaling, and monitoring, only to maintain it indefinitely.

The question is not whether you can manage your own infrastructure. It is whether you should. Most small to mid-sized teams should not be managing infrastructure at all. If it is not your competitive advantage, it is a distraction.

The rise of PaaS as an alternative

Platform-as-a-Service, or PaaS, changes the equation. Instead of managing infrastructure directly, teams deploy applications to a platform that handles the underlying complexity.

With PaaS, concerns like provisioning, scaling, load balancing, and patching are abstracted away. Engineers focus on code and configuration, not on servers and networks.

This does not eliminate all operational work, but it shifts the responsibility. The platform provider handles the heavy lifting. Your team benefits from standardised, battle-tested infrastructure without having to build and maintain it.

PaaS also reduces cognitive load. Developers interact with a simpler interface. Deployments become more predictable. Observability is often built in. This allows teams to move faster and with greater confidence.

Importantly, PaaS aligns infrastructure with application needs. Instead of designing infrastructure first and fitting applications into it, teams define what their application requires, and the platform provides it.

Heroku was the first to bring PaaS mainstream. Since Heroku is shutting down, I moved to Sevalla for its simplicity and the speed with which new features, especially agentic tools, are introduced. Here is a list of alternatives.

Speed is a competitive advantage

In most markets, speed matters. The ability to ship features quickly, respond to feedback, and iterate on ideas is a key competitive advantage.

Infrastructure management can slow this down. Changes require coordination. Deployments carry risk. Debugging issues takes time away from development.

By reducing the infrastructure burden, PaaS enables faster delivery. Teams can deploy changes more frequently. They can experiment with new ideas without worrying about underlying systems. They can recover from failures more quickly.

This is not just about engineering efficiency. It has a direct impact on business outcomes. Faster delivery leads to better products, happier customers, and a stronger market position.

Cost is more than the cloud bills

When teams evaluate infrastructure strategies, they often focus on direct costs. Cloud bills, reserved instances, and resource utilisation are measured and optimised.

But the hidden tax of infrastructure is mostly indirect. It includes engineering time spent on maintenance, the opportunity cost of delayed features, and the risk of outages and security incidents.

These costs are harder to quantify, but they are often larger than the direct costs. A single incident can consume days of engineering time. A delayed feature can impact revenue. A security breach can damage a reputation.

PaaS may appear more expensive on paper, but it often reduces total cost when you account for these hidden factors. It shifts spending from operational overhead to product development.

Rethinking ownership

The core question is not about tools or technologies. It is about ownership. What should your team own, and what should it delegate?

Your product is your core asset. It is what differentiates you in the market. Infrastructure, while critical, is a means to support that product.

By continuing to manage infrastructure, teams take on responsibilities that do not directly contribute to their goals. They pay the hidden tax in time, focus, and risk.

PaaS offers a way to rebalance this. It allows teams to delegate infrastructure concerns and focus on building value.

The shift is not always easy. It requires changes in mindset, tooling, and processes. But for many teams, it is a necessary step.

Because the real cost of infrastructure is not what you pay your cloud provider. It is what you give up to run it yourself.

\ \