2026-03-04 06:08:19
Cloud dashboards show you the problem.
\ They don’t solve it.
\ Every organization running in AWS, Azure, or GCP eventually faces the same issue:
\ What teams need is not another dashboard.
\ They need an intelligent control plane.
\ In this article, I’ll walk through how to build a production-ready multi-agent FinOps system powered by:
\ This is implementation-focused. Minimal theory. Real architecture.
\ \
Most FinOps tools stop at:
\ But real optimization requires reasoning:
Should we downsize this instance? \n Is this idle volume safe to delete? \n What’s the performance risk?
\ Static rules are too rigid. \n Pure AI is too risky.
\ The solution: Rule-based triggers + LLM reasoning + human approval.
At a high level:
User → React UI → FastAPI → Agents → LLM → Structured Output → Human Approval
\ We separate responsibilities clearly:
\ This keeps the system enterprise-safe.
Instead of one monolithic “AI service”, we use specialized agents.
Detects inefficiencies and optimization opportunities.
Identifies unused resources that may be safely removed.
Recommends better instance sizing based on usage trends.
\ Each agent follows the same pattern:
\ This is not chat AI. \n This is constrained reasoning.
FastAPI acts as the orchestrator.
\ Example endpoint:
@app.post("/analyze/idle")
def analyze_idle():
data = fetch_cloud_metrics()
result = idle_agent.analyze(data)
return result
\ Responsibilities:
\ The API layer is critical. \n It prevents LLM outputs from directly impacting infrastructure.
Here’s what a simplified DiagnosticAgent looks like:
class DiagnosticAgent:
def __init__(self, llm_client):
self.llm = llm_client
def analyze(self, resource):
if resource["cpu_avg"] < 5 and resource["days_running"] > 14:
return self._call_llm(resource)
return None
Notice:
We do not send everything to the LLM.
We filter first.
\ This reduces:
We never ask open-ended questions.
\ We use structured prompts:
You are a FinOps optimization engine.
Given:
- cpu_avg: 2%
- monthly_cost: $430
- environment: production
Return:
- recommendation
- risk_level
- estimated_savings
- justification
Output JSON only.
We force:
\ The output must look like:
{
"recommendation": "Downsize to t3.medium",
"risk_level": "Low",
"estimated_savings": 180,
"justification": "CPU utilization below 5% for 30 days"
}
\ If parsing fails, we reject it.
\ Never pass raw model text downstream.
This agent is more sensitive.
\ Deletion is high risk.
\ Example logic:
if resource["attached"] is False and resource["days_idle"] > 30:
flag = True
\ The LLM is not deciding whether to delete.
\ It classifies:
\ Human approval is mandatory.
Rightsizing requires trend awareness.
\ We analyze:
\ Example:
if cpu_avg < 40 and cpu_peak < 60:
candidate = True
\ The LLM suggests a smaller instance while respecting performance buffers.
\ Again:
Recommendation, not execution.
The React dashboard shows:
\ This turns AI output into decision support.
\ Not automation.
Execution flow:
Frontend → Backend → Cloud API → Confirm status
\ \ Key safeguards:
\ AI assists. Humans decide.
We containerize:
\ Example Dockerfile:
FROM python:3.11
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
\ This allows:
This is where most AI projects fail.
\ Enterprise safeguards include:
\ AI without guardrails is a liability.
\ AI with structure becomes leverage.
It balances:
Rules + LLM + Humans
\ Instead of replacing decision-makers, it augments them.
\ The LLM:
\ It does not:
\ That separation is what makes this production-ready.
\ This is how you move from an AI demo to an enterprise system.
FinOps dashboards show cost.
\ Agentic AI systems generate action.
\ When designed correctly, multi-agent architectures can transform cloud cost management from reactive reporting to intelligent optimization.
\ The difference is not in using an LLM.
\ The difference is in how you architect around it.
\ Let’s connect 👇
🔗 LinkedIn: \n https://www.linkedin.com/in/dhiraj-srivastava-b9211724/
💻 GitHub (Code & Repositories): \n https://github.com/dexterous-dev?tab=repositories
\
2026-03-04 05:43:29
Ever wonder what would happen to an open source database project in case its main developers “got hit by a bus”? Or, less dramatically, if they leave the project completely. That’s what the “bus factor” (also called “truck factor”) measures: how many people would have to disappear before no one left knows how to fix or update specific parts of the code.
I’ve been messing around with a tool called the Bus Factor Explorer by JetBrains to explore the associated risk in some of the most popular open source databases. I looked at six of the big ones to see where they stand. Here’s the current baseline (March 2026) according to this tool:
| Database | Bus Factor (higher is better) | |----|----| | MongoDB | 7 | | MariaDB | 5 | | Redis | 5 | | MySQL | 2 | | PostgreSQL | 2 | | SQLite | 2 |
For example, for MongoDB to “hit a wall”, 7 devs would have to leave the project. For MySQL, PostgreSQL, and SQLite, if 2 devs leave, the project is at risk of stalling. Of course, this is just one factor; there are other factors that influence the continuation of open source projects, but this is still an interesting insight you can take into consideration when choosing a database.
\ The tool has a categorization according to the project’s bus factor (a baseline that can be adjusted in the tool if you want):
I also used the tool to see what happens to the root directories (the functional parts of the code) if you start unchecking the top contributors to each project. Specifically, I wanted to see the proportion of directories that would be “lost” if the top one or two contributors left the project. I ignored the individual files at the root level. The results look like this:
| Database | Directories (total) | Directories lost (1 dev gone) | Directories lost (2 devs gone) | |----|----|----|----| | Redis | 6 | 0 (0.0%) | 0 (0.0%) | | MariaDB | 30 | 2 (6.7%) | 5 (16.7%) | | MongoDB | 28 | 1 (3.6%) | 7 (25.0%) | | PostgreSQL | 6 | 0 (0.0%) | 5 (83.3%) | | MySQL | 30 | 1 (3.3%) | 30 (100.0%) | | SQLite | 11 | 5 (45.5%) | 11 (100.0%) |
Here, a lower number is better (fewer directories impacted). So, Redis is pretty strong in this simulation, as no directories would take a hit. On the other end, we have MySQL and SQLite, with 100% of their directories potentially left unmaintained if the top two developers leave. PostgreSQL would lose 83% of its directories in a similar situation. These were the big surprises to me, although all this is aligned with the fact that they have a low bus factor (high risk) of 2.
\ MariaDB did pretty well, especially when compared to MySQL, which supports what I have been trying to say about how MariaDB is much more than a fork of MySQL in my articles and talks (see this and this, if you are curious).
You should not rely merely on “bus factor” risk assessments. This is useful in mission-critical situations or when comparing projects that are even in other metrics that you might be using to compare and evaluate them. Here are some other aspects to look at:
I investigated the bus factor of other open source projects that I’m a big fan of, like MyBatis, Vaadin, and others, but I’ll let you do your own findings with the tool. Let me know if you find something interesting!
This appendix lists every directory and file at the root level that drops to a Bus Factor of 0 in the simulations.
.bazelrc.local.example, .gitattributes, .prettierignore, MODULE.bazel, distsrc, etc
bazel, buildscripts, jstests
VERSION, config.h.cmake, CMakeLists.txt, libmysqld, debian
VERSION, config.h.cmake, CMakeLists.txt, libmysqld, debian
mysql/mysql-server (root meta), iwyu_mappings.imp, config.h.cmake, CMakeLists.txt, libmysql, mysys, client, components, strings, mysql-test
storage, sql, router, extra, plugin, utilities, etc.COPYRIGHT, meson_options.txt
src, contrib, doc, config, interfaces, etc.VERSION, manifest.tags, make.bat, manifest.uuid, configure, README.md, mptest, main.mk, Makefile.msc, doc, manifest, tool, src, ext, test
\
2026-03-04 04:39:53
Hi hackers!
Building a website you can actually update yourself shouldn't require a developer on speed dial. Storyblok is the CMS that fixes that - and right now you can get 45 days of their Growth+ plan free.
\
Storyblok lets you build and manage websites, apps, and digital experiences without getting stuck in a developer queue every time something needs to change. With Growth+ you get:
\
\
:::tip Claim Your Free Storyblok Access
:::
:::warning ⚠️ You must sign up via the link above - the standard signup defaults to a 14-day trial only.
:::
\
https://www.youtube.com/watch?v=Hoed3twFEJ0&embedable=true
The only real limit is your imagination - someone generated an entire website from a single prompt, and another team turned it into a video game engine. Here's what others have already shipped:
\
:::tip Bonus: write about what you build on HackerNoon's Proof of Usefulness Hackathon and you're automatically entered to compete for $5,000 in cash prizes. See the full contest details.
:::
\ With love & treat your internet friends with respect, \n The HackerNoon Team ✌️
2026-03-04 03:37:18
AI tools have made generating code easier than ever, but they haven’t reduced the long-term cost of maintaining it. The real engineering discipline lies in distinguishing between core differentiators worth building and commodity systems better bought or integrated. Use AI to reduce integration overhead—not to justify rebuilding what already exists.
2026-03-04 03:20:11
The AI industry has a dirty secret. While nearly two-thirds of organizations are experimenting with AI agents, fewer than one in four have successfully scaled them beyond pilot programs. Welcome to 2026, the year the gap between AI ambition and AI reality became impossible to ignore.
After two years of breathless hype around generative AI and autonomous agents, the industry is waking up to a sobering truth: building a demo is easy, but building something that works reliably at scale is a fundamentally different problem. And the organizations that figure out the difference are going to define the next decade of technology.
Let’s rewind. In 2024, the tech world went all-in on AI agents. Every major cloud provider launched an agent framework. Startups raised billions on the promise of autonomous digital workers. The narrative was intoxicating: AI agents would handle your emails, manage your code deployments, negotiate your contracts, and maybe even run your company while you sipped coffee on a beach somewhere.
By mid-2025, the cracks were showing. Enterprises that had eagerly deployed agent prototypes found themselves drowning in edge cases. Agents that performed beautifully in controlled demos would hallucinate in production, misunderstand context in ways that caused real damage, or simply fail to integrate with the messy, legacy-ridden infrastructure that actual businesses run on.
Now, in early 2026, Gartner has officially placed generative AI in the “trough of disillusionment”, and many analysts predict AI agents will follow the same trajectory within the year. The agentic AI market is projected to surge from $7.8 billion to over $52 billion by 2030, but the path from here to there is littered with failed pilots, burned budgets, and disillusioned teams.
This isn’t a crisis. It’s an opportunity, if you know where to look.
Here’s what most people get wrong about the AI agent scaling gap: they assume it’s a technology problem. Better models, more compute, smarter architectures, surely that’s the answer, right?
Wrong. The research tells a different story. McKinsey’s latest analysis reveals that high-performing organizations, the ones successfully scaling AI agents to production, are three times more likely to succeed not because they have better models, but because they’re willing to fundamentally redesign their workflows.
Think about that for a moment. The differentiator isn’t the sophistication of the AI. It’s the willingness to change how humans work alongside it.
This makes intuitive sense when you stop and think about it. An AI agent doesn’t exist in a vacuum. It operates within a system, a web of processes, approvals, handoffs, data flows, and human decisions. Drop a brilliant autonomous agent into a broken workflow, and you get a brilliantly broken outcome, just faster.
The organizations winning at AI agents in 2026 aren’t asking “How do we make our agents smarter?” They’re asking “How do we redesign our work so that humans and agents can collaborate effectively?”
After studying dozens of successful enterprise AI agent deployments, I’ve identified three patterns that separate the winners from the rest.
The most successful agent deployments don’t try to automate entire workflows end-to-end. Instead, they target the “seams”, the handoff points between systems, teams, or processes where information gets lost, delayed, or distorted.
Consider a typical customer support operation. The naive approach is to build an AI agent that handles the entire support interaction from start to finish. The smart approach is to deploy agents at the seams: the moment a ticket gets classified and routed, the point where a support engineer needs to pull context from three different systems, the handoff from support to engineering when a bug report is filed.
These seam-based deployments succeed for a simple reason: they have well-defined inputs and outputs, they handle a manageable scope of decisions, and critically, a human is always nearby to catch failures. You’re not asking the agent to be perfect. You’re asking it to reduce friction at specific chokepoints.
The second pattern is architectural. Organizations that successfully scale agents design them to fail gracefully rather than trying to eliminate failure entirely. This is a mindset shift borrowed from distributed systems engineering. You don’t build a microservices architecture assuming every service will have 100% uptime. You build it assuming things will fail, and you design the system to handle that failure without catastrophe.
The best agent architectures I’ve seen in 2026 have explicit “confidence thresholds”, when an agent’s certainty drops below a certain level, it doesn’t guess. It escalates. It pauses. It asks for help. And the system around it is designed to handle that escalation smoothly, without breaking the user experience. This is the opposite of the “fully autonomous” vision that dominated the hype cycle. It’s less sexy, but it works.
Most organizations measure their AI agents on accuracy, did the agent get the right answer? and call it a day. The organizations that successfully scale go much deeper. They measure time-to-resolution, not just resolution accuracy. They track how often agents escalate and whether those escalations were appropriate. They measure user trust, do the humans working alongside the agent actually trust its outputs enough to act on them? They monitor drift, is the agent’s performance degrading over time as the world changes around it?
Most importantly, they measure end-to-end business outcomes. An agent that’s 95% accurate but takes longer than the manual process it replaced isn’t a success. An agent that’s 80% accurate but cuts time-to-resolution by 60% might be. The metrics you choose shape the system you build. Choose wrong, and you’ll optimize for benchmarks while your actual business impact stalls.
While the scaling gap dominates the enterprise conversation, there’s a quieter revolution happening underneath: the rise of smaller, domain-specific models. The era of “bigger is always better” is ending. Instead of one giant model trying to be good at everything, organizations are deploying smaller, more efficient models that are deeply specialized.
This matters for the agent scaling gap because smaller models are fundamentally easier to deploy, monitor, and control. They’re cheaper to run, faster to iterate on, and more predictable in their behavior. Financial services firms are deploying small, fine-tuned models for regulatory document analysis that outperform GPT-class models at a fraction of the cost. Healthcare organizations are using specialized models for clinical note summarization that are not only more accurate but also more auditable, a critical requirement in regulated industries.
As AI agents take on more responsibility in enterprise workflows, the security implications are becoming impossible to ignore. When you give an AI agent access to internal systems, customer data, and business-critical workflows, you’re creating a new attack surface. A compromised agent doesn’t just leak data, it can take actions. It can modify records, send communications, and make decisions that affect real people and real money.
The organizations getting this right are treating AI agents with the same security rigor they apply to human employees, identity management, access controls, audit trails, and the ability to revoke permissions instantly. Security can’t be a bolt-on. It needs to be a foundational design principle, integrated into the agent’s architecture from day one.
The AI agent scaling gap isn’t a sign that the technology has failed. It’s a sign that the technology has matured enough to encounter real-world complexity. That’s actually good news. It means we’ve moved past the vaporware phase and into the hard, rewarding work of building things that actually function in messy, complicated environments.
Here’s my prediction for the rest of 2026: the hype around AI agents will continue to cool. Some high-profile failures will make headlines. Skeptics will declare the whole thing a bubble. And quietly, in the background, the organizations that took the time to redesign their workflows, invest in security, choose the right metrics, and build trust with their users will start pulling away from the pack.
The gap between AI ambition and AI reality is real. But it’s not permanent. And the companies that close it first will have a head start that lasts for years.
The question isn’t whether AI agents will transform how we work. The question is whether your organization will be among the ones that figure it out in 2026, or the ones still running pilots in 2028.
2026-03-04 03:12:39
Anthropic recognized Databasus through their Claude for Open Source program. I want to talk about what this means, how the program works and how Databasus got here.
In 2023 I was working on several production projects and home projects, all running PostgreSQL. Every project needed backups. And every time it was the same story: write a bash script, set up a cron job, figure out where to store the dumps, hope the notification webhook still works, repeat. Multiply that by a dozen databases across different teams and environments and it gets old fast.
At some point I got tired of doing this over and over. So I built a small internal tool to handle it. Nothing fancy. Just a web UI on top of pg_dump with scheduling, a couple of storage options and email notifications when something went wrong. The idea was that anyone on the team could configure and monitor backups without touching the terminal.
I called it Postgresus. It ran on our servers, backed up our production databases, and I didn't think much about it beyond that.
\
\
In early 2025 I decided to open source it. The reasoning was simple: if it saves me time, maybe it saves other people time too. I pushed it to GitHub, wrote a README, set up a Docker image and shared it on Reddit and a few other places.
The response was bigger than I expected. Within weeks there were hundreds of stars, then thousands. Docker pulls started climbing. People were actually using it. Not just solo developers, but DevOps teams, DBAs, startups and companies running it in production for real workloads. I started getting messages from teams who replaced their internal backup scripts with Databasus and from companies that needed something simpler than pgBackRest but still reliable enough for production.
By the end of 2025, Postgresus had become the most starred PostgreSQL backup tool on GitHub, passing WAL-G, pgBackRest and Barman. These are established, enterprise-grade CLI tools that have been around for years. A web UI tool overtaking them on stars showed that there's real demand for backup solutions that teams can actually operate without deep infrastructure expertise.
By late 2025 the project had outgrown its name. Three things made the rename necessary.
First, "Postgres" is a trademark of PostgreSQL Inc. and you technically can't use it in project names. I'd been aware of this for a while but kept pushing it off.
Second, the tool was no longer just for PostgreSQL. We had added MySQL, MariaDB and MongoDB support. Calling it "Postgresus" while it backed up MongoDB didn't make much sense.
Third, the scope had changed. It started as a wrapper around pg_dump. By that point it had encryption, retention policies, team workspaces, RBAC, audit logs, health monitoring and 70+ storage destinations via Rclone. The project had evolved from a solo developer tool into something that teams and enterprises were running in production. It was a different project from what I originally built.
So in the end of 2025 we renamed it to Databasus. Same tool, new name that actually fits what it does.
For those unfamiliar: Databasus is a free, open source, self-hosted backup management tool for databases. PostgreSQL is still the primary focus, but MySQL, MariaDB and MongoDB are fully supported. Apache 2.0 license. Runs as a single Docker container or via Helm on Kubernetes. All data stays on your infrastructure, which matters a lot for teams with strict data governance requirements.
Here's what it does:
As of early 2026, the project has around 5,800 GitHub stars, over 250,000 Docker pulls, and tens of thousands of daily active users. The user base ranges from individual developers backing up side projects to engineering teams at companies running Databasus across dozens of production databases.
Now to the main news. Anthropic runs a program called Claude for Open Source. It gives eligible open source maintainers 6 months of free Claude Max 20x, which is the highest-tier consumer Claude subscription with 20x the usage limits of Claude Pro.
The program has two eligibility tracks.
The Maintainer Track requires all of the following: you need to be a primary maintainer or core team member of a public GitHub repo, the repo needs 5,000+ GitHub stars or 1,000,000+ monthly NPM downloads, you must have been active in the repo within the last 3 months (commits, issue triage, PR reviews, releases), and you need merge/write access.
There's also an Ecosystem Impact Track for projects that don't meet the star threshold but that the ecosystem meaningfully depends on. You write a short explanation of the project's significance and Anthropic evaluates it based on downstream dependents, breadth of usage and criticality.
Applications are reviewed on a rolling basis. Meeting the thresholds doesn't guarantee acceptance. Anthropic approves or denies at their discretion. The total cap is 10,000 recipients, and the application deadline is June 30, 2026.
It's worth noting what the program signals. The requirements are not low. 5,000 stars, active maintenance and real adoption. They're looking for projects that people actually depend on, not hobby repos with inflated metrics. Getting accepted means your project passed that filter.
Databasus qualified through the Maintainer Track. The star count exceeds the threshold, the project is under active development and the adoption numbers speak for themselves.
For me, this was a meaningful moment. Not because of the subscription itself, but because of what it represents. A company like Anthropic looked at the project, evaluated it against their criteria and decided it's worth supporting. That's a credibility signal that matters, especially for a tool that handles something as sensitive as database backups. When teams evaluate whether to trust an open source tool with their production data, signals like this help.
I use Claude in the development process. I want to be upfront about that because the topic of AI in open source has become contentious, and for good reason. There's a lot of low-quality AI-generated code being pushed into open source projects right now. For a tool that teams and enterprises trust with their production data, this transparency is not optional.
Databasus has a dedicated AI disclaimer in the README (https://github.com/databasus/databasus?tab=readme-ov-file#ai-disclaimer) that explains exactly how AI is and isn't used.
AI is used for:
AI is NOT used for:
The project has solid test coverage, both unit and integration tests. There's a CI/CD pipeline with automated tests and linting. Every PR goes through manual verification by experienced developers.
Vibe coded PRs are rejected by default. And to be clear, the same applies to poor code written by humans. We don't differentiate between bad human code and AI slop. The bar is the same for everyone.
There were actual cases where we denied PRs specifically because they were obviously AI-generated without proper review. You can see an example in this GitHub issue: https://github.com/databasus/databasus/issues/145
My position on this is simple. AI is a tool. A good one. But you don't get to hand off responsibility for what you ship. Teams and companies trust your project with their production data. That trust has to be earned through engineering rigor, not outsourced to a language model.
I think it's important for open source projects to be transparent about this. If you use AI, say how. If you don't allow vibe coding, enforce it. Especially when your users are running your code in production environments where a bad backup means real data loss.
Databasus keeps growing. We're working on new features, improving existing ones and the community around the project continues to expand. Incremental WAL backups with PITR are in development! Having Anthropic's support through the Claude for Open Source program is motivating and helps keep the momentum going.
If you're an open source maintainer and your project meets the criteria, I'd recommend applying. The program deadline is June 30, 2026 and they review applications on a rolling basis, so earlier is better.
And if your team is looking for a backup tool that doesn't require writing bash scripts or configuring pgBackRest from scratch, give Databasus a try. It takes a few minutes to set up and your team can manage everything from the web UI.
GitHub: https://github.com/databasus/databasus
Website: https://databasus.com
Claude for Open Source program: https://claude.com/contact-sales/claude-for-oss
