DEV Community

Techniques for Making AI Agents Your QA Team for Reliable Modernization

Emmanuel R — Tue, 03 Nov 2026 12:27:34 +0000

Agents can port a legacy screen in minutes, so the bottleneck moves to proving the new code behaves like the old. These are the techniques that turn agents into a QA team you can trust: layered gates, characterization tests, maker-checker review and visual diffs.

AI agents can now port a legacy screen in minutes. That moves the bottleneck. The hard question in a legacy system migration is no longer "can we write the new code?" but "how do we know it behaves exactly like the old code?"

Manual QA can't keep up with agent-speed porting, and a passing build proves very little. The answer is to point agents at verification too, and to set them up so they find problems instead of approving them. Here are the techniques that make an agent QA team you can trust.

Why migration testing is different

Normal QA asks whether software meets a spec. Modernization QA asks whether the new system matches the old one, and the old one usually has no spec. Its real behavior is spread across templates, watchers, global events, server quirks and years of bug fixes nobody wrote down.

So the goal is parity: same outputs, same side effects, same edge cases, unless a difference is a deliberate, recorded decision. Every technique below serves that goal.

“Program testing can be used to show the presence of bugs, but never to show their absence.” — Edsger W. Dijkstra, Notes on Structured Programming

Technique 1: Five layers, cheapest first

Don't send every change to the most expensive check. Stack the gates so cheap, deterministic checks catch the obvious problems before an agent or a person spends time on them:

Static gates. Types, lint, build, and a banned-API list (no jQuery in the React tree, no direct DOM access, no old global stores).
Characterization tests. Tests that record what the old code does today, written before the port.
Behavior parity review. A separate agent compares old and new logic and reports differences.
Visual and end-to-end diff. Screenshots, user flows and network calls, old against new.
Human sign-off. People review a risk-ranked sample, not every line.

Nothing merges on the porter's word. Each layer is a gate, and a failure sends the unit back.

No single layer is close to perfect, and none needs to be. With modest catch rates for each layer, the model above lets through about 6% of behavior bugs, against 28% when you stop at tests. The layers only multiply like this when they look at different things, which is why each one has a distinct job.

Technique 2: Write characterization tests before the port

Have a test-writer agent read the old unit and write tests that pin down its current behavior: rendered output for known inputs, events fired, API calls made, validation messages shown, what happens on empty, error and slow responses. These tests run against the old code first and must pass there.

Then the same tests run against the new code. Because they were written from the original, not from the port, they can't inherit the porter's misunderstandings.

Lock the tests once they pass on the old code. If a porter edits a characterization test to make it pass, that is a finding, not a fix.

“To me, legacy code is simply code without tests.” — Michael Feathers, Working Effectively with Legacy Code

Technique 3: Maker and checker never share a context

An agent reviewing its own work mostly agrees with itself. It already has a story for why every line is right. The reviewer has to be a separate agent with a fresh context that sees only the evidence: the original code, the new code and the test output.

Give the reviewer a narrow job and a strict output format. Ask for concrete findings, each with a file, a line and a failing scenario, and nothing else:

Compare src/legacy/orders/OrderList.js with src/app/orders/OrderList.tsx.
Report only behavior differences a user or API consumer could observe.
For each: file:line, the input or scenario, old result, new result.
Do not comment on style. Do not suggest refactors.
If you find none, say so.

Run a second pass on the findings themselves. A verifier agent tries to reproduce each one, and only confirmed findings go back to the porter. This keeps false alarms from wasting porter time and teaching the team to ignore the reviewer.

The same logic applies to choosing models for each layer. Use a different model family for the reviewer than for the code it checks, put cheap fast models on high-volume checks, and keep top-tier models for the judgment calls.

Technique 4: Diff what the user sees and what the server sees

Logic review misses things a user notices immediately: a shifted layout, a missing loading spinner, a date in the wrong format. An agent driving a browser can run the same flow on the old and new app, take screenshots at each step and compare them.

Record network traffic too. If the old screen made three API calls with certain parameters and the new one makes five, or drops a header, something changed. Network diffs catch problems that never show up on screen until production traffic hits them.

Technique 5: Spend human time where risk is highest

Agents make human review cheaper, not unnecessary. Have the orchestrator rank units by risk: payments, auth, permissions, data writes and anything with a history of incidents go first. People review those in full, and a sample of the rest.

In this model, risk ranking cuts senior review time by about two thirds while still reviewing every high-risk unit in full. Agents run the first four layers on every unit regardless.

Every deliberate difference, such as a bug you chose to fix instead of copying, goes into a decisions log with a reason. When parity tests fail later, the log tells the reviewer which differences are expected.

Technique 6: Measure the QA team itself

An agent QA team needs QA too. Seed a few known bugs into ported units, such as a dropped validation rule, a changed sort order or a missing error state, and check that the layers catch them. If a seeded bug slips through, you know which layer to strengthen before a real one does.

Track the reviewer's precision as well: the share of its findings that the verifier confirms. A reviewer that cries wolf gets ignored, and a reviewer that never finds anything is probably not looking hard enough. Both numbers belong on the project dashboard next to units migrated.

Seeded-bug catch rate: which layer caught each planted defect, and which missed it.
Reviewer precision: confirmed findings divided by all findings.
Escaped defects: bugs found after merge, traced back to the layer that should have caught them.

What this looks like in MigrateX

Our MigrateX plugins build this in. Each framework plugin has a read-only parity-reviewer agent that checks one migrated piece against its original for behavior, markup, data and timing differences before the old code is removed. It can't edit code, so it can only report. The porter fixes, the reviewer checks again, and an engineer signs off.

Key takeaways

Modernization QA is about parity with an undocumented system, not meeting a spec.
Stack gates from cheap to expensive: static checks, characterization tests, parity review, visual and network diffs, human sign-off.
Write tests from the old code before the port, and lock them.
Keep the reviewer in a separate context, ask for concrete findings, and verify findings before acting on them.
Spend human review on the riskiest units, and log every deliberate difference.

Originally published on the CobuildX blog.

10x Your Modernization Efforts With Multi-Agent Teams

Emmanuel R — Tue, 03 Nov 2026 12:26:29 +0000

One agent porting one file at a time stalls fast. Teams getting big gains split the work across an orchestrator, parallel porters, a test writer and an independent reviewer. Here is how that setup works and where the speed-up really comes from.

Most teams try AI on an application migration the same way: one chat, one agent, one file at a time. It works for a demo. Then the codebase turns out to have 400 components, a router nobody fully understands and a service layer with side effects in every getter, and the single agent becomes the bottleneck. It forgets what it ported yesterday, repeats the same mistakes, and marks its own homework.

The teams getting large gains don't use a smarter agent. They use more agents with narrower jobs, coordinated around a plan. This post covers how that setup works, where the speed-up really comes from, and what has to be true before you get anything close to 10x.

Why one agent stalls

A single agent doing a migration carries the whole project in one context window: the old code, the new code, the conventions, the test output and its own earlier decisions. As the window fills, quality drops. It starts to drift from conventions it set itself, and it re-reads files it already understood.

It also works in series. Port, test, fix, review, then the next unit. Even if each step is fast, the project's speed is the sum of every step.

And when the same agent that wrote the code reviews it, it mostly agrees with itself. The bugs that matter most in a migration, small behavior differences between old and new, are exactly the ones its own reasoning has already explained away.

The multi-agent setup for application migration

A working setup has five roles. Each is an agent with its own context, its own instructions and a narrow set of tools.

Orchestrator. Owns the plan: the list of units, their dependencies and their status. It hands out work and never writes app code.
Inventory agent. Read-only. Maps every route, component, service, global and hidden wiring point before anyone writes a line. Its output is the unit graph.
Porters. Each takes one unit at a time and moves it to the target stack, following a shared conventions file. Several run at once.
Test writer. Captures what the old unit does today, as characterization tests, before or alongside the port.
Parity reviewer. A fresh agent that sees only the old code, the new code and the test results, and reports concrete differences with a file, line and failing scenario.

Split by unit, not by step. Give a porter a whole component with its tests, not "all the templates" across the app.

Where the speed-up actually comes from

The chart above is a simple model (Amdahl's law), but the shape holds on real projects. Parallel porters only help when the units they work on don't depend on each other. If unit 6 needs unit 2's new API, it waits. So the real driver of throughput is the unit graph: how well the inventory step breaks the app into pieces that can move independently.

The other multiplier is less obvious: fewer re-dos. Each agent's context stays small and focused, so the work is more consistent. The reviewer catches parity bugs while the unit is still fresh, not at user testing three months later. In practice, avoided rework is often worth more than raw parallelism.

Review capacity matters just as much. In the model above, doubling porters from four to eight with a single reviewer saves nothing: the reviewer is the bottleneck. Adding reviewers is what moves the number.

“Adding manpower to a late software project makes it later.” — Fred Brooks, The Mythical Man-Month

Put together, a well-cut graph, several porters and an early independent review can turn a project measured in quarters into one measured in weeks. A badly cut graph with ten agents is just ten agents waiting on each other.

Five rules that make it work

“There is nothing so useless as doing efficiently that which should not be done at all.” — Peter Drucker

Inventory before you port. No porter starts until the unit graph exists. The graph decides the order, the parallelism and what "done" means.
One shared conventions file. Naming, state management, styling, error handling, folder layout. Every porter reads it, and the reviewer checks against it.
Small, verifiable units. A unit should be portable and reviewable on its own: one route, one component tree, one service. If a reviewer can't judge it in one pass, it's too big.
Maker and checker never share a context. The reviewer gets no access to the porter's reasoning, only the evidence.
Durable state outside the agents. Unit status, decisions and open findings live in files in the repo, not in any agent's memory. Any agent can be restarted without losing the project.

Which model for which agent

Running one flagship model for every role is the simplest setup, and the most wasteful. Roles need different things. The orchestrator and the inventory agent make the decisions everything else depends on, so they get the deepest reasoning: Fable 5.1 or Opus 5.5. Porters and the test writer do high-volume, well-specified work against a conventions file, which is what Sonnet 5.5 is good at. Checking whether a finding reproduces is a narrow yes-or-no task for a fast model like Haiku 5.5.

The reviewer is the one place to deliberately switch model families. If Claude models write the code, a reviewer such as OpenAI's GPT-6 Astra is less likely to share their blind spots, and the reverse holds too. Treat the chart as a starting point, not a rule. Swap models per role as you measure what each one gets right on your codebase.

In this model, tiering moves about 70% of calls to Sonnet 5.5 and Haiku 5.5, while every decision that shapes the project still goes through a top-tier model.

Where it goes wrong

Two porters editing the same shared file is the most common failure. Give shared modules (the router, the store, the design system) a single owner, and have porters ask for changes through the orchestrator.

The second is review becoming the bottleneck. If four porters each produce a unit an hour and the reviewer takes two hours per unit, you've built a queue, not a pipeline. Run more than one reviewer, or keep units small enough to review quickly.

The third is trusting green checks. A porter can make tests pass by changing the tests. Lock characterization tests once they're written, and treat any change to them as a finding in its own right.

Start with a pilot

Don't switch a whole program to multi-agent on day one. Pick one slice of the app, ten to twenty units with a mix of easy and awkward ones, and run the full setup on it: inventory, conventions file, porters, test writer and reviewer.

Track three numbers during the pilot: how many units pass review first time, how many reviewer findings turn out to be real, and how long units wait in the review queue. The first tells you whether your conventions and unit sizes work. The second tells you whether to trust the reviewer. The third tells you how many reviewers to run before you add porters.

Scale porters only after first-time pass rate and review wait time look healthy. Otherwise you are just making a longer queue.

How we run it

This is the structure behind MigrateX, our migration toolkit for moving Angular, AngularJS, Backbone and Ember apps to React. Each plugin runs a read-only inventory agent first, writes the plan and unit map into a .migration/ folder in the repo, then ports unit by unit with a separate parity-reviewer agent checking each one against its original before the old code is removed.

The agents do the volume. Engineers own the plan, the conventions and the final call on anything the reviewer flags. That split, more than any single model, is where the multiplier comes from.

Key takeaways

One agent doing everything stalls on context, works in series and grades its own work.
Use an orchestrator, an inventory agent, parallel porters, a test writer and an independent reviewer.
The speed-up depends on the unit graph and on avoided rework, not on how many agents you run.
Keep project state in the repo, give shared files one owner, and lock tests once they're written.

Originally published on the CobuildX blog.

Build a Tiny M3U Playlist Linter in Python (Zero Dependencies)

Marcus Hale — Tue, 03 Nov 2026 12:26:20 +0000

M3U files look simple. They're plain text: a header, then pairs of lines where one describes a stream and the next one points to it. Because they're so easy to edit by hand, they're also easy to break. One missing URL line shifts every entry below it, a duplicated link hides in line 4,000, and a typo like htps:// fails silently in most players.

In this post we'll build m3u_check.py, a small command-line linter that:

validates the basic M3U structure
reports entries with no URL (and URLs with no entry)
flags duplicate URLs and duplicate names
warns when tvg-id is missing, so you know EPG data won't match
optionally checks every URL with a concurrent HEAD request
returns a non-zero exit code so you can drop it into CI

No pip install needed. Everything comes from Python's standard library.

A 30-second refresher on the format

An extended M3U playlist looks like this:

#EXTM3U
#EXTINF:-1 tvg-id="news.one" tvg-logo="https://example.com/n1.png" group-title="News",News One
https://example.com/live/news1.m3u8

#EXTM3U must be on the first line.
#EXTINF: starts an entry. -1 is the duration (-1 means a live stream with no fixed length).
Everything between the duration and the last comma is a set of key="value" attributes. tvg-id links the entry to an EPG (TV guide) source, tvg-logo holds an icon, and group-title sets the category.
After the comma comes the display name.
The next non-comment line is the URL.

That "next line" rule is where most bugs come from, so it's the core of our parser.

The broken playlist we'll test with

Save this as sample.m3u. It hides four problems. Try to spot them before reading on:

#EXTM3U
#EXTINF:-1 tvg-id="news.one" tvg-logo="https://example.com/n1.png" group-title="News",News One
https://example.com/live/news1.m3u8
#EXTINF:-1 tvg-id="" group-title="Sports",Sports Two
https://example.com/live/sports2.m3u8
#EXTINF:-1 tvg-id="movies.three" group-title="Movies",Movies Three
https://example.com/live/news1.m3u8
#EXTINF:-1 tvg-id="docs.four" group-title="Docs",Docs Four
#EXTINF:-1 tvg-id="kids.five" group-title="Kids",Kids Five
htps://example.com/live/kids5.m3u8

Step 1: Parse entries with a tiny state machine

We read the file line by line and keep one variable, pending, which holds the #EXTINF entry that is still waiting for its URL.

If we see #EXTINF while something is already pending, the previous entry never got a URL.
If we see a URL with nothing pending, it's an orphan.
Otherwise we attach the URL and store the finished entry.

Attributes are pulled out with one regex: ([\w-]+)="([^"]*)". It matches tvg-id="news.one", group-title="News" and so on, and dict() turns the matches into a lookup table.

Two small details make the parser more forgiving in real life:

encoding="utf-8-sig" silently strips the BOM that some Windows editors add, which would otherwise break the #EXTM3U check.
We strip() every line, so stray \r characters and trailing spaces don't create fake URLs.

Step 2: Lint the parsed entries

Once we have clean entries, the checks are short:

URL scheme. urllib.parse.urlparse gives us the scheme. Anything other than http, https, rtmp, rtsp or udp is suspicious, and that's how we catch the htps:// typo.
Missing tvg-id. The entry still plays, but players can't match it to guide data, so it shows "No information".
Duplicates. collections.Counter over URLs and names finds them in one pass, even in very large files.

Step 3: Probe URLs concurrently (optional)

Checking 2,000 URLs one by one with a 5-second timeout could take hours. ThreadPoolExecutor lets us send many HEAD requests in parallel. Network calls spend most of their time waiting, so threads work well here despite the GIL.

We use HEAD instead of GET because we only want the status code, not the video data. A few servers reject HEAD with a 405. If you see a lot of those, switching the probe to a GET that reads only the first few bytes is a simple fix.

The full script

#!/usr/bin/env python3
"""m3u_check.py - lint an M3U/M3U8 playlist and (optionally) probe its URLs."""
import argparse
import re
import sys
from collections import Counter
from concurrent.futures import ThreadPoolExecutor
from urllib.parse import urlparse
from urllib.request import Request, urlopen

ATTR_RE = re.compile(r'([\w-]+)="([^"]*)"')


def parse(path):
    """Return (entries, problems). Each entry is a dict with line, name, attrs, url."""
    entries, problems = [], []
    with open(path, encoding="utf-8-sig", errors="replace") as f:
        lines = [l.rstrip("\r\n") for l in f]

    if not lines or not lines[0].strip().startswith("#EXTM3U"):
        problems.append((1, "missing #EXTM3U header on line 1"))

    pending = None
    for n, raw in enumerate(lines, start=1):
        line = raw.strip()
        if not line or (line.startswith("#") and not line.startswith("#EXTINF")):
            continue  # blank lines, header and other directives
        if line.startswith("#EXTINF"):
            if pending:
                problems.append((pending["line"], f'"{pending["name"]}" has no URL'))
            meta, _, name = line.partition(",")
            pending = {"line": n, "name": name.strip() or "(no name)",
                       "attrs": dict(ATTR_RE.findall(meta))}
        else:  # a URL line
            if pending is None:
                problems.append((n, "URL without an #EXTINF line above it"))
                pending = {"line": n, "name": "(no name)", "attrs": {}}
            pending["url"] = line
            entries.append(pending)
            pending = None
    if pending:
        problems.append((pending["line"], f'"{pending["name"]}" has no URL'))
    return entries, problems


def lint(entries):
    problems = []
    for e in entries:
        scheme = urlparse(e["url"]).scheme
        if scheme not in ("http", "https", "rtmp", "rtsp", "udp"):
            problems.append((e["line"], f'"{e["name"]}" has an odd URL: {e["url"]}'))
        if not e["attrs"].get("tvg-id"):
            problems.append((e["line"], f'"{e["name"]}" has no tvg-id (EPG will not match)'))
    for url, count in Counter(e["url"] for e in entries).items():
        if count > 1:
            problems.append((0, f"duplicate URL x{count}: {url}"))
    for name, count in Counter(e["name"] for e in entries).items():
        if count > 1:
            problems.append((0, f'duplicate name x{count}: "{name}"'))
    return problems


def probe(entry, timeout):
    url = entry["url"]
    if not url.startswith(("http://", "https://")):
        return entry, "skipped (not http)"
    try:
        req = Request(url, method="HEAD", headers={"User-Agent": "m3u-check/1.0"})
        with urlopen(req, timeout=timeout) as resp:
            return entry, f"HTTP {resp.status}"
    except Exception as exc:  # timeouts, DNS errors, 4xx/5xx
        return entry, f"FAIL ({exc.__class__.__name__}: {exc})"


def main():
    ap = argparse.ArgumentParser(description="Lint an M3U playlist.")
    ap.add_argument("playlist")
    ap.add_argument("--check-urls", action="store_true", help="send a HEAD request to each http(s) URL")
    ap.add_argument("--workers", type=int, default=10)
    ap.add_argument("--timeout", type=float, default=5.0)
    args = ap.parse_args()

    entries, problems = parse(args.playlist)
    problems += lint(entries)

    groups = Counter(e["attrs"].get("group-title", "(none)") for e in entries)
    print(f"{len(entries)} entries in {len(groups)} groups")
    for group, count in groups.most_common():
        print(f"  {group}: {count}")

    print(f"\n{len(problems)} problem(s)")
    for line, msg in sorted(problems):
        print(f"  line {line}: {msg}" if line else f"  {msg}")

    if args.check_urls:
        print("\nURL check")
        with ThreadPoolExecutor(max_workers=args.workers) as pool:
            for entry, result in pool.map(lambda e: probe(e, args.timeout), entries):
                print(f"  {entry['name']}: {result}")

    sys.exit(1 if problems else 0)


if __name__ == "__main__":
    main()

Running it

python3 m3u_check.py sample.m3u

4 entries in 4 groups
  News: 1
  Sports: 1
  Movies: 1
  Kids: 1

4 problem(s)
  duplicate URL x2: https://example.com/live/news1.m3u8
  line 4: "Sports Two" has no tvg-id (EPG will not match)
  line 8: "Docs Four" has no URL
  line 9: "Kids Five" has an odd URL: htps://example.com/live/kids5.m3u8

All four hidden problems are caught. Notice that "Docs Four" is reported instead of silently swallowing the next entry's URL, which is exactly what many players do.

To also test the links:

python3 m3u_check.py my_playlist.m3u --check-urls --workers 20 --timeout 3

Using it in CI

The script exits with 1 when it finds a problem, so it works as a guard in any pipeline. A minimal GitHub Actions step:

- name: Lint playlists
  run: |
    for f in playlists/*.m3u; do
      python3 m3u_check.py "$f"
    done

Leave --check-urls out of CI unless you control the servers. Remote streams go up and down for reasons unrelated to your change, and flaky builds teach people to ignore failures.

Ideas to extend it

--fix mode: drop duplicates and orphan lines, then write a cleaned file.
EPG cross-check: load an XMLTV guide and report tvg-id values that don't exist in it.
JSON output: add --json so other tools can consume the report.
Group filter: --group Sports to check only one category.

Wrapping up

M3U is one of those formats that's "just text" until it isn't. A hundred lines of standard-library Python turns silent playback failures into clear, line-numbered errors you can fix in seconds. A state machine for parsing, Counter for duplicates and a thread pool for I/O are patterns you'll reuse well beyond playlists.

What would you add to it? Let me know in the comments.

This article was written with AI assistance. The code was run and the output above was verified before publishing.

Prompting Image Models for AI Headshots That Keep Your Likeness

Mona Lisa Studio — Tue, 03 Nov 2026 12:25:40 +0000

If you have tried turning a casual photo into a professional headshot with an image-editing model such as Gemini's image model (often called Nano Banana), you have probably seen the failure mode: the result looks polished, but it no longer quite looks like the person. The jaw is a little narrower, the skin is airbrushed, the hairline is fuller, and the person looks five years younger.

This post is a practical guide to avoiding that. It covers how to structure the prompt, which constraints do the most to preserve facial features, what to check in the input photo, and a simple checklist for evaluating the output. Nothing here depends on a specific tool; it applies to any model that takes a reference image plus a text instruction.

Why likeness drifts

An image-to-image model treats your photo as a reference, not as a fixed asset. Everything in the frame is open to reinterpretation unless the prompt says otherwise. For headshots, the model's idea of "professional" tends to lean toward retouched studio photography, so small edits to the face are a common side effect of asking for a "professional headshot".

The common drift patterns are:

Skin smoothing: pores, freckles and fine lines disappear.
Face reshaping: slimmer jaw, larger eyes, more symmetrical features.
De-ageing: softened under-eye lines and wrinkles.
Skin tone shifts: brighter studio lighting quietly lightens the skin.
Hairline tidying: receding or uneven hairlines get "fixed".

Each change on its own can be subtle. Together, they produce someone who looks like a relative.

A prompt structure that works

A useful pattern is to split the prompt into four blocks, in this order:

Reference role: tell the model what the image is.
Preserve: list what must not change.
Change: list what should change.
Prohibit: explicit negatives for the drift patterns above.

Putting the preserve block before the style words matters. If the prompt opens with "professional studio headshot, flawless lighting", the model has already been pulled toward the retouched look before it reads your constraints.

Here is a template:

[Reference]
The uploaded photo is the reference and shows the person to portray.

[Preserve]
Keep the person exactly recognizable: face shape, features, eye shape,
age, skin tone and hairline stay as in the photo. Keep real skin texture
and pores. The number of people stays the same.

[Change]
Clothing becomes a navy blazer over a white shirt. Background becomes a
softly blurred light-grey wall. Head-and-shoulders framing, facing the
camera, even soft studio light, crisp focus on the eyes, natural
friendly expression.

[Prohibit]
Do not smooth the skin, slim the face, lighten or change the skin tone,
or make the person look younger or older. Do not add text, logos or
watermarks.

The bracketed labels are just for readability; you can remove them before sending.

Constraints that do the most work

In practice, a few specific instructions carry most of the weight:

Name features, not just "the face". "Keep the face the same" is vague. "Face shape, eye shape, nose, jawline, hairline" gives the model concrete targets.
Say "real skin texture and pores". Without it, smoothing is the default for anything described as professional.
Rule out skin tone changes explicitly. Lighting instructions can shift skin tone as a side effect. A direct "do not lighten or change the skin tone" line counters that.
Pin the age. "Do not make the person look younger or older" stops gradual de-ageing.
Add personal specifics. If someone has a scar, a mole, freckles or a gap in their teeth, name it: "keep the small scar above the left eyebrow". Specific constraints are followed more reliably than general ones.
Change one thing per pass when iterating. If the first result needs a different jacket, ask only for the jacket in the next edit, and use the previous output as the new reference. Stacking several changes in one follow-up prompt invites drift.

If you want to see a full working example of this structure, the professional headshot prompt on Mona Lisa Studio is published on the page, including its preserve and no-smoothing lines, and is a reasonable starting point to adapt.

Input photo checklist

The prompt protects likeness, but the photo supplies it. Before generating, check:

[ ] Sharp focus on the face, especially the eyes.
[ ] Front-facing or slightly turned, looking at the lens.
[ ] Head and shoulders in frame, so the model does not have to invent your build or where the new outfit sits.
[ ] Even daylight, such as a window to one side. Avoid harsh overhead light that hides eye shape.
[ ] No beauty filters. A filtered photo has already altered the face before the model sees it.
[ ] One person only, cropped if necessary, so faces do not blend.
[ ] Recent photo, so the result matches how you look now.

Evaluation checklist

Do not judge the output at thumbnail size. Open it full screen next to the original and go through:

[ ] Eye spacing and eye shape match.
[ ] Nose and jawline match.
[ ] Hairline and hair colour match.
[ ] Skin texture is still visible; it is not plastic.
[ ] Skin tone matches the original under comparable light.
[ ] Apparent age is unchanged.
[ ] Personal details (scars, moles, freckles) are still there.
[ ] Hands, if visible, have five natural fingers.
[ ] No stray text, logos or artifacts.

A quick sanity test: show the result to someone who knows the person, without explanation, and ask whether anything looks off. If something has drifted, add a targeted constraint for that feature and regenerate, rather than rewriting the whole prompt.

Scope and ethics

AI headshots are fine for professional profiles, resumes and team pages. They are not suitable for passports, visas or official ID, which usually require unedited photos. Changing clothing and background is a reasonable presentation choice; changing someone's face is a misrepresentation. And only generate headshots of yourself, or of people who have explicitly agreed.

Summary

Structure the prompt as reference, preserve, change, prohibit.
Name specific features and rule out smoothing, reshaping, de-ageing and skin tone shifts.
Start from a sharp, unfiltered, front-facing photo with shoulders in frame.
Iterate one change at a time.
Evaluate at full size against the original.

Disclosure: I'm part of the Mona Lisa Studio team; this post was drafted with AI assistance and edited by me.

Diffing two PDFs in the browser: PDFs don't have lines, so you have to rebuild them

Kevin Carne — Tue, 03 Nov 2026 12:25:36 +0000

``A common request for a PDF tool: "they sent the contract back with a few small changes, what actually changed?" I wanted to answer that without uploading anyone's contract to a server, so the comparison runs entirely in the browser tab.

The diff part is easy: jsdiff does it in one call. The hard part is getting text you can diff out of a PDF, because a PDF has no idea what a "line" is.

What a PDF actually stores

A PDF page isn't a document with paragraphs. It's a list of drawing instructions: "move to (72, 700), draw these glyphs, move to (210, 700), draw these glyphs". Text can be drawn in any order, split anywhere, and positioned anywhere.

pdf.js gives you that as getTextContent(): a flat list of text items, each with a string and a transform matrix. The last two values of the matrix, transform[4] and transform[5], are the item's x and y position on the page.

So a single visual line like

`plaintext Notice period: 30 days `

might come back as three items ("Notice period:", "30", "days"), all with the same y.

Rebuilding lines

My first version groups items by their (rounded) y coordinate, then sorts the groups top to bottom. PDF coordinates start at the bottom-left, so "top to bottom" means sorting y descending:

`ts
export async function getPageLines(pdf: PDFDocumentProxy, pageNumber: number): Promise {
const page = await pdf.getPage(pageNumber);
const content = await page.getTextContent();

const lines = new Map();
for (const item of content.items) {
if (!("str" in item)) continue; // skip marked-content items
const y = Math.round(item.transform[5]);
const bucket = lines.get(y) ?? [];
bucket.push(item.str);
lines.set(y, bucket);
}

const sortedYs = Array.from(lines.keys()).sort((a, b) => b - a);
return sortedYs
.map((y) => lines.get(y)!.join(" ").trim())
.filter((line) => line.length > 0);
}
`

This same helper turned out to be useful well beyond comparing: PDF to Word, PDF to HTML, PDF to Excel and PDF to EPUB all start from "give me the lines of each page".

Diffing

With lines per page, the comparison itself is short. Flatten both documents into one string each and let jsdiff do a line diff:

`ts
import { diffLines, type Change } from "diff";

export async function comparePdfs(fileA: File, fileB: File): Promise {
const [pagesA, pagesB] = await Promise.all([getAllPageLines(fileA), getAllPageLines(fileB)]);
const textA = pagesA.flat().join("\n");
const textB = pagesB.flat().join("\n");
return diffLines(textA, textB);
}
`

diffLines returns an array of Change objects with added / removed flags, which map directly onto green and red blocks in the UI. Both PDFs are parsed in parallel, and nothing leaves the tab.

pdf.js itself has to be loaded lazily in Next.js (it touches DOMMatrix at import time, which breaks server prerendering), so getPdfjs() does a dynamic import("pdfjs-dist") the first time it's needed.

Where the naive version gets it wrong

This works well for the main use case, contracts and letters that went through a small edit. But "group by y" has sharp edges, and I'd rather list them than pretend they don't exist:

Items on a line aren't sorted by x. I join them in the order the PDF drew them. Most generators draw left to right, but not all. Sorting each bucket by transform[4] is the obvious fix.
Exact y matching is fragile. Superscripts, mixed fonts, or a baseline off by 0.6pt can split one visual line into two. Bucketing with a tolerance (say, a fraction of the font height) instead of Math.round would be more robust.
Two-column layouts merge. Left and right columns at the same y become one "line". You'd need to detect columns by x gaps first.
Re-wrapping looks like a total rewrite. If one word is added early in a paragraph and the text re-flows, every following line in the paragraph changes. A line diff reports the whole paragraph as changed. Running a word diff (diffWords) inside changed blocks would show the actual edit.
Headers, footers and page numbers add noise, especially if pagination shifts by a page.
Scanned PDFs have no text at all. They're images, so there's nothing to diff without OCR first.
It's a text diff, not a visual diff. A moved logo or a changed font won't show up.

For "did they change the notice period?", the current version does the job. For a 200-page reflowed manual, you'd want 1, 2 and 4 at least.

Takeaways

A PDF stores positioned glyphs, not lines or paragraphs. Any text feature starts by reconstructing structure from coordinates.
PDF y coordinates grow upwards, so reading order is y descending.
The diff algorithm is the easy part; the quality of the comparison depends almost entirely on how you rebuild the text.

If you want to try it, the tool is at Handybin Compare PDFs. It runs in your browser, so you can open DevTools' Network tab and confirm the files aren't uploaded.

I'd love to hear how others have handled line reconstruction, especially multi-column layouts.

Trust, but Verify: How We Audited OpenAI's Lean 4 Math Proofs with a Zero-Dependency Sidecar

liao-zhizhi — Tue, 03 Nov 2026 12:24:22 +0000

Recently, OpenAI released a repository of formal proofs (ten-proofs) demonstrating AI's capability to solve complex mathematical problems using Lean 4.

When an AI lab drops thousands of lines of formal code claiming "we solved it," how does the rest of the world verify it? Currently, we rely on a handful of expert mathematicians who don't have the time to read 37,000 lines of code. Or, we rely on another LLM to "judge" it—which just hallucinates a thumbs-up.

I wanted to see if an automated, physical-witness approach could do better. So, I used my open-source project, harness-audit-sidecar, to audit OpenAI's proofs locally.

Here is what happened.

The Setup: No Hallucinations Allowed

LLM-as-a-Judge fails here. A compiler asks "does this elaborate?", but an auditor must ask "is there a physical witness?".

To create a physical witness, I didn't just scan the text. I pulled the 7.2 GB Mathlib cache, compiled 8,687 jobs locally, and ran our LeanProofAuditor.

The Results: 11 PASS, 12 FAIL

The audit took about 40 minutes. Here are the hard facts:

The 11 Main Proof Files achieved a genuine PASS.
All theorems elaborated successfully. Zero smuggled custom axioms. They rely only on the three standard Lean axioms (Classical.choice, propext, Quot.sound). OpenAI's core mathematical proofs are solid.
12 Files returned FAIL (42 placeholders found).
Wait, did OpenAI cheat? No. These 12 files are located in ComparatorChallenges/. They are templates intentionally left with sorry (Lean's unproved placeholder) for human contestants to fill out. Our auditor simply reported the physical fact: these files are not complete proofs.

Why This Matters

If an LLM judged this repository, it would read the comments, see the word "solved", and output a confident PASS for the whole folder—completely ignoring the 42 sorry placeholders.

Our sidecar enforces a four-valued verdict: PASS, FAIL, INVALID, NOT RUN.

It didn't just guess.
It didn't accept exit code 0 as proof (because a file with sorry can compile cleanly).
It inspected the artifact's dependency graph via #print axioms to expose the truth.

The Four-Valued Immune System

This audit is just one application of the harness-audit-sidecar. Originally, it was built to catch AI agents lying about writing files or executing shell commands.

We introduced:

Conditional Immunity: Tier 1 (cheap stat checks) and Tier 2 (full Git diffs). Two consecutive FAILs trigger an "inflammation storm" that blocks writes.
Membrane Gateway: Agents cannot define their own success criteria. They must register expectations before execution.
Agent Metabolism OS: Regulates LLM API costs and fast/slow thinking beats.

A Tool that Audits Itself

During development, our own auditor caught itself producing false completions. We log these in ERRATA.md. For example, we initially failed a legitimate opaque definition because we confused it with an axiom. We corrected it and wrote a regression test.

An audit tool that only audits others is a decoration. You can read our ERRATA to see how the system caught its own bugs.

Resources:

Healthcare AI and the Problem of Downstream Workload

Onyedikachi Onwurah — Tue, 03 Nov 2026 12:24:00 +0000

Healthcare AI is often evaluated by measuring the work it automates. However, an important question is frequently overlooked:

Does the system reduce workload, or does it transfer that workload to another team?

Consider an AI triage system that identifies patients requiring additional investigations. The triage department may process patients faster, but the system could generate more laboratory requests, specialist referrals, and administrative tasks.

The local improvement may conceal a wider operational problem.

Understanding workload displacement

Workload displacement occurs when automation reduces tasks in one part of a workflow but creates additional responsibilities elsewhere.

This can happen through automated referrals, alert generation, clinical review requests, medication reconciliation, documentation, and appointment coordination.

The individual actions may be appropriate, but their combined operational impact can exceed the capacity of receiving teams.

Why agentic AI makes this more important

Agentic AI can initiate multiple actions across connected services. Without appropriate workload awareness, an agent may generate demand faster than healthcare teams can process it.

For example, an agent could identify patients requiring further investigation, request tests, initiate referrals, and generate follow-up tasks.

A safe implementation needs to consider who receives each task, whether the receiving team is authorised and equipped to handle it, and what happens when capacity is unavailable.

What should healthcare organisations measure?

Evaluation should include task volumes across departments, staff time, referral completion, waiting times, unresolved requests, workload concentration, and delays created by additional demand.

Baseline measurements should be compared with post-deployment outcomes. Teams receiving AI-generated work should participate in the evaluation rather than being treated as invisible parts of the workflow.

A better design principle

Healthcare AI should optimise connected workflows rather than isolated tasks.

This requires workflow mapping, downstream impact assessment, capacity-aware automation, appropriate prioritisation, and human escalation when demand exceeds available resources.

The objective is not simply to automate more work. It is to make healthcare delivery more sustainable.

If you are building or implementing healthcare AI, include downstream workload in your system requirements and evaluation metrics.

The error is one line. Investigate the five lines around it.

Dany Cohen — Tue, 03 Nov 2026 12:23:31 +0000

An error line tells you that something failed. The useful clue may be three lines earlier: a retry, a connection message, or a request that never reached the next stage.

This walkthrough uses Flik to keep surrounding events visible while narrowing a log file. It works locally on macOS and Linux. The sample is synthetic, so you can reproduce the interaction without a running service.

1. Open a small example

Download Flik from the project page and create this small synthetic sample:

cat > flik-demo.log <<'LOG'
2026-01-15T09:00:00Z INFO service=demo-api request_id=req-demo-9 request accepted
2026-01-15T09:01:00Z WARN service=demo-api request_id=req-demo-9 connection pool exhausted
2026-01-15T09:02:00Z ERROR service=demo-api request_id=req-demo-9 request timeout
2026-01-15T09:03:00Z INFO service=demo-api request_id=req-demo-9 retry scheduled
2026-01-15T10:00:00Z INFO service=demo-api request_id=req-demo-10 request accepted
2026-01-15T10:01:00Z WARN service=demo-api request_id=req-demo-10 connection pool exhausted
2026-01-15T10:02:00Z ERROR service=demo-api request_id=req-demo-10 request timeout
2026-01-15T10:03:00Z INFO service=demo-api request_id=req-demo-10 retry scheduled
LOG
flik flik-demo.log

Files open at the end with live following enabled. Press g if you want to start at the beginning.

2. Search for the error, including its neighbours

In the main view, press / to open search. Enter the following smart-find expression, then press Enter:

//3,2:error

This retains three original lines before each match and two after it. Context lines are shown alongside the match, in the original order. Overlapping context windows are merged instead of duplicating the same lines.

Read those neighbouring events before adding another condition. Context can change the question from “which line failed?” to “what happened immediately before this request failed?”

3. Narrow one condition at a time

Press x to undo the latest filter. Press 3 to add an include filter, or 8 for an exclude filter. For example, include timeout, then exclude cache. Each rule is a separate step in the stack.

If the result becomes too narrow, x removes only the most recent rule. Ctrl+F opens the filter stack so you can inspect what is active. That matters when an empty view means “my filters excluded it”, rather than “the event never happened”.

4. Recover a wider window

Select a result and press Ctrl+G to inspect its original context. Use n and p inside that view to move between matches; Escape returns to the file. The command palette also accepts context 20 when you want 20 original lines before and after a selected event.

For a live stream, the starting point can be:

docker logs -f demo-api | flik -

The service name in that example needs to match your own container. Begin with the downloadable file if you do not have one running.

What this does—and what it cannot establish

The useful result is an inspectable sequence of events. Adjacent lines alone do not prove a cause: requests can interleave, clocks can differ, and output can be buffered. Check request identifiers and timestamps before drawing a conclusion.

Flik covers interactive filtering, context and following; keep jq for arbitrary JSON transformations and scripted pipelines. The goal is to make a manual investigation easier to inspect and revise.

Watch the short demonstration, then repeat the search on the sample:

https://flik.spedo.dev?utm_source=dev-to&utm_medium=social&utm_campaign=flik-launch&utm_content=post-21

json.dumps Writes NaN by Default: 31 LLM Reports JSON.parse Rejected

jidonglab — Tue, 03 Nov 2026 12:22:33 +0000

Nine people emailed me the same screenshot: a spinner and the line "Your report is being prepared." One of them had been looking at it for 51 hours.

The report was done. It had been done since about 40 seconds after their session ended. It was sitting in object storage as a perfectly normal-looking file. The problem was three characters inside it: NaN. Python json.dumps writes NaN by default, the browser's JSON.parse refuses to read it, and my pipeline had no step anywhere that cared about the difference.

TL;DR

Python's json.dumps has allow_nan=True by default, so float('nan') becomes a bare NaN token. That is not valid JSON.
Python's own json.loads reads NaN back without complaint, so round-trip tests pass. JavaScript's JSON.parse throws a SyntaxError.
My NaN came from np.nanmean over a rubric category where the LLM scorer returned null for every answer. An all-NaN slice returns NaN and only emits a RuntimeWarning.
31 of 1,940 reports (1.6%) over 16 days were unreadable. 26 of the 31 came from one interviewer style.
Fix: score fields as Optional[float] with allow_inf_nan=False in Pydantic, plus json.dumps(..., allow_nan=False) as a tripwire at every write.

What broke?

The system is Preterview, an interview practice platform I run (full disclosure: I built it, preterview.com/en). A candidate does a voice interview with one of three interviewer styles, an LLM scores each answer against a rubric, and a worker assembles everything into a written report.

The report pipeline looks like this:

The LLM scores each answer per rubric category (communication, technical depth, structure, and so on) and returns structured JSON.
A Python worker aggregates scores per category.
The worker writes report.json to object storage.
The frontend fetches that file directly and renders it.

Step 4 is where 31 reports died. The fetch succeeded, JSON.parse threw, my error handler caught it, and the error handler's fallback was "show the preparing state and poll again." Forever. I had built a very polite infinite loop.

Where did the NaN come from?

The NaN came from averaging a category that had no scores at all. The scorer prompt allows the model to say "I can't assess this category from this answer" by returning null. That's deliberate. I'd rather get a null than a confident 6/10 for system design on an answer about a team conflict.

The aggregation code turned those nulls into NaN on purpose so they'd be skipped:

import numpy as np

def category_mean(scores: list[float | None]) -> float:
    arr = np.array([np.nan if s is None else s for s in scores], dtype=float)
    return float(np.nanmean(arr))

np.nanmean ignores NaN values. That's what I wanted. What I hadn't thought through is what it does when every value is NaN:

>>> np.nanmean([np.nan, np.nan, np.nan])
RuntimeWarning: Mean of empty slice
nan

No exception. A warning and a NaN.

When does every answer in a category get null? When the interviewer never asks a question that touches that category. One of my three interviewer styles is a conversational, culture-fit style. It often runs a whole session without a single technical question. So the "technical depth" category came back all-null, nanmean returned NaN, and the NaN flowed downstream. That's why 26 of the 31 broken reports came from that one style.

Why does Python json.dumps write NaN by default?

Because allow_nan defaults to True. The Python docs are upfront about it: with allow_nan=True, out-of-range floats are written as their JavaScript equivalents (NaN, Infinity, -Infinity), and the docs note this is not strictly JSON compliant. RFC 8259 has no representation for NaN at all.

>>> import json
>>> json.dumps({"technical_depth": float("nan")})
'{"technical_depth": NaN}'

The part that let this survive testing: Python reads it back just fine.

>>> json.loads('{"technical_depth": NaN}')
{'technical_depth': nan}

My test suite had a round-trip test: build a report, dump it, load it, compare. Python on both ends, so it passed. The only consumer that enforced the actual JSON spec was the browser:

JSON.parse('{"technical_depth": NaN}')
// SyntaxError: Unexpected token 'N'

Why didn't my logs show anything?

Two reasons, and both are defaults.

First, Python's default warnings filter shows a given warning once per code location, not once per occurrence. My workers are long-running processes. The first all-null category after a deploy printed Mean of empty slice to stderr. The next 30 printed nothing. Across 16 days I found 11 instances of that warning in the logs, one per worker start, sitting between thousands of normal lines. Nothing about it said "a user's report is broken."

Second, the worker considered the job successful. json.dumps returned a string, the upload returned 200, the job was marked done. From the backend's point of view, every one of the 1,940 reports succeeded.

There was one more trap I tripped over while debugging. My first attempt to display the score did this:

>>> round(float("nan"))
ValueError: cannot convert float NaN to integer

But round(float("nan"), 1) quietly returns nan. The report used one decimal place, so this path never raised either. Every layer had a way to pass NaN along without anyone noticing.

Which serializers accept NaN and which reject it?

This is the table I wish I'd had. Same input, float("nan"), very different behavior:

Where	What happens
`json.dumps` (stdlib)	Writes `NaN`. Invalid JSON, no error
`json.dumps(..., allow_nan=False)`	Raises `ValueError`
`json.loads` (stdlib)	Accepts `NaN`, returns `nan`
Starlette / FastAPI `JSONResponse`	Raises `ValueError` (it uses `allow_nan=False`)
Pydantic v2 `model_dump_json()`	Writes `null` by default (`ser_json_inf_nan`)
orjson	Writes `null`
Postgres `jsonb`	Rejects the input as invalid JSON
Browser `JSON.parse`	Throws `SyntaxError`

The irony: if this report had gone through my FastAPI endpoint, it would have been a loud 500 on day one. If I'd stored it in a jsonb column, the insert would have failed. I chose to write it straight to object storage with the stdlib serializer, which happens to be the most permissive path in the whole table.

Also notice that "writes null" is not automatically safe. Pydantic and orjson would have produced valid JSON, but the frontend would then have rendered "Technical depth: null" or crashed on null.toFixed(1). Valid syntax, wrong meaning.

How do you stop NaN from reaching your JSON?

Make "not assessed" a real value instead of a float that pretends to be a number. Then make every serializer refuse NaN so the next mistake fails at write time, not in a user's browser.

The model change:

from pydantic import BaseModel, Field

class CategoryScore(BaseModel):
    category: str
    mean: float | None = Field(default=None, allow_inf_nan=False)
    assessed_answers: int

And the aggregation stops producing NaN in the first place:

def category_mean(scores: list[float | None]) -> float | None:
    vals = [s for s in scores if s is not None]
    return sum(vals) / len(vals) if vals else None

No numpy, no warning, and the empty case is a branch you can read instead of a side effect you have to remember.

Then the tripwire, at the single function that writes report files:

payload = json.dumps(report.model_dump(), allow_nan=False)

If anything upstream ever sneaks a NaN or an Infinity back in, this raises, the job fails, and my alerting sees a failed job instead of a successful one.

Two smaller changes:

Tests run with warnings as errors. filterwarnings = error::RuntimeWarning in pytest config. The "Mean of empty slice" warning would have failed CI on the first test with a skipped category, and I had one. It just never asserted anything about the output.
The frontend stops polling on parse errors. A SyntaxError is not "still preparing." It now shows an error state and pings me.

The frontend change was really the bigger lesson. The NaN was a bug. The spinner turned that bug into 51 hours of a user waiting for something that was never going to arrive.

How did I recover the 31 broken reports?

I re-ran aggregation only. The raw per-answer LLM scores were stored separately from the assembled report, so I didn't need a single new model call. All 31 reports rebuilt and rendered in under two minutes, with "Technical depth: not assessed in this session" where the NaN used to be. I emailed the nine people who'd written in, plus the other 22 who'd quietly given up.

If I'd only stored the final report, I'd have had to re-score 31 sessions and explain why their scores changed. Keep your raw LLM outputs. You will need to re-derive something from them eventually.

Does Python json.dumps write NaN by default?

Yes. Python's json.dumps uses allow_nan=True by default, so float('nan') is written as a bare NaN token, which is not valid JSON under RFC 8259. Python's json.loads accepts it back, so Python-only tests won't catch it, but JavaScript's JSON.parse, Postgres jsonb, and most strict parsers will reject the file. Pass allow_nan=False to make serialization raise a ValueError instead, and represent missing numeric values as None/null explicitly, especially for LLM-generated scores where "couldn't assess" is a legitimate answer that averaging code will happily turn into NaN.

Written by the developer behind Preterview, an interview prep platform.

CVE-2026-108452 exposure and asset inventory: what 163,243 SharePoint fingerprints mean

StarkMan — Tue, 03 Nov 2026 12:21:04 +0000

CVE-2026-108452 exposure and asset inventory: what 163,243 SharePoint fingerprints mean

External search can make a vulnerability feel larger than the evidence supports. ZoomEye returned 163,243 matches for app="Microsoft SharePoint" when the query was checked on November 3, 2026. That number is useful for attack-surface discovery, but it is not a count of 163,243 vulnerable servers. The CVE-specific filter returned 0, and the product query does not reveal which build or configuration each asset runs.

The vulnerability

CVE-2026-108452 is a Microsoft SharePoint path traversal issue classified as CWE-22. Microsoft states that an authorized attacker can use it to execute code over the network. The CVSS 3.1 score is 8.8, with low privileges required, low attack complexity, and no user interaction. Confidentiality and integrity impacts are High.

The affected product is Microsoft SharePoint Server Subscription Edition on x64 systems. The vulnerable range starts at 16.0.0 and ends before 16.0.20326.20190. KB5002927, released October 13, 2026, updates the product to build 16.0.20326.20190.

Reading the search results

app="Microsoft SharePoint" is a product-fingerprint query. A match means ZoomEye observed evidence that looks like SharePoint under the chosen search scope. It does not verify the edition, installed cumulative update, application pool identity, workflow configuration, or whether a low-privileged account can reach the vulnerable path.

The separate filter vul.cve="CVE-2026-108452" returned 0. A zero CVE-index result means the CVE was not associated with any matching asset in that query at that time. It does not prove that no vulnerable systems exist. The CVE may be too new, the asset record may not identify the build, or the search engine may not index the relevant version detail.

The correct interpretation is therefore a two-layer statement. First, the broad product population is measurable at 163,243 fingerprint matches. Second, the confirmed vulnerable population is unknown from this evidence alone.

Turning Exposure into an inventory task

Teams should export the public-facing candidate set into an internal review queue. For each host that belongs to the organization, verify the product edition, server build, farm role, and patch history. A SharePoint front end, application server, and workflow component may have different install states.

The fixed build is concrete: 16.0.20326.20190. Microsoft's support guidance also calls for KB5002799 before KB5002927 when SharePoint Workflow Manager is present. A classic Workflow Manager installation requires the stated debug flag step. These dependencies belong in the patch plan because a partially updated farm can create false confidence.

Prioritization

Prioritize systems that are both externally reachable and below the fixed build. Increase priority when the farm accepts partner, contractor, guest, or delegated application access. The vendor says an authorized attacker is required, so the privilege boundary is part of the exposure model. A server reachable only by tightly managed administrators has a different risk profile from a collaboration farm with broad low-privileged access.

Use asset ownership and business function as decision inputs. A customer-facing SharePoint portal, an extranet, and an isolated internal archive may all match the product fingerprint, but they do not carry the same consequence.

What not to do

Do not publish the broad product count as a victim count. Do not infer patch state from a title, favicon, or HTTP header. Do not close an asset review because the CVE filter returned 0. The filter is a useful index signal, not a substitute for build inspection.

Remediation

Apply KB5002927 according to Microsoft's deployment instructions and verify that every farm node reports the fixed build. Until completion, limit untrusted network access to SharePoint management and authoring surfaces and review low-privileged or delegated identities that can reach the farm. These steps reduce exposure, but the vendor update is the substantive remediation identified in the sources.

References

Microsoft Security Update Guide, CVE-2026-108452
Microsoft Support, KB5002927
Microsoft Learn, SharePoint updates
CVE Program, CVE-2026-108452

Nine Keys Can SSH Into Production. Five Owners Don't Work Here Anymore.

Dhruv Malaviya — Tue, 03 Nov 2026 12:20:41 +0000

I cat'd authorized_keys on our oldest box for a boring reason and kept reading: the 2023 contractor, a dead CI pipeline, two ex-engineers, an 'ops-temp' nobody can attribute. The sweep, the smoke alarm, the one-week evidence trick, and keys-that-expire culture.

I opened the file for a boring reason — a connectivity weirdness — and then just kept reading. ~/.ssh/authorized_keys on our oldest production box: nine lines, nine doors.

Matching comments to memory: the 2023 migration contractor (still there), the CI pipeline decommissioned last spring (still there), two engineers who left — one warmly, one not (still there), a key commented ops-temp that nobody including our ops lead can attribute to a human, and one line with no comment at all, which is its own small horror genre.

Four keys belonged to current humans who still needed access. Five were sediment. The door remembered everyone, because nobody had ever asked it to forget.

authorized_keys is an attendance sheet
The oldest access-control file in our profession is a plain-text list on disk: appended to for a decade, reviewed never. Every line was added on someone's worst day — incident, deadline, "just for tonight, add my key." Keys arrive during emergencies; emergencies don't do cleanup; departures miss the file entirely, because it isn't in any system. It's wallpaper. And unlike a password, a key never expires out of embarrassment — it waits for its laptop to be sold, lost, or inherited.

The sweep

#!/bin/bash
# keys-audit.sh — every authorized_keys on every box, with its "who/why" comments
for host in $(cat hosts.txt); do
  ssh "$host" 'for f in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do
    [ -f "$f" ] && {
      echo "== $HOSTNAME $f — $(grep -cvE "^[[:space:]]*$|^[[:space:]]*#" "$f") keys"
      grep -vE "^[[:space:]]*$|^[[:space:]]*#" "$f" | awk "{print \"   \", \$NF}"
    }; done'
done | tee keys-audit.txt
# then the human step: diff the comment column against the current roster.
# every line that doesn't match a living owner is sediment.

Ours diffed to five. Yours will too; that number is your real access list.

The four changes that stuck

Keys got names and reasons. One comment format, enforced at add-time:

echo "$(cat ana.pub) ana@laptop — incident-4821 — 2026-11-03" \
  | sudo tee -a /home/ubuntu/.ssh/authorized_keys
# a key that can't state its reason in six words doesn't get added.
# 'ops-temp' failed this test immediately and was deleted with a small ceremony.

Offboarding gained a server step. Badge, laptop, SSO — and this, on every box:

grep -rn 'ana@' /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys

The step exists because the 2023 contractor taught us it doesn't happen by osmosis.

The file got a smoke alarm. Any change pages someone — not blocks, pages; additions are sometimes legitimate at 2 a.m., silent additions never are:

# auditd: watch writes and attributes to authorized_keys on every box
echo '-w /root/.ssh/authorized_keys -p wa -k ssh_sediment' | sudo tee /etc/audit/rules.d/ssh.rules
sudo augenrules --load
# wire the audit event to your pager; our worst file became our best-monitored one

Deletion ran on evidence, not folklore. We almost kept the unattributed key "in case something depends on it." Instead: a week of fingerprints.

sudo sed -i 's/^#LogLevel INFO/LogLevel VERBOSE/' /etc/ssh/sshd_config && sudo systemctl reload ssh
# after a week — which fingerprints actually authenticated?
sudo journalctl -u ssh --since "-7 days" | grep -oE 'SHA256:[A-Za-z0-9+/=]+' | sort | uniq -c > used.txt
# and per line in the file — which keys never appeared in used.txt?
awk '{print $1" "$2}' /root/.ssh/authorized_keys | while read -r t k; do
  fp=$(echo "$t $k" | ssh-keygen -lf - 2>/dev/null | awk '{print $2}')
  grep -q "$fp" used.txt || echo "UNUSED ALL WEEK: $fp"
done

Nothing used it. Measure before you mourn.

New boxes start at one
The habit stuck because new machines made it easy: on the Cubes we run at Krova Cloud, a box boots with exactly one key — the one handed at creation — and root login is off by default. Additions become a decision you make, not sediment you inherit. Humans increasingly skip static keys entirely: short-lived certs through a bastion for people, per-pipeline keys rotated with the pipeline for robots. Zero sediment, not zero keys.

The honest part

Static keys aren't a sin. Plenty of honest estates run them fine because they run the reviews. The sin is the unreviewed list, not the mechanism.
Ceremony has a cost. Certs and bastions add moving parts and one more thing to fail during the incident that justified the shortcut. We tiered: short-lived access on sensitive boxes, named-and-alarmed keys elsewhere. Perfection is a budget line, not a value.
The alarm will page you once legitimately, at 2 a.m., during a real incident. Thank it. That page is the system proving it can still tell the difference.

The door remembers. You don't have to.
Go cat the file — the actual one, on the actual oldest box, right now. Count the lines; count the owners who are gone. Ours was nine and five. We deleted four, adopted one (the CI key got a name, a rotation, and an apology), and the ninth — the comment-less line — turned out to be me, from a forgotten 2022 incident.

The door remembered me too.

How to Choose an RK3588, RK3576, RK3568, or RK3566 Core Board

ZedIoT — Tue, 03 Nov 2026 12:20:00 +0000

How to Choose an RK3588, RK3576, RK3568, or RK3566 Core Board

Suppose a device needs two cameras, two wired network connections, and a display. A supplier sends back a one-page RK3588 or RK3576 specification headed "6 TOPS, eight cores." Neither number answers the first design question: can the particular core board and carrier board run those interfaces together? A SoC may expose a controller that the module does not bring to its connector, or the carrier may route a high-speed lane to a different peripheral. For a single-display controller with one Ethernet port and modest local inference, starting with RK3588 by default may buy capability the product cannot use.

The useful first pass is elimination, not a four-chip performance ladder. List the interfaces and software constraints that cannot be traded away. Use Rockchip's public SoC documentation to narrow the field. Then request evidence for the exact module revision and carrier design, and test sustained operation in the product enclosure. This article supports that documentation-stage shortlist. It is not a measured comparison of frame rate, power, temperature, unit price, or availability.

Start with interfaces that must operate at the same time

Write a simultaneous-use requirement, such as "two camera inputs + two physical Ethernet ports + NVMe storage + one touch display," rather than four independent checkboxes. The camera path still has to coexist with display, video processing, storage, and network traffic at the required resolution and format. A controller on the SoC block diagram is not proof that the module exposes it; a signal on the module connector is not proof that the carrier provides a usable port. Extra NPU capacity cannot create a lane already assigned elsewhere.

The distinction is especially important for shared high-speed resources. Rockchip's RK3576 product page lists USB 3.0, PCIe 2.1, and SATA among combo interface options. Those labels should not be counted as independent ports in the same configuration. The RK3566 brief datasheet likewise describes shared high-speed resources. Ask the board supplier to map the exact target peripherals to pins and mux selections before freezing a design.

Software can eliminate a candidate even when the wiring works. "Boots Linux" is weaker than "the supplier's current BSP supports this camera sensor, display panel, network PHY, and NPU runtime together." Record the module and carrier revisions, kernel branch, device tree, image version, driver ownership, and patch path. A boot demo proves only the first step. Products with field updates and component substitutions need a maintainable software combination, not an isolated demonstration.

The decision path separates documentation screening from product testing. Failure at either hardware gate ends the current board proposal; passing them only qualifies a module-and-carrier combination for a reproducible software check and sample test.

Where each SoC belongs on an initial shortlist

The following rows identify plausible evaluation tasks and the first board-level question for each chip. They do not rank four tested products under one workload.

Candidate	Reason to evaluate it	First question for the module vendor
RK3588	Multiple high-resolution vision inputs, complex displays, or substantial high-speed expansion	Which camera, display, PCIe/storage, and Ethernet paths are exposed concurrently, and how is the enclosure cooled?
RK3576	A display-and-vision terminal with industrial connections	How are combo lanes assigned, are both network paths and CAN FD exposed on this board revision, and which BSP is supported?
RK3568	A gateway, HMI, or lighter vision device that still needs networking and expansion	What do the module connector and carrier actually provide for Ethernet, PCIe/SATA, image support, and temperature range?
RK3566	A single-screen or lighter edge-control device where limited expansion is acceptable	Are its exposed peripherals, shared lanes, memory, and runtime headroom sufficient for the target application?

RK3588 and RK3576 share a headline NPU figure, not a system profile

The RK3588 product page describes four Cortex-A76 and four A55 cores, multiple camera inputs, high-resolution media capabilities, and a 6 TOPS NPU. Rockchip describes RK3576 with four A72 and four A53 cores, a 6 TOPS NPU, multiple display options, CAN FD, and two RGMII interfaces. Equal advertised NPU figures do not establish equal operator coverage, CPU preprocessing time, memory behavior, video throughput, or sustained performance.

For a product dominated by several camera streams, complex display output, and fast storage, include an RK3588 board in the test set. For a display-focused industrial terminal that also needs network and field-bus connections, an RK3576 board deserves evaluation. These are reasons to request pinout and BSP evidence, not promises about which finished device will perform better.

Do not transfer a carrier's connector list to every board using the same SoC. Firefly, for example, describes Core-3588JD4 together with the MB-JD4-RK3588 carrier in its AIO development board; HDMI, serial, camera, and other accessible connectors belong to that defined combination. Another RK3588 module can have a different board-to-board connector, power design, image, or manufacturing revision.

RK3568 and RK3566 need separate network and expansion checks

The RK3568 brief datasheet and RK3566 brief datasheet both describe quad-core A55 devices with media and edge-compute resources. That common ground puts them in the same early screening exercise, but does not make their boards interchangeable. If a gateway needs two independent wired networks plus high-speed storage and expansion, ask an RK3568 supplier for the exact port and lane map. If one physical network and modest peripherals meet the requirement, an RK3566 module may remain in scope. Neither conclusion establishes price or power savings; those need like-for-like quotations and measurements.

Firefly's Core-3568J and Core-3566JD4 documentation shows how a specific module is paired with a carrier to make a usable development system. It is a useful prompt for supplier questions, not a universal specification for all RK3568 or RK3566 boards.

Three pieces of evidence turn a chip shortlist into a board shortlist

First, request an interface and concurrency map for the exact core-board revision. A pinout, board-to-board connector definition, carrier schematic, or supplier-signed interface matrix should show camera lanes, display outputs, PHYs, PCIe, SATA, USB, CAN, serial, and debug paths in one place. Mark mux alternatives explicitly. A design supported only by a SoC block diagram, without evidence that the board exposes the required combination, is not ready for board freeze.

Second, request a reproducible software set: module and carrier revisions, bootloader, kernel and device tree, Linux or Android image, NPU runtime, relevant camera and display drivers, and the supplier's update channel. Ask for a minimal image and test steps for the functions the product will actually ship. For "two cameras, local inference, and network upload," a camera preview and an unrelated NPU demo are not an end-to-end validation. Acquisition, preprocessing, inference, output, and error recovery need to run in one versioned setup.

Third, define the sustained-operation boundary. Published operating-temperature ranges and heatsink recommendations do not predict temperature inside the final enclosure. At the intended ambient temperature, record frequency, power, dropped frames, restart behavior, and component temperatures while the actual peripherals run together. A gateway also needs tests for network loss, power loss, storage wear, and recovery. Until those records exist, the honest conclusion is "eligible for evaluation," not "production-ready."

Apply the evidence to the product, not to a chip hierarchy

Multi-camera industrial vision device. Give RK3588 and RK3576 board suppliers the same sensor, resolution, encoding, display, network, and storage workload. Compare their pinout and lane allocation first. Then run the same model and runtime version on candidate hardware inside a representative thermal setup. Decide whether RK3568 or RK3566 should leave the list based on the target chain, not a presumed market tier. Both six-TOPS labels leave end-to-end frame rate and cooling unresolved.

Dual-network gateway with a local HMI. Establish whether the networks must be physically independent and whether cellular, CAN, isolated serial, or maintainable storage is also required. RK3568 and RK3576 are reasonable documentation-stage candidates; a single-network, single-screen product may also retain RK3566. Require a board-specific PHY and connector map, then test the actual protocols and recovery behavior. CPU or NPU peaks are poor substitutes for wiring, power, and update evidence.

Single-display controller. Ask whether multiple video streams, fast storage, or complex inference are genuine requirements. If not, begin with specific RK3566 or RK3568 modules and add RK3576 or RK3588 only when an identified display, vision, or industrial interface exceeds their board-level resources. Do not infer lower price or power from the chip name. Quotations become comparable only after memory, storage, carrier, cooling, quantity, and support terms are held constant.

When none of the four is the right starting point

A product doing simple sensing and control, without Linux-class applications or media processing, may be better served by an MCU or a simpler platform. If the hard constraint is cellular certification, electrical isolation, deterministic control, or long-term supply, select around that system boundary first. Familiarity with Rockchip is not a reason to force one of these application processors into the design. Conversely, if a specific peripheral driver or NPU operator is mandatory and the available BSP cannot establish support, a generic "Linux supported" statement should not keep a board on the shortlist.

The useful output of this phase is a record of rejected candidates and why they failed, plus no more than two module-and-carrier combinations for sample testing. Attach each combination's interface map, software versions, power and cooling proposal, and the workload that must be measured. The next discussion can then be about a reproducible product configuration rather than an abstract claim that one chip is "stronger."

Sources and scope

Rockchip RK3588 product specifications
Rockchip RK3576 product specifications
Rockchip RK3568 brief datasheet
Rockchip RK3566 brief datasheet
Firefly Core-3588JD4, Core-3576JD4, Core-3568J, and Core-3566JD4

The conclusions above are limited to public SoC and board documentation. They do not cover the target module's complete connector definition, current BSP release notes, orderable part number, or a like-for-like workload measurement. The product scenarios are selection exercises, not results from a deployment.