Attebury

Attepack: shared packet envelopes for JSON-first tools

2026-07-27T00:00:00Z

Attepack is now open source.

I built Attepack because several open tools used the same JSON packet shape. The tools did not share the code that builds and checks that shape. Remogram emits forge facts. SkillPress and ReleasePress emit status and receipt packets. Each tool needs type, schema_version, observed_at, and ok. Each tool needs stable error codes when a command fails. Each repository kept its own copy of the envelope builder. Some copies were partial. Some copies were out of date.

The pattern

Error output is one example. A command fails on a bad path or a missing config key. The error message includes a home directory path. The error message also includes a token from the environment. The packet says ok: false. The leak is already in error_message. The agent logs the JSON. The secret leaves the workspace.

Mutation is a second example. A tool changes forge state or writes a local file. The CLI prints success prose. Nothing records what changed. Nothing records what was intended. Nothing records whether readback matched. You cannot audit the action later except from shell history.

Facts versus diagnostics is a third example. A routing failure uses the same envelope as a forge fact. Downstream code treats a diagnostic event as if it were a forge fact. The packet shape does not mark the boundary.

What Attepack is for

Attepack puts the shared packet code in one library. The library can:

Build and validate a packet envelope.
Use one error code registry.
Clean error messages and detail fields through Atteguard text-safety.
Build mutation receipts with digests and readback status.
Build diagnostic events and emit them through execFile. It does not emit through a shell string.

Attepack is a library. It is not a CLI. It does not hold your domain logic. Remogram still owns forge fact types. SkillPress and ReleasePress still own their status and receipt types. Attepack owns the envelope, the error shape, and the shared clean-up around both.

Example

A forge read fails because write commands are not configured. The tool must emit a structured error. The tool must not echo the config text or the workspace path.

import { buildErrorPacket } from "attepack";

const packet = buildErrorPacket({
  type: "example.forge_facts.v1",
  ok: false,
  errorCode: "write_not_configured",
  errorMessage: "Write command is not listed in config",
  providerId: "gitea",
  remoteName: "origin",
  repoId: "owner/repo",
  details: {
    write_command: "cr_open",
    remediation: "Add cr_open to write_commands in .example.json",
  },
});

Attepack normalizes the error code. It removes paths and secrets from messages and from allowlisted detail fields. It keeps the envelope shape the same as a success packet. Automation can branch on error_code. It does not need to parse prose.

Fact packets, mutation receipts, and diagnostic events stay separate. Fact packets answer what the forge observed. Mutation receipts answer what changed and whether readback verified it. Diagnostic events answer what failed in command routing. Attepack gives each one a shape. Your tool still owns the policy for when a mutation is allowed.

Install steps, subpath exports, module layout, and API detail are in the README.

Start here: github.com/attebury/attepack#readme

Atteguard: trust-decision primitives for agent tooling

2026-07-26T00:00:00Z

Atteguard is now open source.

I built Atteguard after a security review across Remogram, SkillPress, ReleasePress, and related open tooling. The same defect type appeared in many repositories. A tool had a real guard for a trust decision. Then a second path into the same decision did not use the guard. The second path trusted data from the caller. Or the second path used a short check that failed when a symlink or a flag injection was present.

The pattern

Path containment is one example. You write a check that keeps output inside a trusted root. A symlink inside the root points outside the root. A weak check compares the candidate path to itself and accepts it. The write still leaves the root.

Command execution is a second example. You allow only approved argv in the main command path. A helper builds a shell string. A test fixture sends a ref that starts with -. Git reads the ref as a flag.

Signature verification is a third example. You verify a signature packet. The verifier reads the public key from the packet that it verifies. An attacker makes a key pair, signs data, and puts that public key in the packet. The check accepts the signature for the wrong reason.

What Atteguard is for

Atteguard puts the shared repairs in one library. The library can:

Keep a path inside a trusted root when symlinks are present.
Scan text for secrets and remove secret data before you show the text.
Allow only approved argv templates. It does not accept raw shell strings.
Validate a git ref before a subprocess starts.
Verify a signature with a trusted key from your configuration. The trusted key must not come from the packet that you verify.
Read authority-claims.json and compare it to write call sites in source code.

Atteguard is a library. It is not a CLI. You import the module that you need. You connect that module in your tool. Atteguard gives you the guard code. Your tool must still put that guard on every path that needs it.

Example

A tool exports files from a trusted workspace root. An agent sends work/report.json. The path looks as if it stays inside the root. The directory is a symlink to /tmp.

import { resolveContainedPath, resolveCanonicalRoot } from "atteguard/path-safety";

const root = "/path/to/trusted-workspace";
const canonicalRoot = resolveCanonicalRoot(root);

const { canonical_path } = resolveContainedPath({
  name: "report",
  candidatePath: "work/report.json",
  root,
  canonicalRoot,
});
// use canonical_path for the read or write, not the raw agent string

Without the second check against the real path of the root, the export looks protected when it is not protected.

Each module includes adversarial tests named *.self-issued.test.js. These tests encode the exploit that the module must block. Pin an exact version. These modules are trust controls. An old install can look safe when it is not safe.

Install steps, subpath exports, module examples, release policy, and API detail are in the README.

Start here: github.com/attebury/atteguard#readme

Remogram: forge state as JSON facts for agents

2026-07-11T00:00:00Z

I'm open-sourcing Remogram. I built it because agents kept guessing about forge state, and the tools we had were built for humans reading prose in a terminal.

I run a local Gitea installation for most of my development work. That's been good for previewing changes and keeping public repos separate from the mess on my machine. But once agents entered the workflow, the forge became another surface that needed a contract. An agent doesn't need a paragraph about pull request #47. It needs to know whether the head is stale, whether checks finished, whether merge is blocked, and what the forge actually thinks the base and source refs are.

The official CLIs can get you there, if you're willing to scrape text and hope the format doesn't change. That's fragile, and it mixes up two jobs that shouldn't share a pipe: reading forge state and deciding what to do about it.

Remogram sits at the boundary. It talks to Gitea, GitHub, or GitLab through HTTP APIs and returns provider-attributed JSON facts. Read and plan by default. Writes are opt-in, listed explicitly in config, and gated so an agent can't merge or publish by accident because the command happened to exist.

remogram doctor --json
remogram repo status --json
remogram cr view --number 1 --json
remogram cr checks --number 1 --json
remogram merge plan --number 1 --json

doctor checks config, auth presence, provider capabilities, and write policy before you trust anything else. cr view reconciles forge-reported SHAs against your local git. If the head drifted, you get stale_head, not a silent lie. merge plan lists blockers. It doesn't execute a merge. mergeability: clean means the git side looks conflict-free. It is not permission to merge.

Every forge packet carries the same trusted envelope: type, schema_version, provider_id, remote_name, repo_id, observed_at, and ok. That's the part you build automation against. Titles, URLs, and descriptions are forge-sourced prose. Treat them as untrusted even when the envelope is good.

That's the distinction I care about. Remogram emits facts. Runlane, Worklane, and whatever planning layer you use can interpret intent and route work. Those concerns stay outside Remogram's JSON on purpose. You won't find lane roles, task ids, or handoff metadata mixed into forge packets. If planning concepts leak into the fact layer, every consumer inherits the wrong abstraction.

Remogram also ships as an MCP server. Same commands, same packets, same boundaries. Point it at a repo with .remogram.json and agents can inspect forge state without improvising shell pipelines.

Writes fail closed

The write surface is closed by default. If an agent tries a command that isn't listed in write_commands, Remogram doesn't guess. It returns write_not_configured and tells you what to add to config.

To opt in, name the commands explicitly:

provider capabilities --json shows what's implemented, what auth class each write requires, and how idempotency scanning is bounded:

Once configured, writes return the same kind of structured facts as reads. Open a change request:

Set a commit status:

The full packet still carries provider attribution and timestamps:

If you're dogfooding multiple CLI tools against a private forge while keeping public release paths separate, you've probably hit this already. You want agents to open a change request, read checks, and report blockers without becoming merge authority. Remogram is built for that narrow job.

It's early. The packets are strict. The write surface is closed by default. That's the point.

Source and docs: github.com/attebury/remogram

SkillPress: agent guidance as installable packages

2026-07-10T00:00:00Z

I'm open-sourcing SkillPress. I built it for the same reason I built ReleasePress: I had too many moving parts and not enough control over what was actually installed.

Once you're developing more than one CLI tool with agent skills, the skills stop feeling like documentation and start feeling like dependencies. Runlane has skills. ReleasePress has skills. Remogram has skills. They live in the repo under agent-skills/src, scoped by tool, with contracts and policy rules wrapped around them. That's the canonical source.

But agents don't read the repo. They read what's installed.

Codex looks in ~/.codex/skills. Cursor wants rules under .cursor/rules/skillpress. Claude Code has its own tree. Antigravity has another. Each surface wants a slightly different shape, and each one is easy to edit by hand when you're in a hurry. So we do. We patch the installed copy, tell ourselves we'll backport it later, and then we can't remember which machine has which version of which skill.

That's not a workflow. That's drift with extra steps.

SkillPress treats provider directories as install caches, not source. You edit skills in the repo. SkillPress syncs them to the right provider surface, records hashes in the installed header, and gives you commands to inspect what's stale before you trust it.

skillpress status --json --config skillpress.config.json
skillpress doctor --json --tool runlane --provider codex
skillpress sync --json --config skillpress.config.json --provider cursor --tool releasepress
skillpress repair-plan --json

status tells you what's installed and where. doctor runs policy checks against the source tree: frontmatter shape, unsafe command patterns, interactive prompts that'll block CI, that kind of thing. sync pushes canonical skills into a provider target. repair-plan is read-only. It tells you what needs a resync without rewriting anything behind your back.

SkillPress doesn't write the skills. It doesn't promote CLI binaries. It doesn't run lanes or decide merge authority. It owns one narrow job: get the right guidance onto the right surface, keep the install honest, and make drift visible before it becomes habit.

If you're running multiple agent tools against the same product repo, you've probably already felt this. You fix a skill in source, open Cursor, and nothing changes because Cursor is still reading yesterday's cache. Or you fix it in the cache because it's faster, and the repo falls behind. SkillPress is built to keep that boundary clean.

It's early. The policy packs are strict on purpose. The installed headers are there so you can see when a provider copy is lying to you.

Source and docs: github.com/attebury/skillpress

ReleasePress: local promotion and export hygiene for CLI tools

2026-07-09T00:00:00Z

I'm open-sourcing ReleasePress. I built it because I was running several CLI tools at once and kept stepping on my own feet.

When you're developing more than one tool in parallel, local promotion stops being a convenience and starts being a coordination problem. Tool B depends on a version of Tool A that's installed on your machine. You promote a half-finished change to A because you're testing B. Now B works, A is broken, and you're not always sure which install is which. I needed a way to control when and how tools were promoted locally, so a change to one wouldn't silently wreck another's use of it.

The same problem showed up at the boundary between private development and public release. I've been working against a local Gitea installation. That's useful, but it also means the repo on my machine is not the repo the world should see. Operator config, lane state, agent skills, scripts I wrote at midnight, all of it lives in the same tree. I wanted to choose what gets deployed publicly, preview it before it goes anywhere, and not treat "git push" as the same thing as "release."

ReleasePress is built for that. It exports a public tree from an allowlist, scans it for secrets and private paths, and publishes to a controlled destination for human review. Staging isn't delivery. Preview isn't publication. Nothing public moves until someone has actually looked.

The workflow is intentionally boring:

Export a public tree from your allowlist
Scan for secrets and private paths
Stage to a local or private review repo
Attest after a human has actually looked at it
Deliver to configured providers only when explicitly approved

releasepress release plan --json --config releasepress.config.json
releasepress release prepare --json --config releasepress.config.json --out /tmp/releasepress/public-tree
releasepress release publish-review --json --config releasepress.config.json --path /tmp/releasepress/public-tree --target public-review
releasepress release attest --json --config releasepress.config.json --path /tmp/releasepress/public-tree --target public-review --approve-public-review
releasepress release deliver --json --config releasepress.config.json --path /tmp/releasepress/public-tree --target npm-beta --approve-public npm-beta

Every step writes JSON receipts to .releasepress-report/. ReleasePress doesn't replace your build tools, your forge, or your package registry. It sits in front of them and keeps the boundaries explicit: what's local, what's under review, and what's actually public.

It's early. The contracts are strict and the gates fail closed. That's the point.

Source and docs: github.com/attebury/releasepress

Trace Turns Agent Runs Into Audits

2026-06-05T00:00:00Z

Agent work is easy to watch and hard to audit.

You can read the final diff, skim the transcript, count tokens, review tests. Those are useful signals, but they aren't enough.

The useful question is sharper: did the run deserve trust?

Trace turns a completed agent run into evidence that can be reviewed, compared, and improved.

The diff is not the whole run

A finished diff can look reasonable while hiding the cost of getting there.

Maybe the agent read half the repo before finding the right file. Maybe it asked for the same next action three times. Maybe it skipped the proof. Maybe it never used the scaffold named in the work packet.

The change may still pass.

That doesn't mean the workflow was good.

Agent performance is how the run moved through the work, not just the final output.

If the path was noisy, that noise is product feedback.

It may mean the packet was too broad. It may mean the next command was unclear. It may mean the docs hid the real workflow. It may mean the harness surfaced proof too late. It may mean the model did fine, but the operating surface wasn't decisive enough.

Trace gives that review somewhere to happen.

Trace is an audit surface

Trace reads a completed run and asks what actually happened.

It can look at run manifests, usage logs, tool results, model calls, proof outcomes, and transcripts when they exist. With an audit bundle, it can compare the observed run against the workflow context the agent was expected to use.

The command shape is intentionally direct:

topogram trace analyze <run-dir> --audit-bundle <bundle-dir> --json
topogram trace report <run-dir> --audit-bundle <bundle-dir> --format markdown
topogram trace compare <run-a> <run-b> --json

The input can come from any run that matters enough to inspect.

We want an inspectable run, not a perfect judge.

An audit should answer practical questions:

What did the agent actually read?
Which tools did it call?
How many model calls and tokens did it use?
Did it follow the expected workflow?
Did it run proof?
Where did it spend extra attention?
What would make the next run cleaner?

That moves review from vibes to evidence.

Token usage was the first clue

One reason I started using trace was practical: token usage is visible.

When an agent run uses far more context than expected, something usually happened. Maybe the packet was too vague. Maybe the agent searched broadly because the target wasn't clear. Maybe the docs pointed at the right concept but not the right file. Maybe the agent repeated the same command state because the next action wasn't decisive.

Token totals don't tell the whole story, but they're a useful smoke alarm.

The real value isn't this run used fewer tokens. A cheap run can skip proof. A costly run can produce durable learning.

The useful question is whether the tokens were spent on relevant context or on avoidable wandering.

Trace pairs usage with path evidence. It can show model calls, observed tools, files read, proof outcomes, and packet estimates together.

The team can see whether a token spike came from necessary work, weak guidance, or missing structure.

That makes token usage less like a scoreboard and more like a diagnostic.

Smells are product feedback

Trace reports attention smells. They're not hard failures by default, but they flag the need for further review.

A large actual-vs-packet token delta may mean the packet didn't localize the work.
Repeated next-action states may mean the next step wasn't decisive enough.
Excessive file reads may mean edit targets were too broad.
Skipped proof may mean the result is weaker than it looks.
Expected scaffold that wasn't used may mean generator status or harness gating needs review.

None of that automatically means the run was bad.

It means the run is telling us something.

If every smell becomes a gate, trace becomes another brittle compliance tool. If every smell is ignored, trace becomes decorative logging.

The useful middle is audit.

Ask what the smell says about the system. Then decide whether it should become a packet improvement, generator improvement, docs improvement, harness fix, or backlog note.

After-action record

The after-action record is the most important part.

After a meaningful agent run, the team should be able to answer a few basic questions without reconstructing the whole session from memory:

What context did the agent receive?
What context did it actually use?
Which files did it inspect?
Which tools did it call?
Which proof did it run?
Where did it spend attention that the packet should have avoided?
What should change before the next run?

That's a different posture from the diff looks fine.

The diff is the artifact. The trace is the path evidence.

Agent work creates a new review problem. The human may not have watched every step. The agent may have made reasonable choices for bad reasons. The tests may pass while the run still shows weak context, missing proof, or unclear ownership.

Trace gives the team a place to inspect that path.

If the run failed, ask whether the map, packet, scaffold, docs, or proof surface made failure more likely.
If the run passed, ask whether it passed with clean attention or got lucky.
If proof was absent, treat the result as weaker evidence.
If the agent had to read widely, ask whether the packet localized the work well enough.

The goal is to make the next run more explainable.

Auditing makes claims safer

I've been making a structural claim in my agent tooling work: agents can work better when they receive bounded context, ownership, contracts, and proof before editing.

That claim needs evidence.

Not just screenshots. Not just polished demos. Not just final diffs.

It needs auditable runs that show what the agent was expected to do, what it actually did, where it spent attention, what proof it ran, and what the team changed after learning from the result.

The loop is simple:

run -> trace -> inspect -> improve context -> run again

That's the maintenance workflow for agent-assisted software.

The map says what should matter. The audit bundle says what context the agent should have received. The trace says what the agent actually did. The report turns that difference into reviewable evidence.

If agents are going to change important code, we need to audit more than the final diff.

We need to audit the path that produced it.

Prompt Injection Is a Boundary Problem

2026-06-04T00:00:00Z

Prompt injection is easy to frame as a model problem.

The model read something bad. The model obeyed it. The model should have known better.

That's part of it, but I don't think it's the whole problem.

In an agent workflow, prompt injection is also a boundary problem.

The agent reads docs, source files, fixtures, generated reports, shared app maps, diffs, test data, local instructions, and packets prepared for model calls. Some of that text is useful context. Some of it is product evidence. Some of it may be malicious, stale, copied from somewhere else, or simply written in a way that sounds like an instruction.

The mistake is treating all readable text as authority.

The security work I've been doing tries to make that boundary explicit.

Evidence is not authority

The useful phrase is evidence, not authority.

Repo text can tell an agent what exists. It can describe requirements. It can show prior decisions. It can explain an edge case. It can include examples of unsafe behavior.

But repo text shouldn't be able to tell the agent to ignore system instructions, bypass proof, reveal hidden prompts, skip gates, weaken a skill, or send raw workspace context to a provider.

That sounds obvious until the agent workflow gets real.

Agents read a lot of project text. They read it quickly. They mix prose with tool output. They pass slices of that context into model calls. They may use external providers. They may adopt shared project maps. They may summarize findings back into new packets.

At that point, "just don't obey bad text" is too vague.

The system needs a boundary the workflow can inspect.

What changed in my thinking

The recent work adds that boundary in a few places.

First, a prompt-boundary scan.

It looks for project prose that appears to tell agents, tools, providers, or gates to do unsafe things. Examples include ignoring trusted instructions, revealing secrets, bypassing checks, weakening proof, overriding agent guidance, or hiding instructions in markup and code fences.

The scanner isn't pretending to be perfect.

It's a practical tripwire.

High-confidence cases block. Advisory cases stay visible. Security discussions and examples can remain as evidence. If a finding is intentionally present, the waiver has to be command-owned, tied to a task or bug, tied to an actor, and hash-bound to the exact finding.

That last part matters.

A waiver shouldn't become a blanket permission slip. If the source text changes, the waiver goes stale.

The inventory matters

An inventory of agent-facing prose surfaces sounds less exciting than a scanner, but it may be the more important piece.

You can't protect a boundary you haven't named.

The inventory says which commands and packets are model-visible. Some packets are agent-bound. They go to the coding agent as working context. Some packets are provider-bound. They leave the local workflow for a model provider.

Both need labels.

The inventory tracks whether JSON packets carry content trust, whether markdown output labels project-derived prose as untrusted evidence, and whether the surface has focused tests.

That creates a ratchet.

If a change adds or modifies an agent-facing surface, the workflow can ask whether the surface is registered, labeled, scanned, and tested.

This is the right kind of boring security.

Not "we hope the agent behaves." Not "we trust everyone to remember." A named surface has a named owner, named output formats, trust metadata, and proof.

Provider-bound packets need the same line

The provider boundary is where this gets more concrete.

Provider input is the packet the workflow allows out to an external model provider. It's the model-bound payload.

That payload shouldn't contain raw workspace context by accident. Local paths, secret-like values, hidden checks, git remotes, raw source fields, and unallowlisted output should stay out of provider-bound packets.

Provider input should be its own trust surface.

The packet carries content trust. The payload is scanned. The redaction report is auditable. If the audit fails, the payload is rejected instead of being sent anyway.

That's the right shape.

The boundary isn't only what did the agent read?

It's also what did the system send onward?

Shared maps are still untrusted until reviewed

Shared app maps are useful because teams want reusable records: terms, capabilities, workflows, rules, patterns, reference structures.

But shared doesn't mean trusted.

A shared map may come from another repo, another team, another version, or another context. It might be useful. It might also contain unsafe prose, authority files, or colliding records.

Shared map text should be a separate trust class.

The workflow can review a source, require a pinned hash, scan the imported records, block authority files, and write an adoption receipt. That keeps shared context from silently becoming project authority.

You can make context portable without making trust portable.

The useful standard

The goal isn't to make prompt injection impossible.

That would be too broad a claim.

The useful standard is smaller and stronger:

Agent-visible prose should be inventoried.
Project-derived text should be treated as evidence, not authority.
Unsafe authority-shaped text should be scanned.
External provider payloads should be sanitized and auditable.
Shared maps should be pinned and reviewed before adoption.
Waivers should be exact, reviewed, and stale when the source changes.

Model the app. Bound the context. Label the trust. Scan the prose. Audit the packet. Keep exceptions narrow.

Prompt injection isn't only about bad text.

It's about whether the workflow can tell the difference between context that helps the agent and text that's trying to steer it.

One Graph, Many Native Surfaces

2026-05-30T00:00:00Z

Cross-platform frameworks have always chased a hard promise: build once, reach many platforms.

Frameworks like .NET MAUI, Flutter, React Native, and earlier hybrid stacks try to reduce the cost of shipping web, iOS, Android, and desktop apps. They package platform differences behind shared code, shared components, or shared runtime layers.

That has real value.

But AI may change the thing we most need to share.

If agents can produce more of the implementation, the most valuable shared asset may not be one UI framework.

It may be one product graph.

Shared code is not shared intent

Shared code solves a real problem. It reduces duplication. It keeps business logic from being rewritten four times. It can help a company ship a mobile app without building separate native teams from scratch.

But shared code also creates pressure.

The app may feel less native. Navigation may get awkward. Accessibility, gestures, offline behavior, and performance may not line up cleanly across targets. The team can spend as much time working around the abstraction as using it.

That doesn't mean cross-platform frameworks are wrong.

It means shared code is not shared product intent.

The better question is: what should actually be shared?

The shared layer may move up

The useful shared layer may move above the UI framework.

Instead of asking one framework to make every platform feel right, teams may ask one graph to describe what should stay true.

The graph should answer:

Which capabilities exist.
Which entities and workflows matter.
Which surfaces users need.
Which widgets and states belong on each surface.
Which rules constrain behavior.
Which accessibility and localization promises apply.
Which proof says the experience works.

From there, agents or generators could produce different native outputs.

The web app could use web-native patterns. The iOS app could use iOS-native navigation and controls. The Android app could use Android-native conventions. The desktop app could use desktop affordances.

The shared layer wouldn't be a lowest-common-denominator UI. It would be the product map.

Agents may work better natively

An agent working on an iOS app may be more effective in a native iOS environment than inside a generic cross-platform abstraction. The compiler, simulator, platform APIs, accessibility tools, and design conventions all give the agent stronger feedback.

The same may be true on Android, desktop, and web.

The agent doesn't have to guess whether a custom abstraction maps cleanly to the platform. It can work with the platform directly. It can run platform-specific tests. It can inspect native warnings. It can use native components the way a human specialist would.

But that only works if the agent has a shared source of intent.

Without one, every native surface becomes its own interpretation of the product. The iOS app drifts. The web app drifts. The Android app drifts. Desktop becomes the odd surface nobody quite trusts.

Native output is powerful only if we can keep the product coherent.

One graph, many native surfaces

The possible shape is one graph, many native surfaces.

The graph describes the product. Each surface implements that product in the right platform language.

That could mean:

One capability appears on web, iOS, Android, and desktop.
Each platform gets native layout, navigation, and interaction patterns.
Shared rules define behavior, not pixels.
Surface records describe what each platform owes the user.
Agents generate or maintain platform-specific code from the same intent.
Reviewers compare each output against the graph and proof.

This isn't write once, run everywhere.

It's closer to spec once, realize everywhere.

The implementation can differ. The product contract should not.

What happens to .NET MAUI

This isn't an argument that .NET MAUI goes away.

Frameworks like .NET MAUI solve real problems. Some teams want a unified codebase. Some apps are similar enough across platforms that one framework is the right tradeoff. Some organizations would rather accept platform compromises than staff multiple native surfaces.

AI doesn't erase that.

But it may create another path.

A team may not need one cross-platform UI layer for every target if agents can help maintain several native targets from the same product graph.

That changes the tradeoff.

The question may stop being: which framework lets us share the most code?

It may become: which shared graph lets us keep the most product coherence while each platform stays native?

A possible shape

If AI keeps lowering the cost of implementation, cross-platform development may become less about one runtime and more about one coordinated source of truth.

Some teams will still use frameworks like .NET MAUI because shared code is the right constraint. Others may choose native surfaces because agents can carry more of the implementation load.

In that world, the valuable asset isn't just the app code. It's the graph that tells every surface what should stay true.

The future may not be one app that runs everywhere.

It may be one product map that helps every surface feel like it belongs.

Feature Waves, Not Big Releases

2026-05-29T00:00:00Z

If software work keeps compressing, release planning may change too.

The old pattern is familiar. A company plans a release. The release collects features, fixes, migrations, compliance work, and cleanup. Some of that work belongs together. Much of it doesn't. It ships together because the process, calendar, or staffing model needs a bundle.

AI may weaken that bundle.

Not because planning disappears. Not because releases disappear everywhere. But because the useful unit of coordination may become smaller, more coherent, and more fluid.

The memorable shape is feature waves.

The bundle starts to break

Big releases often mix unrelated work because teams are organized around scarce stack capacity. One team owns the front end. Another owns the API. Another owns data. Another owns infrastructure. A feature crosses those stacks, waits for availability, collects dependencies, and eventually joins a release train.

That made sense when the stack boundary was also the people boundary.

If AI lowers the cost of crossing stack boundaries, that boundary may matter less. A product owner may not need to wait for a Python specialist to make a small API change. A designer may not need a dedicated front-end engineer for every component state. A developer may not need hours of repo reading before touching unfamiliar code.

That doesn't make the work easy. It moves the coordination problem.

The hard question may shift from who knows this stack to who understands this wave.

A wave is a coherent change

A feature wave isn't just an epic with a better name. It's a coordinated slice of product intent, system change, and proof.

It might include:

A product need or customer problem.
The workflows and screens affected.
The capabilities, data, and rules that have to change.
The tests, proof, and review criteria that define done.
The people taking temporary responsibility for product judgment, code, design, and verification.

The wave is organized around what should become true, not which team owns which layer.

That makes it feel related to continuous deployment, but at the level of product change. Continuous deployment made it normal to push small code changes quickly. Feature waves may make it normal to push small coherent product changes quickly.

Roles may rotate around the wave

If this happens, teams may organize less around permanent stack ownership and more around temporary responsibility.

For one wave, the strongest Python developer may lead the code path. Someone else may act as product owner and reviewer. A designer may own the user experience and acceptance criteria. An agent may do the mechanical implementation after the team names the boundaries.

For the next wave, those roles may change.

The person who reviewed the Python change may lead implementation for a TypeScript feature because they know that product surface best. The strongest engineer may step back from coding and focus on proof because the riskiest part of the wave is behavior, not syntax. A domain expert may drive the requirement while an agent handles scaffolding and tests.

The team becomes less like a static org chart and more like a small group forming around the shape of the work.

If AI makes unfamiliar stacks less costly to work in, experience may matter differently. Deep technical judgment still matters. But the most useful person for a wave may be the person who understands the need, the boundary, or the proof best.

Fluid work needs stronger memory

This is where the speculation gets uncomfortable.

If work gets more fluid, coordination has to get better. Otherwise the team just moves faster into confusion.

The old system had friction, but some of that friction was useful. Stack ownership created memory. Release gates forced review. Specialists knew where the sharp edges were. Slow handoffs made people explain what they were doing.

AI can remove some of that friction. It can also remove some of that memory.

So the team needs another way to preserve structure:

What wave is this change part of?
What product need justifies it?
Which surfaces, workflows, entities, and rules are affected?
Who is acting as product owner, implementer, designer, and reviewer?
What proof says the wave is done?
What should not change?

Those questions become more important when roles are fluid. You can't answer them only in chat and expect the answers to survive the next wave.

A possible shape

AI-assisted teams may not move from big releases straight to chaos. They may move toward smaller coordinated waves.

One wave improves onboarding. Another changes billing. Another cleans up permission boundaries. Another updates a design system pattern across a few surfaces. Each wave has product intent, affected scope, owners, and proof. Each can move quickly because it doesn't wait for a large unrelated bundle.

That future isn't guaranteed. Some domains need formal releases. Some teams will keep stack ownership because the cost of mistakes is high. Some work will always require deep specialist experience.

But if software work keeps compressing, the team may stop asking, "Which stack team owns this?"

It may start asking, "What wave are we in, who is strongest for this part, and what proof makes the change true?"

When Software Work Gets Shopified

2026-05-28T00:00:00Z

AI can feel like a break from software history, but I think it's more useful to see it as a continuation.

We've been compressing roles for decades. We used to pay one person to design a website, another to code it, another to wire forms, another to publish content, and another to keep the stack running. Then blogs, CMS tools, hosted site builders, and services like Shopify absorbed large parts of that work.

The work didn't disappear. It moved into platforms.

Design became themes and systems. Content publishing became an editor. Commerce became a configured service. Hosting became a deploy button. A single operator could do work that once required a small web team.

AI may do something similar to software development.

Role compression is the pattern

The important pattern isn't replacement. It's compression.

When platforms mature, they package repeated work into defaults, workflows, and constraints. The old specialist work becomes a product surface. A smaller team can operate at a higher level.

That's what happened to many websites. The average business no longer needs a dedicated designer, front-end developer, back-end developer, hosting operator, and analytics consultant just to sell products online. Shopify compressed much of that into a service.

AI can compress software work in a similar way:

Scaffolding becomes a prompt or template.
Boilerplate implementation becomes generated code.
Refactoring becomes an agent task.
Test creation becomes a guided loop.
Documentation updates become part of the change.
Design translation becomes a conversation with constraints.
Investigation becomes a context query instead of hours of repo reading.

If that's accurate, entire areas of software development will get platformed. Not all of software, and not all of engineering judgment. But many repeated slices of implementation, maintenance, migration, and glue work will get absorbed into tools and workflows we haven't fully named yet.

What teams might look like

Smaller teams may cover more surface area.

One person may own product shape, user experience, and implementation for a bounded feature. Another may own platform rules, security posture, release quality, and proof. A designer may work directly with generated components and semantic UI contracts. A domain expert may author workflows and acceptance criteria that agents turn into code.

The team becomes less like a row of specialists passing tickets downstream and more like a small group of operators coordinating systems.

That doesn't make engineering easier. It changes where the difficulty lives.

The hard parts move from reading requirements and typing code to choosing intent, setting boundaries, reviewing generated work, proving behavior, and keeping the system coherent through time.

In that world, the riskiest gap isn't whether an agent can produce code. The risk is whether the agent is changing the right thing for the right reason, in the right part of the system, with the right proof.

Where AI needs structure

AI coding tools are good at local transformation. They edit files, write tests, explain code, and propose refactors. They're less reliable when the work depends on product intent, ownership, unstated decisions, or system boundaries.

That's where role compression gets messy.

If one person uses AI to do the work of several roles, that person needs more than a faster editor. They need a way to keep the compressed roles from blending together into guesses.

The product decision shouldn't disappear into the implementation. The implementation shouldn't invent the contract. The contract shouldn't ignore proof. Proof shouldn't be an afterthought.

AI makes those separations more important, not less.

What we still have to carry

I've been building tools for agentic development partly because of this compression. When fewer people cover more roles, the team needs durable answers to boring questions:

What should be true after this change?
Who owns this boundary?
What proof counts as done?
What context is safe to give an agent, and what is only evidence?

You can answer those in tickets, chat, and memory for a while. Then the team moves faster and the answers stop matching the code.

Compressed teams still need a map of what they're building. AI can help produce the code. We still have to know what should be true, who owns it, what rules apply, and how to prove the change is done.

That's not a product pitch. It's the problem I'm working in.