DEV Community: Sospeter Mong'are

Stop Trading Time for Money: A Software Engineer's Guide to Building Wealth Through Code

Sospeter Mong'are — Fri, 31 Jul 2026 08:02:30 +0000

One piece of advice every software engineer should think about is this:

"Figure out how to use your skills to make money, not just trade time for money."

At first, it sounds like someone is saying jobs are bad. That's not the point.

The real message is about leverage.

The Difference Between Working In Software and Building With Software

Most developers begin their careers by trading time for money.

You write code for a company, complete freelance projects, or work as a consultant. Your income depends on the number of hours you work.

There is absolutely nothing wrong with this. In fact, it's how most successful engineers develop their skills, gain experience, and build financial stability.

The limitation is simple: if you stop working, the income usually stops too.

Now imagine a different model.

Instead of building the same solution repeatedly for different clients, you build it once and allow hundreds or even thousands of customers to use it.

That's leverage.

You're Not Just a Developer. You're a Problem Solver.

One of the biggest mistakes software engineers make is believing their value lies in writing code.

It doesn't.

Your real value lies in understanding problems well enough to build solutions that people are willing to pay for.

The code is simply the tool.

Every project you've worked on has exposed you to problems that businesses struggle with every day.

Ask yourself:

What tasks do companies repeat constantly?
What processes waste the most time?
What integrations are always painful?
What manual work could be automated?

Those are business opportunities disguised as technical problems.

Productize What You Already Know

Many developers chase the next trendy idea when their biggest opportunity is hiding in the work they're already doing.

Suppose you've built payment integrations for multiple companies.

Instead of manually implementing the same integrations over and over, you could build:

A unified payments API
A webhook management platform
A payment reconciliation tool
A payment testing environment
A subscription billing platform

Rather than getting paid once for every integration, you create a product that many businesses can subscribe to.

The same principle applies across every industry.

If you've solved a problem more than three times, there's a good chance that problem deserves a product.

Build Software That Works While You Sleep

The beauty of software is that it scales.

Imagine you've built an inventory management system for a retail shop.

If you sell it as custom software, every new client requires another implementation, customization, and deployment.

But if you build it as a cloud-based SaaS platform, every new retailer simply signs up, configures their business, and starts paying a monthly subscription.

The same product serves hundreds or thousands of businesses with minimal additional effort from you.

That's the power of recurring revenue.

Instead of asking:

"How much should I charge for this project?"

Start asking:

"How many businesses have this problem?"

Developers Have More Opportunities Than Ever

Today's software engineers can build businesses around almost any technical skill. Here are a few examples:

SaaS Applications

Inventory Management System
Property Management Platform
School Management System
HR & Payroll Software
Appointment Booking Platform
CRM for SMEs
Restaurant POS System
Hotel Management Software

APIs for Developers

Payment Aggregation API
SMS & Email API
WhatsApp Messaging API
Identity Verification API
Currency Exchange API
Address Validation API
Document Generation API
Authentication & Single Sign-On API

Automation Platforms

Invoice Processing Automation
Employee Onboarding Automation
Approval Workflow System
Procurement Automation
Customer Support Workflow Automation
Marketing Campaign Automation
Data Synchronization Platform

AI-Powered Tools

AI Customer Support Assistant
AI Resume Screening Platform
AI Meeting Notes Generator
AI Document Search & Q&A
AI Contract Analysis Tool
AI Sales Assistant
AI Knowledge Base Assistant

Developer Tools

API Testing Platform
Error Monitoring Service
Database Migration Tool
CI/CD Deployment Platform
Log Management System
Feature Flag Service
Code Quality Analyzer
API Documentation Generator

Industry-Specific Software

Healthcare Clinic Management
Insurance Claims Platform
Construction Project Management
Agriculture Farm Management
Logistics & Fleet Tracking
Manufacturing ERP
Legal Case Management
Sacco Management System

Integration Platforms

ERP Integration Hub
CRM Integration Platform
Accounting Software Connectors
E-commerce Integration Platform
Data Synchronization Engine
Enterprise API Gateway

Monitoring & Security Tools

API Monitoring Dashboard
Uptime Monitoring Service
Security Vulnerability Scanner
Audit Logging Platform
Fraud Detection System
Access Management Platform
Compliance Monitoring Dashboard

The internet has made it possible for a single engineer to serve customers across the world.

You no longer need thousands of employees to build a successful software company.

Sometimes, all you need is one valuable product solving one painful problem.

Your Job Is Not the Enemy

There's a common misconception that every developer should quit their job and become an entrepreneur.

That's terrible advice for most people.

Your job provides more than a salary.

It gives you:

Real-world experience
Access to business problems
Industry knowledge
Professional relationships
Capital to invest in your own ideas

Think of your job as a paid research lab.

Pay attention to the frustrations customers repeatedly face.

Observe the repetitive work your team performs.

Listen to the complaints people make every day.

Hidden inside those frustrations are business opportunities.

Think Like a Business Owner

Instead of asking:

"What app should I build?"

Ask:

"What expensive problem can I solve repeatedly?"

Instead of asking:

"How do I get more freelance clients?"

Ask:

"Can I build a product that hundreds of clients can use?"

Instead of asking:

"What programming language should I learn next?"

Ask:

"What industry do I understand well enough to improve with software?"

Those questions lead to businesses, not just careers.

The Journey

Most successful software entrepreneurs don't start by building billion-dollar companies.

They start by solving one real problem.

Then they solve it again.

Then they turn that solution into a product.

The journey often looks like this:

Developer → Problem Solver → Product Builder → Business Owner

The goal isn't to stop trading time for money overnight.

The goal is to gradually build assets that generate value beyond your own working hours.

Because the most powerful thing about being a software engineer isn't your ability to write code.

It's your ability to create systems that continue delivering value long after you've finished writing them.

Your AI Agent Is Not an Engineer

Sospeter Mong'are — Mon, 27 Jul 2026 08:44:59 +0000

Building Reliable Software in the Age of Agentic Coding

A few weeks into using coding agents seriously, not for autocomplete, but for actually driving multi-file changes, wiring up integrations, standing up agent pipelines, I noticed a pattern. The code that came out looked right. It compiled, it ran, the demo worked. And then, days later, something broke in a way that made it obvious the agent had never actually understood the system it was working in. It had pattern-matched its way to a plausible-looking answer.

That's the core thing to internalize: a coding agent is a very good pattern completer, not an engineer. Engineers hold intent, constraints, failure modes, and tradeoffs in their heads at the same time. Agents hold a context window. Confusing the two is where reliability problems start.

What coding agents are actually good at

To be fair to the tools, they've earned their place in the workflow:

Boilerplate and scaffolding. CRUD endpoints, config files, test skeletons, repetitive glue code across a codebase.
Translating a clear spec into a first draft. If you can describe the shape of what you want precisely, an agent will get you 80% of the way there fast.
Working across unfamiliar syntax. An agent that's seen a thousand times more Terraform or SQL dialects than you have can save real research time.
Mechanical refactors. Rename this across 40 files, migrate this API surface, update this dependency's usage pattern everywhere it appears.

These are real productivity gains. The mistake is extrapolating from "good at boilerplate" to "can be trusted with architecture."

Where they fail

The failures aren't random, they cluster in predictable places:

Silent scope narrowing. Ask an agent to "handle errors properly" and it will handle the errors it can see in the current file, not the ones three layers up the call stack that your actual production traffic hits.
Confident wrongness. Agents don't have a strong signal for "I'm not sure." They'll write a Daraja API callback handler that looks idiomatic and is subtly wrong about idempotency, with the same confidence as one that's correct.
Local optimization, global blindness. An agent fixing a bug in one service has no model of the three other services that depend on the behavior it just changed.
Security as an afterthought. Left to their own devices, agents will happily hardcode a secret, skip input validation, or generate SQL that's one crafted string away from an injection, because none of that breaks the immediate task.
Test theater. Agents will write tests that pass, sometimes because they wrote the test to match the implementation's actual (wrong) behavior rather than the intended one.

None of this is a knock on the tools. It's what you'd expect from a system optimizing for "produce plausible next tokens" rather than "hold this system accountable over time."

Why fundamentals matter more, not less

The tempting narrative is that agentic coding makes engineering fundamentals less relevant, that if the AI writes the code, you don't need to understand it as deeply. The opposite is true.

When you're the one writing every line, your understanding is forced on you by the act of typing it. When an agent writes it, understanding becomes optional, and skipping it is exactly how systems accumulate debt nobody can explain later. The engineer's job shifts from writing correct code to specifying, verifying, and bounding correct code. That's arguably a harder skill, not an easier one. It requires the same grounding in data modeling, failure modes, concurrency, and system boundaries, just applied at review time instead of write time.

If you don't already know what a race condition looks like, you won't catch one in a 400-line diff an agent generated in nine seconds.

Context management

Most agent failures I've traced back aren't reasoning failures, they're context failures. The agent didn't have the right information in front of it, so it filled the gap with something plausible.

Practical habits that help:

Keep the agent's working context scoped to the smallest slice of the system that's actually relevant. A bloated context window doesn't mean better decisions, it often means diluted attention.
Externalize constraints instead of assuming they're inferred: rate limits, idempotency requirements, data retention rules, compliance boundaries. Say them explicitly, every time, rather than trusting the agent remembers them from three turns ago.
Treat the agent's memory of your codebase as a snapshot, not a live view. If you changed something in another session, don't assume it knows.

Testing AI-generated code

Agent-written code needs a different testing posture than human-written code, because the failure distribution is different. Where a human engineer tends to make errors of omission under time pressure, an agent tends to make errors of false confidence, it will implement something that looks complete but quietly diverges from the spec.

That argues for:

Writing the test cases yourself, or at minimum reviewing them line by line, rather than letting the agent write both the implementation and its own tests.
Testing the boundaries the agent wasn't explicitly told about, the empty list, the network timeout, the malformed webhook payload, since those are exactly where pattern-completion breaks down.
Running generated code against real, messy data before trusting it against clean fixtures.

Security risks

Agentic coding introduces a security surface that didn't exist five years ago, and it's not hypothetical:

Secrets leakage. Agents pulling credentials into logs, commits, or prompts they shouldn't.
Dependency sprawl. An agent reaching for a package to solve a small problem, without anyone evaluating its maintenance status or supply-chain risk.
Injection through generated code. String-built queries, unsanitized inputs, permissive CORS, the classic mistakes, just produced faster and in more places at once.
Prompt injection in agent pipelines. If your agent reads external content (a webpage, a customer message, a file) as part of its task, that content can carry instructions the agent will follow unless you've explicitly hardened against it.

None of this is solved by "the agent is usually careful." It's solved by treating every agent-touched surface as untrusted until reviewed, the same discipline you'd apply to a contributor you'd never met.

Reviewing agent decisions

Code review of agent output has to be different from code review of a colleague's PR, because the failure mode is different. A colleague's mistake usually comes with a reasoning trail you can interrogate. An agent's mistake often doesn't, it just produced the output.

That means review has to reconstruct the "why," not just check the "what":

Ask the agent to explain its reasoning before accepting a nontrivial change, and read the explanation critically, not as a formality.
Diff against intent, not just against the previous version. Does this change actually do what was asked, or does it do something adjacent that happens to pass the visible tests?
Be especially suspicious of changes that touch more files than the task seemed to require. That's often where an agent "helpfully" over-scoped.

Keeping humans in control

The workflows that hold up under real production load share a shape: agents propose, humans dispose. Concretely, that looks like:

Agents work in tightly scoped tasks with clear, checkable success criteria, not open-ended "improve this system" mandates.
Every agent-generated change goes through the same review gates as human-generated change, with no shortcut for "the AI wrote it so it's probably fine."
Irreversible or high-blast-radius actions, deployments, schema migrations, anything touching payments or customer data, require an explicit human approval step, not just an agent's self-assessed confidence.
Someone on the team remains accountable for understanding the system end to end, even if they didn't type most of the code.

The bottom line

Coding agents are a genuine force multiplier for the parts of engineering that were always mechanical. They are not a substitute for the parts that were never mechanical: judgment about tradeoffs, understanding of failure modes, and accountability for what ships. Building reliable software with agentic tools doesn't mean trusting them more as they get better. It means getting sharper about exactly where the boundary of their competence sits, and refusing to let that boundary quietly drift because the code that came out looked right.

How to Check Whether Your Git Branch Is Up to Date With QA, Master, and Your Remote Branch

Sospeter Mong'are — Tue, 21 Jul 2026 12:31:15 +0000

When working with Git in a team environment, especially with a workflow such as:

feature branch -> qa -> master

it is important to know whether your branch is up to date before creating or completing a Pull Request.

A common mistake is assuming that this:

Your branch is up to date with 'origin/feature/smongare'.

means your branch is also up to date with qa and master.

It does not.

That message only confirms that your local feature branch is synchronized with its remote feature branch.

Let's look at how to properly check everything.

1. Understanding Local and Remote Branches

Suppose you have:

feature/smongare
qa
master

Your local repository may look like this:

feature/smongare
qa
master

But the remote repository has separate branches:

origin/feature/smongare
origin/qa
origin/master

You can visualize the relationship like this:

Local Repository                 Remote Repository

feature/smongare  <---------->  origin/feature/smongare
qa                <---------->  origin/qa
master            <---------->  origin/master

Your local branches may not automatically know about the latest changes made remotely.

That is why the first step is always to fetch the latest information.

2. Fetch the Latest Changes

Run:

git fetch origin

This does not modify your working files or merge anything into your current branch.

It simply updates your local knowledge of the remote branches:

origin/feature/smongare
origin/qa
origin/master

After running:

git fetch origin

your Git repository knows the latest commit positions of the remote branches.

3. Check Whether Your Feature Branch Is Up to Date With QA

Suppose you are currently on:

feature/smongare

Run:

git rev-list --left-right --count origin/qa...feature/smongare

You might get:

3 5

This means:

3 commits  -> exist in QA but not in your feature branch
5 commits  -> exist in your feature branch but not in QA

In other words:

QA:               A - B - C - D - E
                         \
Feature Branch:          F - G - H - I - J

Your feature branch is missing 3 commits from qa.

You should probably bring the latest changes from qa into your feature branch before completing your PR.

4. Understanding the Output

The command:

git rev-list --left-right --count origin/qa...feature/smongare

returns two numbers:

<commits in QA> <commits in feature branch>

For example:

Result:

0 5

Your feature branch contains everything currently in qa.

Your feature branch has 5 additional commits.

QA:      0 missing commits
Feature: 5 additional commits

This is generally what you expect when developing a feature.

Result:

3 5

Your feature branch is behind qa by 3 commits.

QA:      3 commits your branch does not have
Feature: 5 commits QA does not have

You should consider updating your feature branch.

Result:

3 0

Your feature branch is behind qa.

It has no commits that are not already in qa.

5. Check Your Feature Branch Against Master

You can perform the same check against master:

git rev-list --left-right --count origin/master...feature/smongare

For example:

0 5

This means your feature branch contains all commits currently in master.

However, if your Pull Request is targeting qa, then qa is the more important branch to check before completing the PR.

Your typical workflow might be:

feature/smongare
        |
        v
       QA
        |
        v
     MASTER

Therefore:

Before PR to QA:
Check feature/smongare against qa

Before PR to master:
Check qa against master

6. Check Whether Your Local Feature Branch Matches the Remote Feature Branch

Your git status already tells you:

Your branch is up to date with 'origin/feature/smongare'.

This means:

Local feature/smongare
        =
Remote origin/feature/smongare

You can also verify it manually:

git rev-list --left-right --count origin/feature/smongare...feature/smongare

If you get:

0 0

then both branches are identical.

7. See the Actual Commits Missing From Your Feature Branch

Numbers are useful, but sometimes you want to see the actual commits.

To see commits that exist in qa but not in your feature branch:

git log --oneline feature/smongare..origin/qa

Example:

a1b2c3d Fix Airflow connection
e4f5g6h Update dbt configuration
i7j8k9l Add new environment variables

These are commits that your feature branch does not currently contain.

To see commits in master that your feature branch does not have:

git log --oneline feature/smongare..origin/master

To see commits in your feature branch that are not in qa:

git log --oneline origin/qa..feature/smongare

8. A Complete Check for All Branches

You can run:

git fetch origin

echo "Compared with QA:"
git rev-list --left-right --count origin/qa...feature/smongare

echo "Compared with MASTER:"
git rev-list --left-right --count origin/master...feature/smongare

echo "Compared with remote feature branch:"
git rev-list --left-right --count origin/feature/smongare...feature/smongare

You might get:

Compared with QA:
0 5

Compared with MASTER:
0 5

Compared with remote feature branch:
0 0

This means:

Your feature branch contains all the latest changes from qa
Your feature branch contains all the latest changes from master
Your local feature branch is identical to the remote feature branch
Your feature branch has 5 commits that have not yet been merged into qa

9. The Most Important Check Before a PR

Suppose your Pull Request is:

feature/smongare -> qa

The most important thing is to ensure that your branch works with the latest version of qa.

You can merge the latest qa changes into your feature branch:

git fetch origin

git checkout feature/smongare

git merge origin/qa

If Git reports:

Already up to date.

then your feature branch already contains the latest changes from qa.

If there are conflicts, Git will show them.

You can then:

Resolve the conflicts
Stage the resolved files

git add .

Complete the merge

git commit

Push the updated feature branch

git push origin feature/smongare

Your Azure DevOps Pull Request will then be updated with the latest changes.

The Key Lesson

This:

Your branch is up to date with 'origin/feature/smongare'.

only tells you:

local feature branch = remote feature branch

It does not tell you:

feature branch = qa

or:

feature branch = master

To properly check your branch relationships:

git fetch origin

Then compare branches:

git rev-list --left-right --count origin/qa...feature/smongare

git rev-list --left-right --count origin/master...feature/smongare

And before completing a Pull Request to qa, the safest approach is usually:

git merge origin/qa

This is one of the simplest ways to discover potential conflicts before Azure DevOps blocks or complicates your Pull Request.

Airflow 3 Simple Auth Manager

Sospeter Mong'are — Wed, 15 Jul 2026 10:03:46 +0000

If you've recently upgraded to Apache Airflow 3 and logged into the webserver, you may have noticed something different about how login and permissions work. Gone is the Flask-AppBuilder (FAB) based login system that powered Airflow 2. In its place is the Simple Auth Manager, the new default authentication and authorization system for Airflow 3.

This guide explains what Apache Airflow is for readers who are new to it, what an auth manager does, how the Simple Auth Manager works, how to configure it, and what you need to know before relying on it, especially in production.

What Is Apache Airflow?

If you're brand new to Airflow, here's the short version: Apache Airflow is an open-source platform used to author, schedule, and monitor workflows. A "workflow" in Airflow is called a DAG (Directed Acyclic Graph), which is essentially a series of tasks with dependencies between them, written as Python code. Data engineers commonly use Airflow to orchestrate things like ETL pipelines, machine learning training jobs, and routine data syncs between systems.

Because Airflow has a web-based UI where you can view, trigger, and monitor these workflows, it needs a way to control who can log in and what they're allowed to do once they're in. That's where an auth manager comes in.

What Is an Auth Manager?

An auth manager is the component in Airflow responsible for two things:

Authentication — verifying who a user is (usually via username and password, or an external identity provider)
Authorization — determining what that user is allowed to see and do once logged in

Airflow's auth manager system is pluggable, meaning you can swap in different implementations depending on your needs. You could use one built around your company's identity provider, for example, or write a custom one. The Auth Manager documentation covers the full interface and the available options.

What Is the Simple Auth Manager?

The Simple Auth Manager is the auth manager that comes by default in Airflow 3. As its name suggests, its logic and implementation are intentionally simple. It replaces FabAuthManager, the default in Airflow 2, as part of a broader effort to remove the FAB dependency from Airflow's core and make the authentication layer pluggable.

The intended usage of the Simple Auth Manager is only for development and testing purposes, and it should not be used in production. It's deliberately limited in scope: it doesn't support flexible role definitions or custom mappings between roles and capabilities. If you need a production-grade authentication setup, Airflow supports other pluggable auth managers, including ones built around cloud identity providers, and you can write your own using the auth manager interface.

The full official reference for this feature lives in the Simple Auth Manager documentation.

How User Management Works

Unlike FAB, which stored users and roles in Airflow's metadata database, the Simple Auth Manager is fully config-controlled and doesn't touch the database at all. Users are defined directly in your Airflow configuration file (airflow.cfg), or via environment variables.

Here's the basic format:

[core]
simple_auth_manager_users = "bob:admin,peter:viewer"

The list of users is comma-separated, and each user is a username/role pair separated by a colon. In the example above:

bob is assigned the admin role
peter is assigned the viewer role

Passwords Are Auto-Generated

You'll notice the configuration only specifies usernames and roles, not passwords. That's intentional. Passwords are auto-generated for each user and printed in the webserver logs. Once generated, they're saved to a file set by core.simple_auth_manager_passwords_file, which defaults to $AIRFLOW_HOME/simple_auth_manager_passwords.json.generated. You can open that file and read (or manually update) the passwords if needed.

If you're running Airflow through Breeze (Airflow's local development environment) for local development, two users come predefined out of the box: admin and viewer, each with a password matching their username.

A common gotcha: setting environment variables like AIRFLOW__SIMPLE_AUTH_MANAGER__USERNAME and PASSWORD won't reliably let you pre-seed a specific password. Since Airflow generates a random password on startup by default, this trips up a lot of people trying to force a known password this way. If you need deterministic credentials, editing the generated passwords file directly after startup is currently the more dependable route.

Roles and Permissions

The Simple Auth Manager doesn't let you create custom roles or fine-tune permission mappings. There's no option to manage roles and permissions; they're defined as part of the implementation and can't be modified. There are four fixed roles:

Role	Permissions
Viewer	Read-only access to Dags, assets, and pools
User	Viewer permissions, plus full edit, create, and delete permissions on Dags
Op	User permissions, plus full permissions on pools, assets, config, connections, and variables
Admin	All permissions

This is a deliberate tradeoff. Rather than giving you the granular role-based access control (RBAC) that FAB offered, the Simple Auth Manager sticks to four broad tiers that are easy to reason about and hard to misconfigure, at the cost of flexibility.

Multi-Team Support

If you're running Airflow for multiple teams sharing a single environment, the Simple Auth Manager supports basic team-based resource isolation. When multi-team mode is enabled, users can be associated with one or more teams, and teams restrict which resources (DAGs, connections, variables, pools) a user can access.

Enable it with:

[core]
multi_team = True

Then assign teams to users by adding a third colon-separated field, with multiple teams separated by a pipe character:

[core]
multi_team = True
simple_auth_manager_users = "bob:admin:team1|team2,peter:viewer:team1,alice:op:team2"

In this example, bob is an admin with access to both team1 and team2, peter is a viewer restricted to team1, and alice is an op restricted to team2.

A couple of details worth flagging:

Resources that aren't explicitly assigned to a team are treated as global and remain accessible to everyone, including team-restricted users.
Admins bypass team restrictions entirely. You can still assign an admin to a team, but it has no practical effect since admins already have access to everything.

Disabling Authentication Entirely

For fast local development or throwaway testing environments, the Simple Auth Manager offers an option to skip authentication altogether. This lets anyone who accesses the Airflow UI automatically log in as an admin with full permissions.

You enable it like this:

[core]
simple_auth_manager_all_admins = "True"

This is convenient when you're spinning up a local instance just to test a DAG, but it should never be used anywhere reachable outside your own machine.

Generating a JWT Token for the API

Airflow 3's public REST API is JWT-based, and the Simple Auth Manager provides the endpoint that issues those tokens. To generate one, send a POST request with your username and password:

ENDPOINT_URL="http://localhost:8080"
curl -X 'POST' \
  "${ENDPOINT_URL}/auth/token" \
  -H 'Content-Type: application/json' \
  -d '{
    "username": "<username>",
    "password": "<password>"
  }'

You can then include the returned token in subsequent API requests. If simple_auth_manager_all_admins is enabled, you can generate a token without providing any credentials at all. For more detail, see the Simple Auth Manager token guide and the token API reference.

Key Things to Keep in Mind

It's not built for production. This is the single most important thing to understand. The Simple Auth Manager exists to give Airflow 3 a working, dependency-light default so the core project could drop its hard reliance on FAB. If you're deploying to production, you should either configure a different auth manager or make sure access to your Airflow environment is locked down through other means (network isolation, a reverse proxy with its own auth layer, VPN access, and so on).

No database, no dynamic role editing. Everything lives in your configuration file. That makes it simple to version-control and reason about, but it also means you can't add or edit roles without changing the auth manager implementation itself.

Passwords are ephemeral by default. Since Airflow generates them fresh unless you intervene, plan for how you'll retrieve or fix credentials, particularly in containerized or ephemeral environments like Docker Compose or Kubernetes, where logs might not be easy to inspect after the fact.

Multi-team isolation isn't full multi-tenancy. It's resource-level filtering based on team assignment, not a hard security boundary. Global (unassigned) resources are visible to everyone, so don't rely on it as your only access control layer.

Switching auth managers later is a heavy lift. If you start with the Simple Auth Manager and later move to a production-grade option, all users, roles, and permissions need to be recreated in the new system. It's worth deciding early if the Simple Auth Manager is only a placeholder for you or a long-term fit.

Frequently Asked Questions

Is Simple Auth Manager safe to use in production?
No. It's explicitly intended for development and testing only. For production, use a different auth manager and control access through additional layers like network isolation or a reverse proxy.

Where do I find my auto-generated password?
Check the webserver logs on startup, or look in the file set by core.simple_auth_manager_passwords_file (default: $AIRFLOW_HOME/simple_auth_manager_passwords.json.generated).

Can I create custom roles in Simple Auth Manager?
No. Only four fixed roles exist: Viewer, User, Op, and Admin. Custom roles require a different auth manager.

How do I disable login entirely for local testing?
Set simple_auth_manager_all_admins = "True" under [core] in your Airflow configuration. Everyone who accesses the UI will be logged in as an admin automatically.

Wrapping Up

The Simple Auth Manager is Apache Airflow's answer to needing a lightweight, dependency-free authentication system out of the box for Airflow 3. It's easy to configure, requires no database, and gets you up and running in minutes with config-defined users and four fixed roles. But its simplicity is also its boundary: no custom roles, no dynamic user management, and an explicit warning against production use. If you're evaluating Airflow 3 for a real deployment, treat the Simple Auth Manager as your development sandbox and plan your production authentication strategy separately.

For more on Airflow's authentication options, see the official Auth Manager documentation and Airflow Security guide.

What Is a Proxy Server? Types, Setup, and How It Differs From a VPN

Sospeter Mong'are — Wed, 15 Jul 2026 05:59:40 +0000

If you've ever looked into web scraping, bypassing geo-restricted content, or just browsing more privately, you've probably run into the term "proxy." But what exactly is it, and how does it stack up against a VPN? This guide breaks down everything you need to know before buying or setting one up.

What Is a Proxy?

A proxy server acts as a middleman between your computer and the internet. Instead of connecting directly to a website, your traffic first passes through the proxy server, which forwards your request and relays the response back to you. In the process, it can mask your real IP address, filter content, cache data, or help you get around geographic restrictions.

Types of Proxies

Proxies aren't one-size-fits-all. They vary by protocol, anonymity level, IP source, and intended use case.

By Protocol

HTTP/HTTPS proxy: Handles web traffic only, making it a good fit for browsing. It's simple and fast, but limited strictly to web protocols.
SOCKS proxy (SOCKS4/SOCKS5): Handles any type of traffic, including web browsing, torrents, email, and gaming. More flexible than HTTP proxies, though slightly slower since it lacks built-in caching.

By Anonymity Level

Transparent proxy: Doesn't hide your IP address; the destination server can see you're using a proxy and knows your real IP. Commonly used by companies and schools for content filtering.
Anonymous proxy: Hides your IP address but still identifies itself as a proxy to the destination server.
Elite/high-anonymity proxy: Hides your IP address and gives no indication that a proxy is being used at all.

By Source or Ownership

Datacenter proxy: Uses IP addresses from cloud or hosting providers. Fast and inexpensive, but easier for websites to detect and block.
Residential proxy: Uses IP addresses assigned by ISPs to real households. Harder to detect and typically more expensive, often used for web scraping or ad verification.
Mobile proxy: Uses IP addresses from mobile carriers (4G/5G networks). Very difficult to block, and usually the most expensive option.

By Use Case

Reverse proxy: Sits in front of a server (rather than your device) to distribute load, cache content, or add a layer of security. Nginx and Cloudflare are common examples.
Rotating proxy: Automatically switches IP addresses at set intervals, which is especially useful for web scraping at scale.

How to Connect a Proxy on Your Computer

Setting up a proxy varies slightly depending on your operating system.

On Windows:

Go to Settings → Network & Internet → Proxy
Under "Manual proxy setup," toggle on "Use a proxy server"
Enter the proxy's IP address and port number
Save your settings

On macOS:

Go to System Settings → Network → select your connection → Details (or Advanced)
Open the "Proxies" tab
Check the relevant protocol (Web Proxy HTTP, Secure Web Proxy HTTPS, or SOCKS Proxy)
Enter the server address and port
Apply the changes

At the browser level: Firefox allows you to configure proxy settings independently under Settings → Network Settings, without affecting the rest of your operating system. Chrome, by contrast, defaults to your system-wide proxy settings, though extensions like FoxyProxy can manage rules on a per-browser basis.

Via command line or apps: Many applications, including curl, git, and torrent clients, accept proxy settings directly through config files or environment variables such as http_proxy and https_proxy.

Whichever method you choose, you'll need the proxy's IP address, port number, and possibly a username and password, all of which are provided by whoever supplies the proxy, such as a paid service or your workplace.

How to Confirm Your Proxy Is Connected

Once you've bought a proxy and entered your settings, it's worth double-checking that it's actually working before you rely on it.

1. Check whether your IP address changed. Before connecting, visit a site like whatismyipaddress.com or ipinfo.io and note your current IP. Then enable the proxy and reload the same site. If the IP shown is now different, and matches the proxy provider's location (a different city or country), it's working.

2. Check the proxy status in your OS or browser settings.

Windows: Settings → Network & Internet → Proxy should show "In use" next to your manual proxy entry.
macOS: System Settings → Network → your connection → Details → Proxies should show your configured address under the checked protocol.
Firefox: Settings → Network Settings will show your saved proxy configuration; there's no separate "connected" indicator, but if pages load and the IP check above confirms it, it's active.

3. Use command-line tools. If you set proxy environment variables (http_proxy/https_proxy), test with:

curl -x http://your-proxy-ip:port https://ipinfo.io

If it returns the proxy's IP instead of your own, the connection is live.

4. Watch for authentication prompts. If your proxy requires a username and password, your browser or OS should prompt you for credentials the first time you try to browse. If you're never prompted and pages fail to load, the proxy likely isn't applied correctly.

5. Check for DNS leaks. Even with a proxy active, your DNS requests might still go through your ISP, which can reveal your real location indirectly. Sites like dnsleaktest.com can confirm whether your DNS queries are also routed through the proxy or leaking.

A few signs your proxy is not working: your IP address stays the same as before, pages time out or fail to load entirely (often a wrong port or protocol mismatch), or you see "proxy refused connection" errors (usually wrong credentials or an IP not whitelisted by the provider).

The quickest gut-check: change your settings, then check your IP on a site like ipinfo.io. If it shows the proxy's location instead of yours, you're connected.

Proxy vs. VPN: What's the Difference?

While proxies and VPNs both reroute your internet traffic, they serve different purposes and offer very different levels of protection.

	Proxy	VPN
Encryption	Usually none	Encrypts all traffic
Scope	Often app/browser-specific	Covers the entire device
Speed	Generally faster (no encryption overhead)	Slightly slower due to encryption
Security	Low, traffic can be intercepted	High, encrypted tunnel
Use case	Bypassing geo-blocks, scraping, simple IP masking	Privacy and security, especially on public Wi-Fi
DNS leaks	Common, since only some traffic is routed	Typically routes DNS through the encrypted tunnel too

The Bottom Line

A proxy simply reroutes your traffic and hides your IP address for specific apps or browsers, but it doesn't encrypt anything. That means anyone snooping on the same network, like public Wi-Fi, could potentially still see your data. A VPN, on the other hand, encrypts everything at the operating-system level, protecting all of your device's traffic rather than just what passes through your browser.

If your goal is something like web scraping or accessing region-locked content, a proxy is usually sufficient and more affordable. But if privacy and security are your priority, especially on public networks, a VPN is the better choice.

RAG Is Not an AI Agent

Sospeter Mong'are — Fri, 10 Jul 2026 07:11:23 +0000

One of the biggest misconceptions in AI today is treating Retrieval-Augmented Generation (RAG) and AI agents as the same thing.

They're not.

RAG improves an LLM's ability to answer questions using external knowledge. AI agents go a step further by reasoning, planning, making decisions, and taking actions.

Understanding the difference will help you design better AI systems and avoid using the wrong architecture for the job.

What is RAG?

Retrieval-Augmented Generation (RAG) is an architecture that gives an LLM access to information outside its training data.

Instead of relying solely on what the model learned during training, it retrieves relevant documents from a knowledge base and includes them in the prompt before generating a response.

Think of RAG as "open-book AI."

RAG Architecture

          User Question
                 │
                 ▼
        Embed the Question
                 │
                 ▼
         Vector Database
                 │
       Retrieve Documents
                 │
                 ▼
      Prompt + Retrieved Context
                 │
                 ▼
                LLM
                 │
                 ▼
             Final Answer

The LLM does not search the internet by itself or decide what action to take. It simply answers using the retrieved context.

What RAG Does Well

RAG is excellent when your AI needs accurate, up-to-date, or organization-specific information.

Common use cases include:

Internal company knowledge bases
Customer support chatbots
HR policy assistants
Product documentation
Legal document search
Medical reference systems
Financial knowledge assistants

Instead of retraining an LLM every time information changes, you simply update the knowledge base.

Where RAG Ends

This is where many people get confused.

A RAG system can retrieve information and generate an answer.

It cannot inherently:

Decide which tool to use
Execute code
Send emails
Book meetings
Query multiple systems intelligently
Break large tasks into smaller ones
Plan multiple steps
Retry after failures
Decide whether another search is needed

For example:

"Find all unpaid invoices and email each customer."

A RAG system cannot complete this task.

It might explain how to do it, but it won't actually perform the work.

Where AI Agents Begin

AI agents are built for decision-making and action.

Instead of following one fixed pipeline, an agent reasons about the task before deciding what to do next.

A typical agent can:

Understand the objective
Create a plan
Choose the right tool
Execute the tool
Evaluate the result
Try another approach if needed
Continue until the goal is achieved

AI Agent Architecture

              User Request
                    │
                    ▼
                 Planner
                    │
      ┌─────────────┼─────────────┐
      ▼             ▼             ▼
 Search Web     Query Database   Run Code
      │             │             │
      └─────────────┼─────────────┘
                    ▼
              Evaluate Result
                    │
          Need Another Step?
            Yes           No
             │             │
             ▼             ▼
       Choose Next Tool   Final Answer

Notice the difference.

The workflow isn't fixed.

The agent decides what to do while solving the problem.

The Key Difference

A RAG pipeline follows a predefined sequence:

Retrieve → Generate → Respond

An agent follows a reasoning loop:

Think → Plan → Choose Tool → Execute → Observe → Repeat

One retrieves knowledge.

The other solves problems.

Can an AI Agent Use RAG?

Absolutely.

In fact, many production AI agents use RAG as one of their tools.

For example:

                 AI Agent
                     │
     ┌───────────────┼────────────────┐
     ▼               ▼                ▼
     RAG         SQL Database      Calendar API
     │               │                │
     └───────────────┼────────────────┘
                     ▼
              Final Response

Here, RAG is simply one capability among many.

The agent decides when to retrieve documents and when to use other tools.

When Should You Use RAG?

Choose RAG when your goal is to answer questions using trusted knowledge.

Examples:

Company documentation chatbot
University handbook assistant
Product manuals
Insurance policy lookup
Research assistant
FAQ systems

If users mainly ask questions, RAG is often enough.

When Should You Use an AI Agent?

Choose an AI agent when the system needs to make decisions or perform actions.

Examples:

Schedule meetings
Generate reports from multiple systems
Process invoices
Customer service workflows
Software engineering assistants
DevOps automation
Data analysis
Multi-step business processes

If the task involves reasoning, planning, or interacting with multiple tools, an agent is the better fit.

RAG vs AI Agent at a Glance

Feature	RAG	AI Agent
Retrieves knowledge	✅	✅
Answers questions	✅	✅
Uses external tools	Limited	✅
Makes decisions	❌	✅
Plans multiple steps	❌	✅
Executes actions	❌	✅
Adapts workflow dynamically	❌	✅
Retries after failures	❌	✅

Final Thoughts

RAG and AI agents aren't competing technologies.

They're complementary.

RAG gives an AI access to knowledge.

AI agents give an AI the ability to reason, decide, and act.

A useful way to remember it is:

RAG = LLM + Your Data

AI Agent = LLM + Memory + Planning + Tools + State

Production AI = Agent + RAG + Reliable Infrastructure

The most capable AI systems today don't choose between RAG and agents. They combine both. The agent decides what needs to be done, while RAG ensures it has the right information to do it well.

LangChain & LangGraph Concepts You Should Know

Sospeter Mong'are — Fri, 10 Jul 2026 05:58:30 +0000

Here are five foundational LangChain and LangGraph concepts every AI engineer should understand.

1. Chains (The AI Workflow)

A chain is a sequence of steps where the output of one step becomes the input of the next.

Example:

User Question
      ↓
Retrieve Documents
      ↓
LLM Generates Answer
      ↓
Format Response

Think of it as a pipeline for AI tasks.

2. Tools (Giving AI Superpowers)

LLMs only know what was in their training data.

Tools let them interact with the outside world.

Examples include:

Search the web
Query SQL databases
Call REST APIs
Execute Python code
Read PDFs
Send emails

Instead of only generating text, the AI can now do things.

3. Memory (Remembering Conversations)

Memory allows an AI to remember information across interactions.

Without memory:

User: My name is Sam.
...
User: What's my name?

AI: I don't know.

With memory:

AI: Your name is Sam.

Memory can be:

Short-term (current conversation)
Long-term (saved facts)
Semantic memory (knowledge)
Episodic memory (past interactions)

4. Agents (Reason + Choose Tools)

An agent doesn't follow a fixed workflow.

Instead, it:

Understands the goal
Decides what to do
Chooses the right tool
Executes it
Evaluates the result
Repeats until the task is complete

Example:

User:
"Find the latest exchange rate and calculate how much 250 USD is in KES."

Agent:
→ Search exchange rate
→ Use calculator
→ Return final answer

The workflow is dynamic rather than predetermined.

5. Graphs (LangGraph's Superpower)

Traditional chains are linear.

LangGraph introduces graphs, where execution can branch, loop, pause, or resume.

Example:

          Start
             │
             ▼
      Understand Task
        ┌────┴────┐
        ▼         ▼
   Search Web   Query Database
        │         │
        └────┬────┘
             ▼
      Evaluate Results
        ┌────┴────┐
     Good?      No
       │         │
       ▼         │
    Final Answer │
                 │
                 ▼
          Try Another Tool

This makes LangGraph ideal for building autonomous AI agents that can recover from errors, make decisions, and manage complex workflows.

A Simple Way to Remember

LangChain = LLM + tools + workflows
Agents = LangChain + reasoning + tool selection
LangGraph = Agents + state + loops + branching + durable execution

If you're learning modern AI engineering, mastering these five concepts will give you a strong foundation for building production-ready AI applications.

Understanding Integration Runtimes in Azure Data Factory (ADF)

Sospeter Mong'are — Thu, 02 Jul 2026 12:54:49 +0000

When people begin learning Azure Data Factory (ADF), one concept that often causes confusion is the Integration Runtime (IR). Pipelines, datasets, and linked services are fairly intuitive, but many beginners wonder:

"If Azure Data Factory orchestrates everything, what exactly is an Integration Runtime?"

The simplest answer is this:

An Integration Runtime is the compute infrastructure that Azure Data Factory uses to move data, transform data, and execute activities.

Think of Azure Data Factory as the brain that plans the work, while the Integration Runtime is the muscle that carries it out.

Why Do We Need an Integration Runtime?

Imagine you're a logistics manager.

You create a schedule for transporting goods from Nairobi to Mombasa. You know what should be transported, when it should leave, and where it should arrive.

However, without a truck, nothing actually moves.

Azure Data Factory works the same way.

A pipeline defines what should happen, but the Integration Runtime is responsible for actually performing the work.

It is responsible for:

Moving data between different data sources
Running data transformation jobs
Connecting securely to cloud and on-premises systems
Executing activities within your pipeline

Without an Integration Runtime, your pipeline has instructions but no execution engine.

Types of Integration Runtime

Azure Data Factory provides three types of Integration Runtime, each designed for different scenarios.

1. Azure Integration Runtime

This is the default Integration Runtime provided and managed by Microsoft.

You don't install or maintain any servers. Azure automatically provisions and scales the compute resources needed to execute your workloads.

It is ideal when your data resides entirely in the cloud.

Common use cases include:

Copying data from Azure SQL Database to Azure Data Lake
Moving data between cloud storage accounts
Running Mapping Data Flows
Executing cloud-native activities

A typical architecture looks like this:

Azure SQL Database
        │
        ▼
Azure Integration Runtime
        │
        ▼
Azure Data Lake Storage

Advantages

Fully managed by Microsoft
Automatically scales
No infrastructure to maintain
Highly available

For most cloud-to-cloud data movement, Azure Integration Runtime is the recommended choice.

2. Self-hosted Integration Runtime (SHIR)

What happens if your data is not in Azure?

Suppose your organization has an on-premises SQL Server inside a corporate network protected by a firewall.

Azure Data Factory cannot directly access it.

This is where the Self-hosted Integration Runtime comes in.

The Self-hosted IR is software that you install on a Windows machine, virtual machine, or server within your network.

It acts as a secure bridge between Azure and your private environment.

Example architecture:

On-Prem SQL Server
        │
        ▼
Self-hosted Integration Runtime
        │
        ▼
Azure Blob Storage

Because the runtime resides inside your network, it can securely communicate with your local databases while also communicating with Azure Data Factory.

Common use cases

SQL Server
Oracle Database
MySQL
PostgreSQL
SAP
Local file servers
Private APIs
Any data source behind a firewall

This is one of the most commonly used Integration Runtimes in enterprise environments.

3. Azure SSIS Integration Runtime

Many organizations have existing ETL processes built using SQL Server Integration Services (SSIS).

Rather than rebuilding those packages from scratch, Azure allows you to run them in the cloud using Azure SSIS Integration Runtime.

Example:

SSIS Package
      │
      ▼
Azure SSIS Integration Runtime
      │
      ▼
Azure SQL Database

This option is mainly used during cloud migration projects where businesses want to continue using their existing SSIS investments.

A Real-World Example

Imagine you work for a bank.

Every night, customer transactions stored in an on-premises SQL Server need to be copied into Azure Data Lake for reporting and analytics.

The architecture would look something like this:

ADF Pipeline
      │
      ▼
Self-hosted Integration Runtime
      │
      ▼
On-Prem SQL Server
      │
      ▼
Azure Data Lake Storage

Here's what happens:

The pipeline starts according to a schedule.
Azure Data Factory sends the job to the Self-hosted Integration Runtime.
The Self-hosted IR connects to the SQL Server.
It reads the required data.
It securely transfers the data into Azure Data Lake.
The pipeline completes successfully.

Notice that Azure Data Factory never directly connects to the SQL Server. The Self-hosted Integration Runtime performs that task.

Which Integration Runtime Should You Use?

The choice depends on where your data resides and what type of workload you're running.

Scenario	Recommended Integration Runtime
Azure SQL Database to Azure Blob Storage	Azure Integration Runtime
Azure SQL Database to Azure Data Lake	Azure Integration Runtime
SQL Server on-premises to Azure	Self-hosted Integration Runtime
Oracle behind a firewall	Self-hosted Integration Runtime
Local files to Azure Storage	Self-hosted Integration Runtime
Running Mapping Data Flows	Azure Integration Runtime
Running existing SSIS packages	Azure SSIS Integration Runtime

Understanding the Difference Between Pipelines and Integration Runtime

One common misconception among beginners is assuming that pipelines execute the work.

They don't.

A pipeline is simply an orchestration layer.

Think of the relationship this way:

Pipeline decides what should happen.
Activity defines the specific task.
Linked Service stores the connection information.
Dataset represents the data being used.
Integration Runtime performs the actual work.

Without an Integration Runtime, the pipeline has instructions but no execution engine.

A Simple Analogy

Imagine you're running a courier company.

The customer places an order.
The operations manager plans the delivery.
The address tells the driver where to collect and deliver the package.
The package is the data.
The truck transports the package.

In Azure Data Factory:

Customer order = Business requirement
Pipeline = Delivery plan
Activity = Delivery task
Linked Service = Pickup and destination addresses
Dataset = The package
Integration Runtime = The truck

Without the truck, nothing gets delivered.

Final Thoughts

Integration Runtime is one of the most important concepts in Azure Data Factory because it is responsible for executing your data integration workloads.

Choosing the correct Integration Runtime depends on your environment:

Use Azure Integration Runtime for cloud-to-cloud data movement and transformations.
Use Self-hosted Integration Runtime when accessing on-premises or private network resources.
Use Azure SSIS Integration Runtime when migrating or running existing SSIS packages in Azure.

Once you understand the role of the Integration Runtime, Azure Data Factory becomes much easier to visualize. Instead of thinking of it as just another Azure service, you'll see it as a complete orchestration platform where pipelines coordinate the work, and Integration Runtimes provide the execution power that makes everything happen.

How to Install Apache Airflow 3.1.3 on WSL (Windows Subsystem for Linux)

Sospeter Mong'are — Wed, 01 Jul 2026 07:46:51 +0000

What is Apache Airflow?

Apache Airflow is an open-source platform used to programmatically author, schedule, and monitor workflows. It's widely used in data engineering, MLOps, and backend automation pipelines. If you're building ETL pipelines, running scheduled tasks, or orchestrating complex workflows, Airflow is a tool you'll likely encounter.

Airflow 3 is a major upgrade from Airflow 2 - it introduces a new React-based UI, a dedicated API server (replacing the old webserver), improved task isolation via the Task SDK, and better scalability overall.

Prerequisites

Before we begin, make sure you have the following in place:

1. Windows Subsystem for Linux (WSL2) installed

You need WSL 2 with Ubuntu 24.04 (Noble) installed on your Windows machine. If you haven't set it up yet, open PowerShell as Administrator and run:

wsl --install

Restart your machine when prompted, then launch Ubuntu from the Start menu.

Important: Always work inside the Linux home directory (~), not a Windows-mounted path like /mnt/c/.... Performance and file permission issues can occur on mounted drives.

2. MobiXterm or Windows Terminal (optional but recommended)

Either gives you a better terminal experience for working inside WSL.

3. Basic familiarity with the Linux terminal

You don't need to be a Linux expert, but knowing how to navigate directories (cd, ls) and run commands will help.

Step 1: Update Your System

Open your WSL terminal and run:

sudo apt update && sudo apt upgrade -y

This ensures your package lists and installed packages are up to date.

Step 2: Install Python 3 and Check the Version

Ubuntu 24.04 ships with Python 3.12 by default. Verify it's available:

python3 --version

You should see something like Python 3.12.x. Airflow 3.1.3 supports Python 3.10, 3.11, and 3.12 - so you're good.

If Python isn't installed:

sudo apt install python3 python3-dev python3-pip python3-venv -y

Step 3: Set Your AIRFLOW_HOME (Important - Do This First)

Airflow needs a home directory to store its configuration, logs, and database. Set this before installing Airflow so it knows where to store everything:

export AIRFLOW_HOME=~/airflow-3.1.3/airflow_home

To make this permanent so it survives terminal restarts:

echo 'export AIRFLOW_HOME=~/airflow-3.1.3/airflow_home' >> ~/.bashrc
source ~/.bashrc

Why this matters: If you skip this step, Airflow defaults to ~/airflow and may pick up config files from a previous Airflow installation, causing unexpected warnings or errors.

Step 4: Create a Project Directory and Virtual Environment

Create a dedicated folder for your Airflow 3.1.3 installation:

mkdir ~/airflow-3.1.3
cd ~/airflow-3.1.3

Create a virtual environment inside it:

python3 -m venv env

Activate the virtual environment:

source env/bin/activate

Your terminal prompt should now show (env) at the beginning:

(env) user@DESKTOP-XXXX:~/airflow-3.1.3$

Step 5: Upgrade pip

Before installing Airflow, upgrade pip to the latest version:

pip install --upgrade pip

Step 6: Install Apache Airflow 3.1.3 with Constraints

Install Airflow using the official constraints file. This is critical - Airflow has many dependencies, and the constraints file ensures compatible versions are installed together without conflicts:

pip install "apache-airflow==3.1.3" \
  --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.1.3/constraints-3.12.txt"

This may take several minutes. Once complete, verify the installation:

airflow version

You should see:

3.1.3

Step 7: Install the FAB Auth Manager Provider

In Airflow 3, user authentication is handled by a separate provider package. Install it now:

pip install apache-airflow-providers-fab \
  --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.1.3/constraints-3.12.txt"

Verify it's registered:

airflow providers list | grep fab

You should see:

apache-airflow-providers-fab  |  Flask App Builder ...  |  3.x.x

Step 7b: Set FAB as the Auth Manager (Critical)

This is the most important step that is easy to miss. Airflow 3 ships with a new lightweight SimpleAuthManager as the default. While it works for single-user local setups, it does not expose the airflow users CLI command - meaning you won't be able to create admin users from the terminal.

You must explicitly switch to the FAB auth manager.

Check what auth manager is currently set:

airflow config get-value core auth_manager

If it returns:

airflow.api_fastapi.auth.managers.simple.simple_auth_manager.SimpleAuthManager

You are on the wrong auth manager. Switch it by opening your airflow.cfg:

nano ~/airflow-3.1.3/airflow_home/airflow.cfg

Find the [core] section and change:

[core]
auth_manager = airflow.api_fastapi.auth.managers.simple.simple_auth_manager.SimpleAuthManager

To:

[core]
auth_manager = airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager

Save and exit (Ctrl+O, Enter, Ctrl+X). Verify the change:

airflow config get-value core auth_manager

Should now return:

airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager

SimpleAuthManager vs FabAuthManager:

SimpleAuthManager - Airflow 3's new default. Lightweight, no CLI user management, suited for single-user or automated setups

FabAuthManager - Full-featured auth manager from Flask AppBuilder. Supports CLI user creation, roles, permissions, and OAuth. Required for proper multi-user setups and for the airflow users command to work

Note: You may see a RemovedInAirflow4Warning about airflow.security.permissions being deprecated. This is harmless in 3.1.3 - it's just a heads-up that some internal FAB APIs will change in Airflow 4.

Step 8: Initialize the Airflow Database

Airflow 3 uses db migrate instead of the old db init command. This creates the metadata database and applies all schema migrations:

airflow db migrate

Step 9: Create an Admin User

airflow users create \
  --username admin \
  --firstname YourFirstName \
  --lastname YourLastName \
  --role Admin \
  --email your@email.com

You will be prompted to set a password. Type it carefully - input is hidden (no asterisks shown) in the terminal. Confirm it when prompted.

Tip: Remember this password - there's no plain-text copy stored anywhere. If you forget it, reset it with airflow users reset-password --username admin.

Step 10: Start the Airflow API Server and Scheduler

Airflow 3 requires three processes running simultaneously - the API server, the scheduler, and optionally the dag-processor (for larger setups). Open separate WSL terminal tabs or windows for each.

Terminal 1 - Start the API server:

cd ~/airflow-3.1.3
source env/bin/activate
export AIRFLOW_HOME=~/airflow-3.1.3/airflow_home
airflow api-server --port 8080

Terminal 2 - Start the scheduler:

cd ~/airflow-3.1.3
source env/bin/activate
export AIRFLOW_HOME=~/airflow-3.1.3/airflow_home
airflow scheduler

Note: In Airflow 3, airflow webserver has been replaced by airflow api-server. This is one of the key architectural changes from Airflow 2.

When the API server starts successfully you will see:

INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

And when the scheduler starts you will see:

INFO:     Starting the scheduler
INFO:     Loaded executor: LocalExecutor

Step 11: Access the Airflow UI

Open your browser and navigate to:

http://localhost:8080

You will see the new Airflow 3 React-based login page. Enter the username and password you created in Step 9.

You should now be inside the Airflow 3 Dashboard - ready to create and manage your DAGs!

Quick Reference: Starting Airflow After a Reboot

Every time you restart your machine and want to use Airflow, run these commands in separate terminals:

# All terminals: navigate, activate venv, and set AIRFLOW_HOME
cd ~/airflow-3.1.3
source env/bin/activate
export AIRFLOW_HOME=~/airflow-3.1.3/airflow_home

# Terminal 1
airflow api-server --port 8080

# Terminal 2
airflow scheduler

If you added AIRFLOW_HOME to your ~/.bashrc in Step 3, the export is automatic and you can skip that line.

Airflow 3 vs Airflow 2 - Key Differences

If you're familiar with Airflow 2, here's what changed:

Airflow 2.x	Airflow 3.x
`airflow webserver`	`airflow api-server`
`airflow db init`	`airflow db migrate`
User management built into core	Requires `apache-airflow-providers-fab` + FAB set as auth manager
SequentialExecutor (default)	LocalExecutor (default)
`execution_date` in DAG context	`logical_date`
Flask-based UI	React-based UI
SubDAGs supported	SubDAGs removed (use TaskGroups)
SLA support	SLAs removed

Troubleshooting

`airflow users` command not found / invalid choice: 'users'

This has two possible causes - fix them in order:

Cause 1 - FAB provider not installed:

pip install apache-airflow-providers-fab \
  --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.1.3/constraints-3.12.txt"

Cause 2 - Wrong auth manager set (most common):
Check your current auth manager:

airflow config get-value core auth_manager

If it shows SimpleAuthManager, switch it to FAB in airflow.cfg - see Step 7b above. This is the most common cause of the users command missing even after the FAB provider is installed.

Deprecation warnings about `[webserver]` settings

These occur when Airflow 3 picks up a config file from an old Airflow 2 installation. Make sure AIRFLOW_HOME points to a fresh directory and not ~/airflow (the Airflow 2 default).

`No module named 'airflow.providers.fab'` warning

The FAB provider isn't installed. See Step 7 above.

Forgot your admin password

Reset it without deleting the user:

airflow users reset-password --username admin

Port 8080 already in use

Either stop the other process using port 8080, or start the API server on a different port:

airflow api-server --port 8081

Summary of All Commands

# Set AIRFLOW_HOME (permanent)
echo 'export AIRFLOW_HOME=~/airflow-3.1.3/airflow_home' >> ~/.bashrc
source ~/.bashrc

# Create project directory and virtual environment
mkdir ~/airflow-3.1.3 && cd ~/airflow-3.1.3
python3 -m venv env
source env/bin/activate

# Install Airflow with constraints
pip install --upgrade pip
pip install "apache-airflow==3.1.3" \
  --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.1.3/constraints-3.12.txt"

# Install FAB auth manager provider
pip install apache-airflow-providers-fab \
  --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.1.3/constraints-3.12.txt"

# Verify Airflow version
airflow version

# Set FAB as auth manager in airflow.cfg (under [core] section)
# auth_manager = airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager

# Verify auth manager is set correctly
airflow config get-value core auth_manager

# Initialize database
airflow db migrate

# Create admin user
airflow users create --username admin --firstname YourFirstName \
  --lastname YourLastName --role Admin --email your@email.com

# Start services (separate terminals)
airflow api-server --port 8080    # Terminal 1
airflow scheduler                  # Terminal 2

What's Next?

Now that Airflow 3.1.3 is running, here are some things to explore next:

Write your first DAG - create a Python file in $AIRFLOW_HOME/dags/ to define a workflow
Explore the new UI - Airflow 3 ships with a brand new React-based interface with improved DAG views
Learn about Assets - Airflow 3 introduces Assets (formerly Datasets) for data-aware scheduling
Set up PostgreSQL - replace SQLite with PostgreSQL as the Airflow metadata backend for production use
Use the Task SDK - Airflow 3 ships with a standalone Task SDK for writing tasks in isolation

For the official Airflow 3 Quick Start guide, visit: https://airflow.apache.org/docs/apache-airflow/stable/start.html

Written based on a real installation walkthrough on WSL2 Ubuntu 24.04 (Noble) with MobiXterm.

How to Build an AI Agent (with Python Example)

Sospeter Mong'are — Tue, 30 Jun 2026 08:33:14 +0000

Artificial Intelligence is changing the way we build software. Instead of creating applications that simply follow predefined instructions, developers can now build AI agents that understand goals, make decisions, use tools, and complete tasks with minimal human intervention.

An AI agent is much more than a chatbot. It is a software system that can think through a problem, decide what actions to take, interact with external tools, remember previous interactions, and achieve a specific objective.

This guide walks you through the complete process of building an AI agent using the roadmap outlined below.

What is an AI Agent?

An AI agent is a program that:

Understands a user's request
Plans how to solve it
Uses tools when necessary
Remembers useful information
Returns the best possible answer

For example:

Instead of asking,

"What's today's weather?"

You could ask,

"Check today's weather, then tell me whether I should carry an umbrella and reschedule my outdoor meeting."

An AI agent can:

Understand the goal
Call a weather API
Analyze the forecast
Make a recommendation
Respond naturally

Step 1: Define the Purpose and Scope

Every AI agent starts with one important question:

What problem is this agent solving?

Without a clear purpose, the agent becomes confusing and unreliable.

Ask yourself:

Who will use it?
What tasks should it perform?
What should it never do?
How will success be measured?

Example

Suppose you are building a customer support agent.

Purpose:

Help customers answer common questions about orders.

Success criteria:

Answers within 5 seconds
90% accuracy
Escalates complex issues to humans

Constraints:

Cannot refund orders
Cannot change passwords
Cannot access customer payment information

Step 2: Design the System Prompt

The system prompt is the agent's personality and instruction manual.

It tells the AI:

Who it is
What its job is
What rules it should follow
How it should respond

Example:

You are a customer support assistant.

Your job is to answer customer questions politely.

If you don't know the answer,
say you don't know.

Never invent information.

A good prompt often matters more than choosing a larger model.

Step 3: Choose an LLM

The Large Language Model (LLM) is the agent's brain.

Popular options include:

GPT
Claude
Gemini
Llama
DeepSeek

Things to consider:

Cost

How much does each request cost?

Speed

How quickly does it respond?

Context Window

How much information can it remember in one conversation?

Accuracy

Does it perform well for your task?

For beginners, cloud-hosted models are the easiest place to start.

Step 4: Connect Tools

Without tools, an AI only knows what it has already learned.

With tools, it can:

Search databases
Call APIs
Read documents
Send emails
Execute code
Control applications

Examples:

Weather Agent

Tool:

Weather API

Finance Agent

Tool:

Bank API

Travel Agent

Tool:

Flight API

Programming Agent

Tool:

Python interpreter

Think of tools as giving your AI "hands."

Step 5: Add Memory

Most conversations require remembering previous information.

There are different types of memory.

Conversation Memory

Remember earlier messages.

Example:

User:

"My name is John."

Later...

Agent:

"Hello John."

Working Memory

Temporary memory while solving one task.

Example:

Reading multiple files before producing a report.

Long-Term Memory

Stores information for future conversations.

Example:

Favorite programming language.

Preferred writing style.

Frequently used APIs.

Many AI systems store memory using databases or vector databases.

Step 6: Orchestrate the Workflow

Real AI agents rarely perform just one action.

Instead, they execute a workflow.

Example:

User asks a question

↓

Understand request

↓

Choose tool

↓

Call API

↓

Analyze result

↓

Generate response

Frameworks like LangGraph and CrewAI help manage these workflows.

Step 7: Build a User Interface

Your AI needs a way to interact with users.

Common interfaces include:

Chat applications
Websites
Mobile apps
WhatsApp bots
Slack bots
REST APIs

The AI engine stays the same.

Only the interface changes.

Step 8: Test and Improve

Never assume your AI agent is perfect.

Test:

Wrong inputs
Missing information
Slow APIs
Invalid requests
Unexpected questions

Measure:

Accuracy
Speed
User satisfaction
Cost
Reliability

Then improve continuously.

The AI Agent Architecture

A complete AI agent usually looks like this:

User
   │
   ▼
User Interface
   │
   ▼
System Prompt
   │
   ▼
Large Language Model
   │
   ▼
Decision Making
   │
   ├──── Weather API
   ├──── Database
   ├──── Email Service
   ├──── Search Engine
   └──── Custom Functions
   │
   ▼
Memory
   │
   ▼
Final Response

A Simple AI Agent in Python

Let's build a very simple AI agent using Python and the OpenAI SDK.

First, install the package:

pip install openai

Set your API key:

export OPENAI_API_KEY="your-api-key"

Now create the agent.

from openai import OpenAI

client = OpenAI()

SYSTEM_PROMPT = """
You are a helpful programming assistant.

Explain concepts clearly.

If you don't know something,
say so honestly.
"""

def ask_agent(question):

    response = client.responses.create(
        model="gpt-5.5",
        input=[
            {
                "role": "system",
                "content": SYSTEM_PROMPT
            },
            {
                "role": "user",
                "content": question
            }
        ]
    )

    return response.output_text

while True:

    question = input("You: ")

    if question.lower() == "exit":
        break

    answer = ask_agent(question)

    print("\nAgent:", answer)

Running it:

You:
Explain Python decorators.

Agent:
Decorators are functions that modify the behavior of another function...

Congratulations!

You have built your first AI agent.

Extending the Agent with a Tool

Suppose we want the agent to answer the current time.

Instead of asking the AI to guess, we create a Python function.

from datetime import datetime

def get_current_time():
    return datetime.now().strftime("%H:%M:%S")

The agent can call this function whenever the user asks:

"What time is it?"

Instead of making up the answer, it retrieves the real system time.

This simple idea scales to many real-world tools, such as weather APIs, databases, email services, payment gateways, and search engines.

Real-World AI Agent Ideas

Once you understand the building blocks, you can create agents for almost any industry:

Customer support assistant
WhatsApp chatbot
Fundraising assistant
Medical appointment scheduler
Personal finance advisor
School management assistant
HR recruitment assistant
Sales assistant
Software debugging assistant
Content writing assistant

Each follows the same architecture: define a purpose, guide the model with a clear prompt, connect the right tools, maintain useful memory, orchestrate the workflow, provide an interface, and continuously test and improve.

Final Thoughts

Building an AI agent is not just about connecting an LLM to a chat window. A successful agent is designed around a clear goal, given the right instructions, equipped with tools to interact with the outside world, supported by memory to maintain context, and wrapped in a reliable workflow and user interface.

The good news is that you do not need to build everything at once. Start with a simple conversational agent, then gradually add tools, memory, and automation as your application grows. By following these eight steps, you will have a solid foundation for creating intelligent AI applications that solve real-world problems.

Understanding the Difference between Agents vs Automation

Sospeter Mong'are — Mon, 29 Jun 2026 06:36:05 +0000

Artificial Intelligence has brought the term "AI Agent" into almost every technology conversation. As a result, many people now use the words agent and automation interchangeably. While both are designed to reduce manual work and improve efficiency, they solve problems in fundamentally different ways.

Understanding this distinction is essential if you're building software, automating business processes, or deciding where AI fits into your organization.

What Is Automation?

Automation is designed to execute predefined instructions.

You tell the system exactly what to do, in what order, and under what conditions. Every time those conditions are met, it performs the same sequence of actions.

For example:

A customer submits a form.
An email is automatically sent.
A record is created in the database.
A notification is sent to the sales team.

Every step is predetermined. If the process changes, the workflow must be updated.

Automation excels at repetitive, predictable tasks where consistency is more important than decision-making.

What Is an AI Agent?

An AI agent is not focused on following instructions. It is focused on achieving a goal.

Instead of executing a rigid sequence of steps, an agent observes its environment, evaluates available information, makes decisions, and adjusts its actions as circumstances change.

If one approach fails, it can try another. If new information becomes available, it can revise its strategy without requiring a developer to define every possible scenario in advance.

In simple terms:

Automation asks:

"What steps should I execute?"

An agent asks:

"What is the best way to accomplish this objective?"

This ability to reason and adapt is what makes agents fundamentally different from traditional automation.

A Simple Example

Imagine you're booking a business trip.

An automated workflow might:

Book the airline you specified.
Reserve the hotel you selected.
Email you the itinerary.

It completes exactly what it was programmed to do.

An AI agent, however, could:

Compare multiple flights.
Choose the most cost-effective option.
Avoid long layovers.
Ensure arrival before your meeting.
Rebook automatically if a flight is cancelled.
Notify you of the changes.

The objective isn't to follow a checklist. The objective is to get you to your destination successfully.

When Automation Is the Better Choice

Despite the excitement around AI agents, automation remains the right solution for many business processes.

Choose automation when:

The workflow is predictable.
Business rules rarely change.
Compliance requires consistent execution.
Decisions are straightforward.
Speed and reliability matter more than flexibility.

Payroll processing, invoice generation, scheduled backups, and email notifications are all excellent examples of automation.

When an Agent Makes More Sense

An AI agent becomes valuable when the environment is dynamic and decisions cannot be fully predefined.

Use an agent when your system needs to:

Reason through complex situations.
Adapt to changing conditions.
Work toward goals rather than fixed procedures.
Handle uncertainty.
Decide between multiple possible actions.

Examples include customer support assistants, intelligent research systems, autonomous coding assistants, network troubleshooting agents, and procurement assistants that negotiate between vendors.

The Biggest Mistake

One of the biggest misconceptions in AI today is believing every workflow should become an agent.

It shouldn't.

Replacing a simple, deterministic process with an AI agent often introduces unnecessary complexity, higher costs, and less predictable behavior.

Likewise, trying to solve a complex, ever-changing problem with traditional automation can lead to brittle systems that constantly require manual updates.

The smartest solutions combine both approaches.

Automation handles the repetitive work, while agents take over where reasoning, judgment, and adaptability are required.

Final Thoughts

Automation follows instructions.

Agents pursue outcomes.

Automation delivers consistency through predefined workflows. Agents deliver adaptability through intelligent decision-making.

Neither is universally better. They solve different problems.

The future of software isn't choosing agents over automation. It's understanding when each is the right tool for the job, and combining them to build systems that are both efficient and intelligent.

How to Tell If a Task Needs an Agent or an Automation

Sospeter Mong'are — Sat, 27 Jun 2026 08:18:57 +0000

One of the biggest mistakes businesses make when adopting AI is trying to use an AI agent for every problem.

Not every task needs reasoning. Not every workflow needs an LLM. Sometimes a simple automation is faster, cheaper, and more reliable.

The question isn't "Can AI do this?"

The real question is:

"Does this task require thinking, or just doing?"

Rule #1: If the steps are always the same, automate it.

Traditional automation excels when the workflow is predictable.

Examples include:

Sending a welcome email after signup
Copying files between systems
Moving data from one database to another
Creating invoices every month
Backing up databases
Syncing CRM records

These tasks follow clear rules.

Trigger → Execute Steps → Finish

No decisions.
No reasoning.
No uncertainty.

This is where tools like Power Automate, Azure Logic Apps, n8n, Airflow, Zapier, or simple scripts shine.

Rule #2: If the task requires judgment, use an AI agent.

An agent becomes valuable when there isn't a fixed sequence of actions.

Instead, it has to decide:

What information is needed?
Which tool should I use?
Is the answer sufficient?
Should I ask the user another question?
Do I need to search somewhere else?

For example:

"Analyze this support ticket, search the customer's purchase history, check whether a refund qualifies under company policy, then draft an appropriate response."

Nobody hard-coded every possible path.

The agent reasons about the problem before acting.

Its workflow looks more like:

Goal
 ↓
Reason
 ↓
Choose Tool
 ↓
Observe Results
 ↓
Think Again
 ↓
Take Next Action

Rule #3: If the workflow contains uncertainty, you're entering agent territory.

Ask yourself:

Can I write every step beforehand?

If yes...

Automation.

If no...

An agent may be the better solution.

Consider these examples.

Automation:

"Every invoice goes to Finance."

Agent:

"Read the invoice and determine which department should approve it."

Automation:

"Archive every email older than 90 days."

Agent:

"Read the email and determine whether it's important enough to retain."

Automation:

"Generate a report every Monday."

Agent:

"Review this week's KPIs and explain the biggest business risks."

Rule #4: If the task only follows instructions, don't use AI.

Many teams build expensive AI systems that simply execute fixed logic.

That's overengineering.

If you already know the exact sequence of actions, a workflow engine is usually the better choice.

AI should solve uncertainty, not replace an if-statement.

Rule #5: Sometimes the best solution is both.

The most powerful enterprise systems combine automation with AI agents.

For example:

A customer submits a request.
An automation triggers the workflow.
An AI agent classifies the request.
The agent decides which internal systems to query.
Automation performs the approved actions.
The workflow updates the CRM and sends notifications.

Notice the difference.

Automation handles execution.

The agent handles decision-making.

Each does what it's best at.

A Simple Decision Framework

Before building anything, ask these five questions:

Are the steps predictable every time?
Does the system need to make decisions?
Will the workflow change depending on context?
Does it need to understand natural language?
Does it need to choose between multiple tools or actions?

If your answers are mostly:

Yes to predictable steps -> Automation
Yes to reasoning and decision-making -> Agent

Final Thought

Don't start with AI.

Start with the problem.

If the work is repetitive, automate it.

If the work requires understanding, reasoning, planning, and choosing the next action, build an agent.

The smartest systems aren't the ones with the most AI.

They're the ones that know when not to use it.