DEV Community: David Buchan

Fine-tuning a YOLO26 classifier on trading-livestream screen captures - with a Whisper + VLM labeling flywheel

David Buchan — Tue, 27 Oct 2026 08:07:50 +0000

Most computer-vision demos start with a dataset someone else curated. Mine started with screen recordings I was not allowed to redistribute - which turned out to be the most instructive constraint in the whole project.

This is the story of trade-state-classifier: a fine-tuned YOLO26n-cls model that looks at a screenshot from a trading livestream and answers one binary question - is there a filled position visible on screen right now? - plus the labeling pipeline that made it possible without anybody's data leaving my machine.

Why binary classification (and not object detection)

The upstream goal is an event pipeline: watch a livestream, detect the moment a streamer's position state changes (flat -> open -> flat), extract the displayed entry/stop/target levels at that moment, and hand a validated event to the execution layer.

Full UI-element detection (order tickets, entry lines, price badges) is the endgame - but it needs far more labeled variety than I could curate responsibly. A state gate needs to answer exactly one question reliably. So v1 = one classifier, one binary decision, measured hard.

The labeling problem

Fine-tuning means labels, and labels for this task have a nasty property: open position is rare. Uniform frame sampling at 1 fps gives you thousands of near-identical flat-screen frames and a handful of meaningful ones. Label quality would drown.

The flywheel that solved it:

Whisper (faster-whisper, local) transcribes the VOD. Talking traders narrate what they are doing.
Speech-cue parser finds candidate windows - phrases around "getting filled", "taking profit", "stopped out", "flat now".
Sparse frame extraction - only the seconds around each cue, not the whole hour. Roughly two orders of magnitude fewer frames to look at.
Local VLM (qwen2.5vl:7b via Ollama) drafts labels for those keyframes, based on an element list (position badge, PnL overlay, position box).
Confluence confirmation - a window only survives if speech and vision agree. The two chatterboxes must contradict each other to flag a frame for me.
Owner-verified dense segments around confirmed trade windows - I confirm every frame in the segments I train on.

That last step matters. VLMs fast-draft; they do not carry truth. Every training frame was verified by the only model with skin in the game: me.

The training run

Base: YOLO26n-cls (Ultralytics), the nano variant, deliberately - CPU inference at ~15ms/frame keeps the state gate cheap enough to run continuously.
Input: ~1,700 confluence-confirmed crops, 512x512.
20 epochs, batch 16.
Evaluation: temporal validation - sessions the model never saw during training. Adjacent frames leak; a random frame-split lies to you. Holding out entire sessions is the honest split.

Result table (iterations v11 -> v17):

Milestone	What changed	Held-out result
v11	context-menu and hypothetical position drawings mined out as hard negatives	100% (341/341), 0 false opens
v13	dense confluence windows per confirmed trade	100%
v16	five more sessions pooled	100% (341/341), 0/165 false positives

The interesting run: a session whose only state was "no trades, all day" produced ten 1-second VLM "open" blips taught nothing - until dense windows around the one confirmed trade window were added. Sparse VLM labels had a blind spot; the fix was density, not cleverness.

The publishing decision that took longer than the training

After validation the question was: what can go public?

The model can. The frames cannot - they are someone else's screen, and I decided redistribution crosses a line I did not want to argue with anyone about.

So: weights on the Hugging Face hub, zero images anywhere, no channel names, no video IDs. Then a full audit of my own public repos - because the training story lives in commit history, docstrings, and example paths. Every identifier got generalized (channel-a/channel-b, session placeholders), the harness scripts removed those, and history was rewritten rather than patched so nothing was merely invisible-but-recoverable.

A "publish without exposure" checklist that I now treat as standard:

Weights are fine, frames are not.
Descriptive metrics OK; provenance narratives are leaks.
git log, example paths, and docstrings are part of your public surface - audit them, not just README.md.
If exposure retrofitting needs three layers (working tree, history, hub), treat that cost as the price of skipping hygiene in the first place.

What the classifier still cannot do

Saying this publicly protects future-me:

It detects a visible position badge - a streamer chart-hopping mid-trade looks like flat.
It is platform-appearance-specific. A position box on one platform does not look like another's; pooled training helps, new platforms will need new data.
A drawn (hypothetical) position-tool box and a filled position can look identical. The visual gate alone cannot tell you a fill happened - that is why the upstream pipeline requires speech confluence and state-transition logic.

What is next

ONNX export and an in-browser demo: the whole model running in the visitor's browser via onnxruntime-web, on screenshots the visitor brings (privacy-compatible demo by construction).
More platform calibrations, pooled rather than forked.
The universal detector: entry/stop/target/quantity reads off any chart, with OCR and geometric validation deciding whether an event is even possible.

The full labeled pipeline, validation tooling and inference scripts are in the stream-signal-vision repository, and the published weights are at trade-state-classifier on Hugging Face.

Practical patterns for LLM scoring in n8n workflows

David Buchan — Wed, 21 Oct 2026 10:18:49 +0000

My n8n workflows follow one hard rule, learned the hard way: rules are cheap, deterministic, and auditable, so they run first. Language models are none of those things, so they run second, on the small population of cases where rules thrash. Lead qualification is the classic example. Company size, email domain, seniority — a lookup table handles those. "Is this inbound request actually a fit for what we sell?" — that is where the rule-based version of me wrote forty brittle IF nodes and lost.

Here are the five patterns I use when adding LLM scoring to a workflow. They are the same principles behind my job-search pipeline, scaled down to node size.

Pattern 1: demand structured output, not prose

Never let the model write you a paragraph you then parse with string matching. Most LLM nodes in n8n (and raw API calls via the HTTP node) support a JSON response format. Ask for exactly this shape and nothing else:

{
  "score": 0-100,
  "verdict": "sales" | "nurture" | "reject",
  "reasons": ["one line each"]
}

Temperature 0. A schema the model cannot deviate from. Prose is for humans; pipelines eat JSON.

Pattern 2: the model scores, the rules route

Put the scoring step behind your existing rule chain, and put an IF node after it. The model's verdict feeds the IF. The model never writes to your CRM, never sends the alert, never decides anything at the edge. It fills a field. Nodes that do things stay deterministic.

Pattern 3: every error branch lands on a default

The model will time out, return malformed JSON on a bad day, or rate-limit you during a burst. Every one of those cases must land somewhere sensible: error branch to a Set node that writes a default score and a reasons: ["model_unavailable"] flag. The workflow keeps running. This is the n8n version of errors-are-data: a full run report with a few defaulted scores beats a dead pipeline with a perfect one.

Pattern 4: cheap model, precise prompt

Scoring a lead against a rubric is not frontier-model work. A small, fast, cheap model with a prompt that contains your actual rubric — with examples — beats a big model with a vague prompt. Put the rubric in the prompt: what makes a 90, what makes a 30, what is an instant reject. The money you save buys a lot of retries.

Pattern 5: log the reasons, not just the scores

Write score and reasons to your log store every single run. Two weeks later you will find the leads that scored 61 and deserved 90, and the exact sentence in the rubric that caused it. Without logged reasons you have a black box; with them you have a reviewable system. The template library runs 1,892-plus alert cycles at 99.7% for exactly this kind of reason — you cannot fix what you do not log.

Status and links

I am applying these to the lead-qualification template in my open-source n8n library, and the job-search engine that taught me these patterns is public too: n8n-automation-templates and remote-job-engine. The bigger version of this story — 1,500+ postings scored, rules first, model second — is here.

I am a junior automation and data builder, career-changer, fully remote from Germany (or UK). If your team runs n8n or needs LLM integrations that do not hallucinate their way into production: reaver1000.github.io.

Anyone can claim to be an up-and-coming AI engineer. Here are my receipts instead.

David Buchan — Fri, 16 Oct 2026 08:32:32 +0000

"Up and coming." "Promising." "One to watch." Every job board and every LinkedIn feed is full of people describing themselves with adjectives. I do not want to do that, because adjectives are unverifiable noise. So this post is something else: my first year of building in public, in receipts, with links. Judge the trajectory, not the adjectives.

The receipts

2022 — the degree, done at night. I started a BSc in Computing and IT with the Open University while working full time. I finished it in 2026. Not a receipt for talent — a receipt for stubbornness, which is more reliable anyway.

2025 — n8n templates that run in production. I built a set of workflow templates for n8n and put them to work. The alert monitor has run 1,892 times at 99.7% success. Lead qualification: 247 runs, 99.2%. Data sync: 312 runs, 97.8%. They are open source: n8n-automation-templates. A template that runs weekly for months without you touching it is worth more than any certificate.

2026 — the job search engine. I automated my own job hunt: 30+ ATS boards, deduplication against every posting I have ever seen, hard rule filters before any LLM call, then LLM scoring against my honest profile. Over 1,500 postings evaluated this year; 1,539 parked; 12 apply-worthy. Public and scrubbed: remote-job-engine and job-sweep. The full story is on dev.to, and auf Deutsch too.

September 2026 — the quality wave. One month, four repos, all with tests: a composable ETL framework (errors as data, whitelist mapping, CI), a SQL playground (55 templates, 115 tests, now a live demo), a file automation toolkit (20 tests), and a finance analytics dashboard. The lesson post is here.

October 2026 — the paper trail. Three technical articles, a bilingual portfolio site, and a live demo instead of dead links. You are reading the third article.

What the receipts have in common

Build things you actually use. My n8n templates monitor services I care about. My job engine found the shortlist I am actually working through. Tools you use daily cannot fake it.

Tests or it did not happen. Every framework repo has a test suite. The SQL playground has 115 tests that execute all 55 templates. This is not rigour for its own sake — it is the difference between "code exists" and "code works."

Write it down. The articles are not marketing. They are the honest lessons, including the ones that cost me: six perfect-looking job candidates that died when I read the actual posting bodies.

The honest gap

I have no professional software engineering title yet. Thirteen years in operations — Lloyds Banking Group, Deutsche Post, sysadmin, currently Amazon print production — and a degree, and all the receipts above, and no job title in software. That is the next receipt, and it is the one I cannot publish myself. Someone has to give it to me.

If your team needs a junior or associate who already works like this — AI, automation, or data, fully remote from Germany or UK — everything is on reaver1000.github.io. The receipts are the résumé. The next one is yours to write.

Wie ich eine KI gebaut habe, die meine Jobsuche übernimmt

David Buchan — Sun, 11 Oct 2026 14:01:31 +0000

Jede Woche durchsucht meine Software etwa zwanzig Stellenbörsen. Sie sammelt ein paar hundert Stellenanzeigen. Ein einziger LinkedIn-Sweep brachte kürzlich 112 Ergebnisse. In diesem Jahr hat die Pipeline mehr als 1.500 Anzeigen bewertet. 1.539 davon wurden aussortiert.

Wie viele Bewerbungen ich wirklich abgeschickt habe? Eine Handvoll.

Dieses Verhältnis ist der ganze Punkt. Ich bin Quereinsteiger und über vierzig. Fünf Jahre bei der Lloyds Banking Group, acht Jahre als Postbote, zwei Jahre als Windows-Systemadministrator. Heute arbeite ich in der Druckproduktion bei Amazon. Dieses Jahr habe ich mein Informatik-Studium abgeschlossen (BSc Computing and IT, Open University). Einen professionellen Titel als Softwareentwickler habe ich noch nicht. Ich suche den ersten. Und er muss remote sein.

Stellenbörsen sind anstrengend. Für mich waren sie besonders anstrengend, denn ich filtere nach engen Kriterien und habe den Titel noch nie getragen, auf den ich mich bewerbe. Also baute ich mir die Software, die ich nicht kaufen konnte.

Die Pipeline

Stufe 1, Sammeln. Sechzehn API- und RSS-Quellen. Dazu Playwright-Sweeps für die Börsen ohne API: Indeed, StepStone, LinkedIn (mit gespeicherter Session) und die Arbeitsagentur mit tiefen Suchbegriffen. Alles landet in einem Speicher mit Deduplizierung. Keine Anzeige wird zweimal verarbeitet.

Stufe 2, Harte Filter. Bevor ein Modell etwas sieht, sortieren billige Regeln aus. "Senior" im Titel? Weg. Stadt außerhalb meines Radius? Weg. Mehr als drei Jahre Berufserfahrung gefordert? Nicht meine Ebene. Diese Filter sind bewusst keine Modellaufrufe: Sie kosten nichts und man kann sie prüfen.

Stufe 3, KI-Bewertung. Die Überlebenden liest ein Sprachmodell. Es bewertet die Passung gegen mein ehrliches Profil. Auch die Einschränkungen, die sonst erst im Interview auffallen. Rollen mit "verhandlungssicher Deutsch in Wort und Schrift" für Kundenkontakt sind für mich nichts — mein schriftliches Deutsch ist B1. Interner Team-Kontakt auf Deutsch ist dagegen fein, gesprochen bin ich auf C1-Niveau.

Stufe 4, Verifizierung. Diese Stufe hat sich ihren Platz hart verdient. Aggregator-Titel schmeicheln. Sechs perfekte LinkedIn-Kandidaten starben, als ich den echten Anzeigentext las. Die "Junior"-Stelle wollte fünf Jahre Erfahrung. Die "Remote"-Stelle wollte drei Tage vor Ort in einer anderen Stadt. Die Regel ist jetzt absolut: Nichts kommt in die Bewerbungsliste, bevor der echte Anzeigentext geladen und gelesen wurde.

Stufe 5, der Mensch. Ich öffne die URL selbst. Ich lese die Anzeige selbst. Dann schreibe ich genau das, was das Formular verlangt. Eine Bewerbung nach der anderen. Keine Massen-Anschreiben. Wenn Bewerbungen teuer sind, liest man wirklich. Genau das ist die Funktion.

Was ich gelernt habe

Filter hart, bevor du das Modell aufrufst. Regeln sind kostenlos. Tokens sind es nicht.

Lass die KI nie Stellenanzeigen erfinden. Ein Modell, das man nach Stellen fragt, erfindet glaubwürdige Anzeigen mit plausiblen URLs. Meine Pipeline bewertet nur, was die Scraper wirklich geladen haben.

Die letzte Meile bleibt menschlich. Die Pipeline soll mich wählerisch machen, nicht faul.

Für Quereinsteiger ist die Pipeline das Portfolio. Ich wartete lange auf ein Projekt, das beweist, dass ich Software bauen kann. Irgendwann merkte ich: Der ehrlichste Beweis lief längst. Getestetes Python, echte Scraper, Deduplizierung, CI. Ein System im täglichen Einsatz, mit echten Folgen. Die Werkzeuge sind öffentlich: job-sweep ist das Sweep-Toolkit, remote-job-engine übernimmt Suche und Bewertung. Eines der Projekte läuft als Live-Demo: SQL Query Builder.

Was kommt

Ich suche eine Junior- oder Associate-Rolle — KI, Automatisierung oder Daten. Vollständig remote aus Deutschland oder aus Großbritannien (ich bin britischer Staatsbürger). Alles über mich steht auf reaver1000.github.io, dort gibt es auch eine deutsche Seite.

Und wenn du selbst auf Jobsuche bist: Bau das Werkzeug, bevor du dem Board vertraust. Das Board hat deine Interessen nicht im Blick. Deine Pipeline schon — du hast sie geschrieben.

Errors are data: what building a small ETL framework taught me

David Buchan — Fri, 09 Oct 2026 13:28:26 +0000

Most tutorials show you pandas in a notebook. Real data work is a scheduled job with three sources, and one of them is broken, and nobody is watching when it runs.

That gap is why I built etl-data-pipeline: a small, composable extract-transform-load framework in Python with a full test suite and CI. It ingests deliberately messy sample data, stray whitespace, inconsistent casing, a missing email, duplicate rows etc cleans it, loads it into SQLite, and reads the table back to prove the roundtrip. Twenty-one tests. You can run the whole demo in under a minute:

pip install -r requirements.txt
python demo.py
pytest

It is not Airflow. It is not dbt. It is a few hundred lines that do one job, and building it taught me four things that notebooks never will.

Lesson 1: errors are data, not exceptions

My first version raised on the first bad row. Then I imagined the scheduled-job reality: one dead API source at 3am, an exception halfway through the run, and half the data loaded with no record of what survived. So the extractors and loaders in this framework never raise. Every stage returns a result object with an errors list, and the pipeline produces a structured run report: per-stage record counts, successes, errors, timing.

A full report at the end of a broken run beats a stack trace in the middle of it. Errors became rows in the report, and the report became the thing I actually read.

Lesson 2: schema mapping is a whitelist, not a copy

Upstream APIs grow fields without warning, and "just copy everything" is how an unreviewed column sneaks into your database. The FieldMapper stage only copies fields you explicitly mapped and deliberately drops everything else. Mapping became a security decision, not just a renaming convenience.

Lesson 3: SQL identifiers cannot be parameterised

Values in SQLite can be bound as parameters. Table and column names cannot . They have to be interpolated into the DDL string. So the loader validates the table name and quotes identifiers, while all values stay parameterised. There is an injection test in the suite that documents exactly this edge, because it is the one place a "just use parameterised queries" rule quietly fails.

If you learn one paranoid habit from this post: decide, per identifier, whether it comes from your code (fine) or from anywhere else (validate it first).

Lesson 4: tests never touch the network

The APIExtractor tests mock requests.get. Everything else runs against pytest's tmp_path. That decision, more than any cleverness, is why the suite runs in seconds and never flakes. It also forced the code into honest seams, if you cannot mock the boundary, the boundary is in the wrong place.

The composable part

Every stage is one abstract method. Subclass Extractor, Transformer, or Loader, implement the one method, and the pipeline treats it like any other stage. I added an extractor for a new JSON response shape by writing a few lines, not a new framework.

That is the quiet punchline for other career-changers like me (I wrote this while finishing a Computing and IT degree after 13 years in operations): the big orchestration tools are composable stages with run reports and whitelists underneath. Building the small version once teaches you what the big version is actually doing. Now when a job description says "experience with ETL tooling", I can say what I did, show the code, and point at the tests.

Try it

The repo is public: github.com/Reaver1000/etl-data-pipeline. Fork it, break it, extend it. The design notes in the README cover the extension points, and the CI badge is green.

I am a junior developer looking for my first software engineering title. If your team does data work in Python and this style of thinking fits, everything about me is at reaver1000.github.io.

I built an AI that finds and scores my next job

David Buchan — Thu, 08 Oct 2026 21:12:02 +0000

Every week my tooling sweeps around twenty job sources and pulls in a few hundred postings. A single recent LinkedIn sweep returned 112 results. Over this year the pipeline has evaluated more than 1,500 postings and parked 1,539 of them.

The number of jobs I have actually applied to? A handful.

That ratio is the whole point. I am a career changer in my forties. Five years in banking operations at Lloyds, eight years delivering mail, two years as a Windows sysadmin, and currently I run print production shifts at an Amazon facility. This year I finished a BSc in Computing and IT with the Open University. What I do not have is a professional software engineering title, so I am hunting for my first one, and I need it remote.

Job boards are exhausting for everyone, but they are especially exhausting when you are filtering for a narrow set of constraints and you have never held the title you are applying for. So I built the tooling I could not buy.

The pipeline

Stage 1, collection. Sixteen API and RSS sources, plus Playwright-based sweeps for the boards that have no API: Indeed, StepStone, LinkedIn (via a saved session), and the German Arbeitsagentur job board with deep search terms. Each source writes a markdown file of raw results, and everything lands in a SQLite-backed dedupe store so no posting is ever processed twice.

Stage 2, hard elimination. Before any model sees anything, cheap deterministic filters kill the obviously wrong postings. A title containing "Senior" when the range is junior. A city outside my radius. Recruiter spam patterns. Skills bars over three years of professional experience, because "Erste Erfahrung" (first experience) is fine for me and "5+ years" is not. These filters are strings and rules, not model calls, and that is deliberate: they cost nothing and they are auditable. At last count the confidence list held 12 survivors, 23 maybes, and 1,539 parked. The parked bucket being enormous is the system working correctly.

The funnel in one picture: a weekly LinkedIn sweep produces 112 raw results; after dedupe, hard elimination, and body-verification, the apply-now queue holds 12.

Stage 3, LLM scoring. The survivors get read by a language model that scores fit against my honest profile, including the constraints that usually get discovered at the interview stage. Written German at B1 means customer-facing roles demanding "verhandlungssicher Deutsch in Wort und Schrift" are a no for me, while internal team communication in German is fine because my spoken German is C1. Encoding these rules as a prompt instead of gut feeling removed a whole class of optimistic mistakes.

Stage 4, verification. This is the stage that earned its place the hard way. Aggregator titles flatter. Six consecutive LinkedIn candidates that looked perfect by title died when I fetched the actual posting body: the "junior" role wanted five years, the "remote" role wanted three days on-site in another city, the "AI engineer" role was actually a data-labeling gig. The rule now is absolute: nothing enters the apply queue until the real posting body has been fetched and read.

Stage 5, the human. I open the URL myself and read the posting myself. Then I draft exactly what the form requires, one application at a time. No batch-generated cover letters, no auto-submit. When applying is expensive you actually read, and that is the feature.

What I learned building it

Filter hard before you call the model. Rules are free, tokens are not, and determinism beats cleverness for anything you would want to debug at 6 a.m. before a shift.

Never let an LLM generate the job postings. Left alone, a model asked to "find jobs" will happily invent believable postings with plausible URLs. Mine only ever ranks what the scrapers actually fetched. Every URL in the queue was downloaded from a real board.

The last mile should stay human. The pipeline's job is to make me picky, not lazy. Automation found me a short list worth reading carefully, and the careful reading is mine.

For a career changer, the pipeline is the portfolio. I kept waiting for a project impressive enough to prove I could engineer software. At some point I noticed the most honest proof was already running: tested Python, real scrapers, a dedupe store, CI on the ETL framework, and a system in daily use solving a real problem with real stakes. The tools in this post are public: job-sweep is the scrubbed sweep toolkit, and remote-job-engine handles discovery and scoring.

What is next

I am available for junior or associate roles from November 2026, fully remote from Germany or UK-remote as a British citizen. If you are hiring for AI integration, automation, data, or QA work and any of this resonates, everything is on my site: reaver1000.github.io, or find me on LinkedIn.

And if you are also job hunting in this market: build the tool before you trust the board. The board does not have your interests at heart. The pipeline does, because you wrote it.