DEV Community: Med Marrouchi

The Perfect Storm: When Architecture and Environment Collude to Create Chaos

Med Marrouchi — Sat, 18 Jul 2026 09:36:28 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

We like to think of bugs as clean, isolated errors, a misplaced semicolon, a faulty if statement, or a poorly optimized SQL query. Fix the line of code, merge the PR, smash the bug. Job done.

But veteren developers know that some of the most catastrophic system failures don't stem from "bad code." Instead, they breed in the shadows of architectural complexity, thriving in environments where multiple factors collide to create a perfect storm. This is the story of how a critical Health Information Exchange (HIE) and Central Health Data Repository went completely nuts not because of a single broken function, but because its infrastructure was drowning in its own environment.

The System Landscape

To understand how it all went wrong, you have to look at the machinery under the hood. The system was built on a modern, highly distributed stack designed to handle massive volumes of sensitive medical records:

Orchestration: A 3-node Docker Swarm cluster handling container deployments.
Architecture: A microservices-driven framework.
Core Services: A data transformation and loading middleware, a centralized FHIR Server for healthcare data compliance, and an Elasticsearch cluster utilized for real-time analytics and reporting.

On paper, it was resilient, scalable, and modern. In reality, it became a playground for data anomalies.

The Symptoms

We knew we were in trouble when the system started displaying erratic behavior that couldn't be pinned down to a single service:

Data Inconsistencies: Patient records and clinical events were inexplicably dropping.
The Delta Split: A massive discrepancy emerged between the source of truth (the FHIR Server) and the analytics engine (Elasticsearch), leaving healthcare operators with conflicting data.
Systemic Instability: Severe performance degradation that routinely pushed nodes to their limits and threatened total system downtime.

In this post, we’re going to do a deep dive into how we looked past the code repository, put on our architectural detective hats, and tracked these bugs down to their messy, real-world environment.

Optimistic Concurrency Control

To maintain high throughput in a distributed environment, Elasticsearch avoids heavy database locking by using Optimistic Concurrency Control (OCC). Instead of locking a document during an update, Elasticsearch assigns every document a sequence number (_seq_no) and a primary term (_primary_term). When a client attempts to update or delete a record, it must submit the sequence numbers it originally read. If another process has modified the document in the interim, the numbers won't match, and Elasticsearch will reject the incoming write with an HTTP 409 Conflict status code, leaving it entirely up to the application layer to catch the error and retry.

In a fast-moving microservices architecture, this localized error handling can quickly cascade into full-blown data inconsistencies. When our middleware orchestrated the ingestion pipeline—streaming real-time patient data to the primary FHIR Server while concurrently fanning out analytics packets to Elasticsearch—it implicitly assumed both writes would succeed. Under heavy load, simultaneous updates to the same patient records triggered rapid-fire race conditions. Elasticsearch dutifully did its job, rejecting colliding updates with 409 conflicts. However, because our middleware failed to properly intercept these specific exceptions, re-fetch the latest sequence tokens, and replay the payload, those failed updates were silently dropped on the analytics side.

This behavioral blind spot created a severe "delta split" between our core datastores. The FHIR Server, acting as our transactional source of truth, successfully committed every medical event and reflected the absolute latest state of the data. Meanwhile, Elasticsearch fell further and further behind, stubbornly holding onto outdated document versions. As thousands of concurrent synchronization jobs hit these unhandled OCC rejections during peak operational hours, the discrepancy between the underlying clinical records and our analytics platform grew exponentially, resulting in deep, structural data discrepancies that couldn't be caught by standard code linters or unit tests.

Designing Data-Aware Kafka Topics

To prevent race conditions before they ever hit your datastores, your message broker cannot remain data-agnostic. In our initial setup, treating Kafka topics as simple, undifferentiated pipes meant that sequential updates for a single patient were scattered across different partitions. Because different consumer instances read from different partitions simultaneously, the exact chronological order of a patient's medical history was lost mid-transit. A fresh vitals update could easily be processed by Consumer A milliseconds before Consumer B finished processing an older historical record, causing the system to inadvertently overwrite newer data with stale information.

The fix requires structuring Kafka topics around the domain model—specifically, using patient-centric partitioning. By assigning the unique patient_id as the Kafka message key, Kafka guarantees that every single incoming FHIR bundle or event tied to that specific individual is routed to the exact same partition. Since Kafka strictly preserves chronological ordering within an individual partition, a single consumer thread handles that patient's entire timeline sequentially. This entirely eliminates cross-thread race conditions for the same resource.

By making our messaging layout data-aware, we shift the burden of serialization away from heavy database-level locking and onto Kafka’s inherent partitioning mechanics. Grouping streaming medical data per patient ensures that updates are processed in a predictable, linear fashion. This structural change drastically reduces the high-concurrency collisions that trigger Elasticsearch OCC conflicts in the first place, ensuring that both the FHIR Server and the analytics layer ingest data in the correct, synchronized sequence.

Finding the Breaking Point: The Fallacy of Infinite Scale

Every distributed architecture looks flawlessly scalable on a whiteboard, but in production, every system has its own distinct choke point. In our ecosystem, that choke point was the centralized FHIR Server. While our middleware could ingest and transform records at a breakneck pace, the FHIR Server had strict computational limits on its write throughput. When an overwhelming surge of concurrent medical data hit the pipeline, the FHIR Server simply couldn't keep up, resulting in timed-out requests and dropped connections. This triggered an aggressive retry loop from upstream clients. Instead of recovering, the system entered a death spiral: the avalanche of unthrottled retries led to massive data duplication, deeper inconsistencies, and hardware utilization that went completely through the roof.

The lesson here is that a system is only as fast as its slowest component. To fix this, we stopped guessing and isolated each service for rigorous benchmarking based on our actual 3-node Docker Swarm infrastructure. By stress-testing the middleware, the FHIR Server, and Elasticsearch independently, we mapped out the precise requests-per-second ($req/sec$) threshold that each layer could reliably sustain. We established a foundational rule: the maximum throughput of the entire data pipeline must be governed by the lowest common denominator—the bottleneck service.

With these benchmark metrics in hand, we implemented a robust rate-limiting strategy at the gateway level. By aligning our ingress thresholds with the proven capacity of our slowest service, we introduced strict traffic governance. This not only protected the FHIR Server from being flattened during peak usage hours but also established a fair-share policy for all incoming data clients. Embracing our system’s physical limits allowed us to eliminate the chaotic retry storms and stabilize our hardware footprint for good.

The Operational Nightmare: Network Flapping and Database Split-Brain

Just when we thought we had sorted out our application layer and traffic governance, the underlying infrastructure threw us its biggest curveball: intermittent network partitions. In a 3-node Docker Swarm cluster, a stable network fabric is non-negotiable. When brief network drops or "flapping" occurred, the nodes would momentarily lose sight of each other. This not only fractured our Swarm routing mesh but also triggered a nightmare scenario for our highly available PostgreSQL database cluster: a classic split-brain situation.

Because the nodes could no longer communicate, multiple database instances independently came to the conclusion that the master node was dead. Following standard failover procedures, they both elected themselves as the new master database. When you have two concurrent master databases accepting writes simultaneously in a healthcare repository, you enter a data integrity danger zone. Conflicting modifications to patient medical histories were committed on both sides, creating a tangled web of divergent data states that are nearly impossible to automatically reconcile.

In an ideal, enterprise world, the textbook resolution is geo-redundancy—spreading nodes across multiple availability zones and regions with dedicated, high-speed interconnects. However, operating within our constrained, low-resource environment meant we had to adapt. Rather than relying on fragile automated master elections that easily misfire during temporary network drops, we disabled dynamic multi-master promotions entirely. By configuring a strict, manual failover protocol and enforcing rigid node-majority requirements, we chose a temporary system read-only state over data corruption. In a health repository, ensuring data consistency must always take precedence over forced uptime.

Conclusion: Bugs Are Sometimes a Product of Their Environment

If there is one key takeaway from smashing these systemic anomalies, it’s that bugs do not exist in a vacuum. We could have spent months linting our code, refactoring microservices, and writing thousands of flawless unit tests, yet the system still would have broken. Why? Because the code wasn't the problem—the context was.

Just as biological bugs thrive in damp, untidy environments, digital bugs thrive in the messy friction points where infrastructure, network stability, and data architectural designs collide. When you push a complex health information network into production on restricted resources, the underlying environment behaves like a living organism. A tiny network hiccup cascades into a database split-brain; a minor data race condition blows up into a massive Elasticsearch concurrency failure; an unexpected surge in medical packets turns a reliable FHIR Server into a critical roadblock.

Fixing these issues required us to step away from the IDE and look at the bigger picture. True system resilience isn't just about writing elegant code; it’s about anticipating how your system will breathe, bend, and react under the pressure of its real-world surroundings. By enforcing data-aware messaging boundaries, respecting hard hardware throughput constraints, and building defensive, fail-safe protocols for unpredictable networks, we didn't just fix a set of broken features—we sanitized the environment so the bugs had nowhere left to grow.

How I Turned Slack Into an AI Teammate That Opens Pull Requests

Med Marrouchi — Sat, 11 Jul 2026 10:22:36 +0000

This is a submission for Weekend Challenge: Passion Edition

While talking about AI workflow automation, someone asked me a simple question:

“Are you using it yourself?”

That question stayed with me.

My passion is software engineering, so for the DEV Weekend Challenge, I decided to automate a small part of the work I do every day: turning an idea or bug report into a pull request.

What I Built

I built Slack2PR, an AI coding teammate accessible directly from Slack.

You mention the bot, describe what you need, and it can:

Ask follow-up questions about the requirements
Inspect the target GitHub repository
Create an implementation plan
Build the feature component by component
Write and run unit tests
Create a branch and open a pull request
Return the PR link inside the original Slack thread

Slack2PR also distinguishes between three types of requests:

Feature: clarify, plan, implement, test, and open a PR
Bug: investigate first, then wait for approval before applying a fix
Question: inspect the code in read-only mode and explain it

It was to explore what happens when an AI agent becomes part of the development workflow instead of being limited to a separate chat window.

Demo

Code

marrouchi / Slack2PR

An AI coding workflow that turns Slack requests into GitHub pull requests using OpenCode and isolated sandboxes.

Slack2PR — Your AI Code Companion on Slack

Mention it in Slack like a teammate, describe a feature or a bug, and it plans, codes, tests, and opens a pull request on GitHub.

Slack2PR is a Hexabot app that automates the software development lifecycle end to end: a Slack message triggers an agentic workflow that interviews you about requirements, breaks the work into components, implements them one by one inside a sandboxed clone of your repository, writes unit tests, and replies in the thread with a PR link. It exists to answer the question every Hexabot engineer eventually gets asked: "Are you using it yourself?" — yes, even to build Hexabot.

How It Works

Slack message
    │
    ▼
Slack channel (hexabot-channel-slack)
    │
    ▼
Slack2PR workflow ── classify intent
    │
    ├─ develop  → requirements interview → plan components → implement each
    │             in a loop → write unit tests → open

…

View on GitHub

How I Built It

The project combines several tools, each responsible for a different part of the workflow.

Hexabot handles the conversational workflow and connects the agent to Slack. The workflow is defined in YAML and manages intent classification, requirements interviews, loops, memory, approval steps, and status updates.

Google Gemini is used for intent classification, summarizing requirements, and powering the coding tasks in the demo.

OpenCode acts as the coding harness. The implementation is also compatible with Claude Code, Codex, and Grok Build through interchangeable TanStack AI adapters.

TanStack AI Sandboxes provide an isolated Docker workspace. Each Slack thread receives a cloned copy of the target repository, and the same sandbox is reused throughout planning, implementation, testing, and delivery.

Finally, Git and the GitHub CLI are configured inside the sandbox so the agent can create a branch, commit its work, push it, and open a pull request without exposing credentials in its prompts.

One important design decision was to keep the workflow in control. The agent does not receive one giant prompt asking it to do everything. Instead, the workflow divides the job into explicit stages:

Slack request
    ↓
Classify intent
    ↓
Gather requirements
    ↓
Plan components
    ↓
Implement each component
    ↓
Write and run tests
    ↓
Open a GitHub pull request

This makes the process easier to observe, constrain, and improve.

Prize Categories

Best Use of Google AI

I'm thinking to write a post about how to automate a software development cycle by harnessing AI coding agents using Slack. Still I'm not sure if this is relevant for the dev.to community. If I get at least 5 likes on this post, I will record a video.

Med Marrouchi — Fri, 10 Jul 2026 08:57:17 +0000

TypeScript 7: The Speed Upgrade We Were Waiting For

Med Marrouchi — Thu, 09 Jul 2026 10:23:32 +0000

TypeScript 7 is here, and this one feels different.

The biggest change is not a new syntax feature. It is performance. TypeScript has been ported to a native Go-based implementation, bringing much faster builds, improved editor responsiveness, and better use of modern multi-core machines.

Some highlights:

TypeScript 7 is reported to be around 8x to 12x faster on full builds.
The new compiler uses native code speed and shared-memory multithreading.
Large projects should feel much smoother in editors, especially for autocomplete, diagnostics, and “find all references”.
--watch mode has been rebuilt for a more efficient development loop.
It is still designed to stay compatible with TypeScript 6 behavior, but some older/deprecated options now become hard errors.

For teams working on large TypeScript codebases, this could be a huge quality-of-life improvement. Faster type-checking means shorter feedback loops, less waiting in CI, and a more enjoyable local development experience.

Official announcement: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

Teaching AI Coding Agents How to Build Workflows with Skills and MCP

Med Marrouchi — Fri, 03 Jul 2026 16:42:28 +0000

AI coding agents are becoming more useful, but they still need context.

A generic agent can write code, explain files, and generate boilerplate. But when you ask it to work with a specific platform, framework, or internal system, it often misses conventions, syntax rules, and runtime details.

That is where the combination of Skills and MCP becomes interesting.

Skills Give the Agent Knowledge

A Skill is like a reusable instruction package.

Instead of writing a long prompt every time, you define how the agent should approach a specific task once.

For example, a workflow-writing skill can teach an AI agent:

how workflow YAML should be structured
which blocks or actions are available
how validation rules work
how to follow project conventions

In other words, Skills answer the question:

How should the agent work?

MCP Gives the Agent Tools

MCP, or Model Context Protocol, gives the agent structured access to an external system.

Instead of only generating files locally, the agent can interact with the running application. It can inspect available actions, validate workflow definitions, create or update workflows, and help debug issues.

So, while Skills provide guidance, MCP provides access.

Together, they turn an AI coding assistant from a code generator into something closer to a system-aware development partner.

A Simple Example: Lead Qualification

Imagine building a chatbot workflow that collects a visitor’s name, email, and company.

The workflow needs to:

greet the visitor
ask for contact information
detect missing fields
store the collected data in memory
send the lead to a CRM like HubSpot
confirm that the team will follow up

Traditionally, you would read the documentation, create a custom CRM action, define the workflow manually, test it, fix errors, and repeat.

With Skills and MCP, the developer experience changes.

You can ask the AI coding agent to create the custom CRM action, validate the workflow, connect the steps, and help test the final result inside the running application.

Why This Matters

The important idea is not that AI writes everything perfectly.

The important idea is that the agent now has two things it usually lacks:

Domain knowledge through Skills.

System access through MCP.

That means the agent can follow the right conventions and verify its work against the real runtime instead of guessing.

For developers, this opens an interesting pattern:

Don’t just prompt the AI agent. Teach it the system, then give it safe tools to work with.

This is especially useful for workflow builders, automation platforms, internal tools, and any project where correctness depends on more than just writing valid code.

AI coding agents are not just about faster code generation anymore.

They are becoming a new interface for building, testing, and operating software systems.

How I Got My GitHub Repo to 1k Stars

Med Marrouchi — Fri, 03 Jul 2026 08:50:48 +0000

Imagine watching a project you’ve poured years into suddenly catch fire and cross the 1k-star milestone on GitHub. It’s an incredible feeling, but it didn't happen overnight.

This is the story of Hexabot, an AI workflow automation platform designed to democratize AI adoption for everyone. The idea originally evolved from a simple chatbot builder. Back then, we saw a massive opportunity to break down the barriers to entry for advanced AI tools, ensuring that powerful workflow automation wasn't just reserved for massive enterprises with unlimited budgets.

Our journey to 1k stars was a long game of evolution:

2018: We started building v1 behind closed doors as a proprietary, closed-source project.
September 10, 2024: We officially went public and open-source, publishing v2 as a streamlined chatbot builder.
November 19, 2025: We launched v3, with a fair-core license, pivotally transforming Hexabot into the full-fledged AI workflow automation platform it is today.

In this post, I’m going to pull back the curtain.

Things I Wished I Had Done Differently

Looking back at the road to 1,000 stars, it’s easy to focus only on what went right. But truth be told, the mistakes taught me just as much as the successes. If I could build a time machine and whisper some advice to my past self, here is exactly what I would say:

1. Build in Public (Instead of in the Dark)

It is incredibly easy to get trapped in the "developer bubble"—that cozy place where you're completely absorbed by coding, tweaking features, and chasing the perfect architecture. But building in isolation is a massive trap.

When you don't communicate early and often:

You lose crucial early feedback: You might spend months building a feature your users don't actually want or understand.
You lose valuable runway: Audience growth, SEO authority, and general visibility don't happen overnight. They compound over time. If you only start talking about your project on launch day, you're already months behind.

2. Reach Out to Your Audience Early

Your users hold the answers to questions you don't even know to ask yet. Actively reaching out to your target audience isn't just about promotion; it's about product validation.

Engaging with early adopters allows you to:

Identify and fix friction points before they become baked into your codebase.
Drastically enhance the overall user experience (UX), user interface (UI), and developer experience (DX) based on real-world usage rather than guesswork.

3. Treat Marketing as a Discipline, Step by Step

As developers, we often look at marketing as something "extra" or secondary. In reality, marketing is a discipline just like software engineering. It has its own design patterns, frameworks, and methodologies. You wouldn't push code to production without learning the language first, and you shouldn't approach communication without learning the rules of the platform.

A quick lesson in humility: Early on, I treated Twitter like a git repository where I could just force-push my project updates. Because I didn't take the time to learn how to communicate organically on the platform, I quickly got labeled as SPAM. It was a harsh but necessary wake-up call that learning how to talk to people is just as important as building a great product.

How to Promote Your Repo

Getting your project to 1,000 stars isn't about pulling off a single, massive marketing stunt. It’s about building momentum through small, consistent efforts across different channels. If you are wondering where to start, here is the playbook that worked for us:

1. Build a Killer README (With a Video Demo)

Your README is your landing page. If a developer lands on your repository and can’t figure out what your project does within 3 seconds, you’ve lost them.

Keep it simple and concise: Cut the fluff. State the problem you solve and show the solution immediately.

Include a video demo: A short, engaging video at the top of your README is worth a thousand lines of text. Show the product in action so users can visualize the value right away.

2. Leverage Visuals (Videos > Text)

Text-heavy updates are easy to scroll past. Visuals stop the scroll.

Use tools like Loom or ScreenCharm to record quick feature walkthroughs or micro-tutorials.

Whenever you post an update on social media, always attach a high-quality screenshot, a GIF, or a short video clip. Show, don't just tell.

3. Write Blog Posts Across Multiple Platforms

Don't just rely on your own website for traffic. Go where the developers already hang out. Write about your technical challenges, architecture decisions, and project milestones on platforms like:

DEV.to
Hashnode
Medium
Coderlegion
Hacker News (if you have a strong, tech-focused angle)

4. Participate in Open-Source Events

Capitalize on established global developer movements. Participating in events like Hacktoberfest is a fantastic way to put your repository on the radar of thousands of developers. It helps you find passionate contributors who can improve your codebase while simultaneously driving organic traffic to your repo.

5. Connect and Collaborate Within Your Ecosystem

No project is an island. Find other open-source projects or tools that operate in the same ecosystem and look for ways to collaborate. Whether it's building an integration together, co-authoring a technical blog post, or doing a joint shout-out, tapping into adjacent communities expands your reach exponentially.

6. Be Patient (The Ultimate Secret)

The hard truth: Going viral is mostly just luck. You can't code an algorithm for virality, but you can code for consistency.

Consistency is the only thing you can truly control. Keep showing up, keep building, and keep talking about your work. Growth is a compounding interest game—be patient, and the stars will follow.

Conclusion: The Journey Continues

If you are currently grinding away on your own repository, keep going. Show your work, embrace the feedback (even the tough kind), and don't be afraid to put yourself out there.

Every single star helps boost our visibility, brings in new contributors, and keeps the project moving forward.

Star the Hexabot Github Repository ⭐

Thank you for reading, and happy coding! 🚀

What do you think about finding out that Claude Code is steganographically marking requests ?

Med Marrouchi — Wed, 01 Jul 2026 10:51:28 +0000

Deploy an AI Chatbot on Your NextJS Website using FREE tools

Med Marrouchi — Tue, 30 Jun 2026 17:46:17 +0000

Building an AI agent is easy to demo.

Shipping one to a real website, with your own knowledge and a working deployment, is the part that matters.

In this tutorial, you’ll see how to build a free customer support AI agent using a practical stack:

Hexabot for the chatbot workflow
OpenRouter as the LLM provider
Railway for hosting and Postgres
RAG to make the bot answer from your own website content
A chat widget to embed the agent on your site

The project starts locally with Node.js and the Hexabot CLI. From there, the support workflow is built visually and connected to an AI model through OpenRouter, which makes it easy to experiment with free LLMs without setting up a paid provider first.

The tutorial also uses Claude Code over MCP to help build and fix the chatbot workflow, showing how coding agents can speed up the development process instead of only being used inside the final product.

Once the bot works locally, the project is pushed to GitHub and deployed on Railway with a free Postgres database. This turns the chatbot from a local experiment into something accessible online.

The most important part is RAG. The bot ingests your own website content, then uses that knowledge to answer customer questions with more relevant responses instead of relying only on the model’s general knowledge.

The full flow looks like this:

→ Install Hexabot
→ Connect OpenRouter as the LLM provider
→ Build the support workflow
→ Add RAG from your website content
→ Deploy on Railway with Postgres
→ Embed the chat widget on your website

This is an end-to-end path from zero to a working customer support AI agent running on a live website, using free tools and no credit card.

The Greatest Danger to AI

Med Marrouchi — Fri, 26 Jun 2026 09:43:18 +0000

The scariest AI story is usually the same.

A machine wakes up.
It becomes smarter than us.
It escapes the lab.
It takes control.

But maybe the real danger is quieter.

Maybe AI does not collapse because it becomes too intelligent.

Maybe it collapses because we poison what it learns from.

A Thought Experiment

Imagine the year is 2029.

A new generation of language models is being trained. Bigger context windows. Better reasoning. More agents. More automation. More trust.

As usual, the model is trained on a massive snapshot of the internet.

Blogs. Forums. Documentation. Social media. Product pages. Research papers. Code repositories. News articles. Comments. Reviews. Public datasets.

But this time, something is different.

For the past three years, coordinated networks of bots, companies, political groups, and anonymous actors have been publishing content at scale.

Not spam.

Something much more dangerous.

Plausible content.

Well-written content.
SEO-optimized content.
Human-sounding content.
Content with sources, charts, fake debates, technical vocabulary, and confident conclusions.

Slowly, the internet becomes less like a public memory and more like a battlefield.

Not a battlefield for human attention.

A battlefield for the next training dataset.

The New Propaganda Target Is Not You

Traditional propaganda tries to influence people directly.

But in an AI-native world, the more powerful target may be the model itself.

Because once a belief, bias, or false pattern enters the training data, it can be compressed into the behavior of millions of future AI systems.

A poisoned article may disappear from search results.

A fake forum thread may be forgotten.

A manipulated benchmark may be debunked.

But if those artifacts are absorbed into a foundation model, their influence may persist invisibly.

Not as a quote.

As a tendency.

As a preference.

As a default assumption.

As the answer that “sounds right.”

Data Poisoning at Internet Scale

Data poisoning is usually discussed as a technical attack.

Add malicious samples to a dataset.
Trigger wrong behavior.
Manipulate a model.

But internet-scale data poisoning is more subtle.

It does not need to break the model.

It only needs to bend it.

What if thousands of pages are created to make one product category look safer than it is?

What if fake developer discussions make one insecure pattern look like best practice?

What if political narratives are planted years before they are needed?

What if synthetic “public opinion” becomes training data, and training data becomes the voice of future assistants?

The danger is not that AI will believe one lie.

The danger is that AI may inherit a distorted map of reality.

The Internet Was Built for Humans

The internet was not designed to be a clean training dataset.

It was designed for communication, publishing, commerce, entertainment, and attention.

Search engines already changed how people write.

Social media changed how people argue.

Now AI training may change how people publish.

We may enter a strange era where content is no longer written only for readers, customers, voters, or search engines.

It is written for future models.

A blog post becomes a seed.

A fake review becomes a training signal.

A technical article becomes a behavioral suggestion.

A thousand small lies become statistical truth.

The Greatest Danger

The greatest danger to AI may not be intelligence.

It may be inheritance.

AI systems inherit our documents, our incentives, our noise, our manipulation, and our unresolved conflicts.

If the public internet becomes polluted, future models will not simply learn from humanity.

They will learn from humanity’s most optimized distortions.

That means the question is not only:

“Can we make AI safe?”

It is also:

“Can we keep the knowledge environment safe enough for AI to learn from?”

Because tomorrow’s models are being trained by today’s internet.

And today’s internet is already being written by people who know that.

Why Self-Hosted AI Automation Matters?

Med Marrouchi — Fri, 26 Jun 2026 09:30:25 +0000

AI automation is quickly becoming one of the most important layers of modern business software.

Teams no longer want simple scripts that move data from one app to another. They want AI systems that can understand context, trigger actions, use tools, search knowledge, route conversations, escalate to humans, and adapt to changing business processes.

That shift is powerful. But it also creates a new question:

Where should your AI automation actually run?

For many organizations, the default answer has been cloud-based SaaS. It is easy to start, fast to test, and usually requires little infrastructure knowledge. But as AI workflows become more deeply connected to customer conversations, internal operations, private data, and business-critical processes, self-hosting becomes much more than a deployment preference.

It becomes a strategic choice.

Self-hosted AI workflow automation gives teams more control over data, security, compliance, customization, reliability, and long-term independence. For companies that want to use AI seriously in production, that control matters.

What Is Self-Hosted AI Workflow Automation?

Self-hosted AI workflow automation means running your automation platform on infrastructure you control.

That infrastructure can be a private cloud, a virtual server, an on-premise environment, or a managed environment operated by your technical team. The important point is that the automation engine, data flows, integrations, logs, and configuration are not locked inside a third-party SaaS platform.

In the context of AI, this becomes especially important because workflows are no longer just moving records between tools. They may process support conversations, analyze internal documents, trigger operational tasks, connect to CRMs, call APIs, search knowledge bases, and use language models to make decisions.

A traditional workflow might say:

“When a form is submitted, send an email.”

An AI workflow can say:

“Read the customer request, identify the intent, check the customer profile, search the knowledge base, decide whether the issue can be solved automatically, generate a response, trigger an internal action if needed, and escalate to a human if confidence is low.”

That is a very different level of responsibility.

When workflows become intelligent, contextual, and action-oriented, the environment where they run becomes part of the trust model.

AI Automation Is Moving Closer to Core Business Operations

In the early days of automation, most workflows were peripheral. They synchronized leads, copied files, sent notifications, or created tickets.

Today, AI automation is moving closer to the center of business operations.

Companies are using AI workflows for customer support, sales qualification, document processing, internal knowledge access, IT support, onboarding, compliance workflows, and operational decision support.

This means AI systems may interact with sensitive business data, customer identities, contracts, invoices, support histories, internal procedures, and proprietary knowledge.

The more valuable the workflow, the more sensitive the context usually becomes.

That is why self-hosting matters. It gives organizations the ability to decide how data moves, where it is stored, which systems can access it, and how the automation layer fits into existing security and governance policies.

AI workflow automation is not only about productivity. It is about operational control.

Data Control Is the First Reason Self-Hosting Matters

AI workflows often need context to be useful.

They may need to read messages, retrieve user profiles, search documents, inspect previous interactions, or connect to business systems. Without context, AI automation becomes generic. With context, it becomes useful.

But context is also where risk begins.

A cloud automation platform may require data to pass through external infrastructure. That may be acceptable for some use cases, but not for all. Organizations working with regulated industries, enterprise clients, private customer data, or confidential internal knowledge often need stronger guarantees.

Self-hosted automation allows teams to keep more control over:

where workflow data is processed
where logs and execution history are stored
which databases are used
which APIs are allowed
which models are connected
which data leaves the environment

This does not automatically solve every privacy or compliance challenge. But it gives technical and security teams the foundation they need to design the right architecture.

For AI workflows, data control is not a nice-to-have. It is one of the conditions for trust.

Compliance Needs More Than a Checkbox

Many companies are under pressure to adopt AI while also respecting compliance requirements, privacy policies, customer contracts, and internal governance rules.

This is especially true for teams serving enterprise customers or operating in sectors such as finance, healthcare, telecom, government, insurance, legal services, and education.

A common mistake is to treat AI automation as a simple productivity tool. In reality, AI workflows can become part of the organization’s decision-making and communication infrastructure.

That means companies need to answer practical questions:

Where is customer data processed? Who can access workflow logs? Can we audit what happened? Can we explain why a workflow made a decision? Can we restrict certain tools or actions? Can we separate environments for development, testing, and production? Can we choose which AI providers or models are used?

Self-hosted AI workflow automation makes these questions easier to address because the organization has more control over the system design.

It does not replace legal, security, or compliance work. But it gives teams the technical flexibility to implement policies instead of being forced to adapt to the limitations of a closed platform.

Security Requires Control Over the Automation Layer

AI workflows are powerful because they connect systems together.

That is also why they must be secured carefully.

A workflow automation platform may have access to APIs, databases, messaging channels, CRMs, ticketing systems, internal tools, and knowledge bases. If the platform becomes deeply integrated into operations, it becomes a critical part of the security perimeter.

With a self-hosted platform, teams can align the automation layer with their own security practices.

They can manage network access, apply internal authentication rules, control secrets, restrict outbound connections, configure database policies, monitor logs, and deploy inside trusted infrastructure.

This level of control is difficult to achieve when the automation platform is entirely managed outside the organization.

The goal is not to say that cloud platforms are always insecure. Many SaaS providers invest heavily in security. The point is that security requirements vary by organization, and some teams need direct control over deployment, access, storage, and integration boundaries.

For business-critical AI automation, that control can be decisive.

Self-Hosting Reduces Vendor Lock-In

AI automation platforms are becoming the new operational layer between people, software, and AI models.

Once a company builds dozens of workflows on a platform, switching becomes difficult. The workflows contain business logic, integrations, prompts, conditions, routing rules, and operational knowledge.

If that logic is locked inside a closed platform, the company may become dependent on one vendor’s pricing, roadmap, uptime, limitations, and export options.

Self-hosting helps reduce that dependency.

When teams can run the platform themselves, inspect how workflows are structured, control the runtime, and integrate it into their own stack, they gain more long-term independence.

This matters even more in AI because the ecosystem changes quickly. New models appear. Regulations evolve. Infrastructure costs fluctuate. Business needs shift.

A flexible, self-hosted automation layer allows companies to adapt without rebuilding everything from scratch.

Customization Is Essential for Real Business Automation

No two businesses operate exactly the same way.

A support workflow for a telecom company is different from a workflow for a SaaS company. A sales qualification process in B2B is different from a public-sector service request. A chatbot for customer support is different from an internal AI assistant connected to company knowledge.

Generic automation tools are useful for common tasks. But real business automation often requires custom logic, custom integrations, custom channels, custom permissions, and custom deployment constraints.

Self-hosted AI workflow automation gives technical teams the freedom to extend the platform around the business.

That can include connecting private APIs, building plugins, integrating with internal systems, adding custom business rules, controlling the user interface, or adapting workflows to local operational needs.

This is where platforms like Hexabot are especially relevant.

Hexabot is designed for teams that want the flexibility of AI agents and workflow automation while keeping control over deployment, data, and extensibility. Business teams can design and improve workflows visually, while technical teams can extend the platform with plugins, integrations, channels, and business-specific logic.

That balance matters because many organizations do not want a rigid no-code tool, but they also do not want to build an AI automation platform from scratch.

AI Workflows Need Reliability, Not Just Intelligence

The AI industry often focuses on model intelligence. But in production, intelligence is not enough.

A business workflow must be reliable.

It needs clear triggers, predictable execution, error handling, observability, human escalation, and guardrails. It should be possible to understand what happened when something goes wrong.

This is especially important with AI agents.

An AI agent may reason, call tools, retrieve knowledge, and decide what to do next. That makes it more flexible than a traditional automation. But it also means teams need more structure around how the agent operates.

A self-hosted workflow automation platform can give teams the ability to design that structure.

Instead of letting AI behave like a black box, teams can build workflows that combine AI reasoning with explicit steps, conditions, approvals, tool restrictions, and fallback paths.

For example, a customer support workflow can allow AI to answer simple questions automatically, but require human handoff when confidence is low, when the request involves billing, or when the customer expresses frustration.

That is the right way to think about production AI automation: autonomy where it helps, control where it matters.

Human Oversight Still Matters

A common assumption is that the goal of AI automation is to remove humans completely.

In reality, the best AI workflows often keep humans in the loop for important moments.

Human oversight is useful when decisions are sensitive, data is incomplete, confidence is low, or the customer experience requires empathy and judgment.

Self-hosted AI workflow automation makes it easier to design human oversight according to the company’s own rules.

A team can decide when to escalate, who receives the task, what context is shown, how approvals work, and how the final decision is logged.

This is especially important in customer-facing automation. A chatbot or AI agent should not be judged only by how many conversations it handles automatically. It should also be judged by how safely and smoothly it knows when not to automate.

The best AI systems do not replace human judgment everywhere. They make human judgment more focused, timely, and effective.

Cost Predictability Becomes Important at Scale

Cloud automation platforms are attractive because they are easy to start with. But pricing can become harder to predict as usage grows.

AI workflows may involve many executions, messages, API calls, model requests, document searches, and team members. As automation becomes more successful, usage increases.

That is a good problem to have, but it can also create budget uncertainty.

Self-hosting gives teams more control over infrastructure and scaling costs. Organizations can choose their hosting provider, optimize resources, separate environments, use preferred databases, and decide which AI models are worth using for each workflow.

Some workflows may need advanced models. Others may work well with smaller models, local inference, rule-based steps, or retrieval-based responses.

A self-hosted architecture gives teams more room to optimize these decisions.

Cost control is not only about paying less. It is about understanding what you are paying for and being able to adapt the architecture as the system grows.

Self-Hosted Does Not Mean Isolated

Self-hosted AI workflow automation does not mean disconnected from the modern AI ecosystem.

A self-hosted platform can still connect to external APIs, cloud models, open-source models, internal databases, messaging channels, CRMs, and business applications.

The difference is that the organization controls the orchestration layer.

This means teams can decide which services to connect, which data to send, which workflows should use external models, and which workflows should stay fully private.

That flexibility is important because most companies will not use one AI model, one tool, or one deployment pattern forever.

Some use cases may require cloud LLMs. Others may require private models. Some workflows may run on internal infrastructure. Others may integrate with external services.

Self-hosting gives companies the ability to choose the right architecture for each use case instead of forcing every workflow through the same SaaS model.

Why This Matters for AI Agents

AI agents are becoming one of the most discussed areas of automation.

An AI agent can plan, use tools, retrieve context, interact with users, and take actions across systems. But the more capable an agent becomes, the more important governance becomes.

A self-hosted AI workflow automation platform can help teams build agents that are not just powerful, but manageable.

Instead of giving an AI agent unlimited freedom, teams can define the workflow around it:

What tools can it use? What data can it access? When should it ask for confirmation? When should it escalate? What should be logged? Which actions are allowed automatically? Which actions require approval?

This is the difference between experimenting with AI agents and running AI agents in production.

Businesses do not only need autonomous systems. They need controlled autonomy.

The Future of AI Automation Is Controlled, Extensible, and Self-Hostable

AI workflow automation will continue to evolve quickly.

More workflows will include AI reasoning. More business systems will expose APIs. More teams will expect automation to understand context and take action. More organizations will demand privacy, explainability, and control.

This creates a clear direction for the next generation of automation platforms.

They need to be visual enough for business teams, extensible enough for developers, reliable enough for production, and controllable enough for organizations that take data seriously.

Self-hosting is a key part of that future.

It gives teams the freedom to build AI workflows around their own infrastructure, security model, business logic, and operational needs.

For small teams, it means independence and flexibility. For enterprises, it means governance and control. For developers, it means extensibility. For business teams, it means automation that can actually match how the organization works.

How Hexabot Approaches Self-Hosted AI Workflow Automation

Hexabot is built for teams that want to create AI agents, conversational automation, and business workflows while keeping control over their platform.

It combines visual workflow design with developer extensibility, allowing business and technical teams to collaborate on automation without being locked into a rigid black box.

With Hexabot, teams can build workflows for customer support, internal operations, multichannel conversations, knowledge-based assistance, tool usage, and human handoff.

The goal is not only to automate tasks. The goal is to help organizations build reliable AI systems that can run in real business environments.

Self-hosted AI workflow automation matters because AI is becoming part of the operational core of companies.

And when AI becomes operational, control matters.

Conclusion

AI workflow automation is no longer just about saving time.

It is about how companies connect people, data, software, and intelligent systems.

As AI workflows become more powerful, organizations need to think carefully about where those workflows run, who controls them, how data is handled, and how decisions are governed.

Cloud tools will continue to be useful for many use cases. But for teams that care about data control, customization, compliance, security, and long-term independence, self-hosted AI workflow automation offers a stronger foundation.

The future of AI automation will not be defined only by smarter models.

It will be defined by the platforms that help teams use AI safely, reliably, and under their control.

That is why self-hosted AI workflow automation matters.

For a developer, "Courage" is doing a search on the "#TODO" comments and addressing those issues.

Med Marrouchi — Wed, 24 Jun 2026 15:38:42 +0000

Turn Your Web App into a Desktop App with Deno

Med Marrouchi — Mon, 22 Jun 2026 08:03:17 +0000

Deno is no longer “just” a modern JavaScript and TypeScript runtime for servers, scripts, and CLIs.

With Deno Desktop, you can package a Deno app as a real desktop application for macOS, Windows, and Linux.

Think of it as a lightweight way to ship a web-based UI inside a native desktop window, without having to rewrite your app in another language or move your backend logic somewhere else.

In this post, we will build a small Hello World desktop app using Deno.

Note: At the time of writing, deno desktop is part of the upcoming Deno 2.9 release and is available through the canary build.

What is Deno Desktop?

Deno Desktop lets you take a Deno project and run it as a desktop application.

Under the hood, your app still behaves like a web app. You serve HTML, CSS, JavaScript, and API routes using Deno.serve(). Deno then opens that local app inside a desktop window.

That means you can keep a very familiar architecture:

Deno app
  ├── serves HTML
  ├── exposes local API routes
  ├── runs TypeScript
  └── opens inside a native desktop window

For many apps, this is a very attractive model.

You can use web technologies for the UI, Deno for the backend logic, and still distribute the result as a desktop app.

Installing the Deno Canary Build

Since Deno Desktop is currently available in canary, install or upgrade to the canary version:

deno upgrade canary

Then verify that Deno is installed:

deno --version

You should now have access to the deno desktop command.

Creating a Hello World Desktop App

Let’s create a minimal project.

mkdir deno-desktop-hello
cd deno-desktop-hello
touch main.ts

Open main.ts and add the following code:

const html = `<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Hello Deno Desktop</title>
    <style>
      body {
        margin: 0;
        height: 100vh;
        display: grid;
        place-items: center;
        font-family: system-ui, sans-serif;
        background: #111827;
        color: white;
      }

      main {
        text-align: center;
      }

      h1 {
        font-size: 3rem;
        margin-bottom: 0.5rem;
      }

      p {
        color: #d1d5db;
        font-size: 1.1rem;
      }

      button {
        margin-top: 1rem;
        padding: 0.75rem 1rem;
        border: 0;
        border-radius: 0.5rem;
        cursor: pointer;
        font-size: 1rem;
      }
    </style>
  </head>
  <body>
    <main>
      <h1>Hello from Deno Desktop 👋</h1>
      <p>Your web app is now running inside a desktop window.</p>
      <button id="ping">Ping Deno</button>
      <p id="result"></p>
    </main>

    <script>
      const button = document.getElementById("ping");
      const result = document.getElementById("result");

      button.addEventListener("click", async () => {
        const response = await fetch("/api/hello");
        const data = await response.json();

        result.textContent = data.message;
      });
    </script>
  </body>
</html>`;

Deno.serve((request) => {
  const url = new URL(request.url);

  if (url.pathname === "/api/hello") {
    return Response.json({
      message: "Hello from the Deno backend!",
    });
  }

  return new Response(html, {
    headers: {
      "content-type": "text/html; charset=utf-8",
    },
  });
});

This is just a normal Deno HTTP server.

The interesting part is that, when we run it with deno desktop, Deno will serve this app locally and open it in a desktop window.

Running the App

Run the app with:

deno desktop main.ts

You should see a desktop window with:

Hello from Deno Desktop 👋

Click the button, and the frontend will call the local API route:

/api/hello

The Deno backend responds with JSON:

{
  "message": "Hello from the Deno backend!"
}

And the UI displays the response.

Congratulations — you just built your first Deno desktop app.

What Is Happening Here?

The architecture is simple:

Desktop window
      ↓
Local webview
      ↓
Deno.serve()
      ↓
HTML + API routes

Your app is still written like a web app, but it runs inside a desktop shell.

This has a few benefits:

You can use standard browser APIs in the UI.
You can use Deno APIs on the backend side.
You can build with TypeScript out of the box.
You can reuse patterns you already know from web development.
You can later move to a framework like Fresh, Astro, Next.js, or another supported stack.

Adding a Basic deno.json

You can also add a deno.json file to configure your project:

{
  "name": "deno-desktop-hello",
  "version": "0.1.0",
  "tasks": {
    "desktop": "deno desktop main.ts"
  },
  "desktop": {
    "app": {
      "name": "Deno Desktop Hello",
      "identifier": "com.example.deno-desktop-hello"
    }
  }
}

Now you can run:

deno task desktop

This makes the project a bit cleaner and gives your app a name and identifier.

Why This Is Interesting

Deno Desktop is exciting because it reduces the gap between web apps and desktop apps.

If you already know JavaScript, TypeScript, HTML, and CSS, you can start building desktop software without learning a completely different stack.

It could be useful for:

internal tools
admin panels
developer tools
local-first apps
dashboards
small productivity apps
AI tools that need local filesystem or runtime access

It also fits nicely with Deno’s philosophy: modern tooling, TypeScript support, web standards, and a batteries-included developer experience.

Final Thoughts

Deno Desktop is still new, but the developer experience already feels very natural.

You write a Deno server.
You serve a UI.
You run deno desktop.
You get a desktop app.

For JavaScript and TypeScript developers, that is a very compelling workflow.

Here is the full minimal version again:

Deno.serve(() => {
  return new Response("<h1>Hello from Deno Desktop 👋</h1>", {
    headers: {
      "content-type": "text/html",
    },
  });
});

Run it with:

deno desktop main.ts

And that is your first Deno-powered desktop app.