DEV Community: Serhiy Kucherenko

How to hurt yourself with AI

Serhiy Kucherenko — Tue, 25 Aug 2026 14:56:39 +0000

Summary

34x more work than it should have been.

Timeline

I write technical articles, and I like experimenting with something new in each one. For one of them, the experiment was an AI pipeline: it would draft the piece and pass it through several rounds of automated review before I saw it.

That pipeline produced 1,948 words while processed 65,930 in total which is ~34x more.

The idea was to base the writing on careful review and a feedback loop. So I ended up reviewing in person and wasting 34x words/tokens more than what I could actually produce.

Root cause

I am not sure what the exact cause is. There are several candidate explanations, and I do not think any one of them is complete on its own:

Not enough context to judge whether a cut was a real improvement.
The AI outputs what is locally coherent, what "sounds right," with no guarantee that coherent and applicable are the same thing.
The AI was built to fill in gaps rather than flag them, and what it fills in with is often an assumption, usually one that turns out false.

What a human has that the AI does not is a felt sense of consequence: what a decision actually costs or breaks, in a specific world, learned from having been wrong before. "Experience" is the word for that, and it is overused to the point of meaning nothing, but I do not have a better one.

If I compress all of that into one line: the pipeline optimized for the wrong thing. It optimized for passing a check. It could not optimize for "is this piece actually good," because nothing in it could feel the cost of being wrong.

The aim behind building it was sound and I would keep it: automate whatever a computer can do so a human does not have to. What failed was assuming editorial judgment was one of those things.

The debt

Engineers already track several kinds of debt that are not financial.
One of them is getting real attention now: cognitive debt, which is what you take on when you outsource tracking why your own system does what it does to an LLM. Two recent sources define it the same way: a
MIT Media Lab study on AI-assisted writing, and getdx.com's framing for software teams specifically.

This pipeline is a worked example. I could tell you the ratio, the gate verdicts, the timeline. For a while I could not have told you, from memory, what any single piece actually argued.

The more AI gets pushed into everything, the more this particular kind of debt matters. On a prototype, nobody bothers tracking it. On something meant to hold up, not understanding what you built is a deal-breaker,
and "just ship it, iterate later" is the same old fallacy wearing an
AI-shaped coat: speed and understanding traded off as if they were opposites, when the trade was optional.

What changes

The intent behind the pipeline was to be the reviewer: read a draft,
judge it, hand back a correction, and only step in myself when the correction failed too. In practice, I was correcting constantly, sentence by sentence, round after round, and each correction only produced more issues.

That does not work, and it should not. Scale it up and the failure gets clear: imagine ten thousand articles like this shipping out daily, all with a human correcting sentence by sentence, all costing that person a 34x reading tax.

Going forward, AI in this workflow does small, bounded jobs: formatting, a lookup, a narrow research question with a checkable answer. Things that do not load much cognitively.

Question for you

What have you noticed, using AI or watching it get used badly? Two data points I found while researching this piece:

Different domain, same shape as this piece: a check that looked like it was working, until someone read closely enough to notice it wasn't.

Judge strictly to avoid hallucinations

Serhiy Kucherenko — Fri, 14 Aug 2026 13:13:20 +0000

Ten questions over the SEPA rulebooks. A second model grades each answer against a reference, zero to a hundred, and the run came back healthy.

Except for question five, which asked which currency SCT Inst payments are executed in. The reference answer is one word long.

A zero on a one-word question reads like a system that does not know the first thing about its own subject matter. That is not what happened.

It was doing what it was told

The production prompt is explicit about the case where retrieval comes up short:

Answer the question using ONLY the sources below. If they do not contain the
answer, say so.

Retrieval never put the euro page in the top five results. So the sources handed to the model genuinely did not contain the answer, and the model was under written instruction to say exactly that.

The grader took that response, compared it to the word "Euro", and returned a zero.

The grader cannot see the difference

The judge receives the question, the reference answer and the answer text. It does not receive the sources, and that is deliberate: a grader holding the retrieved chunks would end up grading the retrieval instead of the answer.

That choice has a cost. "Correct, given what it was handed" is not a judgement this grader can make. It has one axis, factual match against the reference, and everything that fails to match lands at the bottom together.

Which means a fabricated answer about euro payments would have scored exactly what the refusal scored. Zero, either way. The eval could not tell the two apart.

The saved run does not help either. Each question is stored as an id, a score and a one-line critique. The answer text itself is not kept, so nothing downstream can recover the distinction the grader could not draw.

The failure was upstream

If the refusal had been the problem, changing the answering model would have moved the number. It was not, and it did not.

Two separate experiments recovered that question, and neither one touched generation. Keyword search found the euro page instantly, because the page contains the actual word. Vector search matches on meaning rather than
words, and it ranked that page outside the top five. A cross-encoder reranker, kept to the eval path only, found it as well and lifted recall@5 from 0.60 to 0.70.

Neither is a free fix. Leaving keyword search on permanently left recall@5 exactly where it started, at 0.60, because it dropped a question the vectors had been getting right. The blind spot moved. It did not close. The reranker is the only arm that moved the number, and it is not in production.

Make a wrong answer cost something

Retrieval will keep missing pages. Improving that is a separate job, so what matters here is how the eval reacts when it happens.

The grader was not being harsh. My rubric just stops at zero, so both failures pile up there together. One of them wastes the reader's time. The other sends them into a payments rulebook holding a rule that does not exist. My eval scored those the same.

So the strictness belongs on the wrong answer. Meta's CRAG
benchmark, which I only found after this run, grades four outcomes instead of one axis: a correct answer scores 1, a useful answer with minor errors 0.5, a missing answer 0, and an incorrect answer minus one. "Missing" is defined there as the system replying "I don't know".

That minus sign is the part I was missing. Saying nothing costs you nothing. Being wrong costs you a point.

Nothing was fabricated in this run. The system declined, as instructed, and the number punished it for that. But the rubric that could not credit that refusal is the same rubric that would not have charged for a made-up answer, and a made-up answer is the one that reaches the reader.

Charge the model for being wrong. Let it say nothing for free.

The illusion of improvement

Serhiy Kucherenko — Sun, 09 Aug 2026 19:24:47 +0000

The problem

My RAG answers questions about SEPA payment rulebooks. Every page of those PDFs carries the same header and footer, and all of it lands inside the chunks that get embedded.

Two lines of letterhead on every one of 290 pages, sitting in the same vector as the sentence that actually answers something.

The hypothesis

Identical text in every chunk means a shared component in every embedding. I believed that component was flattening the similarity signal: distances on my test query all clustered tightly around 0.34 instead of spreading out.

Strip the repeated lines, and while I am in there, stop splitting mid-sentence. Sharper chunks, sharper vectors, better ranking.

It is a mechanism, and it is checkable. I would have bet on it.

What improved

The cleanup worked exactly as designed. Any line repeating on at least half a document's pages gets stripped, with digits masked first so page numbers cannot disguise a repeat. "www.epc-cep.eu 35" on one page and "www.epc-cep.eu 36" on the next both normalise to "www.epc-cep.eu #", counted once per page. That line recurs on all 290 pages, so it goes. The rulebook title and the "Date issued" line collapse the same way and go with it:

Boilerplate in chunk text: every chunk, to none.
Words on a typical page: 464, to 448.
Chunks in the corpus: 495, to 484.
Chunk boundaries: cut mid-sentence, to whole sentences.

Eleven chunks disappeared, and the reason is duller than it sounds. No chunk was pure boilerplate. The junk was about sixteen words per page, spread across every chunk on that page. Chunking runs per page at a 300-word target, so the only pages whose count changed were the eleven sitting just above that line: 315 words became 299, 306 became 290, and two chunks became one.

Everywhere else the text simply got cleaner without changing shape.

The reality check

Then I re-ran the query I had been watching. Same top pages, same order.

The one thing I could have seen with my own eyes did not happen. Nothing reordered.

That is the entire result, and it is worth being blunt about how weak an observation it is. There was no evaluation set yet. The test was me reading one query's results and forming an impression, and an impression cannot separate "no effect" from "an effect too small to notice".

Why the mechanism was wrong

Ranking does not compare chunks to each other. It compares each chunk to the query and sorts by that angle. The boilerplate was only ever in the chunks; the question you type carries none of it.

I have two explanations and they both fit. The junk was identical in every chunk, so removing it nudged them all in a similar direction instead of spreading them apart. It was also only about 3% of a page's words, which is not much of a shove to begin with. Either way, I predicted a reshuffle and got a nudge.

What I cannot do is tell those two apart. Separating them needs the per-result distances to more than two decimal places, and I never wrote them down. Even a 3% shift should have moved something in the third decimal. Whether it did is a question my own logs cannot answer.

The 0.34 floor was not noise the boilerplate added either. That is what a dense, homogeneous legal corpus looks like to an embedding model. The chunks really are that similar to each other, because rulebook pages really are that similar.

What I kept, and what I changed

The cleanup stayed. Clean chunks are what a citation displays against an exact page, and what the prompt feeds the model. The payoff is real. It is just not the payoff I built it for.

What actually changed was my process. Three days later I built a golden set of questions with verified answers, and it produced a retrieval baseline of recall@5 = 0.60, the number every retrieval change has had to argue with since.

One detail I have left alone deliberately. The comment at the top of the cleanup module still states the dead hypothesis as fact: boilerplate "drags every embedding toward the same noise, which flattens the similarity signal". It is wrong, it is still there, and it is a better reminder than anything I would write on purpose.

The hypothesis was reasonable, the mechanism was checkable, and the check said no. The next fix that sounds this obviously right gets measured before it gets believed.

Three small lessons from building a RAG by hand

Serhiy Kucherenko — Sun, 02 Aug 2026 19:16:41 +0000

A retrieval system over the SEPA payment rulebooks. Plain Python, Postgres, two LLM vendors. Three independent decisions from it are worth writing down, because in each case the decision was cheap and the thing it taught was not the thing it was made for.

1. The vector database never got installed

Every RAG guide starts in the same place. LangChain's own documentation
puts it plainly: to build RAG, you first need to create a vector store. Then the shortlist writes itself: Pinecone, Qdrant, Weaviate, Chroma.

The vectors live in Postgres instead, through pgvector.

Not because Postgres is faster. Because a new datastore is a new failure surface, with its own consistency model, its own operational habits and its own way of going wrong at 2am. Postgres was already there holding the documents, and I already knew how to debug it. Scaling was never the plan for a corpus of one rulebook.

The whole of the retrieval query is this:

SELECT id, source, text, page, embedding <=> %s::vector AS distance
FROM chunks
ORDER BY distance ASC
LIMIT %s

<=> is cosine distance: 0 is identical, 2 is opposite. The ::vector cast is not decoration. A bare Python list arrives as double precision[], which that operator refuses, so the vector travels as a text literal and is cast on arrival.

One operator, one cast, one index. That is the entire integration.

Convenience is not proof, though. Would the real vector database have bought back time worth having?

One question, end to end, takes about 2,823 ms. The vector search inside it takes 4.9 ms. Replacing pgvector with something infinitely fast would return 0.17% of the wait.

None of this says a vector database is wrong. It says the unfamiliar one would have been paid for in operations and returned a line nobody was waiting on.

2. You can only measure what you own

No LangChain, no LlamaIndex either. The pipeline is plain Python calling two LLM vendors and a Postgres.

The usual defence is YAGNI, and it holds: the flow is five fixed steps with no branching. Embed the question, search, build a prompt, call the model, parse the answer and its citations. Orchestrating five fixed steps is the easy part. A framework earns its keep on branching, retries and swappable backends, and none of those were in play.

But that is not the reason worth giving.

Every result worth publishing from this project came out of a layer a framework would have owned.

I wrote the chunker, so the repeated headers could be stripped from every page and the effect measured: retrieval did not move at all. I wrote the rank fusion, so it was visible that hybrid search scored exactly the same as dense-only, and that the corpus was too small to show a difference rather than the technique being wrong. I wrote the database call, so it could be timed alone and found to be 4.9 ms.

Three findings, all negative, all only visible from inside.

The cost is real and there is a file listing it: mature libraries exist for the chunker, the fusion, the metrics, the eval harness. That file is the off-ramp for when this stops being worth it.

You cannot instrument an abstraction you did not build.

3. Two dependencies called "model", two very different bills

The model this system was planned around was retired before the first commit. The decision record replacing it carries the same date as that commit. The project lost its LLM before it had a second file.

The swap itself was trivial. The responder is one environment variable:

LLM_MODEL: str = os.environ.get("LLM_MODEL", "claude-haiku-4-5")

One line, one deploy, done. Now the other model.

The embedding model cannot move like that. The table declares its vectors as 1536 dimensions and an insert guard rejects anything else, because vectors from different embedding models do not share a space. Changing it means re-embedding the entire corpus before a single query works again. An afternoon at this size. A migration at a real one.

Same word, "model". One is a config value. The other is infrastructure wearing a config value's clothes.

The vendor's deprecation schedule does not read your roadmap. Decide which of your dependencies is which before it decides for you.

The localhost trap: a 10-second database connection on Windows

Serhiy Kucherenko — Mon, 27 Jul 2026 15:41:36 +0000

Every question in the app took about 15 seconds. The model was fast. Retrieval was fast. Ten of those seconds were hiding somewhere else, and for days I couldn't say where.

The app is payments-rag, a RAG system I built over the SEPA payment rulebooks. You ask a question in plain English, it retrieves the relevant passages from Postgres + pgvector, sends them to Claude, and returns an answer with the exact rulebook page cited. Fast is not a goal; under 5 seconds is. On my Windows machine it was taking three times that, every single query, and the answers were correct, which somehow made it worse. Correct but slow doesn't scream "bug." It whispers "maybe that's just how it is."

For days I told myself it was just slow on Windows. Docker overhead, antivirus, something environmental, whatever. I checked the model latency three times before I thought to check the connection. That was the wrong order, and it cost me the better part of a week.

There's a reason this class of bug survives. An LLM app carries a built-in excuse: models are slow, everyone knows models are slow, so a 15-second answer doesn't trigger the same alarm a 15-second SQL query would. The LLM had a good alibi for the slowness. I believed it too early.

Measuring instead of guessing

Two cheap pieces of observability ended the mystery in minutes.

The first was a per-stage timer. I split each request into connect, retrieval, and generation, and logged the breakdown on every answer. The line read:

retrieval 2.1s · generation 3.4s · connect + overhead 10.2s

Retrieval plus generation was about 5.5 seconds. The other ten were sitting around the database connection, not in the model, not in the vector search.

The second was a health check: a small panel that pings each dependency and shows the round-trip time. For the database it read:

DB reachable · 10137 ms

Unambiguous. The connection itself took 10.1 seconds. Not the query, not the embedding, the TCP connect. The bug had been there for days behind a vague "it's just slow." The moment we measured, it took one screenshot to locate.

What was actually happening

The connection string said localhost. That one word triggered a chain of events.

On Windows, localhost is dual-stack: it resolves to both IPv6 ::1 and IPv4 127.0.0.1, and the OS prefers IPv6. So the Postgres client first tried to connect to ::1:5433.

Nothing was listening there. The Postgres in this setup runs in Docker, and the published port was bound on IPv4 only. The IPv4 loopback answers; ::1 does not.

And because no connect_timeout was set, the client sat on the dead IPv6 route until the OS gave up on its own schedule and retried over IPv4. That giving-up takes about 10 seconds. Then the IPv4 connection succeeds in milliseconds, the query runs fine, and the answer comes back correct. Every query paid the toll again.

Three things had to line up to make it hurt:

localhost is dual-stack, and Windows tries IPv6 first.
Docker published the container port on IPv4 only, so there was nothing on ::1 to answer.
No connect_timeout, so instead of failing fast and loud, the client waited out the full OS-level fallback on every single connection.

Remove any one of the three and the problem disappears, which is exactly why it survived for days. On Linux and macOS colleagues' setups the same code was quick.

The fix

One word. localhost becomes 127.0.0.1, which skips DNS ambiguity entirely and goes straight to the IPv4 loopback that Docker actually publishes:

# .env
DATABASE_URL=postgresql://user:pass@127.0.0.1:5433/mydb

And a timeout, so this class of bug can never hide as a silent hang again:

psycopg.connect(DATABASE_URL, connect_timeout=10)

A hang is worse than an error. An error tells you where it hurts; a hang just eats your latency budget and says nothing.

The before and after:

host	connect latency
`localhost` (IPv6 detour)	10,137 ms
`127.0.0.1` (direct IPv4)	27 ms

About 375× faster, one word changed.

One caveat so nobody over-applies this: the trap needs the specific combination above. Windows resolution order, a container port published on IPv4 only, no connect timeout. If your stack differs, your ten seconds are hiding somewhere else.

What I keep from this

localhost is not 127.0.0.1 once IPv6 is in play. For a container whose port is mapped to IPv4, prefer the literal address; it behaves identically on Linux and macOS, where loopback is loopback anyway.
Always set a connect timeout. Fail fast and loud.
Cheap observability pays for itself. A per-stage timer and a one-line health check are maybe an hour of work combined, and they turned a multi-day "it's just slow" into a five-minute fix.

The per-stage timer and the health check both stayed in the project permanently. They've earned their place: the same health view now checks all five dependencies on demand and every 10 minutes, so the next silent hang, wherever it comes from, gets a number attached to it before it gets a story.

Serhiy Kucherenko builds backend systems and LLM tooling. The project this story comes from, payments-rag, is open source: github.com/KucherenkoSerhiy/payments-rag.

When 60% recall meant 90% accuracy: a RAG measurement story

Serhiy Kucherenko — Sun, 26 Jul 2026 21:49:28 +0000

Retrieval recall sat at 0.60 and would not move. Hybrid search did nothing. A reranker rescued exactly one question, and cost seconds per query to do it. The number that finally explained everything came from neither technique. It came from reading what the retriever had actually pulled back.

Two numbers that shouldn't coexist

payments-rag is a small RAG over two SEPA payment rulebooks. One eval checks whether the labelled page lands in the top 5 retrieved chunks. Another checks whether the final answer is correct.

The two evals disagreed. Recall@5 read 0.60, six of ten. The answer eval read 84.8 out of 100, a 90% pass rate. If the right page misses the top 5 four times in ten, how do nine answers in ten come out fine? That gap was the whole story.

Hybrid search: no lift

Hybrid retrieval was the obvious first move: vector similarity plus keyword search, combined. (The first run looked broken for a dumb reason: Postgres's plainto_tsquery ANDs every query word by default. Fixed the operator before the real measurement.)

The fair result was 0.60 to 0.60. Zero. Vector stayed the default.

A reranker hits its ceiling

A reranker was the fashionable next move, and it did move the number: 0.60 to 0.70. But 0.70 was not a random landing spot.

It promoted every fetchable page into the top 5. The remaining misses were never retrieved in the first place, so no amount of reordering could reach them. Worth building to understand the mechanism, but it costs seconds per query and stays eval-only.

The misses weren't misses

A recall miss hides two very different failures: the content was fetched but ranked low, or it was never fetched at all. Reranking and hybrid only reorder what was fetched, so neither could touch the second kind. To tell them apart, I re-ran retrieval on each of the four misses and searched the full text of every retrieved chunk for the answer fact itself. Not the labelled page. The fact.

Three of the four had the fact sitting in a retrieved chunk, on a page I had never labelled. My golden set pointed at one correct page among several, and recall@5 punished the retriever for finding a different correct one. I spent a Tuesday convinced it was broken. It wasn't.

Count "fact present in any retrieved chunk" instead of "labelled page in the top-k" and retrieval scores 9/10, exactly the answer eval's pass rate. The two numbers reconcile.

The fourth miss, currency, is the real one. "Euro" appeared in none of the retrieved chunks, and currency is the single question that scored 0 on the answer eval. Every LLM knows SEPA runs in euro, yet the model refused to answer without a grounded chunk. For a citation tool, failing out loud beats papering over a gap with training knowledge.

Coarse chunks: why the page ranks low

Why did the right page rank low in the first place? Each page-sized chunk embeds hundreds of words, averaging the answer together with the legal scaffolding around it. The further your wording drifts from the specification's own, the lower that chunk ranks. One fact on page 26, retrieved under three wordings:

Same fact. The rank tracks how far your phrasing sits from the spec's.

What carries over

Split "ranked low" from "never fetched" before you tune. Reranking and hybrid reorder the fetched set; they cannot conjure a missing page. Both were aimed at the wrong problem here.
Literature numbers don't transfer. Big-corpus hybrid gains say nothing about a 2-document, 10-question set. Small corpora behave differently, and 10 questions is a noisy ruler.
Label your golden set to the fact, not to one page. A single "correct" page turns real hits into phantom misses, which is the whole reason these two numbers ever disagreed.

The honest gap

One caveat: that soft recall, fact-present-in-any-chunk, is still a manual check, not a built eval. For now I ship the strict 6/10.

I started the week thinking the retriever found the right answer 60% of the time. It was finding it 90% of the time. The metric was wrong, not the retriever.

Serhiy Kucherenko builds backend systems and LLM tooling. Try payments-rag live at rag.serhiykucherenko.dev. Full code and evals in the repo: github.com/KucherenkoSerhiy/payments-rag.