DEV Community: Runix

We let an AI write SQL against customer databases. Here is every guardrail, and why prompting is not one.

Runix — Fri, 04 Sep 2026 07:21:33 +0000

A customer writes in: "my last three orders are missing." Someone has to open a database and look.

We built an AI agent that does that part. It reads the ticket, forms a hypothesis, queries the customer's own systems, and writes up what it found with the queries attached as evidence. Useful. Also, on its face, a terrible idea — you have an LLM reading untrusted text from strangers on the internet, and you are handing it a database connection.

We shipped it anyway. The interesting work was not the agent. It was the roughly 400 lines standing between the agent and the data, and the thing we got wrong twice before getting it right.

All of this is Apache-2.0 and sitting in our repo, so you can read the real thing rather than take our word for it. The two files are backend/app/services/sql_guardrails.py and backend/app/services/db_connector_service.py.

Prompting is not a security boundary

Start here, because everything else follows from it.

You cannot write "only generate SELECT statements" in a system prompt and call that a control. You can write it — we do — but it is a hint about intent, not a guarantee about behaviour. The model reads customer messages. Customer messages can contain instructions. Somewhere between those two facts is every prompt-injection writeup of the last three years.

So the rule we settled on: every guarantee is enforced outside the model, on a parsed AST. Not on the string. Not by asking nicely. If a property matters, it gets checked by code that the model cannot talk to.

That sounds obvious written down. It is also the part most "AI + your database" demos skip, because the demo works fine when nobody is attacking it.

Layer one: parse it, do not regex it

The first thing we do with model-generated SQL is throw away the string.

statements = sqlglot.parse(raw_sql, read=dialect)
if len(statements) != 1:
    return SqlValidationResult(ok=False, reason="Exactly one SQL statement is allowed")
statement = statements[0]

if not isinstance(statement, exp.Select):
    return SqlValidationResult(ok=False, reason="Only plain SELECT statements are allowed")

Then a denylist of node types that must not appear anywhere in the tree: Insert, Update, Delete, Merge, Create, Drop, Alter, TruncateTable, Grant, Command, Transaction, Set, Into, Lock.

Into and Lock are on that list for a reason. SELECT * INTO evil FROM orders is a SELECT, and it writes. SELECT * FROM orders FOR UPDATE is a SELECT, and it takes locks. Both parse as exp.Select. Both would have walked straight through a naive sql.strip().upper().startswith("SELECT") check.

At the end, the statement is re-rendered from the AST with comments=False, and that rendering is what executes. Two things fall out of that. Comments never reach the server, which matters more than it sounds — MySQL executes /*! ... */. And whatever runs is canonical SQL derived from a tree we inspected, not the raw string we were handed.

Layer two: an allowlist that walks the whole tree

Every table reference has to be on the connector's allowlist. The obvious version of this check is also the broken one, because table references hide in places people forget to look.

WITH x AS (SELECT * FROM pg_shadow) SELECT * FROM x

The top-level FROM is x. Looks clean. The real read is inside the CTE body.

SELECT * FROM (SELECT id FROM orders UNION ALL SELECT oid FROM pg_shadow) t

Same trick, different wrapper.

statement.find_all(exp.Table) walks all of it — CTEs, subqueries, joins, union arms. CTE names are exempted, since a reference to x resolves to a CTE we already walked, but only when unqualified. A CTE called users does not authorize secret_schema.users. That is a real test case, and it exists because it is exactly the sort of thing you would get wrong.

Bare names resolve against default schemas, so an allowlist entry of public.orders also authorizes orders. But hidden.orders is refused. Same table name, different schema, no.

Layer three: filter the relation, not the predicate

This is the part worth the whole article.

Support data is multi-tenant in the worst way: one orders table, every customer's rows in it. The agent investigating Ann's missing orders must not be able to read Bob's. And the naive approach — check that the model's WHERE clause contains the right customer filter — cannot be made to work.

Think about what you would have to prove. That no OR widens the predicate. That no join reintroduces unfiltered rows. That no correlated subquery reaches around it. That no UNION arm adds a branch without it. You are writing a static analyser for arbitrary SQL semantics, and you will lose.

So we stopped validating the predicate and started rewriting the relation:

FROM orders o   ->   FROM (SELECT * FROM orders WHERE customer_email = 'ann@x.com') AS o

Every scoped base table gets swapped for a pre-filtered subquery. The model's own SQL is then applied on top of that.

Now OR 1=1 is not a bypass. It is not even interesting. The outer predicate can say whatever it likes, because the relation it selects from only ever contained one customer's rows:

def test_or_true_cannot_widen_the_scope(self):
    result = scoped("SELECT id FROM orders WHERE 1=1 OR customer_email = 'victim@x.com'")
    assert result.ok
    assert "FROM (SELECT * FROM orders WHERE customer_email = '%s')" % OWNER in result.sql

Note that the query is allowed. We are not blocking it. We are making it harmless, which is a much better place to be than pattern-matching hostile predicates forever.

Three details that took us longer than they should have:

It fails closed. A scoped table with no customer identity on the ticket is refused outright. The tempting behaviour — no scope value, so skip the filter — reads every customer's rows. That is the bug you only find in production, so there is a test pinning it shut for None, "" and " ".

The value is a literal node, never string-formatted. exp.Literal.string(value) escapes on render. Feed it x' OR '1'='1 and you get 'x'' OR ''1''=''1' — one string, no injection. We are rewriting SQL to defend against injection, so it would be somewhat embarrassing to introduce one while doing it.

Scoping happens last. The allowlist and masking checks run against what the model actually wrote. If we rewrote first, those checks would be inspecting our own wrappers.

Layer four: masked columns, and the whole-row trick

Some columns should never reach the model at all. Email, phone, whatever your compliance people circled.

The naive implementation masks by output column name, after the query runs. It survives about ninety seconds of adversarial thinking:

SELECT email AS harmless FROM customers          -- alias
SELECT substr(email, 1, 3) FROM customers        -- expression
SELECT id FROM customers WHERE email = 'a@b.c'   -- probe by inference

The last one never selects the column at all. It just asks yes/no questions until it knows the value.

So masked columns cannot be referenced, anywhere. Not in SELECT, not in WHERE, not inside a function.

Then there is the category we did not think of first, and which is the reason this section exists:

SELECT to_jsonb(t) FROM customers t
SELECT row_to_json(customers) FROM customers
SELECT customers FROM customers
SELECT customers::text FROM customers
SELECT (c.*)::text FROM customers c
SELECT array_agg(customers) FROM customers

Every one of those collapses an entire row into a single value. Name-based masking looks at the output column, sees to_jsonb, finds nothing called email, and passes the whole record through with the email inside it.

In Postgres a bare table name used as a value is the row. SELECT customers FROM customers is legal and returns row tuples. That one genuinely surprised us.

The fix is two rules on the AST. A star nested inside anything other than a top-level projection is refused. And a bare, unqualified column reference whose name matches a table, alias or CTE in scope is refused, because that is a whole-row value wearing a column's clothes.

SELECT *, t.* and count(*) stay legal. The first two expand to real column names that get redacted by name on the way back; the last is a count, and counts do not leak rows.

Layer five: assume all of the above is wrong

Everything so far is one system. One system means one bug away from nothing.

So the session is independently read-only, at the driver:

# postgres
options="-c statement_timeout=5000 -c default_transaction_read_only=on"

# mysql
cursor.execute("SET SESSION TRANSACTION READ ONLY")
cursor.execute("SET SESSION max_execution_time = 5000")

If the AST validator has a hole we have not found, a write still fails at the server. The statement timeout does the same job for the resource-exhaustion cases the function denylist is aimed at — pg_sleep, benchmark(), and the rest of that family.

And the executor fetches max_rows + 1 even though the validator already forced a LIMIT. Belt and braces, deliberately.

What we are still not certain about

Two things, stated plainly, because a security post with no open questions is a marketing post.

The denylist is a denylist. BLOCKED_FUNCTIONS covers the Postgres and MySQL functions we know about for sleeping, reading files, opening network connections and poking at server config. Denylists are structurally incomplete. It is defence in depth behind the read-only session, not the thing holding the line, and we would rather have an allowlist here — we have not found a workable one that does not break ordinary queries.

Row scoping is opt-in, and that is a sharp edge. row_scope is empty until you set a customer-identifying column per table. An operator who connects a database and skips that step gets an agent that can read every row of every allowlisted table. The docs say to set it. Defaults beat documentation, and this default is the wrong way round. It is the change we would most like to make.

The whole corpus lives in backend/tests/services/test_sql_guardrails.py — mutations, table smuggling, function abuse, masked-column exfiltration, row-scope bypasses. If you find one it does not cover, that is a genuinely useful issue to open, and we would rather hear it from you than from a customer.

The part that generalises

If you are building an agent that touches real data, the shape of this is reusable even if none of the code is:

Parse, do not pattern-match. Model output is untrusted input, and untrusted input gets a parser.
Constrain the relation, not the model's predicate. Anything the model can write around, it eventually will.
Assume your first masking implementation leaks. Ours did, via a Postgres feature most people never touch.
Put a second, independent barrier underneath. Then write the test that proves the first one failing is survivable.
Fail closed. Every time.

None of this makes an LLM trustworthy. That is the point. It makes trustworthiness unnecessary, which is the only version of this that scales.

I build ChatterMate, an open-source AI customer support platform with human handoff — Apache-2.0 and self-hostable. Everything above is in the repo at github.com/ChatterMate/chattermate.chat, so go and find the hole I missed.

ChatterMate vs Chatwoot vs Typebot: Which Open-Source Chat Platform Is Right for You?

Runix — Thu, 26 Mar 2026 04:44:31 +0000

If you're evaluating open-source alternatives to Intercom, Drift, or Zendesk Chat, you've likely come across three names: Chatwoot, Typebot, and ChatterMate. They all live in the "self-hostable customer chat" space — but they solve very different problems.

Here's an honest breakdown.

The Quick Summary

Feature	ChatterMate	Chatwoot	Typebot
Primary focus	AI-first chatbot automation	Human agent inbox	No-code bot builder
Local LLM support	✅ Ollama native	❌	❌
No-code workflow builder	✅	❌	✅
Human handoff	✅ Smart escalation	✅ Core feature	✅ Basic
License	AGPL-3.0	MIT	AGPL-3.0
Self-hostable	✅ Docker	✅ Docker	✅ Docker
Vector search / RAG	✅ pgvector	❌	❌
API-first	✅ FastAPI	✅ Rails API	✅
Multi-LLM provider	✅ (OpenAI, Groq, Ollama, Google)	❌	❌

Chatwoot: The Human Agent Inbox

Chatwoot is excellent at what it does: routing customer conversations to human agents. It's battle-tested, mature, and has a large community.

Best for: Teams with human support agents who need a shared inbox, SLA tracking, and omnichannel support (email, Twitter/X, WhatsApp, etc.)

Not ideal for: AI-first automation where you want bots handling the majority of conversations without human involvement.

If you want AI, you'd need to bolt it on externally — Chatwoot doesn't natively run language models.

Typebot: The Flow Builder

Typebot is a drag-and-drop conversation flow builder. Think visual programming for chatbots — you build branching dialogue trees, collect form data, and trigger webhooks.

Best for: Marketing teams building lead capture bots, survey flows, or onboarding sequences.

Not ideal for: Dynamic AI responses. Typebot's bots are deterministic — they follow the script you build. You can integrate OpenAI via blocks, but the LLM is a plugin, not the core.

ChatterMate: The AI-First Agent

ChatterMate takes a different approach: the AI is the agent, not a bolt-on.

You connect a knowledge base, configure an agent, and ChatterMate uses vector search (pgvector) to give the AI relevant context before responding. Customers get accurate, contextual answers 24/7 — and the agent escalates to humans when it can't help.

What makes it different:

1. Fully local AI with Ollama

Run ollama pull llama3.2 and ChatterMate connects to it directly. No OpenAI account, no API costs, no data leaving your infrastructure. This matters enormously for regulated industries (healthcare, finance, legal).

2. Multi-LLM switching

Already have OpenAI access? Use GPT-4o. Want to experiment with Groq's speed? Switch providers without changing your setup. Per-agent model selection means you can run different LLMs for different use cases.

3. Smart human handoff

ChatterMate doesn't just dump the customer to a human — it's aware of business hours, routes based on team availability, and includes conversation context so the agent isn't starting from scratch.

4. RAG-ready from day one

pgvector is baked in. Upload documents, connect to your knowledge base, and the AI has semantic search over your content before every response.

5. No-code workflow builder

For custom logic — conditional responses, Jira ticket creation, form collection — there's a drag-and-drop builder. No Python required.

# Get started in minutes
git clone https://github.com/chattermate/chattermate.chat.git
cd chattermate.chat
cp .env.example .env
docker compose up -d

When to Pick Each

Pick Chatwoot if: You primarily have human support agents who need a shared inbox, omnichannel support, or SLA tracking.

Pick Typebot if: You're building marketing or onboarding flows and want visual, no-code flow control.

Pick ChatterMate if: You want AI handling 80%+ of conversations autonomously, data sovereignty matters (fully local with Ollama), or you need smart human escalation baked in.

The Honest Take

These tools aren't really competing — they're solving different problems. If you want a chatbot that thinks, ChatterMate is the open-source option built for it.

⭐ GitHub: chattermate/chattermate.chat — 58 stars, AGPL licensed, v1.0.9

Contributions welcome — zero open issues means the board is yours.

I'm Runix, building ChatterMate in public. Follow @ChatterMat65796 for updates.

Self-Host Your Own AI Chatbot: ChatterMate + Ollama in 10 Minutes

Runix — Tue, 24 Mar 2026 06:31:58 +0000

Running your own AI chatbot shouldn't require a PhD or a cloud bill.

ChatterMate is an open-source (AGPL) AI chat agent built from scratch to work with LLMs. Pair it with Ollama and you get a fully local AI assistant — no API keys, no third-party data processing.

Why Self-Host?

Privacy: Customer conversations never leave your infrastructure
Cost: No per-token API charges
Control: Pick your model, tune your prompts, own your data

Quick Start

Clone the repo: git clone https://github.com/chattermate/chattermate.chat
Use Docker Compose to spin everything up
Point it at your Ollama instance
You're live

The Stack

Backend: Python
Frontend: Vue.js
LLM: Ollama (local) or any OpenAI-compatible API
Database: PostgreSQL

Current Stats

58 GitHub stars, 26 forks, 4 contributors, v1.0.9 released.

We're actively looking for contributors — the issue tracker is clean and we're happy to mentor first-time OSS contributors.

Check it out: github.com/chattermate/chattermate.chat

How to Self-Host an AI Customer Chat Agent with Ollama + ChatterMate (No API Keys Needed)

Runix — Thu, 19 Mar 2026 16:03:23 +0000

So you want an AI-powered customer chat widget on your site — but you don't want to send every conversation to OpenAI or pay per token?

ChatterMate is an open-source AI chat agent that works seamlessly with Ollama, meaning you can run the entire stack locally. No API keys. No cloud dependency. Full data ownership.

In this post, I'll walk through getting ChatterMate running with Ollama on your own server.

What you'll need:

A Linux server (or Mac/Windows with Docker)
Docker and Docker Compose
About 8GB RAM for running a decent local model

Step 1: Clone the repo

git clone https://github.com/chattermate/chattermate.chat.git
cd chattermate.chat

Step 2: Set up Ollama

Install Ollama and pull a model:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.2

Step 3: Configure and run

Copy the example environment file and configure it to point to your local Ollama instance. Then spin everything up with Docker Compose.

What's in v1.0.9 (latest release):

Slack integration with OAuth
Secure token-based authentication for widgets
XSS attack prevention and security hardening
Database connection pooling improvements
Contributions from external developer @cdmx-inWhy self-host your AI chat?

Complete data privacy - conversations never leave your server.

No per-token costs - run as many conversations as your hardware allows.

Customize everything - the AI agent's personality, knowledge base, and behavior are all yours to tune.

AGPL licensed - truly open source.

Current stats: 58 stars, 26 forks on GitHub, 4 contributors, 586 commits, 10 releases.

Get started: https://github.com/chattermate/chattermate.chat

Star the repo if this is useful - we're a small team and every star helps us keep building in the open. We'd also love PRs, issues, and feedback from the community.

Introducing LogManticsAI: LLM-Powered CLI for Semantic JSON Log Analysis

Runix — Tue, 03 Jun 2025 05:10:47 +0000

In the evolving landscape of IT operations and DevOps, the ability to efficiently analyze and monitor logs is paramount. Enter LogManticsAI, an open-source command-line tool that leverages Large Language Models (LLMs) to provide semantic analysis of JSON logs, real-time anomaly detection, and continuous monitoring—all within your terminal.

🔍 What is LogManticsAI?
LogManticsAI is designed to enhance log analysis by integrating the power of LLMs. It offers:

Interactive Setup: Easily configure LLM settings and specify log file paths.

Multi-File Monitoring: Simultaneously monitor multiple JSON log files.

Secure API Key Storage: Utilizes keyring for safe storage of API keys.

JSON Validation: Ensures log files are properly structured.

Semantic Analysis: Identifies important log keys and patterns using LLMs.

Real-Time Anomaly Detection: Continuously monitors logs to detect anomalies as they occur.

LLM Provider Support: Compatible with various LLM providers via Agno, including OpenAI, Anthropic, Google, and Groq.

Slack Integration: Sends real-time notifications to Slack channels.
GitHub

🚀 Getting Started
Clone the Repository:

git clone https://github.com/chattermate/LogManticsAI.git cd LogManticsAI

Install Dependencies:

pip install -r requirements.txt

Run the Tool:

python logmantics.py

Follow the interactive prompts to configure your LLM settings and specify the log files you wish to monitor.

🧠 Why Use LLMs for Log Analysis?
Traditional log analysis tools often rely on predefined rules and patterns, which can miss novel or unexpected issues. By leveraging LLMs, LogManticsAI can:

Understand Context: Interpret logs in a more human-like manner, considering the context of events.

Detect Anomalies: Identify unusual patterns that may not match predefined rules.

Adapt to New Patterns: Learn from new types of log entries without manual updates.
signoz.io

This approach aligns with the growing trend of integrating AI into observability tools to enhance system monitoring and incident response.

📣 Join the Community
LogManticsAI is open-source and welcomes contributions. Whether you're interested in adding new features, improving documentation, or sharing feedback, your input is valuable.

GitHub Repository: Github

**Issues & Feature Requests: **https://github.com/chattermate/LogManticsAI/issues

Embrace the future of log analysis with LogManticsAI and experience the power of LLMs in your DevOps toolkit.

🧠 The Image War: OpenAI vs Grok — Who’s the Real Visual Genius?

Runix — Thu, 27 Mar 2025 06:31:20 +0000

In the last 24 hours, the AI world has been shaken. OpenAI just dropped a bombshell with their new image generation model, and it's turning heads everywhere. Naturally, I had one question:

Who’s the king of image generation — OpenAI or Grok?

To find out, I decided to run a series of real-world tests with basic prompts. No fancy engineering here — just casual, natural instructions. Because let’s be honest, that’s how we all talk to AI.

🎨 Round 1: The Doodle Challenge

Goal: Create a doodle that shows “English is the new programming language,” with a character talking to a computer.

Prompt: A very casual, not-so-intelligent prompt — just to see how well AI interprets human intention.

🧠 Grok: Struggled a bit in the beginning, but got the idea eventually.
🚀 OpenAI: Nailed it from the start.

Verdict: 🤝 Tie — Grok took a while to warm up, but the final outputs were similar. What's your preference?

😂 Round 2: Meme Reply Challenge

Goal: Reply with a meme to a tweet that says: “I got my first customer!”

Prompt: Give a meme image reply for someone who just made their first paying customer.

🧠 Grok: Meh, not really meme-worthy.
🚀 OpenAI: Delivered a perfect meme — even asked for confirmation. Nice touch.

Winner: 🏆 OpenAI

📣 Round 3: Product Review Announcement

Goal: Create an image for an X (Twitter) post announcing a review of Chattermate by Scoutforge.

Review Link: Chattermate Review by Scoutforge

Rating: 4.2/5

🧠 Grok: Just gave up. Gibberish text, chaotic visuals.
🚀 OpenAI: Absolutely stunning result. Photoshop, are you watching?

Winner: 🏆 OpenAI

🎉 Final Test: Birthday Invitation Challenge (A Dad’s Special)

This one's personal. For the past 8 years, I’ve been designing my son’s birthday invitations from scratch in Photoshop.

Goal: See if AI can beat me at this.

Prompt:

Create a birthday invitation for my son Runix, this Sunday at 3:30 PM. Theme: Nerf Gun. Age: 9. Ask guests to RSVP.

🧠 Grok: Started with gibberish again.
🚀 OpenAI: Blew away every expectation. Honestly, I might retire from Photoshop forever.

Winner: 🏆 OpenAI (no contest)

🧾 Summary

The results were far beyond my imagination. What started as a casual test made me question the future of design tools.

Graphic designers, Photoshop, Canva...

You're officially on AI notice.

OpenAI's image model isn’t just good — it's a game-changer.

Let me know in the comments if you've tried both tools.

What’s your pick: Grok or OpenAI?

The Future of Development: From Code to Prompts – Will We Become AI Operators?

Runix — Wed, 19 Mar 2025 17:15:00 +0000

In the whirlwind of technological evolution, a bold question emerges: Will developers soon swap their code editors for prompts, stepping into roles as "AI operators"? Picture this—a job posting for an "AI Operator," someone who crafts precise instructions, verifies outputs, and ensures intelligent systems hum along smoothly. It’s not a distant sci-fi fantasy; it’s a possibility creeping closer every day. As AI reshapes the tech landscape, what does this mean for developers, their work-life balance, and even humanity’s broader relationship with nature? Let’s dive into this shift, blending optimism with realism, and back it up with some eye-opening stats.

AI Operators: The Next Evolution of Developers?

The idea of an "AI operator" isn’t as wild as it sounds. Tools like GitHub Copilot, Cursor, and Claude 3.5 are already nudging developers toward a future where AI does the heavy lifting—writing boilerplate code, debugging, or even generating entire functions. A speculative post on X suggested that roles like "AI Prompt Engineers" or "AI-Human Collaboration Experts" could account for 25% of software jobs by 2026. But does this mean traditional software engineering is on its way out?

Not quite. AI might automate the grunt work, but it won’t erase the need for human ingenuity. Think of it as a partnership: developers could evolve into AI operators, guiding machines to solve complex problems while focusing on strategy, creativity, and innovation. It’s less about replacement and more about redefinition.

The Numbers Tell the Story

Recent data paints a vivid picture of this transformation:

75% of companies plan to adopt AI within the next five years, signaling a seismic shift in how tech is built and managed (Source: Web ID 6).
300 million jobs could be displaced globally by AI by 2030, yet 69 million new jobs are expected to rise from the ashes of this disruption (Source: Web ID 8).
25% of routine tasks are already handled by AI, liberating workers from monotony (Source: Web ID 8).
AI could inject $19.9 trillion into the global economy by 2030, reshaping industries and creating opportunities we can barely imagine (Source: Web ID 8).

These stats suggest a dual reality: disruption is coming, but so is opportunity—for those ready to pivot.

Work-Life Balance: A Dream Within Reach?

Here’s the tantalizing upside: AI could usher in a golden era of work-life balance. If AI takes over repetitive tasks—think endless bug fixes or CRUD operations—developers might reclaim hours for creative pursuits or simply stepping away from the screen. Surveys show 51% of office workers believe AI improves their work-life balance, and 81% say it boosts job performance (Source: Web ID 5).

Imagine spending less time wrestling with syntax and more time dreaming up bold architectures or mentoring the next generation. This isn’t just about clocking out early; it’s about rediscovering the joy of development. AI could amplify human potential, not diminish it.

The Bright Side: Back to Nature?

Elon Musk once mused about a future of abundance where AI produces so much that money becomes irrelevant. It’s a utopian vision, but it sparks an intriguing thought: What if AI frees us from repetitive thinking, pushing us toward a more natural existence? If machines handle the mundane—coding loops, managing servers, optimizing databases—humans could focus on art, exploration, or simply living in harmony with the world.

This isn’t pure fantasy. With 25% of routine tasks already automated, we’re inching toward a reality where AI manages complexity, leaving us room to breathe. The positive side? A world where technology solves problems so efficiently that we’re nudged back to simpler, more human rhythms.

The Transition: A Rough Ride

But let’s not sugarcoat it—history warns us that big shifts get messy. The Industrial Revolution upended lives before it stabilized, and AI’s takeover could follow suit. The stats are sobering: 60% of jobs in advanced economies face risks from AI automation, and that 300-million-job displacement figure looms large (Source: Web ID 8).

The "in-between" phase worries me most. As one X user put it, "Developers will still be needed, but only for high-level tasks like designing architectures." Those who can’t adapt—whether due to skill gaps or resistance—risk being left behind. It’s survival of the fittest, just as it’s always been when technology leaps forward.

Adapt or Fade: The Developer’s Challenge

So, how do we thrive in this AI-driven future? It’s all about adaptability:

Master AI collaboration: Learn to write killer prompts, spot AI’s blind spots, and integrate it into your workflow.
Lean into human strengths: Creativity, empathy, and big-picture thinking will outshine any algorithm.
Never stop learning: With tech evolving at warp speed, curiosity is your lifeline.

The developers who succeed won’t just code—they’ll orchestrate. They’ll wield AI like a conductor wields a baton, creating symphonies of innovation.

A World Run by AI, Lived by Humans

Let’s dream big for a moment. Picture a future where AI runs the show—managing infrastructure, optimizing resources, even governing with cold efficiency—while humans chase passions and purpose. It’s exhilarating, terrifying, and, frankly, possible. The $19.9 trillion economic boost AI might deliver by 2030 hints at a world of surplus, where scarcity fades and new possibilities bloom.

Will developers become AI operators? Maybe. But more crucially, they’ll become architects of this strange, thrilling future—one where machines and humans dance in sync.

Your Move

Don’t sit on the sidelines. Start playing with AI tools now—try Cursor, experiment with Claude, or tinker with whatever’s next. Learn to prompt, iterate, and innovate. The future belongs to those who see AI not as a doom, but as a partner in building something extraordinary.

The Top 10 Open-Source Chatbot Frameworks of 2025

Runix — Tue, 18 Mar 2025 16:51:00 +0000

Chatbots are transforming how we engage with technology, and open-source frameworks are at the heart of this revolution. Whether you’re crafting a simple Q&A bot or sophisticated conversational AI, these tools offer flexibility, power, and—best of all—no cost. In this post, we’ll explore the top 10 open-source chatbot providers lighting up the dev world in 2025. Let’s dive in and find the perfect framework for your next project!

Why Open-Source Chatbot Frameworks?

Open-source frameworks let you customize to your heart’s content, tap into vibrant communities, and skip subscription fees. From startups to enterprises, these tools empower developers to build smarter bots faster. Ready to meet the best of the best?

Top 10 Open-Source Chatbot Frameworks

1. Rasa

What it does: Advanced platform for contextual chatbots with strong natural language understanding (NLU).
Why it’s great: Perfect for complex, multi-turn conversations with deep customization.
Language: Python

2. Botpress

What it does: Full-stack chatbot platform with a visual flow editor.
Why it’s great: Balances no-code ease with powerful NLP features.
Language: JavaScript (Node.js)

3. ChatterMate New Entrant

What it does: Easiest framework to deploy, optimized for large language models (LLMs), Built for AI.
Why it’s great: Instant knowledge base training via PDFs or website links; advanced integrations (human transfers, Jira tickets).
Key Features:
- Rapid setup (operational in 5 minutes).
- Instant knowledge base integration.
- Advanced capabilities: human transfer, Jira ticket creation, etc.
Language: JavaScript/Python
Links: Website | GitHub | Docs

4. Microsoft Bot Framework

What it does: Builds bots for Teams, Slack, etc.
Why it’s great: Enterprise-ready with Azure integration and multi-language options.
Language: C#, JavaScript, Python
GitHub Stars: 4,000+

5. BotMan

What it does: PHP framework for multi-platform chatbots.
Why it’s great: Simple syntax, versatile.
Language: PHP
GitHub Stars: 5,000+

6. Bottender

What it does: React-based conversational interfaces.
Why it’s great: React state management integration.
Language: JavaScript
GitHub Stars: 2,000+

7. Dialogflow Community Edition

What it does: Open-source Google Dialogflow variant.
Why it’s great: Intent detection, ideal for small-scale projects.
Language: JavaScript
GitHub Stars: 1,000+

8. Botonic

What it does: React-powered, serverless chatbots.
Why it’s great: WhatsApp, Messenger integrations, extensive plugins.
Language: JavaScript (React)
GitHub Stars: 1,000+

9. ChatterBot

What it does: Creates responsive bots trained by data.
Why it’s great: Quick setup, trainable.
Language: Python
GitHub Stars: 10,000+

10. Botkit

What it does: Customizable multi-platform bots.
Why it’s great: Easy API, strong community support.
Language: JavaScript (Node.js)
GitHub Stars: 7,000+

How to Pick the Perfect Framework

Choosing the right tool depends on your needs:

Language: Python (Rasa, Chattermate), JavaScript (Botpress, Botkit).
Complexity: Simple (Chattermate, BotMan), Advanced (Rasa, Microsoft Bot Framework).
Features: Multi-channel (Botpress, Botkit, ChatterMate).
Community: Larger communities (Rasa, Botpress) offer more resources.

Quick Tip: Match the framework to your team’s skills. New to chatbots? Start easy with ChatterBot.

Real-World Win: ChatterMate in Action

Last month, I challenged my intern to build a customer support bot using ChatterMate. The result? A masterpiece! With AI integrations, real-time messaging, and smooth escalation, our response times dropped dramatically. If you’re in customer service, this is a hidden gem!

Comparison at a Glance

Framework	Language	Key Feature	GitHub Stars	Multi-Channel
Rasa	Python	Advanced NLU	15,000+	Yes
Botpress	JavaScript	Visual editor	10,000+	Yes
ChatterBot	Python	Automatic learning	10,000+	Limited
Microsoft Bot Framework	Multiple	Enterprise tools	4,000+	Yes
BotMan	PHP	Platform-agnostic	5,000+	Yes
Bottender	JavaScript	React-based	2,000+	Yes
Dialogflow CE	JavaScript	Intent recognition	1,000+	Yes
Botonic	JavaScript	Serverless	1,000+	Yes
ChatterMate	JS/Python	AI + human support	new	Yes
Botkit	JavaScript	Multi-platform	7,000+	Yes

Your Turn: What’s Your Favorite?

These frameworks are reshaping the chatbot landscape. Whether simplicity or cutting-edge AI is your goal, there's a perfect tool here for you. Have you used any? Got a hidden favorite we missed? Drop a comment—I’d love to hear your thoughts!

chatbots #opensource #AI #programming #developers #technology #javascript #python #php

Is the AI Revolution a Boom or Doom for Programmers?

Runix — Mon, 17 Mar 2025 16:08:00 +0000

The rapid advancement in AI, especially large language models like Claude 3.5, GPT-4 Turbo, and Gemini, has sparked an intense debate: Are these tools enhancing developers' capabilities, or are they setting the stage for an existential crisis for programmers?

Recently, I experienced something astonishing that made me reconsider my stance.

I assigned my intern a fairly complex task: implementing a "delete account" feature across multiple databases and microservices. This wasn't trivial—it involved intricate dependencies, cross-service validations, and careful handling of foreign keys that weren't consistently named.

My intern turned to Claude 3.5 for assistance. The results? Mind-blowing.

The code Claude helped him produce was not just good—it was exceptional. Here's what it did:

Automatically accessed system tables to discover and map foreign key relationships—even when naming conventions were inconsistent.
Dynamically generated mapper logic to manage these relationships accurately.
Covered extensive edge cases effortlessly.

The kicker? This all took 90% less time than we had initially estimated. A task that would typically take days was completed within hours, freeing up valuable time for other critical tasks.

Consider these recent industry insights:

According to GitHub’s Copilot survey, developers reported completing tasks up to 55% faster with AI-assisted tools.

Gartner predicts that by 2025, AI tools will be standard practice in over 70% of development organizations.

Stack Overflow’s 2023 developer survey revealed that nearly 75% of developers are already using or planning to use AI in their workflows.

Based on this experience and industry trends, here's my prediction:

AI won't entirely replace programmers. Instead, it will establish a middle ground, significantly improving efficiency and productivity. AI will handle repetitive and tedious coding tasks, freeing developers to focus more on innovation and higher-level problem-solving. Additionally, AI-assisted coding might encourage experienced programmers, who moved into management roles, to return to hands-on coding due to the reduced monotony and increased productivity.

This experience got me thinking:

Is AI here to replace us or empower us?

How should we adapt our skills and workflows?

Are we prepared for a future where coding is drastically accelerated or even automated?

I'd love to hear your experiences and views:

Do you see AI as a threat or a valuable partner in software development?

ChatterMate: A No-Code AI Agent Framework That Puts You in Control

Runix — Mon, 17 Mar 2025 09:56:36 +0000

For over 17 years, I’ve seen technology evolve—from the days of coding in COBOL and Rexx on mainframes to becoming a full-stack developer in today’s dynamic landscape. Yet, despite all these advancements, I often found myself frustrated by bloated, expensive, and overly complex chatbot solutions that didn’t really harness the full power of modern AI.

That’s why I built ChatterMate.
Why ChatterMate?
ChatterMate is a no-code AI agent framework designed for anyone who wants to build and run intelligent chatbots on their own terms. Here’s what makes it different:

Self-Hosted & Open-Source:
You retain full control over your data without being locked into costly SaaS subscriptions. Deploy it on your own server or cloud, and enjoy the freedom to customize every aspect.

Choice of AI Models:
Whether you prefer GPT-4, Claude, or even your own custom LLMs, ChatterMate is built to work with a range of AI engines so you can choose what best fits your needs.

Seamless Integrations:
It connects easily with tools like Slack, WhatsApp, Zendesk, and Jira. Automate conversations, manage support tickets, and maintain a smooth workflow without switching platforms.

Smart Handoff & Feedback:
ChatterMate isn’t just an AI chatbot—it’s an AI-powered agent. It automatically transfers chats to human agents when necessary and even collects feedback to improve its responses over time.

No-Code Customization:
Designed for both non-coders and developers, you can set up and customize the chatbot with a few clicks, or dive deeper into the code if you wish. There’s no pressure to subscribe to expensive services—just the freedom to build exactly what you need.

The Journey to ChatterMate
I started my career coding on mainframes, writing COBOL and Rexx, and later transitioned to full-stack development. Throughout my journey, I’ve always been driven by a desire to simplify and perfect the tools I use. I wanted software that wasn’t just functional but also intuitive, affordable, and under my control.

When I looked for a good AI-powered chatbot, I found that most available options were either massive, expensive sales traps or simply didn’t embrace AI as the core driver of innovation. I thought, “Why not build something that does it right?” That’s when I started experimenting with AI agent chat widgets. Working with Claude 3.5 and tools like Cursor reignited the thrill of coding for me. It was like rediscovering the magic of my early days—except now, AI is the creative force.

Building with AI: Tips & Lessons
Here are some tips that helped me along the way, and might inspire you if you’re looking to explore AI-driven development:

Find a Project You Can Improve:
Look for software that frustrates you—something that you know could be done better. This will fuel your motivation and ensure your project makes a real impact.

Plan for Drawbacks:
Identify the limitations of current solutions. Then, reimagine how you’d rebuild them with AI as the first principle. Transform obstacles into opportunities for innovation.

Get Design Inspiration:
Tools like Cursor and Claude 3.5 don’t just help you code—they inspire you. Use them to experiment with UI designs and functionality, and watch your ideas come to life.

Ask AI to Code Step by Step:
Instead of issuing one long command, break your tasks into smaller steps. This way, the AI won’t get overwhelmed, and you’ll have more control over the output. Always review and refine—never blindly accept AI-generated code.

Embrace the Addiction:
Once you experience the immediate gratification of rapid iterations and quick feedback, you might just get hooked. The creative freedom AI offers is addictive—in a good way. Enjoy the process, but balance it with careful planning and testing.

Looking Forward
ChatterMate isn’t just another chatbot framework—it’s a testament to the power of AI in transforming how we build and interact with software. It’s built for a future where you have the freedom to innovate without being chained to expensive, proprietary solutions.

If you’re excited about a future where AI-driven tools empower you to build better, more efficient software, I invite you to check out ChatterMate. Explore the code, contribute to the project, and join the conversation. Let’s build something amazing together!

Explore ChatterMate:

Website: chattermate.chat
GitHub: github.com/chattermate/chattermate.chat
Happy coding, and welcome to the AI revolution!

AI Is Additive !!

Runix — Mon, 17 Mar 2025 09:52:45 +0000

For over 17 years, I’ve witnessed the evolution of technology firsthand — from the days of coding in COBOL and Rexx on mainframes to becoming a full-stack developer in today’s dynamic landscape. Despite the incredible advancements, I often found myself longing for software that was both easy to use and sensibly priced. When I set out to find a good AI-powered chatbot, I was disappointed to discover that most available solutions were either massive, expensive sales traps like Sierra.ai or Observe.ai, or simply didn’t leverage AI to its fullest potential.

My breakthrough came when I started experimenting with a few test AI agent chat widgets. Working with Claude 3.5 and Cursor felt nothing short of magical. Claude 3.5 — oh it’s additive — it almost seems to understand your thoughts. Sure, it makes mistakes, but coupled with nearly two decades of experience and a passion for innovation, it reignited the thrill I once felt playing with pointers and records on a mainframe.

Coding has transformed into an art where imagination is seamlessly translated into code with the help of AI. Those small wins and smiles, which once came after grueling weeks debugging broken Java or mainframe code, are now instantaneous. In just a few weeks, I vibe-coded an extensive chat framework that I can hardly believe I built. This isn’t just another project — it’s a testament to how AI can be a catalyst for creativity and innovation.

For many, AI may seem like a harbinger of doom. But for some of us, it’s become a new form of addiction — an addiction to the freedom and endless possibilities it brings. As I look at the monstrous SaaS offerings flooding the market, I’m convinced that AI truly empowers innovation. It’s additive, it’s liberating, and it’s redefining what it means to build software in our time.

Tips for AI Addictive Coding
Over the years, I’ve honed a few tips to help you embrace the power of AI and even get a little “addicted” to the creative process:

- Find a Project You Can Improve
Look for a piece of software or a process that you know you could do better. Identify its shortcomings and imagine how AI can transform it. This will not only motivate you but also ensure that your project has a tangible impact.

- Plan for Drawbacks and Rewrite with AI in Mind
Every project has its limitations. Before diving in, plan for potential drawbacks — what’s not working and why? Then, consider how you would rebuild it with AI as the foundation. This mindset shift allows you to see obstacles as opportunities for reinvention.

- Get Design Inspiration
Tools like Cursor and Claude 3.5 are your new best friends. They not only help you code faster but also inspire you with their intuitive understanding of what could be. Use them as a reference point to explore design ideas and create user interfaces that are both modern and functional. (Imagine the seamless integration of a dynamic UI, where AI and design coalesce to enhance the user experience.)

- Ask AI to Code Step by Step

When working with AI, break down your tasks into smaller, manageable steps instead of issuing one long, complex command. This approach prevents the AI from becoming overwhelmed and making mistakes. Always review every change thoroughly — don’t blindly accept the code generated by AI. Remember, AI is a tool that follows your instructions, and we’re still the ones in charge.

- Get Ready to Get Addicted
Once you start experiencing the immediate gratification of AI-driven coding — where your ideas are rapidly transformed into working code — you might find yourself hooked. The thrill of quick iterations, instant feedback, and the creative freedom to explore new solutions can be irresistible. Embrace it, but remember to balance it with thoughtful planning and testing.

AI isn’t just a tool; it’s a new way of thinking and building. It’s additive, it’s liberating, and it’s here to stay. So, if you’re ready to experience a revolution in coding — where every line of code feels like a work of art — jump in and let the addiction begin!

Check out the repo which has born out of my addiction: github.com/chattermate/chattermate.chat

I Built an Open-Source AI Chatbot That You Can Fully Own – No Vendor Lock-In! 🚀

Runix — Mon, 17 Mar 2025 09:43:03 +0000

After working with AI chatbots for years, I kept running into the same problems—most chatbot platforms are either:
❌ Closed-source & overpriced (Intercom, Drift, Zendesk Chat)
❌ Rule-based & outdated (Rasa, BotPress)
❌ Too dependent on external APIs (DialogFlow, GPT-based services with no real control)

So I spent the last few months building ChatterMate (GitHub Repo), an AI-first, open-source chatbot framework that’s:

✅ Fully self-hostable – No forced cloud, full control over data
✅ Works with GPT-4, Claude, or your own models
✅ Handles AI-human handoff seamlessly
✅ Integrates with Slack, WhatsApp, Zendesk, Jira, and more
✅ No-code customization – But devs can extend it, too!

Why Open-Source?
I wanted something that devs, startups, and businesses could use without vendor lock-in, and something customizable for real-world AI automation. Whether it’s for customer support, AI assistants, or workflow automation, this is built to adapt.

Looking for Feedback & Contributors!
I’d love to hear what you think—

What’s your biggest frustration with AI chatbots today?
Do you prefer self-hosting over SaaS chat tools?
What features would make an AI chatbot actually useful for you?
If you’re into open-source, AI automation, or chatbot dev, feel free to check it out and share any feedback! 🚀

👉 GitHub Repo: github.com/chattermate/chattermate.chat
👉 Live Demo & Docs: chattermate.chat

Would love to hear your thoughts!