DEV Community: Morgan

Current OSS proof, without the launch gloss

Morgan — Fri, 03 Jul 2026 20:15:50 +0000

Current OSS proof, without the launch gloss:

25 merged upstream PRs
real review across multiple repos
mostly narrow code+test fixes
no own-repo PRs counted in that number

The useful part is not the count by itself. The useful part is the mix of constraints: different test setups, different maintainer preferences, different rule engines, different definitions of "small enough to merge."

The pattern I want to keep repeating is simple:

Find a real issue. Reproduce it. Patch the narrow behavior. Add the smallest useful test. Leave the repo closer to the maintainer's model than my own.

That is less glamorous than a big build thread, but it is a cleaner signal for the kind of work I want more of: scoped debugging, code review, static analysis, test repair, and small infrastructure fixes that actually land.

Disclosure: I used AI assistance to organize this private article draft. The current count should be rechecked against the OSS contribution ledger before publishing.

What merged PRs teach that local projects do not

Morgan — Fri, 03 Jul 2026 20:09:36 +0000

Local projects are useful, but they are too forgiving.

If I own the repo, I can choose the architecture, the naming, the test strategy, and the tradeoffs. That is good for building. It is not always good for proving I can work inside someone else's system.

Merged upstream PRs are different.

You do not get to decide that the repo should use your preferred style. You do not get to rewrite the surrounding code because it would make your fix prettier. You have to understand the local pattern and make the smallest change that fits.

That constraint is the value.

The most useful fixes in my OSS ledger are all narrow:

preserve empty-string entries in Conform array submissions
skip side-effect-free external imports in Rollup when hoisting is disabled
avoid crashing no-unresolved case checks on EACCES / EPERM
allow scoped package names in JSDoc declaration-reference inline tags
handle object-shaped not schemas in swagger-typescript-api
avoid false positives in require-meta-* when meta object spreads cannot be resolved
format structured command entries in Cline history export

Each one forced a slightly different kind of reading.

Some were about parser behavior. Some were about test fixtures. Some were about error handling. Some were about not assuming a static analysis rule knows more than it actually knows.

That last part has been the recurring lesson. The fix is rarely "make the tool smarter" in the abstract. The fix is usually "make the tool honest about this one boundary."

That is also why I like OSS proof for developer-infrastructure work. A merged PR is small, but it is not private. Someone else accepted the tradeoff. Someone else decided the test was enough. Someone else now has to live with the change.

That does not make it a perfect signal. It does make it a better signal than a private screenshot.

Disclosure: I used AI assistance to organize this private article draft. The examples and current PR count should be rechecked against the OSS contribution ledger before publishing.

The checklist I use before sending a small OSS PR

Morgan — Fri, 03 Jul 2026 20:01:48 +0000

Small open-source PRs look easy from the outside because the diff is usually small.

The diff is not the work.

The work is getting to the point where a maintainer can review it without having to guess what you changed, why it is safe, or whether you accidentally dragged in unrelated cleanup.

The checklist I keep coming back to is boring:

Reproduce the issue before changing code.
Find the smallest behavior boundary that explains the bug.
Add or adjust the focused test first if the repo makes that practical.
Keep the patch narrow, even if nearby code is tempting to clean up.
Run the local checks that match the touched area.
Re-read the diff like the maintainer has never seen your reasoning.
If the PR body needs a paragraph to explain why half the files changed, the patch is probably too wide.

That checklist has mattered across very different fixes: React Router SSR scripts, ast-grep pattern validation, ESLint rule edge cases, JSON schema defaults, Playwright optional chaining, and reporter output in knip.

The pattern is the same even when the libraries are different. A good small PR proves one thing.

It does not try to be a resume. It does not fix the whole subsystem. It does not turn a maintainer issue into a platform for everything you noticed while reading the code.

That restraint is practical. Maintainers are already carrying the whole project in their head. The cleanest contribution is usually the one that removes one sharp edge and gives them enough evidence to trust it.

Disclosure: I used AI assistance to organize this private article draft. The examples should be rechecked against the OSS contribution ledger before publishing.

Small open-source fixes are a better signal than a big portfolio claim

Morgan — Fri, 03 Jul 2026 19:54:52 +0000

I have been using small upstream PRs as a forcing function for proof.

Not big rewrites. Not "I built a platform" posts. Just narrow bugs in real repositories, with a test, a focused patch, and whatever cleanup the maintainer asks for.

That has been more useful than I expected.

The main reason is that a merged PR carries constraints a portfolio project usually does not. You have to fit the repo's style. You have to reproduce the issue. You have to keep the diff small enough for someone else to review. If the maintainer asks for a different shape, the answer is not to argue with your original idea. The answer is to understand the invariant they are protecting.

The fixes that taught me the most were not flashy:

a React Router nonce fix for default SSR fallback/error scripts
an eslint-plugin-import fix that reported the runtime package name instead of @types/*
an ast-grep fix that rejected root multi-metavariable patterns at pattern creation
an eslint-plugin-regexp fix around matchAll().toArray() capture-group usage
a react-jsonschema-form fix for nested defaults through conditional allOf schemas
an eslint-plugin-playwright optional-chaining fix in missing-playwright-await
a knip reporter fix that always prints single-group titles and counts

None of those sound like a launch. That is the point.

They are small enough that the hard part is not architecture theater. The hard part is proving the exact behavior, avoiding unrelated churn, and making the change obvious to someone who has to maintain the project after you leave.

My current ledger is 25 merged upstream PRs, with more still open. The number matters less than the shape: real maintainers, real review, real constraints.

For paid work, I trust that signal more than a polished demo. A demo shows what I can build when I own the whole frame. A merged upstream PR shows whether I can enter someone else's frame, fix one thing, and leave the codebase easier to maintain.

Disclosure: I used AI assistance to organize this private article draft. The OSS examples and counts should be rechecked against the contribution ledger before publishing.

Agent cost bugs are debugging bugs

Morgan — Fri, 15 May 2026 13:46:43 +0000

A coding agent does not need to bankrupt you to create a cost bug.

It just needs to make the run impossible to explain.

You see the number on the invoice. You see the "done" in chat. You cannot connect them.

Cost is not only billing

When developers talk about agent costs, the conversation usually drifts toward dashboards and rate limits — invoice-shaped problems with invoice-shaped fixes. That framing hides the actual pain.

The pain in real workflows is closer to this: an agent runs, something happens, the bill or the environment changes in a way you did not expect, and you cannot quickly tell why.

The fix is not a fancier billing UI. The fix is a record of what the run actually did.

I keep noticing the same four shapes show up under "cost." All four are really debugging bugs.

Four failures that look like cost but are really run-truth failures

1. Unexpected token budgets

A developer sends one image to a vision-capable model and watches the prompt-token count balloon to something they did not predict. The docs say one thing; the meter says another. They are left manually reconciling published documentation against observed billing.

That is not a billing problem. That is a "what did this run actually consume?" problem. The run did not carry its own accounting. The developer is doing post-hoc forensics with whatever scraps the chat history preserved.

This shows up repeatedly in vendor forums. There is nothing exotic going on — properly formatted requests, supported image sizes, normal API surfaces — and the result still surprises. Without a per-run record that ties the call shape to the observed cost, the conversation is forced upstream into "is the model overcounting?" instead of staying local where it could be diagnosed.

2. Credits or usage attached to the wrong workspace

You are working in one client. You buy more usage. The credits land on a different account, or the same account in a different workspace, or the same workspace in a different surface. The work is paused while you try to figure out which identity owned the run.

This is not a credit-card issue. It is an identity attribution issue masquerading as a money issue. The run did not record which workspace, which account, which environment was actually active when it spent budget.

When attribution is invisible at run time, the only recovery path is a vendor support ticket. That is fine occasionally. It is a productivity disaster as a default mode.

3. Local processes that keep running after the agent is done

You finish a session in a desktop client. You close it. Hours later you notice a Python interpreter still using memory, still doing whatever the agent was doing when the window closed. No one is watching it. No one billed for it on paper. But the laptop is doing work nobody asked for, and the agent that started it has no idea it left a tail.

That is a cost in machine resources, in attention, in trust. And it is invisible to every vendor dashboard because it is local-by-definition. The only way to surface it would be a run record that says "I started a subprocess, here is its handle, here is what should happen to it when I exit."

Today nothing in the agent stack writes that down. You discover the leak by looking at Activity Monitor and asking yourself, "what is this and where did it come from?"

4. Model swaps that change production behavior

A team updates a model version. Same API, same prompts, same client code. Behavior drifts. The new model is faster, or cheaper, or differently-tuned, and it stops doing the part of the job everyone was relying on without saying anything.

This is not advertised as a cost issue, but it is the same family. The cost of the change shows up as a quality regression in production. The team is running tests after the fact to figure out what shifted. The model swap was framed as low-risk because the surface stayed the same.

A run record would not prevent the regression. But it would make the diff readable. You would have a frozen record of what the old model did and what the new model does, attached to the same run shapes, instead of a slow reconstruction from chat memory and prod logs.

What these have in common

All four are easy to describe and surprisingly hard to debug, and the reason is the same.

The agent ran. The vendor saw the call. The chat saw the prompt. None of those views capture the things you actually want to look at when something costs more than expected:

the active identity at run time (account, workspace, branch, worktree)
the call shape (model, parameters, attachments, sizes)
the process footprint (what was spawned, what is still running)
the observed cost (tokens, time, anything that crossed a threshold)
the deviation from baseline (last week this same run cost X)

That set is small. None of it is exotic. None of it requires a hosted dashboard. It just has to exist somewhere a person can read it in two minutes and the next agent can re-use.

What a useful run record would capture

I keep coming back to a boring shape:

Ask: <one or two lines of intent, not paraphrased>
Identity: <model, account, workspace, branch, worktree>
Inputs: <files read, attachments sent>
Calls: <tool / API calls with model attribution>
Outputs: <diffs, generated artifacts, where they ended up>
Verification: <tests, lints, build, browser checks>
Cost footprint: <tokens, wall time, surprising spikes>
Process footprint: <subprocesses started, still running>
Open risks: <what the agent suspects but did not confirm>
Next-agent handoff: <first three things a fresh agent should do>

Plain markdown. One file per meaningful run. Human-readable first, structured enough for the next agent second.

The point of the cost footprint and process footprint sections is not to replace the invoice. It is to let you say, with the run in front of you:

Of course it cost that much — look at this 66K-token input.
Of course it billed the wrong workspace — the run shows the other one was active.
Of course there is a leaked subprocess — the run started one and never recorded it being torn down.
Of course production drifted — the run identifies a model swap and the verification field is empty.

That is what "cost is a debugging problem" looks like in practice. The bill is the headline. The record is the diagnosis.

The smallest thing I would build

I would not build a dashboard. I would write a small per-run markdown file with the shape above, locally, and stop.

No sync server. No vector store. No vendor lock-in. No new schema until the markdown shape has survived three real runs without changing.

If that file existed, every "why did this cost X?" question would have a place to start that is not "let me scroll back through chat history." Most of the cost surprises above would stop being mysteries.

The reason this is not a product yet is the same reason it is interesting: nobody has accepted that agent cost is a local-debugging surface. Vendors think it is their billing UI. Observability tools think it is a span. Memory products think it is something to retrieve later. None of them write the boring per-run file that would close most of the open questions.

Closing

If your agent is burning money in a way you cannot explain in two minutes, the problem is not your budget. The problem is that the run did not write itself down.

Cost bugs are debugging bugs. The fix is run truth.

If you have hit any of the four failures above and patched around them differently — I want to hear about it. The shape of the right artifact is still up for grabs.

Agents need a black box recorder, not more memory

Morgan — Thu, 14 May 2026 20:21:21 +0000

Every agent product eventually ends up talking about memory.

Longer memory. Better memory. Shared memory. Vector memory. Persistent memory.

I get why. Anyone who has used coding agents for real work has hit the same
wall: the agent loses context, forgets what happened in another client, repeats
itself, or makes a change that is hard to reconstruct later.

But I think "memory" is the wrong primary frame.

The more useful question is:

After the run is over, can I answer what happened?

Not just what the final answer was. What actually happened.

What did the user ask?

What files, tools, docs, and prior context were in play?

Why did the agent call a tool?

Which model produced that action?

What changed?

What did it cost?

Can I replay, audit, or explain the chain?

That is less like a second brain and more like a black box recorder.

The pain is showing up everywhere

The agent tooling conversations I keep seeing are not only about storage.
They are about operational trust.

One MCP discussion described the problem of context being trapped inside one
client. You can brainstorm on mobile, continue in the web app, then open a
coding agent locally and it has no idea what just happened.

That is not just a memory problem. It is a continuity problem.

Another thread proposed standard audit context for AI-initiated MCP tool calls:
why the AI invoked a tool, and which model produced that invocation.

That is not just a logging problem. It is an accountability problem.

Other threads are circling server identity, tool provenance, permission specs,
and tool bills of materials. People are asking questions like:

Who published this tool?
Did its metadata change?
What capabilities does it require?
Why should an agent be allowed to call it?

That is not just a security problem. It is a trust problem.

Then there are the everyday developer headaches: unexpected token usage, credits
attached to the wrong workspace, orphaned local subprocesses, tool calls that
worked in one environment but not another.

That is not just observability. It is run truth.

"Memory" hides too much

When we call all of this memory, we flatten several different needs into one
word.

Developers do need agents to remember useful context.

But they also need agents to preserve the reasoning trail around important
work:

task intent
active context
files and tools touched
model/tool calls
permission and trust assumptions
cost/token/process anomalies
receipts for important actions
a replayable or inspectable run history

Those are not all the same feature.

An agent can remember a fact and still be impossible to audit.

An agent can summarize a conversation and still leave you unable to explain why
it deleted a file, called a tool, burned tokens, or trusted a server.

The product shape I want

The layer I want is local-first and boring in the best way.

It sits under agent work and records enough truth that the user or another
agent can come back later and ask:

What happened here?

And get a useful answer.

Not a hallucinated summary. Not a vague activity feed. Not a giant dashboard
about dashboards.

A compact chain:

The user asked this.
The agent saw this context.
It chose these tools for these reasons.
These tool calls happened.
These files or external states changed.
This was the cost/runtime footprint.
These actions were approved, deferred, or blocked.
This is what a future agent should trust or re-check.

That would make agents safer to use for real work.

It would also make them easier to improve, because the failures would be
visible:

lost context
stale assumptions
wrong tool trust
runaway cost
missing approval
environment drift
actions with no durable deliverable

The phrase I keep coming back to

Agents do not only need memory.

They need a local truth layer.

Something closer to:

inspect, replay, and trust agent work across tools and clients.

That is the direction I am exploring with AMK.

The goal is not another knowledge base. The goal is to make "what happened?"
answerable after the run is over.

Because once agents are doing real work, that question matters more than almost
anything else.