DEV Community: Alexandre Oliveira

Your coding agent is bad at Docker, and it isn't the agent's fault

Alexandre Oliveira — Thu, 15 Oct 2026 15:11:27 +0000

I let a coding agent run my local stack for a few months. It writes the compose file, brings the services up, reads the logs, fixes the bug, and checks the fix worked.

It's good at most of that. Docker is where it struggles every time, and after a while I stopped blaming the model. The problem is Docker's interface, which was designed for a person sitting at a terminal. That person can open a browser and has some context about the machine. They also notice when a log repeats itself. An agent gets stdout once the process exits and pays for every byte of it.

Here are the five places where it breaks, with the workaround I use for each using plain docker.

1. "port is already allocated" names no culprit

Error response from daemon: driver failed programming external connectivity:
Bind for 0.0.0.0:8080 failed: port is already allocated

The daemon knows the bind failed but has no idea who holds the port. The operating system knows. An agent that sees this error usually guesses: it changes the port in the compose file, or restarts the engine, or both. Then you end up with a stack on 8081 and nobody remembers why.

On Windows the answer takes two lines:

$c = Get-NetTCPConnection -LocalPort 8080 -State Listen
Get-Process -Id $c.OwningProcess | Select-Object Id, ProcessName, Path

On Linux or macOS, lsof -iTCP:8080 -sTCP:LISTEN does the same job.

The fix is to put this in the agent's instructions as the first step after a bind failure, before it is allowed to edit any port. "Find out who holds it" is a rule the agent can follow. "Use judgment" isn't.

2. `docker ps` and `docker rm -f -v` look the same to an allowlist

Agent tools ask permission before running shell commands, and an allowlist removes the prompt for the safe ones. The trouble is that Docker doesn't split commands into reads and writes. Every verb hangs off the same binary, so you have two bad options:

allow docker *, which also allows docker volume rm and docker system prune -a --volumes
approve every call by hand, and after the fortieth docker ps you stop reading the prompts

You can allowlist subcommand by subcommand (docker ps, docker logs, docker inspect, docker images), and that's what I do. It's still a list you maintain, though, and there are holes in it. docker exec can be a read or a write depending on what it runs. docker compose mixes ps and down -v under one prefix. A global flag before the subcommand (docker --context prod rm ...) gets around a naive prefix rule.

My workaround: allowlist only the pure reads, and accept that every write gets a prompt. That's the place where you want the prompt anyway.

3. Logs are the biggest token sink in the session

A container in a crash loop writes the same stack trace on every restart. Eight restarts means eight copies, and docker logs api hands the agent all eight. Most of what it reads in a debugging session is repetition.

--tail cuts the size but also cuts the part you needed, because the first error is usually at the top. uniq doesn't help, since repeated traces aren't adjacent lines.

What works best for me is to keep the log out of the context entirely:

docker logs api > .agent/api.log 2>&1
grep -n -i -E "error|exception|fatal" .agent/api.log | head -40

A file on disk costs nothing. The agent pays only for the lines grep returns, and it can go back for context around a specific line number. Put this in the instructions as the default way to read logs, and keep docker logs without redirection for short-lived containers.

4. "running" is not "answering"

docker ps says Up 2 minutes. The agent concludes the fix worked. Then you open the browser and get connection refused, because the process inside bound 127.0.0.1 instead of 0.0.0.0, or crashed after startup, or is still running migrations.

Up to that point, the expensive step in the loop was me: open the browser, look, report back. The agent can't close that gap if all it checks is the container state.

Give it an actual readiness check with a deadline:

timeout 60 bash -c 'until curl -sf http://localhost:8080/health; do sleep 2; done' \
  && echo READY || echo "NOT ANSWERING after 60s"

And when it fails, read what the healthcheck itself said instead of guessing:

docker inspect --format '{{json .State.Health}}' api

The healthcheck log usually says ECONNREFUSED 127.0.0.1:8080 in plain words, and that's the whole diagnosis.

5. Cleanup can't tell your work from the agent's

After an afternoon of reproducing a bug, the agent has created six containers, two networks and a volume. When you want them gone, the only tool on offer is prune, which works on the whole machine. It can't tell the agent's scaffolding from the Postgres volume you've been filling since March. So nobody delegates prune, and the scaffolding piles up.

Labels fix this, provided they're applied at creation time:

docker run --label agent.session=repro-17 ...
# compose: add `labels: { agent.session: repro-17 }` to each service

Then the cleanup is scoped:

docker ps -aq --filter label=agent.session=repro-17 | xargs -r docker rm -f

Leave volumes out of that line on purpose. A container comes back from its image, but a deleted volume is gone for good.

The catch is that the agent has to remember to add the label every time, and the one it forgets is the one that bites you later.

The pattern behind all five

Each of these is a join Docker doesn't do: the daemon's view and the OS's view (ports), the command and its intent (allowlists), the raw log and what's new in it (dedup), the container state and the service's behavior (readiness), the object and who created it (labels).

A person does those joins in their head without noticing. An agent does them with extra tool calls, which you pay for, or it skips them and guesses.

None of the workarounds above need anything beyond plain docker and a few lines in your agent's instructions file. Start with #3 and #4, since those two gave me the biggest drop in wasted turns.

I wrote these wrappers in too many projects, and on Windows I ended up putting them into a small CLI with a read/do split that an allowlist can actually express. It's part of FreeWilly, if you're on Windows and want them prebuilt. The patterns work the same without it.

What's the Docker failure your agent hits most? I'd like to know which ones I missed.

Claude Code can write your game. Can it make the rest of it?

Alexandre Oliveira — Tue, 13 Oct 2026 22:25:38 +0000

A coding agent can write a lot of a game today: the player controller, the menu logic, the save system. Then you need a mascot, a coin sound, a background loop and a third level, and the agent can't help anymore. It can't see a render, hear a sound or play a level, and it has no idea when any of those is good enough.

AI generators don't fix that. You type a prompt and get a 3D model, a picture or a voice line in seconds, and then the real work starts. Does it match your sketch? Is it the right orange? Does the loop click at the seam? Does it look like it belongs in the same game as the other forty assets? The generator made a guess, and you're the one who has to check it.

polyweave is a free, open-source plugin for Claude Code that takes on that checking.

Where it came from

polyweave started inside a real game. Cottony is a plush-themed match-3, with hearts, drops and stars made of felt that squash when they land. Its tiles are rendered in Blender, and getting them to look right meant tuning fourteen render settings by hand: change one number, wait about two minutes for a render, look at it, decide, repeat.

Making the model was quick. Most of the time went into the stretch between having a model and knowing it's right. That stretch is what polyweave is for.

The idea: write down what "correct" means

With polyweave, every part of your game starts as a short file that says what correct means for it. You don't write that file yourself. You describe what you want in plain words, and Claude Code writes it down as a list of checks with limits:

the silhouette has to match my sketch
the face has to be this cream colour, within a small tolerance
the sound has to be in C, not too loud, and loop without a click
this level has to be a little harder than the last one

Once that bar exists, the work no longer depends on someone squinting at renders. Claude Code can make a candidate, measure it against the bar, adjust the settings and try again, and the misses get thrown out before they ever reach you.

How it works, in four steps

Ask. Tell Claude Code what you need: "a mascot like this sketch", "a coin sound in C", "make level 3 a bit harder".
Make. polyweave drives the right tool for the job, whether that's Blender, Godot, a 3D or picture generator, a synth or a voice service.
Check. Each result is measured against the bar. A miss gets tuned and tried again.
Approve. The best candidates show up side by side on a review page, each with its checks next to it. You approve, reject, or ask for a change in your own words ("make the ears rounder"), and Claude Code goes back to work.

What it makes

The same loop covers every layer of a game:

3D models, built in Blender or bought from a generator and fitted to your drawing
Images: concept art, icons, sprite sheets, store capsules
Music loops that close without a seam
Sound effects, synthesised or bought, checked for loudness and clicks
Visual effects like particles, glows and hits
Voices, read in each character's own voice
Words: names, dialogue and text, checked against your world and your fonts
Levels, measured for difficulty before anyone plays them
Animation, kept as text so a timing change is one edit you can diff
Game kits: menus, settings, saves, controls and accessibility, installed already tested

Every layer shares one config file, one record of how each part was made and one review page, so you judge the game's parts together instead of one tool at a time.

It works with the tools you already have

polyweave doesn't replace Blender, Godot or your favourite generator. It sits in the middle and talks to each one in its own language:

Layer	Tools it drives
3D	Blender, Meshy
Pictures	FLUX, Ideogram
Sound and music	sfxr, MIDI
Voice	ElevenLabs
Game engine	Godot

Here's what that looks like for a mascot drawn from your sketch:

Before anything is bought, polyweave checks the request against your drawing, so a credit isn't spent on a request that plainly won't match.
Meshy generates the model. polyweave keeps a copy in your project along with the prompt, seed, cost and licence, so nothing expires on the service's side.
Blender renders it, and polyweave measures the render against your sketch: does the silhouette line up, and is the colour right where it should be?
Claude Code adjusts the render settings until every check passes, and only then do the best candidates reach your review page.
Godot opens the game and takes a screenshot, so you see the mascot where the player will actually meet it.

There are plenty of tools that connect an agent to Blender or Godot. What they don't tell the agent is when to stop. In polyweave that's the job of the bar, so the agent works on the tools until the result is right, not just until it's done.

Which tool you use is a line in a config file in your repo. Swap models whenever you like and the bar each part has to pass stays the same.

You stay in charge

Handing an agent a credit card and your art direction is a fair thing to be nervous about. polyweave has three rules about that, and the agent can't get around any of them:

The agent can't approve its own work. It can measure a part, but only you can accept it. Whether something looks right, sounds right or feels fair is your call.
The agent can't spend money on its own judgement. You set a spending ceiling once. Every paid request is quoted first and written to a ledger, and a request that clearly won't match your reference is refused before any credit is spent. Claude Code works freely under the ceiling and can never raise it.
Everything stays on your machine. There's no account and no hosted service. Specs, jobs and records are plain files in your repository, so a teammate can review or repeat anything.

Each file also keeps its history: which model, prompt, seed, cost and licence produced it. Writing your credits screen and checking licences become a lookup.

Real games are being made with it

Viglet Games is making its games with polyweave, and both are in development for Steam:

Cottony, the plush match-3 where it all started
Spinhold, a neon ring shooter where you fly around the outside of a spinning colony

Try it

You need Claude Code and Python 3.11 or newer. Blender and Godot are optional: polyweave tells you which tools it found and what each missing one would unlock.

pip install git+https://github.com/alegauss/polyweave
/plugin marketplace add alegauss/polyweave
/plugin install polyweave@polyweave

Then ask:

Set up polyweave in this project, and make me a mascot from docs/sketch.png.

Website: alegauss.github.io/polyweave
Code: github.com/alegauss/polyweave

If you're making a game with an agent, I'd like to hear which part of it is still eating your time. Leave a comment.

374 tests went in, 352 came out, and the build was green

Alexandre Oliveira — Tue, 13 Oct 2026 14:24:20 +0000

The last run had 374 tests. This one had 352. No failures, so the build was green.

Twenty-two checks had disappeared. The test host died partway through, the runner counted what it managed to finish, and the only evidence was a total nobody had a reason to compare against yesterday's. Every tool in the chain did what it was designed to do. The result was still false.

winwright is a UI testing engine for Windows desktop apps (WPF, WinForms, tray icons, menus, dialogs), and that missing 22 is the reason it exists. Most of its design follows from refusing to let that happen again.

A test has three possible answers

Most test runners give you two outcomes: it passed or it failed. Desktop UI testing has a third one, and it shows up all the time.

Say a test needs to type into a text box. To send keys, Windows has to give your app the foreground. Sometimes it won't: you clicked into Slack, a notification took focus, the CI agent has no interactive session at all. The keystrokes go somewhere else, the read-back doesn't change, and the test goes red.

The red is wrong. Nothing in your application broke. You'll spend twenty minutes reading code that is fine, because the report said your app failed when what happened was the machine never let me try.

winwright calls that third outcome a hole: an assertion that never ran because something it needed was missing. A hole isn't a pass and it isn't a failure, and the exit code keeps them apart:

Exit code	Verdict	What it means
`0`	Passed	Everything that was asked was checked, and held
`1`	Failed	Your application did something wrong
`2`	Degraded	Some checks could not run, and the report names why
`3`	Broken	The run itself threw, so nothing after that point was observed

The summary line puts what didn't happen first:

Passed: 1 of 9 cases, 8 not run, 3 assertions over case 'renaming a profile writes it back'.

A pass over one case out of nine is a weaker claim than a pass, and a report that buries "8 not run" at the end of the line is one people will skim past. If the 352 run had produced that sentence, someone would have noticed.

Even a run that selects nothing is caught. A filter that matches zero cases is refused, because zero cases contain zero failures and would otherwise come back green.

The desk is not your application

Most of the holes you'll meet belong to the machine, not to your code, and winwright says which side each one is on. "No foreground", "no interactive session", "a flyout the shell wouldn't open" and "somebody else touched the mouse during the case" are reported as conditions of the desk. None of them can turn a run red.

One detail I like: a freshly launched app is often still coming forward when the first step runs. Measured against one adopter, that took 1,453 ms. A tool that checks the foreground once at that moment concludes another window owns the desk, which is true for that instant and false for the run. So winwright waits for the foreground up to the project's resolve timeout. Only after that does it report a hole, and the hole says how long it waited.

There's also an easier way around most of it. The default act doesn't need the foreground at all.

Ask the control, don't move the mouse

Every accessible Windows control has a UI Automation peer: an API that lets a screen reader ask "what's your value?" or tell it "invoke yourself". winwright's default verbs (invoke, toggle, set value, select, expand) go through those patterns. No synthetic mouse, no keyboard, no need to be in front.

The verbs that do put real input on the desk (type, click, press, drag, nudge) are marked that way in the catalogue, and they prove something different from their pattern twins. set value writes through the Value pattern. type presses keys.

That difference caught a real bug. A WPF window hosted under a WinForms message pump accepted no keyboard input at all, and the set value check passed anyway, because it never used the keyboard. The type check failed. Neither one was flaky. They answered two separate questions, and only one of those questions was what a user would actually do.

That's also why click won't run until you give it a reason: NoAutomationPeer, NotificationArea, CustomTemplate, or PointerIsTheAct. If the reason defaults, every act quietly turns into a mouse click and your suite ends up driving the desktop instead of asking controls.

A test is a data file

A winwright case isn't C#. It's JSON:

{
  "cases": [
    {
      "name": "renaming a profile writes it back",
      "catches": "a rename that updates the list and never the file",
      "tags": ["smoke", "profiles"],
      "steps": [
        { "locator": "TabItem[name=\"Profiles\"]", "act": "select" },
        { "locator": "Edit#profileName", "act": "set value", "with": "Beta", "expect": "Beta", "reads": "value" },
        { "locator": "CheckBox#autosave", "act": "toggle", "expect": "On", "reads": "toggle" },
        { "locator": "Button#save", "act": "invoke", "named": "save the profile" },
        { "locator": "Text#status", "act": "read", "expect": "Saved", "reads": "text" }
      ]
    }
  ]
}

Notice what's missing: no Thread.Sleep, no retry loop, no WaitUntil. The engine owns the waits, the attempts and the verdict. The case only says what to do and what should be true afterwards.

It even knows which acts are safe to retry. set value can be repeated if the read-back is late. toggle and invoke get exactly one try, because a retried toggle leaves the checkbox in the opposite state and then fails about that.

Locators use one grammar, read the same way by every verb:

Button#save                          automation id + control type
Button[name="Save as..."]            by name
MenuItem[nameStarts="Personal "]     the front of a name that carries live state after it
ComboBox|Slider|Edit                 any one of several types
Window#main > Pane > Button#save     a descendant, at any depth

The > means descendant at any depth, not direct child. That's deliberate: UI Automation wraps controls in panes that differ between frameworks, between framework versions, and between a maximised window and a restored one. A direct-child locator is the kind that passes on your machine and breaks on a colleague's.

Typed expectations go stale

This is the part that changed how I write UI tests.

One adopter's hand-written harness checked a window's tabs. It listed the three tab labels by hand and reported "all three tab headers read". Then the window gained a fourth tab. The harness kept reporting all three tab headers read, against a four-tab window, and nothing went red. It was still accurate about the three tabs it knew. It had just stopped checking the window.

A string you type into a test is a second copy of the truth, and that second copy is the one that goes stale. So winwright prefers expectations that are derived:

{ "locator": "TabItem", "act": "read", "covers": "stats.tab" }

stats.tab is a key in your application's own strings file. The claim goes both ways: every string declared under that key appears in the window, and nothing else does. Add a fifth tab to the strings file and this step fails until the window shows it. Add a fifth tab to the window without declaring it and the step fails too. The test file doesn't change either way.

The same idea shows up throughout the format:

label compares a reading against a string from your language files, in whatever language the fixture launched the window in. Your pt-BR run checks Portuguese without a separate test.
forEach runs a case once per string under a key, so a settings page with six panels gets six runs, and a seventh panel added next quarter gets a seventh with no edit.
reportedSets asks the application itself for sets that live in the machine's data rather than in strings (profiles, accounts, devices). Your test then holds on a machine with one profile and on a machine with five.
moves, answers, matches, sameAs and unlike cover values a case can't know in advance: the reading changed, it said something, it has the right shape, it came back to what an earlier step read.

Even negative claims are honest about how hard they looked. never asserts that a string (say, "no readings yet") never appeared while a step was waiting. One adopter's report comes back from cache in 12 ms or gets rebuilt in 961 ms with that placeholder flashing on screen, and once the waiting is over the two windows look identical. So the result reports how many times it checked. For a claim that something never appeared, the number of looks is the evidence.

Screenshots that refuse to lie

A screenshot proves layout and nothing else. It says nothing about whether a button works, and winwright keeps those questions in separate loops: pictures and geometry for layout, act-then-read for input, render-twice-and-compare-bytes for determinism.

Within its job, a capture is held to the same rule. A capture is refused if a window covered it, if the backdrop showed through, if it came back as a single flat colour, or if the page in it was still showing its loading text. The refusal names the window that got in the way, its process and the rectangle. An optional in-app package (Winwright.InApp) lets the application render its own visual tree to a PNG. That includes a popup nobody has clicked open yet, which no screen copy can capture.

Refusals are instructions

winwright says "no" a lot, and it tries to make every "no" tell you what to do next:

A locator that doesn't parse names the character position and the reason.
A misspelled control type gets the nearest name UI Automation actually has.
An unknown key in a case file is refused, never ignored. "expects" next to "expect" would otherwise load, run, check nothing, and pass.
A case whose steps expect nothing is refused: it acts, never looks, and passes on a build that still has the bug.
Every refusal is addressed into the file, as in cases[2].steps[1].act, so you fix a field and not a file.

The part built for AI agents

This is where it gets a bit unusual.

If you ask a coding agent to "test this window", it will write a harness script. The script is always available and always faster in the moment, and that's how one adopter ended up with a 2,732-line one.

winwright ships as a Claude Code plugin, and the plugin includes a PreToolUse hook. Any write whose content references Winwright.Acting, Winwright.Locating or Winwright.Asserting is denied, and the denial points the agent to the case format and the tool that validates it. The agent gets the refusal before it writes the script, not after you've reviewed it.

The MCP server then gives the agent four tools:

winwright_format: every field a case may carry, and the closed list of what each accepts.
winwright_vocabulary: every act, what it needs beside it, and whether the engine may retry it.
winwright_check: validates a case before the file exists. Its input schema is the loader's schema, so a misspelled key can't even be sent.
winwright_run: runs it and returns the verdict. A machine that can't observe returns a hole naming which condition is missing, not a red and not a green.

Two commands wire it into a repository, and committing .claude/settings.json wires it for everyone who clones it:

claude plugin marketplace add alegauss/winwright --scope project
claude plugin install winwright@alegauss --scope project

One deliberate rule: the tool never writes the test. There's no recorder that turns clicks into a scenario and no assertion invented on your behalf. The engine owns the loop and the waits, and deciding what's worth asserting stays with you.

When you should not use it

The project site has an honest comparison where every alternative keeps the column it wins:

Playwright for anything in a browser. The name is a nod, not a rivalry.
Appium when one suite has to drive more than Windows.
WinAppDriver when WebDriver compatibility is the requirement.
FlaUI when you want a mature UI Automation library without opinions attached.
Your existing script, right up until the run where the total changes and the colour doesn't.

winwright is Windows-only, .NET 10 only, and will stay that way: the whole engine is UI Automation and Win32. What it offers is narrower: a report that tells a failed check from a check that never ran, one locator grammar, expectations derived from the app instead of typed into the test, and screenshots that refuse instead of lying.

Trying it

<!-- the test project that drives your app -->
<PackageReference Include="Winwright" Version="1.0.2" />

<!-- optional, inside the app, for the readings only it can take -->
<PackageReference Include="Winwright.InApp" Version="1.0.2" />

Add a winwright.json with your executable's path, write a .cases.json, and run it with four calls:

var project  = ProjectDeclaration.Find(repository);
var declared = ScenarioFile.Across(ScenarioFile.LoadAll(Path.Combine(repository, "cases")));

using var register = ProcessRegister.For(project);   // anything the run started is stopped, and named if it won't stop
var verdict = Suite.Launch(declared, Selection.All, register, project);

Console.WriteLine(verdict.Sentence());
return verdict.ExitCode;

One piece of advice from the docs that I'd underline: give the run a desk of its own. Cases take the foreground and send real input. If you run them on the machine you're working at, your typing lands in the app under test. That isn't a flaky suite, it's two people sharing one keyboard. Use a VM with an interactive session, a dedicated runner, or any machine nobody is sitting at.

📦 NuGet: Winwright · Winwright.InApp
🌎 Site: alegauss.github.io/winwright/
📖 Docs: alegauss.github.io/winwright/docs/
💻 Source (Apache-2.0): github.com/alegauss/winwright

Has your suite ever passed with fewer tests than it had the day before? I'd like to hear how you noticed, or how long it took.

I spent 10 years building enterprise search for clients. Then I open-sourced all of it.

Alexandre Oliveira — Mon, 27 Jul 2026 22:53:54 +0000

Every enterprise search project I did in the last decade ended the same way. A search engine (Solr or Elasticsearch), a pile of glue code for facets and relevance, then, in recent years, a RAG pipeline bolted on the side, and finally an agent framework on top of that. Three stacks, three sets of bugs, one recurring client requirement: the data cannot leave our network.

After repeating that build enough times, I turned it into a single platform. This year I open-sourced the whole thing under Apache 2.0: Viglet Turing ES.

This post is about the three design decisions that I think matter most, and how to try it in one command.

Decision 1: run on the engine you already have

Most teams evaluating "AI search" already operate Solr or Elasticsearch. Asking them to migrate to a new engine just to get RAG is a non-starter.

So Turing sits on top of the engine instead of replacing it. Solr, Elasticsearch or an embedded Lucene index, behind one query API. Hybrid retrieval fuses keyword (BM25) and vector results with Reciprocal Rank Fusion, and a pluggable reranker (LLM, cross-encoder or Cohere) reorders the page. If you have nothing installed, the embedded Lucene engine means the whole stack runs in a single container.

The same idea applies to models: OpenAI, Anthropic, Gemini, Azure, or fully local via Ollama. For air-gapped deployments, local models plus local embeddings plus embedded Lucene means literally nothing leaves the machine.

Decision 2: answers you can audit, including "no answer"

The feature enterprises actually ask about is not chat. It's trust. A support portal or an intranet cannot ship confident wrong answers.

Turing's RAG chat streams answers with inline citations that trace back to the exact source passage. Before the LLM sees anything, a relevance gate drops weak matches. After generation, an optional groundedness check flags claims the sources don't support. And when nothing in the index clears the bar, the assistant gives a deterministic "not covered here" answer instead of improvising.

That last behavior sounds small. In practice it's the difference between a demo and something a regulated organization will put in front of users.

Decision 3: agents grounded in the same index

Once search and RAG share an index, agents get interesting: they can act on content instead of just answering. Turing's agents do tool calling, run skills in a Docker sandbox, and connect to MCP servers, so the same assistant that cites your docs can also call your internal APIs.

Try it

One command, no account, no telemetry:

docker run -p 2700:2700 ghcr.io/openviglet/turing-ce

The console comes up at http://localhost:2700/console (set the admin password with the TURING_ADMIN_PASSWORD env var on first run).

Searching is a plain REST call:

curl "http://localhost:2700/api/sn/sample-site/search?q=enterprise+search&rows=10&_setlocale=en_US"

And the RAG chat streams over SSE:

curl "http://localhost:2700/api/sn/sample-site/chat?q=What+is+enterprise+search"

There are TypeScript SDKs (a zero-dependency vanilla one and a React one) if you're embedding search in a frontend. The live demo on the site runs on that same SDK, over Turing's own documentation, so you can see the cited answers before installing anything: turing.viglet.org/#playground

One honest note about the repo

The public repository is a clean snapshot per release, because day-to-day development happens against client work I can't publish. I know a thin commit history looks odd at first glance, so I'd rather say it here than have you wonder. Issues and PRs are very real and ship in the next release.

What I'd love feedback on

If you self-host Elasticsearch or run local LLMs and have opinions about hybrid ranking, citation UX, or what a search platform should refuse to answer, I want to hear them. The repo is github.com/openviglet/turing-ce and the docs live at docs.viglet.org.

Thanks for reading!

DEV Community: Alexandre Oliveira

Your coding agent is bad at Docker, and it isn't the agent's fault

1. "port is already allocated" names no culprit

2. docker ps and docker rm -f -v look the same to an allowlist

3. Logs are the biggest token sink in the session

4. "running" is not "answering"

5. Cleanup can't tell your work from the agent's

The pattern behind all five

Claude Code can write your game. Can it make the rest of it?

Where it came from

The idea: write down what "correct" means

How it works, in four steps

What it makes

It works with the tools you already have

You stay in charge

Real games are being made with it

Try it

374 tests went in, 352 came out, and the build was green

A test has three possible answers

The desk is not your application

Ask the control, don't move the mouse

A test is a data file

Typed expectations go stale

Screenshots that refuse to lie

Refusals are instructions

The part built for AI agents

When you should not use it

Trying it

I spent 10 years building enterprise search for clients. Then I open-sourced all of it.

Decision 1: run on the engine you already have

Decision 2: answers you can audit, including "no answer"

Decision 3: agents grounded in the same index

Try it

One honest note about the repo

What I'd love feedback on

2. `docker ps` and `docker rm -f -v` look the same to an allowlist