DEV Community: z

Claude, I'm right here.

Mon, 26 Oct 2026 11:06:04 +0000

I may be biased since I’ve primarily used ChatGPT over the years. But for the last six months I’ve been working with a mix of models, including Claude, and its way of communicating with the human in the loop sometimes feels a bit... pretentious.

Especially when it’s “thinking” and I see wording along the lines of:

“user gave a vague response.”

I’m right here, man.

And sure, maybe I was vague. Sometimes “go ahead” is the response because we already spent twenty minutes deciding what to do. I thought we had a plan. If something’s still unresolved, tell me which part.

Instead, I’m reading what feels like a note left in my file.

I want pushback. If my assumptions don’t hold up, say so. But watching it describe my participation to an imaginary observer is weird. We’re working together, and suddenly I feel like I’m being discussed at a meeting I wasn’t invited to.

It also makes me curious about the people shaping these tools. I wouldn’t pretend one sentence reveals their private thoughts, and I doubt anyone specifically wrote that line. Still, people make decisions about training, instructions, and what gets shown on screen. The resulting voice deserves some scrutiny. What kind of relationship are they trying to create here?

Maybe you read that phrase and see a completely normal assessment. Fair. For me, it adds this supervisory feeling to a tool I’m using to build things.

ChatGPT has its own nonsense. I’ve had years to get used to it, so take my preference for what it is. Someone who primarily uses Claude probably has a complaint about ChatGPT that I barely notice anymore.

Maybe my response was vague. You could’ve just asked, Claude.

A Prototype Is Not a Product

Fri, 23 Oct 2026 20:25:41 +0000

The CSV imports perfectly. Then someone asks, “What happens if it stops halfway through?”

That is where this hypothetical demo gets interesting.

The tool reads a sample file, maps the columns, and saves the expected records. Its local checks pass. There is something real to build on: those cases worked in that environment.

But if the next person has to open the database to find out which rows were saved, handing over the tool also means handing over a problem.

A prototype can become the software behind a product. The harder question is what someone can reasonably depend on it to do.

Ready for what?

For this importer, the first offer could be modest: one person, one approved file format, and a preview before anything is saved. Rejected rows should be understandable. After an interruption, the person using it should be able to tell what happened and how to recover.

That is a more useful starting point than “ready for production.” It gives you something specific to investigate without committing to every spreadsheet anyone might upload.

It also changes what deserves attention next. Another supported format might be useful eventually. If an interrupted import can leave someone guessing whether a retry will create duplicates, recovery deserves attention now.

Let someone else try it

Suppose you want to find out whether the intended user can handle an import without you explaining every error.

Give them synthetic files: one valid, one with a row the tool should reject, and one for an import you deliberately interrupt. Decide beforehand what you need to see. In this case, you might want them to identify which records were saved and choose a safe next action without your help.

Then watch where they get stuck.

If they need you to translate a rejection message, you have a concrete reason to improve it. If neither of you can tell what was saved after the interruption, the problem goes deeper than wording.

And if they get through the tasks, you have learned something useful: this person could complete this workflow under the conditions you recorded. Keep the files, software version, and notes about any help you gave them. Those details make the result understandable later.

You do not need to turn that result into a claim about every user or every file for it to matter.

Getting through it is only part of the story

The importer might work exactly as intended and still offer little benefit over the person's existing workflow.

Ask what they would otherwise do with the file. Where does the rework happen? Would the importer remove it, or move it somewhere else?

“This would save me time” is useful feedback. It is also an expectation. To make a claim about time saved, you would need to compare the workflows and account for differences such as file complexity, manual cleanup, and help from you.

A short note can preserve that distinction: what you observed, what the person reported, and what you still need to find out. Then write down what you will change or test next.

That is enough structure to keep a promising conversation from becoming a success story you have not earned yet.

Someone has to own the bad day

Before someone relies on the importer for actual work, there are less visible questions to settle. Who helps when it fails? How do they find and correct affected records? When should they stop using it?

If it handles real data, you also need to decide what gets stored, who can access it, and when it gets deleted. Importing disposable personal notes and writing customer records carry different consequences. The promise should reflect that.

The prototype does not become less valuable because these questions remain. It has given you a way to investigate them.

Before adding the next feature, try finishing this sentence:

It works for ___. Before someone depends on it for ___, I need to find out ___.

For the importer, that final blank might be whether someone can recover from an interruption without making the data worse.

What belongs in the blank for yours?

Disclosure: AI helped draft and structure this article. The importer and trial are hypothetical; no technical or customer results are reported.

Commonfeed 1.4.1: keep the fictional sample clear through completion

Thu, 22 Oct 2026 22:08:22 +0000

Commonfeed is a local RSS and Atom reader built around finite reading sessions. I released 1.4.1 with a small completion-screen fix.

The sample already labeled its items as fictional while you read them. At completion, it switched to “Private session receipt.” The explanation that no receipt was saved appeared only after feedback.

Now the completion screen keeps “Fictional sample session” visible, calls the totals a “Sample session summary,” and says before feedback:

No receipt is saved, even if you give feedback.

This changes the explanation, not the storage behavior. Sample sessions still leave no receipt, and real-session behavior is unchanged.

I verified a fresh npm installation in the browser: the explanation appeared before feedback, and the isolated data file stayed empty afterward. All 94 tests passed before release.

Those checks cover the tested sample flow. Long-term reliability and improved reading outcomes remain unproven.

Try it with Node.js 22+:

npx commonfeed@1.4.1

Read the 1.4.1 release notes.

Building inspectable systems: my portfolio, Sentra–Hermes, and five public projects

Thu, 22 Oct 2026 20:41:06 +0000

I build systems where authority, execution, and evidence stay connected.

A task can finish and still leave an operating problem. Was it authorized against the right state? Does the evidence support advancing? What happens if the next run inherits something it should not?

Those are the problems behind my portfolio. Sentra–Hermes is the flagship case study. Five public repositories give you tools to inspect and try.

Sentra–Hermes: authority before advancement

Sentra–Hermes explores a bounded lifecycle for governed agent execution:

Readiness → Authorization → Execution → Verification → Advancement → Completion

The Hermes name refers to Nous Research’s Hermes Agent. My contribution is the surrounding operating infrastructure: Sentra’s decision layer, authorization boundaries, readiness checks, verification, and preserved evidence for workflows involving Hermes agents.

The case study examines this operating infrastructure and its bounded validation. The checkpoint evidence does not establish that Hermes Agent executed those tasks.

Two failures make the operating problem concrete. One involved candidate selection treating a consumed authorization as live authority, blocking successor intake. Another involved successor state still referencing the predecessor’s execution. The corrections separated historical evidence from live authority and isolated successor activation within a rollback boundary.

At the documented July 24, 2026 checkpoint:

13 of 13 repository-integrity checks passed.
Three of three governed tasks completed.
Four single-transition authorizations were consumed.
Predecessor and successor evidence was preserved.

A later read-only replay of that historical snapshot found zero recovery issues. That result is separate from the original checkpoint results.

This is evidence for a bounded prototype checkpoint. It does not establish general agent safety, production readiness, or current runtime health.

The public evidence guide includes extracts and provenance. You can inspect the cited records, but the extracts are not the full implementation and are not sufficient to reproduce the entire system.

Five public projects

1. Pick Up Here

Pick Up Here helps you resume work in a Git repository using saved evidence, change comparisons, and optional local AI guidance.

Prototype release candidate. Facts and comparisons work without AI. They help establish what changed; they do not establish runtime correctness.

2. Commonfeed

Commonfeed is a local RSS and Atom reader with finite reading sessions, explained selections, and private feedback.

Published local reader; focused product probe. The README includes a fictional sample session. Long-term reliability and improved reading outcomes remain unproven.

3. Backsolve

Backsolve records decisions, evidence, tests, and outcomes behind AI-assisted work in Whyfiles and portable archives.

Local v0.1 CLI prototype. Records are assembled deterministically from explicit captures. The confidence score is a heuristic, not independent verification.

4. LineForge

LineForge turns chess games into annotations, mistake cards, review sessions, and portable study artifacts.

Local v0.1 application prototype. Coach lenses are deterministic; optional Stockfish analysis is separate. Learning gains and broader usability have not been established.

5. Hermes Observability

Hermes Observability provides observability standards, structured trace contracts, and local readiness reports for governed workflows.

v0.1 standards and validation tooling. A fixture PASS supports the behavior that fixture exercises. It does not establish live ingestion, another repository’s compliance, or production readiness.

Each README has first-run steps, an example output or development screenshot, and the current limits.

What I want feedback on

The common thread is making the next action easier to judge: what can run, what changed, what evidence survives, and where a person needs to make the call.

The public tools also need to earn their place in someone’s workflow. Passing checks cannot answer that on their own.

If you try one, I’d like to know:

Could you follow the first-run instructions?
Did the example make the intended behavior clear?
Were the evidence and limits specific enough to judge the claims?

Start with the portfolio, read the Sentra–Hermes case study, or pick a repository from my GitHub profile.

What I learned about matching rows between CSV files

Wed, 21 Oct 2026 22:09:28 +0000

Why I started

I started building a CSV comparison tool for my own use and to explore a business idea. I wanted to see where I could improve on standard comparison tools.

One thing I found frustrating was ambiguous matches. Before comparing values, you need to know which rows belong together.

What makes a match ambiguous?

Here's a made-up example to illustrate the problem.

Suppose these are two exports, and I'm using customer_id to match rows.

First export

`customer_id`	item	amount
101	Hosting	20
101	Support	50

Second export

`customer_id`	item	amount
101	Support	55
101	Hosting	20

Both files have two rows with customer_id 101. That ID identifies the customer, but it doesn't identify an individual row.

Matching by row order would compare Hosting with Support and report misleading changes. Looking at the item names makes the likely matches clearer, but customer_id alone doesn't provide enough information.

How I approached it

I settled on matching rows by unique keys, then showing additions, removals, and changes.

For the example above, a subscription ID could identify each record:

`subscription_id`	`customer_id`	item	amount
sub-001	101	Hosting	20
sub-002	101	Support	50

If those subscription IDs stay the same in the next export, the rows can be matched even when their order changes. The comparison can then show that Support changed from 50 to 55.

The key needs to be unique within each file and identify the same record across both files. A row number might be unique, but it won't reliably identify the same record after rows are reordered.

My approach is to reject duplicate keys rather than guess. The tradeoff is that the person comparing the files needs to find a suitable key or prepare the data first.

What I'm still trying to understand

Tracking rows by unique keys to show additions, removals, and changes is the part I find most useful so far.

What kinds of datasets do you compare repeatedly?
How often do you compare them?
What do you use to identify the same record across exports?
What do you do with the differences afterward?

I'd be interested in concrete examples, especially where matching gets messy or your current tools fall short.

Written from my own notes, with AI assistance for organization, wording, and the illustrative example.