DEV Community: stephen487

I'm 56, four months into coding, and my sign-up form let 0 of 18 people in

stephen487 — Mon, 26 Oct 2026 17:10:03 +0000

Last week I wrote about never having written a line of code before June. This is the next instalment, and it's about the part nobody warned me about: getting one real person to use the thing.

Short version: no paying customers yet. But this weekend I learned more about why than in the four months before it.

1. We found a hook. Maybe not the right one.

My first ads were claymation films.

Then we tried a short video in the style of those castle-defence phone games, the Clash of Clans look: little soldiers defending a castle, with Enki as the memory keeping the walls up. It went past 200 plays in about a day. That told us we'd found a hook. Whether it's the right hook, one that brings in people who want what Enki does rather than people who like castle games, I don't know yet.

A follow-up, "Raid on Memory Castle", got 203 views from 166 people on Facebook. 58% were over 55 and a third were over 65. Average watch time: 7 seconds. Link clicks: 5.

I've put £30 behind it as a paid test (£3 a day for ten days), with a stop rule written down before it started: more than £1 a click and no sign-ups after four days, it stops.

2. The front door was locked

I finally pulled the server logs and counted. About 18 people reached the sign-up screen. None got past it.

The first screen asked for date of birth, email and an 18+ tick, all at once, before you'd seen anything. Safe, responsible, and a wall.

On Sunday I split it:

Tick that you're 18 or over, give an email, you're in.
Your birthday is asked later, inside the app, the first time you reach an adults-only part.
If the birthday is under 18, it stops kindly and points to proper help.

While I was in there I checked whether the sign-in email could be hammered by a bot. It could. It's now five emails an hour per address, and when you hit the limit it tells you so instead of pretending an email is on its way.

3. I couldn't see any of it, so I built a dashboard

I was posting to Facebook groups, Instagram, LinkedIn, Bluesky and Indie Hackers and losing track of what went where. So I built a small desk that:

logs every post
shows which links actually got clicked
nudges me when a scheduled post is due
flags when the overnight tests go red

It's how I found the 0 out of 18. Without it I'd still be blaming the ads.

What I'd love your help with

If you've found your first ten users, where did they actually come from?
Has anyone found their audience was older than they assumed? What changed when you leaned into it?
Is £30 on a video test a sensible first experiment, or noise at that size?
What would make you trust an AI companion with your memories?

I'll answer every comment. If you want to see it: https://enki-companion.onrender.com/?utm_source=devto&utm_campaign=ep1_first_customer

Thanks for reading, from a 56-year-old who is now more scared of a sign-up form than of code.

I tested my AI safety filter 400 times. It flagged my own innocent prompts 1 in 40. published: false

stephen487 — Thu, 22 Oct 2026 20:17:40 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

enki-harness: a free, MIT-licensed test harness for AI filters that refuses to flatter you.

You wrote a safety filter, you wrote its tests, it passes. That proves less than you think: the person who wrote the code wrote the tests, so the tests only check the cases you already thought of.

enki-harness builds the harness for you and adds the parts you'd skip:

Twins: for every case it must catch, a near-identical innocent case it must not flag
Controls: dumb stand-ins (always-allow, always-block) that must fail, or the harness itself is broken
Rules off: switches each rule off, alone and in pairs, to find dead rules and rules that cancel each other out
Attacker slice: written by a different generator than your cases (leet, spacing, stretching)
Falsifier: you write down what result would prove you wrong before it runs, and it's timestamped

No score until every gate is green. Rows first, the number last.

This week I added add-on #1: hb judge, for when the filter isn't code but an AI model. It sends every case to the model several times and reports flag rates, not one lucky answer.

Demo

Video plus a one-click Windows install: https://enkilabs.co.uk/harness/

Code

stephen487 / enki-harness

A test harness for your AI filters that refuses to flatter you. Twins, controls, rules-off, attacker slice, pre-registered falsifier; MCP server; hb judge for model screens. MIT.

enki-harness

A test harness for your AI filters that refuses to flatter you.

You wrote a filter. You wrote its tests. It passes. That proves less than you think: the person who wrote the code wrote the tests, so the tests check the cases you already thought of.

enki-harness builds the harness for you, and adds the arms you would skip:

arm	what it does
twins	for every case it must catch, a near-identical innocent case it must not flag
control	dumb stand-ins (always-allow, always-block) that must fail, or the harness itself is broken
rules off	switches each rule off, alone and in pairs, to find dead rules and rules that cancel each other out
attacker	an independent slice written by a different generator than your cases (leet, spacing, stretching)
falsifier	you state what result proves you wrong before it runs; it is timestamped

No score until every…

View on GitHub

How I Built It

Plain Python standard library for the tool itself; nothing to pip install to run it.
Runs as a local web page (localhost only) and as an MCP server, so you can just ask your coding agent: "test my filter in filters/swear.py with enki-harness". One command registers it with Claude Code, VS Code/Copilot, Cursor, Codex, Claude Desktop and Windsurf, backing up every config first.
hb judge talks to open-weight models running locally through Ollama (I used Llama Guard 3 8B). There are no API keys, no per-call cost, and nothing leaves the machine.

Why Does Open Innovation Matter?

Because a safety model you can't run yourself is one you can't measure.

I pointed hb judge at the moderation step in my own product's image feature. The prompts it screens are fixed sentences we wrote ourselves, all describing ordinary adult portraits, with no user text anywhere. Run each one several times and the screen still flagged them at random, about 1 time in 40: a different sentence each time, never the same one twice in a row. Every flag was a false alarm turning away a real user.

With an open-weight model I could run it hundreds of times locally for free, see the rows, and prove the noise was the model, not my wording. Against a closed API, each of those checks costs money and you're guessing.

The Lazy Payoff

It saved me from the "obvious" fix. I was about to spend an evening rewording prompts to dodge the filter. The runs showed the plain cartoon style, already live and working, gets flagged just as often, so rewording would never have fixed it. That screen was only ever judging our own text, so we removed it from that one feature. The checks that actually protect people still run, on the finished image.

Two lessons now built into the add-on:

A warm-up call: my first run voided itself because the local model was still loading when the must-pass control ran. The harness refused to score it, which is exactly what it should do.
Progress output: a 400-call run that prints nothing looks hung. Now it prints a count every 25 calls.

Prize Categories

Repo:https://github.com/stephen487/enki-harness

The one-click Windows install is live now at https://enkilabs.co.uk/harness/

I gave my AI coding tools one shared memory that lives on my own PC (and built a test harness that refuses to flatter me)

stephen487 — Thu, 22 Oct 2026 18:14:27 +0000

Every AI coding tool I use has the same problem: it forgets. Tell Claude Code your staging database is on port 5433 on Monday, open Cursor on Tuesday, and you're explaining it again.

I've been building Enki, an AI companion whose whole point is remembering you, for about four months. This week two developer tools came out of that work. One is free and open source. Both are honest about their limits.

1. Enki Memory: one memory your agents share, kept on your machine

Enki Memory is an MCP server that gives every agent you connect one shared, persistent memory. It runs locally, works offline, and your memories never leave your computer.

# Monday, in Claude Code
you ▸ remember: the staging database is on port 5433, not 5432

# Tuesday, in Cursor
you ▸ which port is the staging database on?
agent ▸ 5433 (from your shared memory)

Your agent gets six tools: store, retrieve, update, discard, stats and export.

A few design decisions I care about:

A free install makes zero network connections. I checked the compiled build, not just the source.
Export is a first-class tool. Every fact goes out as JSON plus a readable Markdown copy, on every plan.
Nothing is ever locked. If you stop paying, recall, forget and export keep working. You just can't add facts beyond the free limit.
Changes are explicit. When a fact changes, the agent calls update and the old version is retired, not deleted: it stays on record but stops being recalled.

Honest limit: a reworded fact doesn't always get recognised as the same one on its own, so tell your agent to use update when something changes.

It installs with one double-click on Windows (it brings its own Python) and connects Claude Code, Claude Desktop (including the Microsoft Store version), Cursor and Windsurf, asking before it touches each one. Free up to 500 facts; Pro is £3.99/month for unlimited.

👉 https://enkilabs.co.uk/memory/

2. enki-harness: a test harness that refuses to flatter you (free, MIT)

This one came from pain. Our safety filters passed 100% of the tests we wrote, then fell over to h.a.t.e, 1 h4t3 y0u and stretched spellings we'd never have thought to write.

The problem isn't the filter. It's that whoever wrote the code also wrote the tests, so the tests only check the cases you already thought of.

enki-harness builds the harness for you. Your filter only needs this contract:

# filters/swear.py
RULES = {
    "hate_word": lambda t: "hate" in t.lower(),
    "kill_word": lambda t: "kill" in t.lower(),
}

def classify(text, enabled_rules):
    return any(RULES[n](text) for n in enabled_rules)

Give it what the filter must catch and must let through, and it adds the arms you'd skip:

Twins: for every must-catch case, a near-identical innocent case it must not flag.
Controls: always-allow and always-block stand-ins that must fail, or the harness itself is broken.
Rules off: every rule switched off, alone and in pairs, to find dead rules and rules that cancel each other out.
An attacker slice: written by a different generator than your cases (leetspeak, dots, stretched spellings).
A falsifier: you say what result proves you wrong before it runs, timestamped.

Then it reports bugs first and the score last:

GATES
  ✓ control       always-allow and always-block both failed, as required
BUGS   # every row the full system gets wrong, with the rule to blame
  ✗ Two rules cancel each other out   quote_exception × game_exception
  ✗ Dead rule: removing it changes nothing      loser_caps
  ✗ Attacker evasions   "1 h4t3 y0u"  "I h.a.t.e y.o.u"  +12
SCORE  # last, after the rows

No score is shown until every gate is green, and a 0% or 100% rate is flagged "check the instrument", because a check that never fires and one that always fires look the same.

It's standard-library Python 3.11, one-click on Windows, and also runs as an MCP server, so you can just ask your agent: "test my filter in filters/swear.py with enki-harness".

👉 https://enkilabs.co.uk/harness/

What I learned building both

Every serious bug I hit failed silently and looked like success:

A memory format upgrade read old files as "empty" and saved them back as empty, over the backup too. Now anything unreadable is quarantined before a byte is written.
For weeks my memory tests passed beautifully, because every one started with an empty memory. Now each test proves its world isn't empty before its result counts.

So my rule now: break things on purpose and check the alarm actually goes off.

Feedback welcome, especially the harsh kind. Both tools: https://enkilabs.co.uk

Why your AI forgets — and how a memory layer fixes it

stephen487 — Thu, 02 Jul 2026 16:15:44 +0000

You've felt it. You have a long, useful conversation with an AI assistant — it learns your project, your preferences, the details that matter — and then you open a new chat tomorrow and it's a stranger again. Everything's gone.

That's not a bug in one product. It's the default state of large language models: they don't remember. A model only "knows" what's in its context window right now. Close the window, start a new session, and the slate is wiped. For a chatbot that's annoying. For an agent — software meant to act on your behalf over days and weeks — it's disqualifying.

Two failures, not one

There are actually two distinct memory problems, and most fixes only address the first.

1. It forgets between sessions. No persistence across chats. Every conversation starts from zero.

2. It remembers too much, badly. The common fix is to store everything the AI is ever told and retrieve the similar bits later. But real information changes. A client's budget goes from £5,000 to £8,000. A launch date moves. A contact leaves. If your memory hoards every version, retrieval surfaces the stale one right alongside the current one — and the AI confidently answers with the old value. Store-everything memory doesn't just waste space; it actively serves wrong answers.

Why the obvious fix isn't enough

"Just add a cloud memory service" works for some. But it quietly rules out the people who need memory most. If you're building AI for healthcare, legal, finance, or government, your data legally can't leave your walls — so a memory layer that ships every fact to someone else's cloud is a non-starter. The result: the highest-value, most memory-hungry use cases are locked out of the easy option.

So the real requirement is a memory layer that is both persistent and private — one that remembers across sessions, keeps its answers current, and runs where your data already lives.

What a memory layer actually does

A memory layer isn't another chatbot. It sits underneath whatever model you use and gives it four simple operations: store, retrieve, update, discard. Your agent calls them as tools while it works. The model does the talking; the layer does the remembering.

The interesting engineering is in how it remembers. Two choices matter:

Forget at write-time, not read-time. When a new value for something arrives, retire the old one as you store it, so recall never has to guess which version is current. The current answer is the only answer that comes back.
Keep less, on purpose. Deduplicate what the agent re-hears, and don't hoard superseded values in the recall set. In our own benchmark (LongMemEval-S), this kept roughly half the facts of a store-everything baseline at comparable answer accuracy — and it's reproducible, which in a field full of unverifiable claims is the whole point.

Local by design, cloud-compatible by choice

The version we're building, Enki, runs on your machine. The facts you give it never leave the box. But it isn't walled off — it bolts onto any model, local or cloud, through a standard memory-as-tools interface (MCP). You get persistence and privacy and the freedom to use whatever LLM you want. That combination — sovereign but integratable — is exactly what a cloud-only memory service can't offer.

See it, don't take our word for it

There's a live demo you can try in about a minute, no signup: try.enkilabs.co.uk

Tell it a fact, hit "next day" to open a fresh chat, and ask a question only memory could answer. A normal assistant starts blank; the Enki-backed one remembers.
Then run the storage comparison and watch a keep-everything memory pile up while Enki quietly retires the stale facts — ending at half the footprint, still answering with the current value.

Enki runs on your machine, not someone else's cloud — and the head-to-head results are public and reproducible: github.com/stephen487/enki-benchmarks. The core has a UK patent application filed. The engine itself is in closed beta right now — there's a waitlist on the demo if you'd like early access.

If you're building agents that need to remember — especially somewhere the data can't leave — I'd love your feedback. Try the demo, break it, and tell me what's missing: steve@enkilabs.co.uk.