Use Coding Agents as Operational Harnesses, Not Chat Windows

A chat interface mostly gives a model text and asks for text back. A coding harness surrounds that model with an environment. It can search a repository, read project instructions, edit files, execute tests, open a browser, call an MCP server, inspect a database, and continue after an initial failure. The transcript becomes only one surface of the work. The real artefacts live outside it and remain available for inspection.

That is why comparing harnesses only by benchmark performance misses the practical question. Codex and Claude Code are natural fits for repository-centred work where the agent must edit, execute, test, and review software. OpenClaw is designed around a single operator, a gateway, devices, messaging channels, tools, and optional sandboxing, making it useful when work needs to arrive through the channels where the operator already lives. Hermes emphasises persistent memory, reusable skills, scheduled automation, multiple execution backends, and a learning loop. Aider remains attractive when the desired unit is a tight terminal-and-git pairing session. These products overlap, but their strongest operating shapes differ.

Choose the harness from the boundary of the job. If the source of truth is a repository and the outcome is a verified change, start with a coding harness. If the work must remain available through messaging and scheduled routines, consider an assistant gateway. If durable procedural memory is central, prefer a system with an explicit skills and memory model. Do not begin with the logo. Begin with the environment, authority, evidence, and recurrence the work requires.

Good prompting still matters, but not because a longer prompt is automatically better. The useful prompt behaves like a reviewed work order. It names the outcome, the available context, the non-negotiable constraints, the expected artefacts, and the checks that define completion. For a large build or rewrite, drafting the requirements first and asking a model to organise them into a technical brief can expose ambiguity before an agent spends time implementing the wrong system. The brief should then be reviewed by the operator, not passed through untouched.

The agent should be asked to inspect before it commits. Let it read repository conventions, primary framework documentation, existing tests, adjacent implementations, and the current data shape. Completion also needs a definition. ‘Build a scraper’ invites a demo. ‘Build a resumable scraper that commits each discovery, stops on anti-bot challenges, exports a stable schema, logs failures, and can be rerun without duplicating completed work’ describes an operating property the harness can verify.

The local-business project began with a deliberately small Playwright scraper rather than an ambitious autonomous sales agent. Search terms live in a plain queries file. The script opens a visible browser, gathers Google Maps place URLs sequentially, visits public business websites, looks for published contact addresses, and stores progress in SQLite. Social profiles are excluded from enrichment, generic business inboxes are preferred when several public addresses appear, and the export schema remains intentionally narrow: business name, website, email, and source query.

The unglamorous design decisions are the case study. Every discovered profile is committed as it is found. Completed queries are recorded. Businesses move through pending, processing, complete, and failed states. An interrupted processing row can return to the pending queue on the next run, while successful work remains preserved. The scraper detects CAPTCHA and automated-traffic markers, stops instead of attempting to evade them, and keeps the data already written. Logs explain what happened after the browser is closed.

This is software automation written for supervision rather than theatre. Codex can author the schema, selectors, normalisation, retry behaviour, CSV export, and documentation; it can then execute focused runs, inspect exceptions, and repair brittle assumptions. But the automation remains the durable worker. Repeating the job does not require the model to rediscover every procedural step or improvise database state in natural language.

Responsible use is part of correctness. Public availability is not unlimited permission. Operators still need to comply with applicable law, platform and website terms, rate limits, privacy expectations, and outreach rules. The repository explicitly avoids CAPTCHA bypass. A production deployment should also make retention, opt-out, access control, and the lawful basis for collection explicit. A harness can enforce some of these boundaries, but it cannot grant permission that the operator does not possess.

Most scraping projects end at a CSV. That is where this workflow becomes more interesting. Each saved business with a website can be inserted into a Lighthouse audit queue. A second resumable Python program calls the Lighthouse CLI against the site, writes the raw JSON report to disk, and records parsed performance, SEO, best-practices, and accessibility scores in the same SQLite database. Running state is recoverable, failed sites can be retried, and mobile or desktop modes can be distinguished.

Lighthouse is valuable here because it produces machine-readable observations instead of a model's impression of quality. The audit program collects failed checks, ignores manual or non-applicable items, weights severity, counts high-priority issues, and calculates a prioritisation tier. The repository then prepares the successful and failed audits as structured workbook data ordered by priority. The chain from a search query to a specific report path remains inspectable.

This separation prevents a common agentic mistake: asking one model to browse a site, remember what it saw, assign a score, and compose a recommendation in a single opaque pass. The deterministic layer should first establish facts it can establish consistently. The model can then reason over a smaller, better-shaped evidence set. If the interpretation appears wrong, the operator can inspect the raw Lighthouse JSON, the parsed findings, the scoring function, and the source record instead of arguing with an untraceable answer.

Objective audits do not tell us whether a lead is worth pursuing, whether an issue matters to that business, or whether a proposed message is fair. A low performance score may reflect a genuinely damaging mobile experience, a temporary network condition, an intentionally media-heavy page, or a site that is irrelevant to the service being offered. Accessibility and SEO checks can identify important signals without understanding the organisation's audience, commercial context, or capacity to act.

This is where running the completed automation through Codex becomes useful. Give the harness the database export, selected raw reports, the scoring logic, and an explicit review rubric. Ask it to challenge the mechanical ranking: identify findings supported by evidence, distinguish repeated technical symptoms from likely root causes, flag uncertain or contradictory records, assess whether the suggested priority matches user impact, and draft a short rationale that cites the underlying fields. The agent is no longer pretending to measure the website. It is interpreting measurements already preserved by a specialised tool.

Subjective analysis should produce reviewable claims, not automatic outreach. A sensible rubric might cover relevance, evidence strength, likely user impact, remediation feasibility, and confidence. Codex can compare sites consistently, cluster recurring problems, notice that a conversation starter overstates what the report proves, and recommend which records deserve human inspection. The human then checks the live site and decides whether contact is appropriate. Measurement, interpretation, and action remain separate permissions.

The loop can improve itself. If subjective review repeatedly rejects high-priority records because the scoring function overweights one audit, update the deterministic weighting and rerun the queue. If the agent repeatedly needs business category or location to judge relevance, add those fields to acquisition. If the same review instructions recur, turn them into a versioned skill or script. Codex is valuable here not only as the author of the automation or the analyst of its output, but as the connective tissue that can revise each layer when downstream evidence exposes an upstream weakness.

The method generalises beyond local-business research. Start by asking the harness to map the work and locate stable rules. Move those rules into ordinary software: a script, test, query, queue, validator, or scheduled job. Let the harness run that software and repair operational failures. Preserve outputs in a form another person or program can inspect. Only then ask the model to make the judgements that resist clean encoding. Feed accepted and rejected judgements back into tests, rubrics, and reusable procedures.

Codex supports this repository-centred pattern particularly well because its documented use cases include building command-line tools for later use, saving workflows as skills, automating QA, and iterating through scored improvement loops. Claude Code exposes a similar distinction through hooks: command hooks provide deterministic lifecycle behaviour, while prompt and agent hooks are reserved for decisions that need model judgement. OpenClaw can carry recurring workflows into messaging channels, but its own documentation warns that inbound messages are untrusted and host-running tools require deliberate sandboxing. Hermes can make procedures persistent through memory, skills, cron, and remote execution backends. The architecture stays the same even when the harness changes.

Treat permissions as part of the program. Reading a report is different from changing a database. Drafting outreach is different from sending it. A command hook that always runs tests is different from an agent deciding whether the tests are adequate. Keep deterministic checks automatic, subjective checks cited, destructive changes reversible where possible, and external side effects behind explicit approval. More autonomy is not the objective. Dependable completion with proportional oversight is.

The same pattern can anchor a Workflow Automation Hub or a much smaller local utility. Effective operators improve the environment between sessions: project conventions remain in the repository, commands stay discoverable, small test fixtures reproduce failures, and interrupted runs leave enough state to resume. They redirect an agent when an assumption proves wrong, separate research from implementation and analysis, and reserve parallel work for genuinely independent tasks whose outputs can be reconciled.

Finally, preserve the good work. A validated command becomes a script. A repeated checklist becomes a skill. A successful evaluation becomes a test fixture. A useful domain rubric becomes a versioned document. A correction becomes a regression case. This is how an agent stops being a clever visitor to the project and begins contributing to an operating system that grows more legible with use.