DEV Community: Mads Hansen

If your AI needs a human SQL translator, it's not really integrated

Mads Hansen — Tue, 07 Apr 2026 07:34:37 +0000

Here's a simple test for whether your AI workflow is real or just cosmetic:

When someone asks a business question, does the system return an answer from live data?

Or does a human still have to step in and translate the question into SQL?

If it's the second one, your AI is not integrated. It's just sitting on top of the same old process.

Human middleware is the giveaway

This is what fake integration looks like:

user asks AI a question
AI sounds smart but lacks the real data
someone technical gets pulled in
that person checks schema and writes SQL
result gets posted back manually

That may be acceptable for a demo.
It does not scale as an operating model.

Real integration starts lower in the stack

The shift happens when AI tools can query databases and APIs through structured interfaces with scoped permissions and schema awareness.

That is what turns a chat interface into an actual workflow layer.

Not because the model became smarter.
Because the data stopped being isolated.

Where we're seeing the gap

A lot of teams are already past the "should we use AI?" phase.
The real question now is whether the infrastructure underneath can support production use.

That's the idea behind this piece: Why AI projects stall at the database layer

And if you want to try that connection layer yourself, conexor.io is built for connecting live databases and APIs to MCP-compatible clients.

If a human still has to translate every useful question into SQL, the bottleneck hasn't moved.
It just got rebranded.

The hidden cost of every 'quick SQL question'

Mads Hansen — Tue, 07 Apr 2026 07:33:09 +0000

Most teams don't notice the cost because each request feels small.

A quick SQL question here.
A quick churn check there.
A quick pull for the board deck.
A quick customer list for sales.

Individually, none of these feel dramatic.
Together, they become a permanent tax on the people who know the data model best.

The real issue

The problem isn't that the questions are hard.

It's that the route to the answers is manual by default.

Every time someone needs a number from a live system, the workflow often looks like this:

Ask in Slack
Wait for the right person
Write or adjust SQL
Double-check joins and filters
Paste result back into chat

That's not analytics.
That's organizational friction.

Why AI doesn't magically fix it

A lot of teams assume adding AI will solve this. But if the model can't access the live database, nothing changes.

You still have the same bottleneck — just with better wording around it.

The only durable fix is connecting AI tools to real data in a structured and safe way.

What changes when you do

Once the connection layer exists, recurring questions stop becoming tickets.

The value is not just speed. It's reducing interruption cost for engineering and data teams, while making answers available where the questions already happen.

I wrote a deeper breakdown here: Why AI projects stall at the database layer

If you're experimenting with MCP-based workflows, conexor.io is built exactly for that layer.

Not another dashboard.
Not another exported CSV.
Just live questions against live data.

AI isn't the bottleneck. Your database access is.

Mads Hansen — Tue, 07 Apr 2026 07:33:09 +0000

Most teams think they have an AI problem.

Usually, they have a data access problem.

You can buy the best model on the market. Claude, GPT, Gemini — doesn't matter. If every useful answer still depends on someone checking a schema, writing SQL, and pasting results back into Slack, your AI stack is just a prettier front-end for the same internal queue.

Where projects actually stall

A PM asks:

"Which customers downgraded after the March rollout?"

That answer should take seconds.

Instead, it often becomes:

find the right database
inspect the tables
write the query
validate the result
send it back manually

So the team says they're "using AI," but the path to the answer still runs through human middleware.

That's the bottleneck.

Why this matters in production

Demos are easy.

Production is where the questions get messy:

What changed week over week?
Which accounts are at risk?
What is driving support load in one region?
Where is revenue slipping relative to plan?

Now you need live data access, schema awareness, scoped permissions, and a reliable way for AI tools to query real systems without custom glue code every time.

That is not a prompt problem. It is infrastructure.

The shift

If you want AI to be part of actual workflows, your database cannot stay trapped behind tickets and ad hoc SQL.

That's the idea behind MCP infrastructure.

We've been writing about this more here: Why AI projects stall at the database layer

And if you want to test it with your own stack, conexor.io connects PostgreSQL, MySQL, SQL Server, and APIs to Claude, ChatGPT, Cursor, n8n, and other MCP clients.

The model is not the hard part anymore.
Getting it to your live data is.

The Monday morning report that should write itself

Mads Hansen — Sun, 05 Apr 2026 09:16:45 +0000

Every Monday morning, somewhere in an IT team, someone is doing the same thing.

They are opening five tabs, pulling numbers from a dashboard, copy-pasting into a spreadsheet, writing a summary in Slack or email, and sending it to a manager who will skim it for 30 seconds.

This takes 45 minutes. It happens every week. It has happened every week for years.

It should not exist.

The report is not the problem

The information in that report matters. Patch compliance rates. Open tickets by priority. Devices offline. SLA performance. Client health scores.

Leadership needs this. Account managers need this. The team lead needs this to plan the week.

The problem is not the report. The problem is that a human is assembling it manually from data that already exists in structured systems.

That is not a reporting problem. That is an automation problem disguised as a workflow.

Why it has not been automated yet

Most teams know this report could be automated. The reason it has not been is usually one of three things:

1. The data is in too many places. PSA here, RMM there, maybe a spreadsheet someone maintains on the side. Building an integration felt like a project.

2. The format keeps changing. Every quarter someone asks for a new column or a different breakdown. Hardcoded scripts break.

3. Nobody owns it. It gets done because someone takes responsibility, not because there is a system.

These are real constraints. But they are not permanent ones.

What the automated version looks like

The shift that makes this tractable is AI with direct data access.

Instead of scripting a rigid report that pulls fixed columns in a fixed format, you connect your data sources to a model and let it generate the report dynamically — from a prompt.

The prompt might look like:

Generate a Monday morning status report covering: patch compliance by client (flag anyone below 80%), open tickets older than 5 days, devices that have not checked in since Friday, and any SLA breaches in the past 7 days. Format it for a non-technical operations lead.

That prompt runs against live data. The model handles the aggregation, the formatting, the flagging. If leadership wants a different view next week, you update the prompt, not a script.

Platforms like Conexor.io are built for exactly this kind of use case — giving AI models structured access to IT data so you can query it in natural language instead of building bespoke integrations for every report.

The 45 minutes is the least of it

Saving 45 minutes a week is not nothing — that is 39 hours a year per person doing this manually.

But the bigger cost is what does not happen during those 45 minutes.

The engineer doing the report is not fixing anything. They are not reviewing alerts. They are not thinking. They are transcribing data between systems that should already talk to each other.

And because reports are assembled manually, they are a snapshot in time. The data is already stale by the time the Slack message is sent.

An automated report that runs at 07:00 every Monday, pulls live data, and drops into a channel is not just faster. It is more accurate. It runs even when the person who usually does it is sick or on holiday.

Where to start

Pick one report that runs on a predictable schedule and currently involves manual data assembly. Just one.

Map where the data lives. Figure out if there is an API or a database you can query. Connect it to an AI layer — via MCP, a direct database connector, or an API integration.

Run the automated version alongside the manual one for two weeks. Compare them. When the team trusts the automated version, stop doing the manual one.

The goal is not to automate everything at once. It is to remove the first one. After that, the second one becomes obvious.

Monday mornings should be for decisions, not for copy-paste.

Why your LLM knows more about ancient Rome than your own database

Mads Hansen — Sun, 05 Apr 2026 09:16:16 +0000

Your AI assistant can tell you the exact year Julius Caesar crossed the Rubicon.

Ask it what devices are currently offline in your network? Blank stare.

This is not a bug. It is architecture.

The training data problem

LLMs are trained on the public internet — Wikipedia, Stack Overflow, GitHub, books, papers. Ancient Rome is well-documented. Your internal database is not.

This means your AI has deep knowledge about everything except the thing you actually care about: your own systems, your clients, your infrastructure state.

And most teams accept this as a limitation. They use AI for writing and coding, and keep their databases separate — queried only by humans who know SQL, or by dashboards someone built two years ago and nobody touches.

The gap is not about AI capability

Modern LLMs are genuinely good at reasoning over structured data. Give Claude or GPT-4 a table of device status, patch levels, and last-seen timestamps, and it will immediately surface patterns a human would take an hour to find.

The gap is about access.

Your LLM does not know what is in your database because nobody connected them. It is an integration problem, not an intelligence problem.

MCP changes the equation

The Model Context Protocol (MCP) is an open standard that lets you connect data sources directly to AI models. Instead of copy-pasting database results into a chat window, your AI can query your database in real time, as part of the conversation.

The workflow shift is significant:

Before MCP:

Think of a question
Write SQL (or ask someone who can)
Export results
Paste into AI
Get answer
Think of follow-up
Repeat from step 2

After MCP:

Ask the question
Get the answer

That is not an exaggeration. The model handles the query, the follow-up, the filtering, the aggregation.

What this looks like in practice

Imagine asking: "Which clients have devices that have not checked in for more than 72 hours and are running an outdated agent version?"

Without MCP, that is a SQL join, an export, maybe a Slack message to someone on the team. Could take 20 minutes. Could get deprioritized.

With MCP connected to your CMDB or IT management platform, it is a single question. You get the answer in seconds, with the option to drill down, cross-reference, or trigger an action.

Tools like Conexor.io are built around exactly this idea — making your IT data queryable by AI, not just by dashboards.

The ancient Rome problem is actually worse than it sounds

Here is the irony: your LLM is confidently wrong about your infrastructure.

Ask it about your network topology and it will hallucinate something plausible. Ask it about ancient Rome and it is accurate. The more domain-specific your question, the less reliable the model — unless you ground it in real data.

Connecting your data sources via MCP does not just make AI more useful. It makes it trustworthy. The model stops guessing and starts reporting.

The practical starting point

You do not need to connect everything at once. Start with one data source that gets queried manually every week. Your device inventory. Your ticket backlog. Your patch compliance report.

Connect it. Ask questions. See what the model surfaces that you were not looking for.

The goal is not to replace your dashboards. It is to make your data answerable to anyone on the team — not just the people who know SQL.

Your database knows more about your infrastructure than any LLM ever will. The only question is whether you let the AI access it.

The 3 questions every new IT manager asks on day one (and why they're so hard to answer)

Mads Hansen — Fri, 03 Apr 2026 18:29:09 +0000

It doesn't matter what company you join. The first week as a new IT manager has a predictable shape.

You sit down with your team, open your laptop, and start asking the questions that seem like they should have obvious answers:

"What do we have?" — What devices, what software, what licenses, what infrastructure?
"What does it cost?" — Total spend, renewals coming up, anything overprovisioned?
"What's out of date?" — Unpatched systems, expired licenses, EOL software still running?

Simple questions. Completely reasonable. And almost always — surprisingly hard to answer.

Why can't anyone answer them?

It's not that the data doesn't exist. It's that it lives in five different places, maintained by different people, updated on different schedules, and nobody has a unified view.

The asset list is in a spreadsheet. License info is in email threads and a shared drive. Patch status is in the patching tool. Cost data is split between procurement, finance, and a SaaS management platform that only covers some of the stack.

You end up spending your first two weeks not managing IT, but auditing IT. Piecing together a picture that someone should have already had.

The cost of the answer gap

This isn't just onboarding friction. The same problem bites every time there's an audit, a renewal, a security incident, or a board question about IT spend.

Every time someone needs a clear answer to "what do we have and what's its status," there's an investigation instead of a lookup.

What would actually fix it

A single queryable source of truth. Not another tool to maintain — but something connected to your existing data that can answer these questions in real time.

That's the promise of MCP-connected databases: natural language queries against your live IT data, without the two-week dashboard build.

The three questions should take three seconds. Not three weeks.

Stop building dashboards. Start asking questions.

Mads Hansen — Fri, 03 Apr 2026 18:28:34 +0000

Every data team I've talked to has the same problem: they spend more time building dashboards than answering questions.

A stakeholder asks: "Which accounts are most at risk of churning?"

The data team says: "We can build a dashboard for that. It'll be ready in two weeks."

Two weeks later, the dashboard is live. It answers the original question. And then the stakeholder asks a slightly different question, and the cycle starts again.

Why dashboards are the wrong abstraction

Dashboards are answers to questions you predicted in advance. They're good for monitoring known metrics. They're terrible for exploration, ad-hoc analysis, or any question that wasn't anticipated when the dashboard was built.

The world doesn't ask predictable questions. Business moves faster than dashboard backlogs.

The alternative: queryable data

What if instead of building a dashboard, you made your database directly queryable in natural language?

Not "give everyone raw SQL access" — that's a different kind of problem. But a controlled layer where someone can ask:

"Show me all customers who upgraded in the last 30 days but haven't used the new feature yet."

And get an answer from live data, in seconds, without a ticket.

This is what MCP (Model Context Protocol) enables when it's connected to your database. The AI constructs the query, validates it, and returns the result — without the stakeholder needing to know SQL, and without the data team building yet another dashboard.

It's not about replacing analysts

Data analysts are still valuable — for modeling, for data quality, for building the infrastructure that makes this possible. But routing every ad-hoc business question through a two-week dashboard build is a waste of everyone's time.

If you're curious what this looks like in practice, I wrote about it here: Kill the data request ticket.

The dashboard era isn't over. But for ad-hoc questions? There's a better way.

The patch that broke everything (and the spreadsheet that caused it)

Mads Hansen — Fri, 03 Apr 2026 18:27:58 +0000

It was a routine patch cycle. The team pushed updates to what they thought was the full device list. Three servers weren't on it.

Two of them were running a legacy payment integration. One was exposed to the internet.

The post-mortem finding: the asset spreadsheet hadn't been updated in six weeks. Someone had spun up the servers during a crunch period and never added them. The patch ran, the known devices were updated, and the unknown ones stayed vulnerable.

The real problem with patch management

Most teams treat patch management as a tooling problem. Get the right patch tool, run it on a schedule, check the boxes.

But patch tools only patch devices they know about. If your inventory is incomplete, your patch coverage is incomplete — by definition.

This is why patch management is fundamentally a data problem. You can have the best patching tool in the world and still miss 15% of your environment because your inventory is stale.

What "complete" actually means

A complete asset inventory isn't a spreadsheet updated every quarter. It's a live, queryable record of what's connected to your environment right now — with enough metadata to answer:

Is this device in scope for this patch?
When was it last seen on the network?
Who owns it?
What's running on it?

Without that, you're patching from a map that's already out of date.

The fix isn't more process

Adding a "please update the spreadsheet" step to your onboarding checklist doesn't solve this. People forget. Contractors don't know to do it. Emergency deployments skip it.

The fix is making the inventory self-updating — or at least queryable from your actual infrastructure rather than maintained manually.

If you're thinking about how AI fits into this, conexor.io is worth a look — it's MCP infrastructure that connects your databases to AI tools so you can query live asset data in natural language instead of hunting through stale spreadsheets.

The spreadsheet didn't cause the breach. The gap between the spreadsheet and reality did.

What happens when every developer on your team can query production (safely)

Mads Hansen — Thu, 02 Apr 2026 13:16:18 +0000

The data team is the bottleneck. But giving everyone raw database access is terrifying. There's a middle path.

Most engineering teams have an unwritten rule: only certain people touch the production database. It makes sense. One bad SELECT * on a 50M row table can bring down your app. One accidental DELETE without a WHERE clause is a very bad afternoon.

So instead, teams build dashboards. Write internal tools. Route every ad-hoc question through the data analyst. The bottleneck is real. The fear is real. But the trade-off is painful — especially when the data team is always two weeks behind.

What's changed

AI-native query layers can now act as a safe intermediary between your developers and your production database.

You're not giving your frontend dev raw SQL access. You're giving them natural language access, where the query is generated, validated, and executed through a controlled interface with scoped permissions.

They ask: "How many trials converted last week?"

They don't touch the schema. They don't accidentally run a full table scan. They just get the answer.

The safety properties that matter

For this to work in production, you need:

Read-only by default — no INSERT, UPDATE, DELETE unless explicitly configured
Parameterized queries — not string substitution (protects against prompt injection attacks)
Scoped tools — the AI only sees the tables and columns you expose
Audit log — who asked what, when, against which tables

These aren't nice-to-haves. They're the difference between "we let AI query our database" and "we let AI query our database safely."

How we built this into conexor.io

conexor.io is MCP infrastructure for database access. Every query runs parameterized. Tools are scoped to the data sources you configure. Read-only by default.

If you're curious about the security model in detail: How conexor.io enforces zero data exposure

Democratizing data access doesn't have to mean democratizing risk. The two are separable — if your infrastructure is built for it.

The Monday morning report that should write itself (but doesn't)

Mads Hansen — Thu, 02 Apr 2026 13:15:28 +0000

Every Monday. Same 6 queries. Copy-paste into a spreadsheet. Send to Slack. Repeat forever.

I've talked to dozens of engineering leads and ops managers. They all have a version of the same Monday ritual:

Open database client
Run the weekly queries
Open Excel
Paste and format
Send to #ops-updates

45 minutes. Every week. Nobody questions it.

Why hasn't this been automated?

The data is right there. The queries are deterministic. The output format never changes. And yet — a human is in the loop for 45 minutes of mechanical work every single Monday.

The usual answer: "We tried to build a dashboard but it only covers some of the queries" or "We keep meaning to automate it but nobody owns it."

Here's the thing: the technology to eliminate this has existed for a while. Cron jobs, scripts, even basic automation. But they're brittle — they break when schemas change, they need someone to maintain them, and they still don't handle the "I need a slightly different cut of this" request that comes every other week.

What AI-native query layers actually change

The right solution isn't a dashboard. It's a layer that can answer any question against your live data — including the ones you didn't predict.

With MCP-connected databases, you don't need to pre-build every query. You describe what you want in plain English, and the AI constructs and runs the query against your actual database.

Monday morning report becomes: "Summarize this week's key metrics vs last week and flag anything anomalous." Done. Including the anomalies you didn't think to check for.

The missing piece

For most teams, the blocker is the connection layer — getting your database to actually talk to an AI tool in a secure, structured way.

conexor.io is MCP infrastructure that handles this without custom code. Connect your PostgreSQL, MySQL, or SQL Server database, and your AI tools can query it directly.

More on eliminating the data request bottleneck: Kill the data request ticket

If you're still doing the Monday copy-paste ritual — 2026 is the year to stop.

Why your LLM knows more about ancient Rome than your own database

Mads Hansen — Thu, 02 Apr 2026 13:15:27 +0000

Your AI can write a sonnet about Marcus Aurelius. Ask it your Q4 churn rate — it guesses.

There's a weird paradox in AI tooling right now. The models are extraordinary. GPT-4, Claude, Gemini — they've ingested the internet. They can reason, code, explain, synthesize.

But ask them something actually useful — "what's our average deal size this quarter?" or "which clients haven't logged in for 30 days?" — and they stall.

Why? Because the answer isn't on the internet. It's in your database. And your LLM has never seen your database.

The gap is infrastructure, not intelligence

This isn't a model problem. The models are ready. The problem is that your business data — every transaction, every user event, every metric that actually matters — lives in a PostgreSQL or MySQL database that no AI tool has ever touched.

So every AI conversation about your own business is either:

Based on data you manually copy-pasted into the prompt
A hallucination dressed up as an answer
Redirected to: "I don't have access to that information"

MCP closes the gap

Model Context Protocol is the standard that lets AI models connect directly to external data sources — databases, APIs, tools — in real time. Instead of copy-pasting, the model queries. Instead of guessing, it returns actual numbers.

Ask Claude: "Who are our top 10 customers by LTV?"

It hits your database. It returns the actual list. In about 4 seconds.

Not 4 days. Not a ticket to the data team. Not a dashboard that only answers the questions you thought to ask last quarter.

Getting started

If you want to try this with your own database, conexor.io lets you connect PostgreSQL, MySQL, or SQL Server to Claude, Cursor, or any MCP client in under 5 minutes. Free tier, no credit card.

We wrote a more detailed breakdown here: Why your AI assistant can't answer business questions

The models are ready. The question is whether your data is connected.

Your monitoring stack is lying to you (and you can prove it with SQL)

Mads Hansen — Tue, 31 Mar 2026 05:10:03 +0000

Pull up your monitoring dashboard. Now open your ticketing system. Now check your deployment logs.

Are they telling the same story?

They're not. They never are.

Your dashboard shows green. Your tickets show a slow degradation that started 3 weeks ago. Your deployment logs show a config change that went out the same day the tickets started. Nobody connected the dots because nobody was looking at all three at once.

Dashboards visualize data. They don't correlate it.

The fix is boring: get your operational data into a SQL-queryable form, then ask cross-system questions.

SELECT 
  d.deployed_at,
  COUNT(t.id) as tickets_opened,
  AVG(t.time_to_resolve) as avg_resolve_minutes
FROM deployments d
LEFT JOIN tickets t ON t.created_at BETWEEN d.deployed_at AND d.deployed_at + INTERVAL '48 hours'
GROUP BY d.deployed_at
ORDER BY d.deployed_at DESC;

That query will tell you more about deployment quality than any dashboard you've built.

The challenge is getting your data into one place. Most teams have their monitoring, ticketing, and deployment data in separate systems with separate APIs and separate export formats.

That's what structured IT data platforms solve — and why we built Conexor.io to connect those sources and expose them via MCP so you can query across them with natural language or SQL.

Your data is telling the truth. Your dashboards are just not asking the right questions.