DEV Community: Satoshi Konno

Inside a Persistent AI Agent: Reading MUSE Through Its Harness

Satoshi Konno — Fri, 13 Nov 2026 17:50:32 +0000

A personal AI agent needs continuity: recovering a task, remembering a correction, using a connected service and returning to work later. A model call alone does not provide these capabilities. A surrounding execution system—the harness—selects context, runs tools and retains the state needed for another turn.

Scope and evidence. This unofficial study combines Meta’s public information, a supplied MUSE interview memo, and research and follow-up interviews that Dots, an AI assistant, conducted with MUSE. MUSE answered the documented questions about its own operation; receiving an answer is not independent verification or publication permission. Dots also operated and observed the limited Spaces experiment in §5 at the user’s request. Internal descriptions remain MUSE’s account unless a cited official source or identified UI observation supports the specific claim. Dates and roles appear in Sources and scope, with terms-review limits below; the private research archive is neither reproduced nor linked.

At a glance

The five sections follow the work from a model decision to retained state and a revisitable application. This map highlights what each layer contributes, with links to the mechanisms and evidence behind it.

Section	Key takeaway
1. Execution loop	MUSE describes a harness that assembles context, executes permitted tools and inspects results around model decisions. Continuity comes from coordinating execution with retained state.
2. Tools and connections	MUSE reports on-demand function schemas and document-driven connector commands, with Skills guiding both. Its 112-name catalog counts executables, not model functions; capability loading, action approval and service authorization are separate.
3. State and memory	MUSE reports PostgreSQL records alongside persistent files, while only selected material enters model context. Corrections must update source records and dependent summaries: useful memory requires selection and maintenance as well as storage.
4. Background work	MUSE distinguishes triggers (Cron/Hooks), retained purpose and progress (Goals), and reading or proposals (Feed/Ideas). Continuing work combines these separate responsibilities; a saved goal is not itself a trigger.
5. Spaces continuity	Meta describes revisitable personal features. Dots observed one note and its completed state survive reopening and a heading-only rebuild in the synthetic app. This demonstrates that limited case; restart recovery and schema migration were not tested.

The central distinction is between retaining information and bringing the right information back into an execution. The Spaces experiment provides a concrete, limited example of that continuity; the preceding sections explain the surrounding responsibilities.

1. Architecture and the execution loop

Meta’s Muse overview describes a persistent VM and browser, connected applications, background work and permission controls. MUSE’s interview account assigns the surrounding loop to a harness that assembles context, runs permitted tools and checks results. The model chooses a next step; the harness connects that choice to execution and retained state.

From a request to the next decision

In the reported loop, a request leads to context assembly, model selection of an action, tool execution and inspection of the returned result before the next decision. Delegation and JavaScript workflow execution are available in the account, without implying that every request follows a fixed graph or uses several agents. Tool selection and a successful operation are separate events.

Execution and retained resources

The execution environment, durable stores and model input have different roles. The reported PostgreSQL records organize conversations and runtime state; persistent files hold memory and work products; browser state and job definitions have their own lifetimes. The harness connects these resources to inference. A checkpoint and the records it references may both be needed to resume work; the interview supplies no transaction or recovery guarantee across them.

Following an execution

The memo also describes execution identifiers, parent–child agent relationships, tool records, token counts, job history and diagnostic logs. These provide a reported basis for tracing the loop, without establishing a user-facing trace viewer, complete audit coverage or tamper resistance.

2. Tools and connections to external services

MUSE describes two routes for supplying tool instructions: load a native function schema when needed, or read connector documentation and construct a CLI command. Skills guide both routes, while browser, Computer Use and private-network access reach different environments. These capabilities remain distinct from approval and service authorization.

Two routes from capability discovery to execution

A machine-readable function schema and a connector command are different ways to make a capability usable. The table separates those routes from the Skills that guide them, the context that informs them and the results returned afterward.

Layer	Information reportedly supplied to the model	When and how it is loaded	What it enables, and what it does not establish
Native function tools	Function names and JSON schemas for core capabilities, such as chat, browser operations, artifacts and schedules	The interview describes namespace-level lazy loading; `tool_search` loads the relevant schema when needed	The model can select a function and form its arguments. This is not the same inventory as the 112 filesystem names. Exact request encoding and complete schemas remain unavailable.
Service connector CLI	`CONNECTOR.md`: command syntax, flags, account selection, permissions, output format and operating rules	The interview describes reading the relevant document for the task; the model then constructs a command for a shell-execution tool	The executable calls the service and returns a tool result, often structured JSON. The memo explicitly says this is not a wholesale dump of `--help` into context.
Skills	Short descriptions for discovery, followed by a Markdown procedure in `SKILL.md`; optional references and scripts	The Skill answer describes descriptions in context, choosing the most specific applicable Skill, and `skill_search` when needed. The package comparison reports separate `skill.yaml` metadata including `include_in_prompt`	A Skill guides decisions and tool use; its existence does not make it an executable or prove Agent Skills conformance. The separate-metadata layout is a reported difference from the specification.
Core context and retrieved detail	Core identity, user and memory files plus compact indexes; relevant detailed records and documents	The context answer distinguishes routinely supplied core context from on-demand retrieval	`TOOLS.md` is described as environment guidance, not as the full list of machine-readable tool schemas. Retained content is not necessarily included in every inference request.
Results returned to the model	Tool outputs, often JSON; for large outputs, bounded pages or file paths with coverage information	The service-connection answer describes interpretation of returned structured results; the context-management answer describes paging and retrieving only relevant portions	A returned result supports the next decision. It does not by itself prove success, authorized side effects or complete coverage.

For example, the reported Gmail connector document covers connection, account choice, permission checks, reading, drafts, sending, organization and result reporting. It is operational guidance as well as syntax, rather than a full --help dump in every request. The Agent Skills specification puts YAML frontmatter in SKILL.md; MUSE instead reports separate skill.yaml metadata, including include_in_prompt. This difference prevents inferring conformance from similar names. The MCP architecture distinguishes hosts, clients and servers; a wrapper or -mcp suffix alone does not identify transport or deployment.

An executable catalog, not a function catalog

The reported /opt/hatch/bin/ inventory contains 112 executable names, not 112 model functions. The original classification and complete inventory in Appendix A are retained:

Reported class	Count	Representative names
External-service connector CLI	66	`hatch_gws_cli`, `github`, `slack`, `gumroad-mcp`
Internal runtime	19	`hatch-execd`, `hatch-vault`, `spawnd`
Functional tool	27	`web-search`, `browser-service`, `media-generation`

An installed name does not establish a connected account or current support, and a runtime helper is not necessarily model-callable. Complete per-command contracts were not supplied.

Cloud browser, paired Mac and private-network access

The cloud browser belongs to the execution environment and retains its own browser state. Computer Use is described as a paired Mac application that obtains UI state, performs a local UI action and returns another observation, using macOS accessibility and screen-recording permissions. Background interaction, excluded apps and the absence of an arbitrary local shell are reported constraints. Tailscale is a separate, optional runtime-proxy route to private TCP services, not an established transport for Computer Use. Outbound-only operation, destination approval and restrictions on UDP, incoming traffic and exit nodes describe this integration; they are not a definition of Tailscale itself.

Approval is not service authorization

Operation approval and service authorization are distinct. OAuth scopes can permit a service operation while leaving approval for particular content or an action unresolved; approval in the agent interface cannot supply a missing scope. MUSE reports a separate credential store and protected credential references. Meta describes permission and credential protections at product level, while these internal mechanisms remain interview claims rather than a credential-isolation audit.

3. State, memory and context

Saving information is different from including it in model input. In MUSE’s account, PostgreSQL records and persistent files retain state while the harness selects core context, relevant detail and compacted history for inference. Memory correction also requires updating dependent summaries and checking later retrieval; storage alone does not keep every derived view current.

PostgreSQL: structured conversation and runtime state

The five reported tables divide continuity into chat identity, session identity, ordered context, summarized history and restart state. The overview below shows those responsibilities before the column-level definitions in Appendix B.

Reported table	Columns	Role
`chat.chats`	12	Chat identity and lifecycle
`agent.sessions`	5	Session identity, originating request and archive time
`agent.context_items`	21	Ordered context with message/tool references and content
`agent.compactions`	7	Summary and the history range it replaces
`agent.runtime_restart_checkpoints`	8	Per-agent restart state

The 53-column definitions in Appendix B preserve SQL types, constraints and reference distinctions. These are reported contents of a generated schema reference, not validated live DDL. Declared foreign keys enforce a different relationship from described logical or “soft” references; several targets lie outside the five-table excerpt. The chat/agent schema is not the Spaces application database.

Files: persistent home and replaceable system tools

The memo describes a persistent home containing USER.md for user information, IDENTITY.md and SOUL.md for agent attributes and tone, AGENTS.md and TOOLS.md for working conventions and environment notes, MEMORY.md for selected lasting facts, preferences and commitments, and PROACTIVE_PREFERENCES.md for unsolicited-contact preferences. User-created files and supplied system tools have different update lifetimes. These are reported conventions, not instructions to edit platform internals directly. The reported filesystem tree in Appendix C preserves the selected layout and role annotations supplied in MUSE’s answer.

The simplified layout below groups files by responsibility. The home directory holds user-specific state; /opt holds shared programs and definitions replaced on deployment, according to MUSE. It is a reading guide to the reported layout, not a newly captured filesystem listing.

~/                              User-specific persistent state
├── USER.md, MEMORY.md          User context and lasting memory
├── AGENTS.md, SOUL.md, …       Working conventions and agent identity
├── memory/                    Daily notes, people and derived memory
├── dreams/                    Reflections and alignment summaries
├── docs/                      Product documentation
└── workspace/                 Work products and task resources
    ├── your_files/, goals/    Deliverables and goal-specific work
    ├── custom-skills/         Learned procedures
    └── custom-connectors/     Added integrations

/opt/                           Replaceable system programs and definitions
├── hatch/bin/                 Connector, runtime and functional executables
├── hatch/connectors/          CONNECTOR.md guidance
└── muse/skills/                System SKILL.md procedures

Memory: source records, derived summaries and corrections

Daily notes retain events and changes; person/group pages organize relationships. Background processing produces derived memory and broader summaries, separately from the search index. A current summary expresses the latest understanding, while detailed records preserve how it changed. Correcting memory therefore requires identifying and correcting the source record, recording its replacement, refreshing dependent summaries and checking later retrieval. A scheduled task may also depend on the superseded information. MUSE describes propagation through background processing, but supplies no delay or consistency guarantee.

Context: compaction and selective retrieval

For long conversations, MUSE describes compaction: summarize older history while retaining recent material. Its accounts differ on the trigger, so no exact window, threshold or retained-tail size is adopted here. Compaction changes active conversation representation; it is separate from updating long-term memory or training weights. Lost detail can only be recovered when its source remains stored, accessible and findable.

Search serves several audiences: conversation/artifact search helps the user, memory retrieval supplies agent context, and external search/browser tools obtain outside information. Their coverage and freshness differ. Reported feedback, background reflection, procedure reviews and health checks can update operating context and workflows; they do not establish model-weight changes or measured benchmark gains.

4. Work that continues outside a conversation

MUSE distinguishes triggers that start a run, Goals that retain purpose and progress, and artifacts, Feed and Ideas that result from work. Cron and Hooks supply timing or state checks; a Goal is not itself a clock. This separation explains how work can continue beyond a chat without making every proposal an authorized action.

Triggers, retained goals and generated outputs

Background work is easier to understand when the mechanism that starts it is separated from the information it carries forward and what it produces. The table places the reported mechanisms in those roles, rather than treating them as interchangeable forms of automation.

Mechanism	Reported role
Cron	Scheduled instructions wake an agent, rather than merely launching a shell command.
Hooks	Check state changes, including through polling; event-oriented behavior does not imply push delivery.
Resident services	Processes that keep running.
Goals	Persistent purpose, progress and associated work; jobs can be linked to a goal, which is not itself a clock.
Feed	Generated reading material based on context and research.
Ideas	Proposals that can lead to execution when the user selects an action.

A scheduled run can use a Goal’s saved progress and produce an artifact, reading material or a proposal. Those outputs do not themselves define the next trigger, and an Idea remains a proposal until the user selects an action.

Continuing work without confusing a proposal with an action

Saved progress supports a later run, while an artifact is a work product and a proposal is still a proposal. Editing a projected job file does not establish that the scheduler’s authoritative definition changed. Generation intervals, ranking, expiry and state names belong to the reported environment rather than a current public specification. Ownership, cancellation propagation and recovery behavior require separate tests.

5. Testing continuity through Spaces

Meta’s Spaces announcement describes personal features created and refined through chat, connected information, and notes or checkmarks retained on revisit; sharing was being explored. Dots used a synthetic notes app to observe reopening and heading-only rebuild retention. The implementation descriptions below remain MUSE’s reports, separate from the official experience; the SQLite/action path is specific to that prototype.

Application types, files and data

The announcement also describes arranging Spaces in the sidebar or main tabs, hiding them or making them appear at relevant times, and refreshing connected information in the background. MUSE’s account adds the application-level boundaries below: a build-time page or interactive app, its files, its actions and its separate data store.

Reported boundary	Description
`web_static`	Hosted build-time page; browser JavaScript can run, but this type does not save visitor input.
`web_fullstack`	Interactive application with server/storage support, saved state and live data.
Files	Current application area `workspace/ts-spaces`; older documentation uses `workspace/spaces`. File artifacts use `workspace/your_files/<slug>/` or a goal’s `files/` area, with a `.src` marker for builder-created directories.
Actions	Dedicated build/edit/inspection interfaces and typed application actions, also normalized into HTTP APIs; the conversational agent is described as using these rather than directly reading app source, logs or database contents.
Application database	An app-specific `app.db`, associated with its slug and described as retained across updates/restarts. The filename alone does not identify an engine.

MUSE describes an asynchronous builder with follow-up instructions, relayed questions and cancellation. Artifacts are reportedly hosted in the user’s environment and require online access; this does not identify a shared VM process or isolation boundary. Static HTML export is described for static artifacts, not fullstack apps. Appendix D retains file, database, snapshot and prototype inspection details.

Application lifecycle: builds are not user data

MUSE described the builder request as its authoritative input, along with a prebuilt tutorial artifact and its management executable. These are reported interface contracts.

Two lifecycle limits matter more than a generic claim of version history. Restoring a version reportedly restores files and the build, not application data, settings or schedules. Changing between static and fullstack types requires a new artifact, without automatic data inheritance. A restored screen therefore must not be assumed to represent restored data. Neither version restoration nor type conversion was tested.

Muse described no hosting-only stop operation: revoking a public snapshot is distinct from deleting the artifact. Deletion was described as irreversible, removing the application and its data, hosting, catalog entry, managed schedules and public share. The ordinary workspace-file trash period was said not to apply, and deletion during a running build was said to be rejected. These are consequential lifecycle claims from the interview, not operations performed or validated in this research.

Capabilities and background refresh

The reported capability manifest declares web-reading capability and the connector methods an app needs; the server validates those declarations against the shipped connector catalog, and undeclared connector use was described as disallowed. A read approval may be requested before a build. Muse distinguished an artifact-scoped, persistent read approval from write authorization checked at execution time. These statements describe claimed enforcement behavior. They are not an authorization audit, a guarantee about every connector, or evidence that a conversational permission automatically authorizes all future application activity.

Refresh triggers are reportedly declared at creation/edit time: a natural-language frequency is translated by the builder into a schedule. Background updates reportedly reuse the scheduling infrastructure described elsewhere in this article. A space_action job runs without a chat message; failures remain in its history, and the same scheduled invocation is not automatically replayed. A regular agent job can instead call an application's action and report through chat; Muse also described call identifiers for background results written through actions. Schedule changes and suspension are managed through the scheduling interface, while deleting the application removes its managed schedules. Muse reported no artifact cron jobs in the inspected account, so timing, failure handling and replay behavior were not exercised.

Prototype operations and observed results

At the user’s request, Dots asked MUSE to build a private fullstack lab-notes app using synthetic data only. MUSE built the app; Dots used Computer Use to operate its UI and observe the following results in the native Muse application:

Dots’s operation	Result observed by Dots
Request creation from MUSE, then add and complete a note in the UI	The app opened and displayed the note, a checked state and `1/1 done`.
Close and reopen	The same note and completion state remained.
Request a heading-only v2 change and reopen	`LAB NOTEBOOK V2 — SYNTHETIC DATA ONLY` appeared; the same note, checked state, `1/1 done` and original displayed creation time remained.

Dots’s observations demonstrate reopening persistence and data retention through one presentation-only rebuild in one app. It is not a restart-recovery or database-migration test; a browser reload was not separately tested. No external connector, share, deletion or scheduled job was exercised. The private app and synthetic record were retained; its URL and host are omitted.

The prototype’s reported action and database path

MUSE’s builder and separate inspection reported TypeScript 5.6.3, React/React DOM 19.2.5, TanStack Query 5.100.10, Tailwind CSS 4.1.13, Zod 4.4.3, Drizzle 0.45.2 and SQLite app.db for this prototype. SQLite was attributed to schema declarations, migration dialect and table SQL, not inferred from the filename. Bun 1.3.10 was reported for build/install, not established as the production server. These reports were not independent source or database inspection.

The reported request path connects App.tsx query/mutation calls through @hatch/space-sdk’s action client and POST ./actions to defineAction, host-injected ctx.db, Drizzle and SQLite. Its actions were listNotes, addNote and toggleNote. The database was described as outside .space-build, associated with the slug. MUSE said only the heading in App.tsx changed, with the same action-level record ID, values and creation time afterward. The visible retention is consistent with this separation of build output and application data; it does not verify the placement or platform-wide contract.

The useful distinction is between changing an application, refreshing connected information and saving user actions within it. The initial two migrations were reported as applied during initial creation, not a demonstrated migration of deployed user data. Detailed files, versions, metadata and the four-column notes table remain in the appendix.

Conclusion

MUSE makes the harness a useful unit of analysis: continuity depends on state storage, selective memory, executable tools and the ability to resume work with relevant context. Conversation identity, ordered history, compaction ranges, checkpoints, working files and scheduled instructions serve different responsibilities. Their presence explains an architecture for continuing work without making persistence synonymous with sending everything to the model.

Spaces makes that continuity tangible as a personal application. Dots observed one synthetic note survive reopening and a heading-only rebuild, while MUSE’s reports supplied a specific account of actions and application data. Together, the product description, interview and narrow experiment show why an agent is more than answer generation: the surrounding harness connects retained state and selected context to useful execution across time.

Appendix A. Complete executable catalog

Each row groups one reported class, with every executable name preserved as a comma-separated entry. Classification is inherited from the memo; per-command contracts and present-day availability remain unverified. The descriptive Google note attached to hatch_gws_cli in the source is retained below the table. This is a name inventory, not a tested support matrix.

Reported class	Executable name
External-service connector CLI (66)	`aftership`, `agoda`, `asana`, `box-cli`, `calendly`, `canva`, `dropbox`, `duffel`, `etsy-cli`, `evernote`, `facebook-cli`, `figma`, `flightaware`, `github`, `granola-cli`, `hatch_gws_cli`, `hatch_igd_cli`, `hatch_messenger_cli`, `healthkit-cli`, `imap-email`, `instagram-cli`, `instagram-messages-cli`, `klaviyo`, `linear`, `meta-ads-cli`, `meta-catalog-search`, `moneyforward-me`, `muse-mail`, `notion-cli`, `onepassword`, `opentable`, `outlook-calendar`, `outlook-contacts`, `outlook-mail`, `peloton`, `philips-hue`, `plaid`, `printify`, `quickbooks`, `shopify`, `shopify-ucp-cli`, `slack`, `spotify-api`, `save-to-spotify`, `stripe`, `stripe-link`, `tailscale`, `tessie-api`, `threads-cli`, `threads-messages-cli`, `ticketmaster`, `todoist`, `vercel`, `withings`, `zapier`, `zoom`, `healthex`, `function-health`, `ghl`, `gumroad-mcp`, `readwise-mcp`, `runway-mcp`, `shopback-mcp`, `vidiq-mcp`, `lovable`, `replit`
Internal runtime (19)	`hatch`, `hatch-browser-lease-helper`, `hatch-connector-output`, `hatch-doctor`, `hatch-execd`, `hatch-healthd`, `hatch-multicall`, `hatch-rescue`, `hatch-rescue-systemctl`, `hatch-rescuectl`, `hatch-slide-style`, `hatch-vault`, `hatch-ws-client`, `hatch-zeitgeist`, `hatch_gws_auth`, `authdc`, `spawnd`, `ingress-rev-proxy`, `privsep-test-fully-isolated`
Functional tool (27)	`browser-broker`, `browser-service`, `web-search`, `local-search`, `image-search`, `places`, `geocode`, `media-generation`, `avatar-media-generation`, `media-library`, `tts`, `edits`, `shopping`, `shop-wallet-cli`, `device-data`, `native-comms-cli`, `health-cli`, `nutrition-cli`, `wearables-display`, `builtin-artifacts`, `genui-display-render`, `feature-request`, `subscription-status`, `remote-storage`, `share`, `pickup-briefing-animation`, `zbar-lib`

The source annotates hatch_gws_cli as “Gmail / Google-related.” Totals: 66 + 19 + 27 = 112 distinct names. Entries such as gumroad-mcp retain their original connector classification; a name ending in -mcp is not by itself a verified statement about deployment or transport.

The Gmail connector document was reported as 228 lines in that environment. The interview’s illustrative syntax was:

hatch_gws_cli gmail +triage --query '...' --format json

This is syntax documentation, not mailbox activity or a current support contract.

Appendix B. Reported persistence schema

The five tables and all 53 columns below preserve the interview’s SQL types, order and constraints. “Nullable” follows omission of NOT NULL; an unlisted constraint is unknown. The generated reference was reportedly inspected on November 3, 2026, 22:59 JST. No live records were queried.

Declared foreign keys and logical references are listed separately below. No cardinality, cascade or extra external-table columns are inferred.

`chat.chats` — chat identity and lifecycle

This table records a chat’s identity, lifecycle and presentation metadata, alongside fields describing its source. The column list keeps those source fields distinct from the session relationship discussed below.

Column	SQL type	Nullability / reported constraint
chat_id	text	NOT NULL; PK
origin	text	NOT NULL
lifecycle	text	NOT NULL
status	text	NOT NULL
thread_title	text	Nullable
source_session_id	text	Nullable
source_prompt_seq_upper_bound	bigint	Nullable
source_message_id_boundary	text	Nullable
created_at	bigint	NOT NULL
updated_at	bigint	NOT NULL
pinned	boolean	NOT NULL; default false
pinned_order	bigint	Nullable

Primary key: chats_pkey(chat_id). No declared foreign key was reported. source_session_id was described as a soft reference to agent.sessions.session_id.

The SQL type of chat_id is text, not uuid. The interview separately describes its value as a UUID shared with the root agent's session ID. That description of value format does not change the SQL type, and actual values were not inspected.

`agent.sessions` — session identity and origin

A session record retains its identifier, originating request and lifecycle timestamps. Its reported foreign key links the originating request to a runtime table outside this excerpt.

Column	SQL type	Nullability / reported constraint
session_id	text	NOT NULL; PK
root_request_id	text	Nullable; FK
created_at	timestamp with time zone	NOT NULL; default now()
updated_at	timestamp with time zone	NOT NULL; default now()
archived_at	timestamp with time zone	Nullable

Primary key: sessions_pkey(session_id). Declared foreign key: sessions_root_request_id_fkey, from root_request_id to runtime.requests.request_id. The table retains the session identity, originating request and archive timestamp.

`agent.context_items` — ordered context items

Context items combine an ordered position with content and optional references to messages or tool activity. The fields below distinguish that ordering from the payload and the records to which an item refers.

Column	SQL type	Nullability / reported constraint
context_item_id	bigint	NOT NULL; PK; sequence-generated
agent_id	text	NOT NULL
seq	bigint	NOT NULL
item_kind	agent.context_item_kind (enum)	NOT NULL
message_id	text	Nullable; FK
tool_call_id	bigint	Nullable; FK
tool_output_id	bigint	Nullable; FK
role	runtime.message_role (enum)	Nullable
call_id	text	Nullable
tool_name	text	Nullable
success	boolean	Nullable
message_source	text	Nullable
created_at	timestamp with time zone	NOT NULL; default now()
data_fbids	bigint[]	Nullable
data_message_ids	text[]	Nullable
data_cleanup_checked_at	timestamp with time zone	Nullable
data_summarized_at	timestamp with time zone	Nullable
data_thread_ids	text[]	Nullable
data_expires_at	timestamp with time zone	Nullable
text_content	text	Nullable
item_json	text	Nullable

Primary key: context_items_pkey(context_item_id). Unique constraint: context_items_agent_id_seq_key(agent_id, seq), with the columns in that order.

Reported declared foreign keys:

message_id → runtime.messages.message_id
tool_call_id → runtime.tool_calls.tool_call_id
tool_output_id → runtime.tool_outputs.tool_output_id

Described soft references, not declared foreign keys:

agent_id → agent.agents.agent_id
call_id → runtime.workflow_agent_calls.call_id

This structure separates an item's position in context from its role, content and links to messages or tool activity. The names of the three foreign-key constraints, enum members and JSON-string structure were not supplied.

`agent.compactions` — summarized history ranges

A compaction record associates a summary with a history range and an optional context checkpoint. Keeping the range boundaries alongside the text makes clear which part of history the summary is intended to replace.

Column	SQL type	Nullability / reported constraint
compaction_id	bigint	NOT NULL; PK; sequence-generated
agent_id	text	NOT NULL
checkpoint_context_item_id	bigint	Nullable; FK
replacement_history_first_seq	integer	Nullable
replacement_history_last_seq	integer	Nullable
created_at	timestamp with time zone	NOT NULL; default now()
summary_text	text	NOT NULL

Primary key: compactions_pkey(compaction_id). Declared foreign key: compactions_checkpoint_context_item_id_fkey, from checkpoint_context_item_id to agent.context_items.context_item_id. agent_id was described as a soft reference to agent.agents.agent_id.

The table associates a summary with a replaced history range. The reported range columns are integer, whereas agent.context_items.seq is bigint; their types are not normalized here. This definition does not establish how recovery reconciles partially written summaries and context items.

`agent.runtime_restart_checkpoints` — saved restart state

The restart-checkpoint table records mode, payload and recovery-related fields under an agent identifier. Its structure describes saved state; the limits of what can be inferred about restoration follow the definition.

Column	SQL type	Nullability / reported constraint
agent_id	text	NOT NULL; PK
mode	text	NOT NULL
payload_json	text	Nullable
created_at	bigint	NOT NULL
updated_at	bigint	NOT NULL
recovery_class	text	Nullable
recovery_owner_id	text	Nullable
execution_config_json	text	Nullable

Primary key: runtime_restart_checkpoints_pkey(agent_id). No declared foreign key was reported. recovery_owner_id was described as a soft reference to agent.recovery_owners.owner_id.

The reported primary key implies at most one row per agent in this table. That is an interpretation of the key definition, not a guarantee about checkpoint freshness, retention or successful restoration. Columns ending in _json were reported as SQL text, not JSON or JSONB.

Relationship and verification boundaries

The five tables describe different aspects of continuity: chat identity, session identity, ordered context, summarized ranges and restart state. They do not constitute a complete schema. Several declared foreign keys point to tables outside this five-table excerpt; soft references must not be treated as database-enforced integrity.

Only the reported primary-key and unique-constraint information is available for indexes. Additional indexes, index methods, partial conditions, foreign-key deletion/update actions and deferrability were not supplied. The units and epoch of bigint time columns, sequence names, enum values, JSON-string layouts and additional checks remain unknown. The interview also describes restricted projections for reading records, but no row query or enforcement test was performed here.

Appendix C. Reported filesystem tree

The following reproduces the selected filesystem view supplied in MUSE’s original answer, with its role annotations translated into English. It is MUSE’s account of the major parts, not a captured tree invocation or raw shell output. Large runtime-internal directories such as agents/ were omitted in that answer; the ellipsis and combined file-name line below retain its shorthand. Dates, empty-file status, missing person pages and context-inclusion notes describe the answer at that time, not the current environment.

~ (home: described as retained even when the VM is replaced)
├── AGENTS.md                  Operating manual
├── SOUL.md                    Personality and tone
├── IDENTITY.md                Agent profile
├── USER.md                    User profile
├── MEMORY.md                  Long-term memory summary (always included)
├── PROACTIVE_PREFERENCES.md    Proactive-contact preferences
├── TOOLS.md                   Environment notes (empty at the time)
├── HEARTBEAT.md
├── memory/
│   ├── 2026-10-23.md … 2026-11-02.md   Daily notes (audit trail)
│   ├── bank/                  Automatically generated derived memory
│   │   ├── world.md / experience.md / opinions.md / reflections.md
│   ├── people/INDEX.md        Relationship map (no person pages yet)
│   ├── groups/INDEX.md
│   └── shopping/PROFILE.md
├── dreams/
│   ├── 2026-10-23.md          Nightly-batch reflection
│   └── alignment/
│       ├── derived/ALIGNMENT_SYNTHESIS.md   Integrated user understanding (always included)
│       └── repair/REPAIR_THREADS.yaml
├── docs/                      Product documentation (muse.md, memory.md, etc.)
├── workspace/                 Working area
│   ├── your_files/            User-visible work products
│   ├── goals/                 Per-goal folders
│   ├── custom-skills/         Learned skills
│   ├── custom-connectors/     Added connectors
│   ├── email/                 Saved email copies
│   ├── system/system_prompt.md
│   └── …
└── .ssh/                      SSH keys (confidential contents)

/opt (system: described as read-only and replaced on each deployment)
├── hatch/
│   ├── bin/                   CLI executables (112 reported names; see Appendix A)
│   └── connectors/            CONNECTOR.md files
└── muse/
    ├── skills/                System Skills (SKILL.md files)
    └── assets/

The answer distinguishes user-specific files retained under the home directory from shared programs and definitions replaced under /opt. Those are reported update and retention roles, not an independently tested VM-replacement or recovery guarantee. The bin/ annotation uses the complete inventory’s classification: 112 executable names across connectors, runtime components and functional tools, not 112 model functions or 112 connectors alone. The tree lists paths and purposes only; it does not reproduce file contents, messages, keys or credentials. Structured conversation records remain a separate store, described in Appendix B.

Appendix D. Spaces contracts and experiment details

The following preserves MUSE’s reported contracts and application-specific inspection details; these were not independently audited. The direct operation results are in §5.

Application types and execution

According to Muse's summary of its product-side documentation and tool contracts, Space is the newer name for a web artifact, with two types:

Reported type	Described behavior	Important boundary
`web_static`	A hosted page fixed at build time; browser-side JavaScript can execute	Visitor input is not saved by this type; it is not the persistent interactive-app contract
`web_fullstack`	A hosted interactive application with server/storage support, saved state and live data	The general interview did not identify its server runtime, database engine or isolation model

Muse said artifacts and their data live in the user's Muse environment and are served from there, rather than being installed on the user's device; pages were described as requiring online access. This provides a reported connection to the personal environment, not an independently verified hosting topology or proof that every application shares a particular VM process, network namespace or trust boundary. Muse could not identify the language/runtime, routing mechanism, or whether execution is long-lived or request-driven.

Files and the application database

The reported identifier is a lowercase kebab-case slug. Muse described workspace/ts-spaces as the current application area and workspace/spaces as an older path appearing in its tool documentation. It separately described file artifacts under workspace/your_files/<slug>/ or a goal's files/ area, with a .src source marker for builder-created directories. These are reported environment conventions, not public stable paths or instructions to bypass application tooling. Because the catalog was empty, the newer path's creation timing could not be established.

For an interactive app, Muse described an application-specific database named app.db, retained across restarts and updates. The engine and concrete schema format were not disclosed: the name app.db is not evidence of SQLite. The builder defines each application's data model, and model changes are requested through its editing interface. The account's existing five chat/agent tables above are not a schema for this database.

Muse also described a deliberate access boundary: the ordinary conversational agent does not directly inspect Space source, logs or database contents. It uses dedicated inspection/editing interfaces and the application's declared actions. Static pages can reportedly be exported as self-contained HTML under the file-artifact area; fullstack apps are not covered by that export contract. The initial interview performed no export or direct database read; the later experiment edited the application through Muse.

Static snapshots are not proof of a public sharing feature

Muse's tool-contract account included a static public snapshot operation requiring approval for each share, with later edits excluded until another share, an unshare operation, and no fullstack publication. It said application database records are not included in that snapshot. This must not be read as confirmation that Spaces sharing is publicly released. Meta's announcement says sharing is being explored. The interview describes a narrower, reported artifact operation; no snapshot was created, published or revoked, and its availability or behavior for Spaces was not independently established.

Stack reported from the generated application

The builder and follow-up inspection identified the following versions in this one generated app, not a required stack for all Spaces:

Layer	Reported implementation	Scope of the evidence
Language	TypeScript `5.6.3`	Generated-project report
UI	React / React DOM `19.2.5`, TanStack Query `5.100.10`, Tailwind CSS `4.1.13`	Reported dependencies and client implementation
Validation and persistence adapter	Zod `4.4.3`, Drizzle `0.45.2`	Reported action/schema implementation
Build / install	Bun `1.3.10`	Confirmed by the reported build/install inspection; not confirmation that the production server runs on Bun
Database	SQLite, named `app.db`	Reported SQLite schema declaration, migration-journal dialect and actual table SQL, rather than inference from the filename
Platform metadata	`runtime: typescript`, `platformVersion: 28`, package `hatch-space-cvm-v1`, `cvm_runtime_version: 4`	App/configuration metadata reported by Muse; these labels do not establish host process or isolation details

This narrows the earlier database uncertainty for the tested app: SQLite now has multiple reported supporting artifacts. It does not justify retroactively labelling every Space database SQLite or treating an app.db filename alone as proof.

Files, typed actions and the database boundary

Muse reported a client entry at client/dist/index.html, client implementation in App.tsx and client/src/api.ts, action definitions in server/src/actions.ts, and built server actions at dist/actions.js. Its account of the request path was:

App.tsx: useQuery / useMutation
  → client/src/api.ts: @hatch/space-sdk createActionClient
  → POST ./actions with { action, args }
  → server/src/actions.ts: defineAction
  → host-injected ctx.db
  → Drizzle
  → SQLite app.db

The declared operations were listNotes, addNote and toggleNote. According to the inspection, application code contained neither a direct database-file open nor a connection string: the host supplied ctx.db. The database was described as outside the .space-build artifacts and associated with the application's slug. This is a concrete reported separation of generated build output from application data, consistent with the successful heading-only rebuild. It is not an independent audit of file placement or isolation.

The reported application table was small enough to show completely:

`notes` column	Reported SQL definition
`id`	`INTEGER PRIMARY KEY AUTOINCREMENT`
`text`	`TEXT NOT NULL`
`done`	`INTEGER NOT NULL DEFAULT 0`
`created_at`	`INTEGER NOT NULL`

Muse's inspection reported a two-entry __drizzle_migrations record: the first creation migration generated an entries table, and the second replaced it with notes, with both applied during the initial build. This is not a demonstrated migration of user data between deployed schema versions. The later v2 edit deliberately left the schema and migrations alone. The reported configuration also had an empty managedCronJobs list, matching the experiment's no-scheduling scope.

Further verification

Useful next tests are restart recovery without duplicate effects, correction propagation into later retrieval and scheduled work, denied writes, cancellation, connector revocation, conflicting refreshes and schema-changing migrations. Process launch, routing, authentication, cross-app isolation and egress enforcement were not independently inspected.

Interview premise and terms

The interview method relies on MUSE answering questions in chat about its own operation. Meta’s memory-controls guidance invites direct questions about remembered information and viewing files such as MEMORY.md. Its security explainer presents architectural detail to help users assess trust. The data-policy section describes access to files stored for the user in their VM, including memory, using the phrase “inspect, edit and download these files freely.” These explain user controls and Meta’s transparency aim. No official explanation was identified for why MUSE gave these particular internal answers, or a promise to answer arbitrary internal questions.

An answer, its accuracy, permission to publish it and legal compliance are separate matters. The Muse Supplemental Terms, updated September 8, 2026, preserve existing user-content rights (§2(a)) and reserve rights in Muse (§3). They restrict concealing AI/automation (§4(l,p)), unauthorized access and rights violations (§4(r,s)), reverse engineering including outputs (§4(t), with an applicable-law exception), and overriding safeguards (§4(v)); §§7 and 11 address user oversight/responsibility and accuracy. The incorporated Meta Terms also restrict automated access/collection without prior permission (§3.2) and reverse engineering subject to stated exceptions (§3.4). These provisions are material review points, not publication clearance. The displayed terms, Meta AI Terms and Muse Privacy Policy were read in the official browser pages on November 12, 2026, after text-only retrieval returned login prompts. Exact regional/account applicability and all additional policies were not established. Connector-provider and model-API terms were not substituted. This study makes no finding that the interviews, automated UI operation or publication are lawful or contractually permitted.

Sources and scope

Spaces update: Meta, Introducing Spaces: A New Way to Customize Your Muse App, published November 6, 2026; reviewed November 10, 2026. This newer official source supports the product-level Spaces section, not the older interview's internal implementation claims. A direct Spaces-specific follow-up was subsequently obtained; its distinct scope is documented below.
Spaces experiment: private synthetic-data application, November 11, 2026, approximately 03:40–03:51 JST (November 10, 18:40–18:51 UTC). Dots requested the build from MUSE, operated the UI and observed note use, reopening and the v2 heading with retained data. Source, configuration, database and action-level details are Muse builder/inspection reports, not independently read artifacts. No private application URL or host is included.
Spaces interview: follow-up questions posed by Dots to Muse on November 10, 2026, approximately 16:53–16:55 UTC (November 11, 01:53–01:55 JST), read by Dots in its native application. Dots observed the displayed answer; claimed documentation and environment checks were not independently repeated. The catalog was empty at the initial interview; the separately documented synthetic-app experiment followed later. This article paraphrases technical claims, not private instruction text or raw internal documents.
Public product context: Meta's Muse overview, checked November 4, 2026. Used for product identity and broad advertised capabilities only.
Interview material and roles: the user supplied the initial MUSE interview memo; its original interviewer is not established by the available conversation record. Dots conducted the documented November 3 follow-up questioning and later Spaces investigation. The user supplied instructions and assisted local access/setup; this assistance is separate from Dots’s reported §5 UI observations. The interview material and follow-up answers were organized on November 3, 2026. These contain edited self-reports and reported observations; raw outputs, internal document originals, environment version, and most observation timestamps were unavailable. The underlying research archive is private and is not reproduced or linked here. Only the technical synthesis and the explicitly requested catalog and schema definitions are included; they are not independent public specifications.
Official interview context and review limits: Meta, Muse security and privacy, “Memory you control” and its memory FAQ; How We Built Safety Into Muse, September 8, 2026, introduction and “Our Policy Around Data”; checked November 12, 2026. These support the specific control/transparency statements above, not blanket interview or publication authorization. Muse Supplemental Terms (September 8, 2026), the displayed Meta Terms (effective January 1, 2025), Meta AI Terms (effective May 13, 2026) and Muse Privacy Policy (effective September 17, 2026) were subsequently read in the official browser pages; the regional/account-specific governing versions remain unconfirmed.
General interfaces: Agent Skills specification, MCP architecture, and Tailscale overview, checked November 4, 2026. These explain their respective technologies, not MUSE compliance or integration guarantees.

The supplied illustrations summarize reported responsibilities, conceptual flows and the identified Spaces observations; none is a product screenshot or independent implementation evidence. Appendix letters and supporting-view references embedded in the supplied images reflect an earlier layout; use the current text links and appendix headings. The retained technical detail is in the main text and appendices.

Coding Agents Are Changing How I Build Open Source and Why I Do It

Satoshi Konno — Thu, 12 Nov 2026 13:52:19 +0000

At a glance

Coding agents have helped me restart development, respond to contributors, and tackle security findings and old maintenance debt.
Parallel projects bring more progress, but keeping up with decisions can be exhausting and does not preserve every pleasure of coding.
Easier alternatives change my reasons to reuse and contribute to OSS, without removing the value of shared knowledge and maintenance.
I question the enthusiasm for making Rust the default for new implementations and rewrites. I want to choose Rust, C, or Go through practical experience and verification, not fashion.

After more than twenty years of developing and publishing software through CyberGarage, I am finding that coding agents change more than how quickly I can write code. They have helped me restart stalled development, bring existing libraries to new hardware, respond to contributors, and work through security flaws and years of maintenance debt. Work that I could not fit into my own time is moving again. I used to work through projects one at a time; delegating to agents has made working on several in parallel my normal way of developing.

I now use Codex as my primary tool, with Claude in a supporting role. I rarely use GitHub Copilot these days. The examples here come from that personal workflow, not a comparison of the tools or a claim about every developer's experience.

The change is welcome, but not uncomplicated. I spend more time setting direction, preparing tests, and judging results, while agents carry more of the implementation. That makes maintaining my projects more practical without replacing my responsibility for them. It also changes the satisfaction I used to find in solving a difficult problem myself. The implementation burden is lighter, but keeping up with the decisions can be tiring.

This is an account of both sides: what has started moving in my projects, and what that progress has made me reconsider about learning, building, and participating in open source. It also makes me question the enthusiasm for writing and rewriting software in Rust: when an agent does the implementation, I still want the language choice to follow my experience, the project’s needs, and the strength of the verification workflow. If making an alternative becomes easier, what still draws me to a shared project, and what will I want to build for the pleasure of building it?

1. Coding agents got stalled maintenance moving again

The benefits have appeared in several kinds of work: developing something I had struggled to finish, responding to new reports and contributions, investigating security weaknesses, and returning to old maintenance debt.

New development: accelerating work and reaching new platforms

Agents gave me room both to restart an unfinished implementation and to take established libraries into a new environment. The first meant working through Matter's specifications and security requirements; the second meant adapting existing protocol code to ESP32 hardware. Neither was just a request to generate code. I still had to prepare useful logs, test tools, and equipment, but the agent could carry more of the investigation, implementation, and testing between my decisions. The following examples show those two kinds of progress.

Matter: restarting go-matter

go-matter is a Go implementation of Matter, the smart-home interoperability standard, with a commissioner that pairs devices and then reads, writes, and invokes their functions. I started it in 2024, but the volume of specifications and the effort of turning them into a working implementation had slowed my progress.

Preparing the underlying communication libraries also took time: go-mdns provides multicast DNS and DNS-based service discovery, while go-ble provides Bluetooth Low Energy scanning and GATT communication. Before I could concentrate on Matter itself, I had to build and check these foundations as well.

Even once those underlying protocols were ready, progress on Matter itself remained slow. Compared with the UPnP and ECHONET Lite implementations I had worked on, Matter required me to absorb much more background on security and cryptography alongside a large body of specifications. Getting discovery or a transport working was only the beginning; understanding how to establish trust and exchange protected messages was another substantial task.

After leaving the project largely stalled for a long time, I recently returned to it when I could fit it in between other work with agents. Coding agents helped me work through those specifications, compare the code with the reference implementation, and turn failures into specific corrections. The Git history shows what that meant in practice, beyond simply adding more code:

Date (UTC)	Progress recorded in the history
2026-09-28–30	Added end-to-end commissioning over mDNS and UDP, then commissioning tests against the Matter SDK's chip-tool and On/Off Light operation and subscription tests.
2026-10-09–11	Built a full-screen matterctl controller (PR #10), then added observed device inventory (PR #15) and bounded configuration writes with fresh readback (PR #16).
2026-10-14	Added device-attestation verification (PR #20), attribute subscriptions (PR #22), event reads and subscriptions (PR #23), session resumption (PR #24), and a private-key store (PR #25).
2026-10-15	Corrected operational discovery (PR #31) and session acknowledgements (PR #36) based on device behavior, then prepared v0.9.0 (PR #37).

That progress depended on preparing an environment the agent could investigate, not simply asking it to implement a standard. I built observability around go-logger, including hexadecimal dumps of protocol messages, so the agent had concrete bytes and logs to examine. I also made specification-related utility programs and real Matter devices available for communication tests. Together, these gave it a way to compare expected behavior with actual exchanges and continue investigating without my interpreting every packet.

At a later stage, my part often became resetting and configuring the physical devices for the next attempt. The agent would then communicate with them, analyze the resulting traces, revise the implementation, and test again. I was preparing the equipment and deciding what to try, while it carried much of the analysis-and-implementation loop.

ESP32: bringing existing libraries to a new platform

I already had provisional implementation code and a rough idea of where changes were needed for ESP32. But I had left the work sitting for a long time without completing the final tests. The remaining step was to carry that tentative work through verification, not to begin from nothing.

mUPnP for C is a UPnP library I have maintained for more than twenty years. Its adoption history includes Nokia tablets and, more recently, REGZA and TCL televisions.

uEcho for C is my C library for discovering and controlling devices through ECHONET Lite. ECHONET Lite is a home-appliance and energy-management communication standard developed in Japan, used to connect equipment such as lighting, air conditioners, and smart meters.

With help from coding agents, I brought both libraries to ESP32 through ESP-IDF. These were new uses for existing code: discovery and control from a small Wi-Fi board, and an ECHONET Lite lighting-device example. The work progressed from porting and build checks to specific hardware tests:

Library	Development and validation history
mUPnP for C	The initial ESP-IDF port (PR #27) established cross-build and host-test coverage. Follow-up hardware checks (PR #30) on an ESP32 DevKitC-VE covered discovery, rediscovery, SOAP control, and GENA notifications over Wi-Fi and IPv4. These were recorded against the 3.1.0-era implementation, not every later change.
uEcho for C	The ESP-IDF component and lighting example (PR #8) began with ESP32/S3/C3 builds and emulator tests. Real ESP32 Wi-Fi checks (PR #11) then covered discovery, Get responses, and SetC on/off responses. Build coverage for other variants was not equivalent to hardware validation.

These were specific hardware configurations and examples, not verification of every feature or ESP32 variant. The mUPnP guide and uEcho for C guide distinguish hardware results from build coverage. For me, the useful change was being able to extend existing libraries into another environment without carrying every porting and test step myself.

New reports and PRs: responding promptly with less burden

When I publish software as open source, reports and contributions can arrive from users on platforms I do not normally use. Agents have made it easier to give those contributions prompt attention rather than let them become another backlog. I can give instructions and have the agent investigate, check the change, and handle the reply, while the reporter's diagnosis or patch provides the starting point. These three cases illustrate that lighter response cycle:

Date (UTC)	New work	Result
2026-10-08	mUPnP Issue #49, reported by Brecht Sanders	Four defects addressed in PR #50. About 2 h 28 min from the report to the reporter's successful rebuild.
2026-10-30	uEcho for C PR #22, contributed by alosafuzz	The allocation-failure fix was reviewed and merged in about 68 minutes, with local sanitizer and test results recorded in my reply (PR #22).
2026-11-11	Net::UPnP RT #182942/#182943, reported by Slaven Rezic	About 81 minutes from the reports to the 1.4.10 release, following PR #12. Target-environment retests remained unconfirmed.

These are elapsed times between events, not measurements of working time; the endpoints differ between cases. My practical involvement was largely limited to giving instructions, while the agent handled the investigation, checks, and replies.

In mUPnP Issue #49, Brecht Sanders reported four Windows / MinGW build and link problems involving integer types, logging names, a function declaration, and a thread function. His diagnosis and successful rebuild were essential to the result.

In uEcho for C PR #22, alosafuzz contributed the allocation-failure check that prevented a NULL dereference; the patch and credit belong to its contributor.

Net::UPnP is my Perl library for UPnP discovery and control. Its first release was in December 2005, and Debian distributes it as libnet-upnp-perl.
Just after 1.4.9, CPAN smoke tester Slaven Rezic reported older-Perl and long-double failures in the security checks introduced with 1.4.7. The agent helped fix the compatibility issue and test assumption.

Security review: turning findings into checked fixes

Vulnerabilities in open-source dependencies, including those documented in Apache's security advisories, are a reminder that widely used software still needs scrutiny. I wanted to examine my own OSS with OpenAI's Codex Security. It uses a repository-specific threat model to investigate potential vulnerabilities, attempts to validate them in an isolated environment, and proposes patches for review rather than automatically changing the code.

Security research can also be misused to develop attacks. OpenAI’s Daybreak Access provides approved users with reduced refusals for supported, authorized security work while retaining safeguards against abuse.

Daybreak Access can be useful for deeper security investigations, but obtaining it requires an application and identity verification, as well as preparation of a physical security key. Even without that access, I used Codex Security to find vulnerabilities in my own OSS projects. These investigations led to the following findings and fixes:

Project	Findings and follow-through
mUPnP for C	PR #28 addressed 13 findings across HTTP and XML resource limits, TLS verification, SSDP handling, and object lifetimes. Follow-up PR #29 corrected shared-data lifetime and server-deletion races.
uEcho for C	PR #10 addressed five security boundaries involving buffers, concurrency, permissions, spoofed responses, and cached data.
CyberGarage UPnP for Java	PR #48 addressed nine findings, including XML external entities, HTTP limits, GENA event handling, and SSDP processing. Three other candidates remained deferred rather than being counted as fixed.
Perl Net::UPnP	PR #4 recorded seven validated findings but changed no implementation. PR #5 and PR #6 supplied the repairs, including HTTP deadlines and limits, SSDP destination constraints, bounded traversal, and XML escaping.

In my own experience, Codex Security sometimes warned and stopped during deeper investigations without Daybreak Access. I have now obtained the hardware security key needed for the individual access process and plan to repeat those detailed reviews once the remaining setup and approval are complete.

Existing debt: resolving work that had waited for years

For an individual maintainer, the limiting factor is often the time and effort available for reproducing reports, implementing changes, and checking compatibility alongside other work. Even when I knew what needed attention, I could not always make room for it. Agents made more of that work practical to take on.

mUPnP for C: resolving long-standing discovery and compatibility issues

The mUPnP 3.1.1 release brought together fixes for discovery that could stall, missing access to device-description information, and resource and object-lifetime problems. It also added opt-in IPv6 support requested years earlier.

Long-standing problem	Work included in 3.1.1
Discovery could hang on a dropped TCP connection (Issue #10, 2014).	PR #40 applied pre-connect socket timeouts and bounded connection establishment.
Missing access to declared state-variable information (Issue #9, 2014).	PR #41 and PR #46 exposed SCPD default values and data types.
IPv6 support requested in 2016 (Issue #17).	PR #42 and PR #43 added opt-in link-local support and corrected discovery address handling. Still experimental, without real-network IPv6 validation.
Resource and lifecycle defects.	PR #39 grew HTTP buffers as data arrived; PR #44 fixed subscription URL leaks and a device-deletion use-after-free; PR #47 stopped endless startup retries without a usable interface.

These were different kinds of maintenance work, from making existing behavior reliable to exposing information applications needed and extending protocol support.

Net::UPnP: working through a long-standing CPAN backlog

Before this maintenance effort, Net::UPnP had not had a release since 2018. After the October security review described above, I returned to a CPAN RT queue containing 17 reports from 2006–2018, some nearly twenty years old.

The releases combined security hardening, compatibility corrections, and the long-requested protocol addition:

Release	Main changes
1.4.7 · PR #7	Shipped the security hardening, corrected documentation and example errors, and added the correctly spelled `gettotalbytesreceived()` while retaining the old name as an alias.
1.4.8 · PR #9	Fixed empty service-list handling, respected caller-supplied control URLs and joined relative URLs correctly, switched requests to HTTP/1.1 for devices rejecting HTTP/1.0, and declared the BSD license in package metadata.
1.4.9 · PR #11	Added WANPPPConnection support for routers without WANIPConnection, addressing a request from 2010.

Across 1.4.7–1.4.9, the regression suite grew from 193 to 236 tests, without retesting every historical device. The 17 ticket closures were not 17 new fixes: six were already addressed, and three involved guidance or retest requests.

2. The developer's work and enjoyment have changed

I used to write code at the speed of my own thinking. Working out a design and making it run felt like solving a puzzle. The process satisfied my intellectual curiosity, and completing it brought a sense of achievement.

PuzzleDB: a changing sense of technical challenge

PuzzleDB is my Go-based, multi-protocol database project, inspired by the idea of a Cosmos DB-style system with multiple database interfaces over shared services. It includes PostgreSQL- and MySQL-compatible protocol frontends, with compatibility still being developed rather than complete. I had been working on it energetically in recent years and wrote about its design in Building a Multi-Protocol NewSQL Database in Go.

Building a compatible implementation also meant understanding the protocol specifications in detail, rather than simply translating them into code. That work sometimes exposed errors or inconsistencies in the documentation itself. I submitted MySQL PR #568 to correct the payload length in a COM_QUERY example, and PR #593 to correct COM_STMT_PREPARE examples and the documented condition for reading warning_count. The corresponding MySQL bug records document these fixes in 9.2.0 and 9.3.0, respectively.

It was a difficult, absorbing way to learn by building. Understanding the specifications, checking them against actual packets, and contributing what I found were part of the challenge. But established implementations, protocols, and tests also make this field especially accessible to coding agents. I have lost much of the motivation that came from treating it as a personal challenge.

Project	What changed my sense of the challenge
PuzzleDB	The pleasure lay in learning to make a complex system work myself, not only in obtaining a working database.
pgrust	Michael Malis describes using Codex to reimplement PostgreSQL in Rust from existing code and regression tests.
rusql	Its author describes an agent-written Rust implementation targeting MySQL 8.0 compatibility using Claude Code and Cursor. It remains a developer preview, not a production replacement.

The latter two are independent projects and their authors' accounts, not replacements of upstream PostgreSQL or MySQL or proof of full compatibility.

Even with those limits, seeing such work changes my sense of the challenge. An agent may make implementation easier while taking away the particular satisfaction that made me want to implement it myself. Getting more done does not automatically replace that motivation.

Retro computing: rethinking a retirement hobby

The same change has reached a hobby I had been saving for retirement: hacking retro computers. I had collected many arcade circuit boards and old computers, expecting years of enjoyment from understanding them and making them do something new. Yet my interest in that work has faded surprisingly quickly as well.

Retro-computing example	Agent-assisted work and its limits
Game Boy emulator	Sanjeet describes ten days with Claude Code and other models, getting Tetris running and improving graphics and audio. Incorrect simplification of pixel processing and register/joypad problems still required expert help.
Marbles² game port	Remy Sharp brought his 2002 Palm game to a 32 KB Game Boy cartridge in about a week, with Claude Code writing the code. He directed design iterations and proposed a one-bit font saving about 3 KB; the same approach failed on another game.
ZX-Reaper	The project reports annotated, rebuildable assembly and a Python port of Hungry Horace, checked against gameplay and Z80 memory/state traces. Jet Set Willy had reached assembly reconstruction.

These examples do not reproduce my collection or settle every hardware problem. They do change my anticipation of the work. What I had imagined as a long, hands-on journey of discovery now looks increasingly like something I could direct an agent through. Even when the result is impressive, that is not necessarily the retirement hobby I had been looking forward to.

3. How I develop now

My work now often resembles leading a project with capable staff. I describe the objective, inspect the result, point out what is missing, and make the next decision. Instead of working through one project at a time, I now routinely delegate work across several projects in parallel. That creates a different kind of busyness: I need to keep making decisions so that I do not become their bottleneck.

In my professional work, I have developed substantial systems with human teams, including FractalDB. In that setting, making a design real involved more than solving technical problems. Aligning priorities and carrying a direction through a team could take as much care as the implementation itself. I also put considerable effort into making sure I did not become the person holding everyone else up. I find myself worrying about the same thing with agents, and that sense of needing to keep their work moving can itself be exhausting.

Working with agents feels lighter. Even a large project carries less coordination overhead, and I can pursue my own design intentions more directly. Commissioning designers and securing people used to be essential to moving a project forward. Whether or not I have those skills myself, I can now readily ask an agent to take on such work. I still have to judge the result, but trying another approach no longer requires the same effort to arrange.

When I wrote the code by hand, the work could move at the speed of my own thinking. With agents, the next question, result, or decision can arrive before I have finished processing the last one. Across parallel projects, that pace sometimes exceeds what I can comfortably take in. I can feel as though there is no time to pause, even though the agents are doing more of the implementation. For me, less manual coding has not necessarily meant a less tiring working day.

Capable does not mean infallible. An agent may start implementing before clarifying a requirement, overlook an existing design policy, or produce code that works but does not fit the project's conventions. People also deliver imperfect work. The difference is partly in how I can respond.

With a human team, each iteration costs time and attention and can affect morale. Even a valid architectural refinement or coding-style correction has to be weighed against other priorities. Good collaboration includes deciding which changes justify asking people to revisit their work.

With an agent, asking for another revision feels lighter. I can revisit details I might previously have accepted as a practical compromise, while still having to make the requirements clear and judge whether the result actually meets them. If agents had feelings, though, mine might have quite a grudge against me by now.

There is satisfaction in directing work across several projects and seeing neglected software improve. It is a different satisfaction from solving each puzzle with my own hands. I do not think I need to pretend that nothing has been lost in order to acknowledge what I have gained.

4. If rebuilding becomes easier, what happens to OSS?

These experiences bring me back to the larger question. A substantial reason to reuse software has been the human effort required to build it. Agents are lowering that barrier enough that starting again can feel feasible even for fairly substantial software.

Previously, disagreeing with an open-source project's policies might lead me to accept the difference, propose a change, or maintain a fork. Now I also consider asking an agent to build an implementation around my own requirements. Adopting existing OSS no longer feels like the automatic first choice in every case for me. That is a change in my own decisions, not evidence that everyone will make the same choice.

That does not make the work free. Computation has substantial costs even when my marginal cost feels low within a subscription. Verification, security work, compatibility, and maintenance continue to consume resources. And non-commercial open source has never been motivated by economics alone. Curiosity and the desire to solve a problem are reasons to build something even when a reusable implementation exists.

Companies may make similar choices. An in-house implementation tailored to a business could become more attractive than a general package or SaaS product in some cases. Having source code locally also gives an agent something concrete to inspect and adapt. Whether that choice is economical over the whole lifecycle will depend on the organization and the software.

Shared knowledge and reusable implementations still have value, whether shared by individuals, within a company, across a specialist domain, publicly, or privately. I am consolidating what I learn into libraries and tools such as asciidoc-pubkit for publishing and git-history-cleaner for Git workflows. Reusing that knowledge helps me avoid solving the same operational problem repeatedly.

Libraries and tools also let me put repeatable operations into deterministic code instead of asking a model to interpret a skill and recreate the procedure each time. With fixed inputs, versions, and relevant environmental conditions, that code can provide behavior I can test and reproduce. A model-guided skill is useful for choosing and adapting a workflow, but its interpretation can vary between runs. Skills can call deterministic tools; I see value in combining that flexibility with a stable implementation underneath, rather than replacing every tool with instructions.

This also raises a question about collaboration. When building an alternative takes less effort, I may have less reason to accept upstream decisions or spend time negotiating a change with committers. Shared maintenance and knowledge still give me reasons to participate, but the balance may shift. Projects in which a small group holds decision-making authority may have to reconsider how they involve contributors if those contributors find it easier to leave and build something else. I do not know whether that will change governance, encourage more private implementations, or lead us back to shared foundations.

5. Why the enthusiasm for writing and rewriting in Rust?

The question of rebuilding software also brings me back to language choice. Microsoft’s native TypeScript compiler port uses Go; the independent stc project attempted a TypeScript type checker in Rust, but was archived in 2025. Neither should be presented as evidence that coding agents caused those language choices. More recently, pgrust has used coding agents to build an independent Rust implementation of PostgreSQL functionality, not an upstream PostgreSQL rewrite or a fully compatible replacement. Such examples make me question the enthusiasm for treating Rust as the natural choice for agent-written software. My own perspective comes from implementing uEcho in C, Go, and Rust, rather than from the language choice of a prominent rewrite.

In my earlier comparison of Rust, Go, and C for database and IoT applications, I preferred Go as a general-purpose option for my work. The conclusion weighed design flexibility, reuse of existing code, implementation effort, and surrounding tools, not performance alone. Working across uEcho for C, Go, and Rust, I found that ownership, lifetimes, and the scope of mutex guards in the Rust implementation made it difficult to carry over my existing shared-data design. I used copies in some places; avoiding them would have required more substantial redesign. That was an experience with my implementation, not a claim that Rust’s move semantics inherently require copying or prevent zero-copy concurrency. The benchmarks were also specific to those implementations and build settings, not a general ranking of the languages.

I have tended to see Rust’s restrictions as a way to prevent mistakes that programmers can make. That leads me to ask what changes when an agent does much of the programming. Could I give it C or Go, integrate the relevant tools into its harness, and have it repeatedly investigate and correct failures instead? By harness, I mean the surrounding build, test, analysis, and feedback workflow, not simply a more detailed prompt. For C, that could include compiler warnings, static analysis, sanitizers, fuzzing, and tools such as Valgrind; for Go, it could include vet, the race detector, fuzzing, and application-level tests. These tools are not equivalent to Rust’s compile-time memory-safety and data-race checks: agents still make mistakes, and runtime tools such as Go’s race detector depend on what is actually executed. Neither approach guarantees correct application logic or freedom from deadlocks, so I want to choose through practical experience and verification rather than enthusiasm for a language.

This is not only my question. In “Why Go is a good language for coding agents”, Alexandre Grison questions whether stricter compiler constraints always make a better environment for an agent. He argues that Go’s smaller set of concepts and short build-and-test loop can help an agent converge on an understandable solution. He also acknowledges the strongest counterargument: Rust’s compiler checks properties that Go’s does not and provides useful feedback for autonomous changes. His discussion supports comparing the whole feedback loop, not declaring either language universally better. Steve Francia makes a related case, arguing that Rust’s complexity and refactoring costs can weigh against it as an agentic default while acknowledging use cases where its guarantees and interoperability make it the better fit. These are practitioners’ arguments, not evidence that one language wins across all agents and workloads.

For my projects, I want the decision to follow the requirements, existing libraries, interoperability, and measurable verification results. If an agent can make a C or Go implementation easier to maintain and test, I do not want to dismiss that option merely because a Rust rewrite sounds more modern. Equally, when compile-time guarantees materially reduce the risk, they are a reason to choose Rust even if an agent writes the code. What I am questioning is choosing Rust blindly as the default, without weighing those trade-offs against the project’s needs, not the value of its guarantees.

6. More progress, a different reason to build

Coding agents have made it more practical for me to develop new features, investigate security problems, and keep long-lived projects useful. My role has shifted toward choosing the work, giving it direction, and checking the result. The progress is real, but so is the responsibility that remains with me.

What surprised me was how much of the reward had come from the process itself. I was looking forward not only to finished software or working hardware, but to becoming the person who could understand and build it. Getting the result more easily does not necessarily give me that same satisfaction.

I also want to keep testing which language and verification workflow fits each project, rather than following enthusiasm for Rust rewrites or assuming that agent-written software settles the case for Rust, C, or Go. I have not settled what this means for my own motivation, or how easier alternatives will change my reasons to work with others on shared software.

For now, I intend to keep developing and publishing what I make. I can value the work that coding agents have made possible while continuing to ask what I want from the act of building it.

Rust Implementation Guide - from efficient learning to implementation

Satoshi Konno — Sun, 19 Jan 2025 08:53:26 +0000

In the last issue [30], I implemented the same application in Go, Rust, and C (+ Python) and evaluated the implementation efficiency and speed with each language. In this article, we will summarize our views on how to learn and implement Rust efficiently based on our experience.

How to learn Rust

Rust is considered a language that requires a learning period before productivity is realized [5]. With statistics showing that more than 50% of people leave during the initial learning phase and many of them fail within a month [6], effective initial learning is especially important.

STEP1: Overcoming the Learning Readiness Phase

There are many esoteric interpretations of the Rust compiler (without explicit solutions) [11], but first learn the basics of the Rust compiler until you understand and can interact with its error content.

While Rust is rife with books and materials for beginners [5], there is a dearth of materials aimed at practical intermediate and above [5] has not improved much. In conclusion, instead of struggling with compilers in the dark, the shortcut to Rust mastery is to first improve basic skills with good learning materials, which are the primary resources shown below [7][8].

There are also scattered opinions that C/C++ is easy for skilled users to learn [7][9][10], so in terms of deepening the usefulness of Rust, it is also important to deepen the C/C ++ language may also be a shortcut to learning Rust.

STEP2: Practical project challenges

If your goal is to "learn Rust," you will have achieved your objective at this stage. However, the difficulty of Rust lies in the difficulty of practice, after overcoming the preparatory phase of the learning curve [5][11][12][15]. In conclusion, it seems to be efficient for Rust learning to start some kind of practical project [13][14].

If it does not follow the semantics of Rust, design patterns (experience) in other programming languages cannot be brought in directly [16], and trial and error is required. In terms of comparison with existing languages, the following tutorials may be helpful.

[15] Learning Rust With Entirely Too Many Linked Lists

As mentioned above, the situation [5], where there is a dearth of material aimed at the practical intermediate level and above, has not improved very much. As an actual example, you can read the divergence between the following materials recommended for beginners to step up and the practical subject matter [15] shown in the above tutorial.

In other words, because there is not as much "Effective" intermediate and above information as in other languages, you need to struggle with the Rust compiler and establish (pioneer) the following design patterns (experiences) [16] must be established (pioneered) by yourself while struggling with the Rust compiler.

Many books and materials that are considered intermediate level are simplified by limiting the field of application, both in a good and bad way. In conclusion, there are few things better than official materials, and a practical shortcut may be to deepen understanding by trial and error while going back to official materials in practice.

Books that are field-specific in title are an effective way to gain implementation knowledge of Rust in a specific area, serving as a Rosetta Stone of sorts. However, it should be understood only as one implementation example, and whether it is the best way or not may be reconsidered through practice.

Rust at Work

The most recent Rust community survey included a "Rust at Work" item [21][13], which emphasizes the adoption of Rut as a professional language. The most recent, 2021 survey results [13] show that while the rate of use at work has increased significantly from 42% to 59% in the previous year, industry adoption The lack of adoption in the industry was cited as the biggest concern (38%) for Rust's future.

Basically, a programming language is a means to an end and should be selected based on the circumstances of the target project and team. Based on this assumption, here is a list of items to consider when adopting Rust.

Consideration of project characteristics

First, it is important to determine whether the project to which Rust is applied is compatible with Rust semantics, in the sense of avoiding implementation complexity and performance degradation in Rust. Simply put, a project that is not stateless and involves parallel processing with data sharing in the Rust processing unit cannot be handled solely with Rust's move (Move) semantics, and ownership and lifetime management will become more complex.

For example, stateless web applications and[31], which can be handled naturally with Rust's move (Move) semantics and SEDA[32], which are concurrency models that do not require data sharing, the semantics of Rust adoption is unlikely to be a problem.

Also, if we ignore the compatibility and complexity of the implementation, the adoption track record of Rust in the same field as the project, and for what applications and at what scale it has been implemented, will be a good guide for making an adoption decision [14].

Secure core members

What is clear is that if you are at a stage where you do not have personnel proficient in Rust, and you cannot determine the compatibility of Rust with the characteristics of your project, you should avoid hiring Rust. Simply put, you should avoid hiring Rust out of curiosity.

It is essential to have a core team that is proficient in Rust. Conversely, if the core team has established design patterns for Rust implementation, it will be easier to add more people to the project, even if they are new to Rust.

Basically, if core members have established a template or methodology for implementing Rust in a project, new members can follow that style and extend the project structure even if they are not necessarily proficient in Rust.

Scope of Standard Library Offerings

Rust is a language that has strengths in system programming and situations where high performance is required, but the coverage and functionality of the standard library is on the poor side, similar to the C language. The standard library provided lacks functionality and speed [30]. memo/rust-eval-loc-perf/)[30][31], and other maturity challenges In some cases, the

Realistically, considering the scope of standard library offerings and the economics of the project, we will have to take the approach of developing a combination of third-party crates. In particular, for complex data structures and highly parallel processing functions, we are forced to rely heavily on third-party crates.

However, depending on the quality and maintenance status of the crate, the project may be more at risk, and this should be taken into consideration. Also, as with Perl's CPAN, crates are registered on a first-come, first-served basis, so even if a crate is published under a major name, there may be alternative crates of higher quality and more actively developed, so thorough investigation is essential before adoption.

Inheritance of past assets

Realistically, many will want to leverage existing development assets rather than implement exclusively in Rust, and Rust continues to see a high demand for interoperability with C/C++ language assets as an important issue [5][24][25][26][27][28][29].

Compared to C++, Objective-C, and Go, where interoperability with C is guaranteed at the language level and can be used simply by including header files, Rust's interoperability is one major barrier. Rust provides a FFI (Foreign Function Interface) to interface with other languages, but interoperation with C requires a separate FFI definition that shows the correspondence with Rust types. rust-bindgen[27], but there are also FFI generators such as [28][29] will be an important factor in the decision to adopt Rust.

Conclusion

While Rust is highly secure and performs well, learning Rust involves steep hurdles and struggles with the compiler, so effective learning methods and preparation are necessary. In the initial stages, it is important to cultivate a basic ability to understand and respond to compiler error messages, and to ensure that you learn Rust-specific concepts by using good official materials and books for beginning students.

When considering the adoption of Rust for a project, it is particularly important to confirm the project characteristics and the Rust proficiency of the team, and to establish appropriate design patterns and support systems.

We hope that by utilizing the learning materials and reference materials introduced in this article, you will be able to maximize the potential of Rust by establishing basic skills and then putting them into practice.

Rust vs Go vs C: Database and IoT Application Performance Benchmarks

Satoshi Konno — Sun, 19 Jan 2025 08:46:03 +0000

Rust is a language designed to be both secure and fast [1], and in recent years, it has been expected to make further strides as a professional language employed in business [3] [8]. However, the results of the 2021 survey [3] also show that while the rate of use at work has increased significantly from 42% to 59%, the lack of actual adoption in the industry was cited as the biggest concern (38%) about Rust's future.

In this article, to determine the practicality of Rust, we sought to compare and evaluate its implementation against application implementations with the same specifications in other programming languages, such as C and Go. We prepared two targeted evaluation applications, Database (Redis) and IoT (ECHONET Lite), to assess the efficiency and performance of practical Rust implementation.

In summary, Go is considered the best successor to C from a Better C perspective, followed by Objective-C, Rust, and C++. Rust offers safety and speed but has limitations in productivity, interoperability, and programming flexibility. Despite these challenges, Go stands out for its implementation efficiency and stable performance, making it a safe choice for general-purpose applications.

Evaluation 1 - Database Application (Redis)

This evaluation will compare C, Rust, and Go implementations of the Redis [19] specification in the database area as the same application. The official Redis implementation [19] is in C, while the Rust and Go implementations are unofficial subset implementations. The following is a list of databases using Redis used in this evaluation.

The Rust implementation is mini-redis [21], which was released as a learning tool for the Tokio [20] library, and the Go implementation is a sample implementation (go-redis-server) of my Redis-compatible database implementation go-redis [23].

Compared to the official Redis implementation [19], mini-redis [21] and go-redis [23] are subset implementations, and therefore cannot be evaluated for implementation efficiency using LOC (Lines of Code), only for performance.

Evaluation Benchmarks

The benchmark programs evaluated were performed with redis-benchmark, the official benchmark tool for Redis. The benchmarks are not a full set but are limited to SET/GET commands and are run every 10,000 iterations with the standard 50 threads.

The reason for being limited to only basic SET/GET commands is that mini-redis [21] is only a minimal command implementation, such as SET/GET commands, and we followed the benchmark parameters [22] in mini-redis [21]. Note that mini-redis [21] is the latest version at the time of evaluation and the environment is "Mac mini (2018) + macOS 12.6".

Performance Evaluation - C > Go > Rust

The results of the SET/GET command execution by "redis-benchmark" are shown below. The 99th percentile (p99(ratio)) value, which is used as an indicator for database operation, is shown at the right end of the table along with the performance ratio based on the C language.

In the evaluation benchmarks, the official implementations of redis-server in C [19], go-redis in Go [23], and mini-redis in Rust [21] were faster, in that order. A graph of the above table is shown below.

The C redis-server [19] was optimized and was about 3 times faster than the sample implementations in Go and Rust. Both Go's go-redis [23] and Rust's mini-redis [21] were implemented as samples, and both have room for improvement. Taking this into consideration, a brief review of the evaluation results for each programming language is presented below.

Rust

Compared to the official C redis-server [19], SET: 28% and GET: 41% slower, and compared to the Go implementation go-redis [23], SET: 78% (=2.879/3.663) and GET: 88% (=2.167/2.455) slower.

Since the Tokio [20] library has been released for training purposes, it is assumed that full-scale optimization has not yet been performed. However, to some extent, optimization seems to have been performed by comparing performance with the official implementation of Redis [19] [22].

It is positioned for learning the Tokio [20] library, and the implementation basically uses the Tokio [20] library, with the network part built based on the Tokio [20] TCP server (tokio::net::TcpListener). However, the key-value data management part of the database is implemented with the HashMap of the standard (std) library and Mutex of the standard (std) library for exclusive control, as in the implementation of Evaluation 2. Performance issues may be based on performance issues of the standard (std) library [18], such as HashMap [17], as in Evaluation 2.

Go

Compared to the official C redis-server [19], SET: 35% and GET: 46% faster, while compared to Rust's mini-redis [21], SET: 127% (=3.663/2.879) and GET: 113% (=2.455/2.167) faster.

Go-redis [23] is a framework for implementing Redis-compatible databases, and like mini-redis [21], the target of this evaluation is a sample implementation, so the implementation is simple. The speed difference from the official implementation was unexpected due to the assumption that there was little room for optimization.

Go-redis [23] and the sample implementation "go-redis-server" are implemented only with the standard library, and the key-value data management part of the database is implemented with sync.Map. It will be necessary to refer to the official implementation for performance differences with the official implementation, in parallel with identifying bottlenecks in the profiling.

Evaluation 2 - IoT Applications (ECHONET Lite)

This evaluation targets client-server function implementations of ECHONET Lite [9], a communication protocol in the IoT field. This implementation is an evaluation of an application for which the target requirement specifications (= ECHONET Lite [9] specifications) are the same, and the design and implementers are the same.

Evaluation Frameworks

The Rust implementation [12] of ECHONET Lite [9] implemented in C [11], Go [13], and Python [14] are compared. The basic ECHONET Lite [9] functions are implemented using the same design as far as possible, but there are some differences in function implementation between the languages. An overview of the differences in implemented functions is shown in the figure below.

The ECHONET Lite [9] framework implementation subject to this evaluation was implemented in C, Go, Python, and Rust, in that order, and basically follows the same design.

As explained in the ECHONET Lite [9] Specification, the basic Device function, the Controller function for operating devices, and the Database function for standard devices [10] defined in ECHONET Lite are implemented in all programming languages.

However, for the transport layer of the ECHONET Lite [9] specification, only the mandatory UDP communication function is implemented in all programming languages, while the optional TCP communicator is implemented only in C [11] and Go [13], with implementation in Rust [12] and Python [14] omitted.

Implementation Efficiency (≠ Effort) Evaluation - Python > Rust ≈ Go > C

The efficiency of implementation in Rust was evaluated in terms of lines of code (LOC), which was calculated using Tokei [16] and excludes comments and blank lines. The results of LOC calculation are shown in the figure below.

For Auto, only the source code, which is the automatically generated code defining the ECHONET Lite standard devices [10] and excluding the C language header file, was subject to evaluation. The graphs in the above table are shown below.

Taking into account the range of implemented functionality, the LOC evaluation results in the following order: Python > Rust ≈ Go > C, with the least implemented code. Below is a brief review of each programming language.

Rust

The LOC results show that (although there is no implementation of TCP functionality), the implementation rating is equivalent to Go, with a LOC efficiency of 53% of that of C. This implementation with Rust was implemented using only standard (std) libraries such as Mutex, with the exception of the UDPSocket issue described below.

Rust is a language that generally requires a learning period before it feels productive [5]. Therefore, in Rust, it is not simply ‘less LOC = more implementation effort’: even code with a low LOC often takes a long time to implement because the developer struggles with the Rust compiler. Also, the extremely high LOC of auto-generated code is due to the specification of a standard maximum line width (max_width=100) in Rust's formatter (rustfmt), which is excluded from the evaluation.

There are also restrictions due to Rust-specific move semantics and lifetime, which can make it impossible to bring in designs from other languages, which can lead to high design costs. In the current implementation, some design changes were made due to the limitations of introducing the Observer pattern for trait objects and the locking interval synchronised with the Mutex lifetime.

C

The implementation in C resulted in the largest LOC. The reason for this is that this implementation does not use external libraries and includes self contained libraries (e.g. strings, list structures, object-oriented structures, etc.) which are not needed in other languages, and wrapper classes (e.g. Mutex, Thread, etc.) for portability. The home-grown libraries are shared with other C projects and are not as heavily implemented in this application as the LOC figures.

Go

The LOC results show that the implementation efficiency is comparable to Rust, with an implementation rating of 63% of the source code compared to C. In Rust, there were issues with some of the standard libraries, but in the Go language, the implementation was carried out using only the standard libraries.

Basically, the C design is implemented in the Go language as it is in C. Unlike the implementation in Rust, the design in C can be diverted and implemented, and there is flexibility. In addition, the standard library is more extensive than that of the C language, which can be evaluated as being directly related to ‘less LOC = less implementation time’.

Python

The implementation in Python has the lowest LOC result in this implementation evaluation, because Python does not require parentheses ({}) in code block expressions, so a comparison with other languages that require parentheses (C, Rust, Go) requires a subtraction. Also, in comparison to Rust, the fact that implementations can be inherited contributes to the reduction of LOC.

Python also has the flexibility to straightforwardly transfer designs from C and Go. Apart from the execution speed issues described below, it may be the best prototyping language

Performance Evaluation - Go > C > Rust > Python

The execution performance of Rust was evaluated for the same level of functionality of ECHONET Lite [9], the target of the evaluation, with the same basic design implementation. The benchmark program evaluated was a node in which the controller and objects of ECHONET Lite [9] were implemented.

Evaluation Benchmarks

In the benchmark program evaluated, the ECHONET Lite [9] controller is a UDP client, and the object is a UDP server. The main loop, which is the basic sequence of the benchmark, consists of 12 UDP requests (Requests) from the controller and 12 UDP responses (Responses) from the object per execution.

To explain this in accordance with the ECHONET Lite [9] Specification, the ECHONET Lite controller itself is discovered by a UDP multicast request (ESV: 0x62) and the implementation-required properties of the node profile object (0x0EF001) contained in the discovered controller node (0x0EF001) are set to the following values (12). The benchmark is 10,000 iterations of the request (ESV:0x62) response (ESV:0x72) operation with the UDP protocol for the values of [10] (12 values). For the evaluation of implemented code, no optimization options were used in each environment. The environment is "Mac mini (2018) + macOS 12.6" and the details of the evaluation scripts are available here [15].

Performance evaluation results

The performance evaluation was measured by using the time command to measure the execution time of 10,000 iterations of the basic sequence shown in the evaluation benchmarks. The evaluation results are shown below, along with an overview of the compilation conditions and implementation techniques for each programming language.

In the evaluation benchmarks, Go was the fastest implementation, followed by C, Rust, and Python. Since UDP communication is asynchronous, data transmission and reception from a request (Request) to a response (Response) are implemented using the condition and channel mechanisms of each programming language. A graph of the above table is shown below.

Python was excluded from the scalability analysis due to its extremely slow execution speed. In order to compare performance with C language, the performance ratio of each programming language relative to C language is shown in the figure below, along with a brief evaluation of the performance results for each programming language.

Rust

The Rust implementation performed worse than the Go and C implementations, being only 33% as fast as C and about 20% (=33/160) as fast as Go. While the system (sys) time is comparable to Go and faster than C, the user (user) time is larger than in C and Go.

The cause needs to be investigated, but according to "The Rust Performance Book" [17] and "The Rust Language FAQ" [18], there are some standard (std) libraries, such as HashMap, that may be slow under certain circumstances.

In addition, the standard (std) library Mutex, which is used extensively in this implementation, is difficult to handle because its valid interval is the same as that of the target object, and there are parts where copy semantics are unavoidably used to avoid this. Other language implementations are zero-copy (Zero Copy), so programmatically there is room for improvement (although significant design changes are required).

In addition, the standard (std) library UDPSocket cannot support socket creation by the same port number, so a non-standard crate must be used in conjunction with the implementation of IoT-related protocols such as ECHONET Lite [9] and mDNS, which are the target of this implementation. In addition, although IPv6 functionality has been implemented, it cannot be enabled at this time due to an error.

C

Basically, the user (user) time is the fastest, but the system (sys) time is 2.5 times slower than Go and Rust. We had no concerns about the performance of the C language until this evaluation, but there may be issues with the use of standard libraries such as pthreads.

Go

The Go implementation was the fastest in this evaluation benchmark, 1.6 times (=160%) faster than the C implementation and 5 times (=4.8=160%/33%) faster than the Rust implementation. It seems that the best results were obtained by writing a straightforward program.

Python

As might be expected, the Python implementation produced the lowest results in this evaluation benchmark. The system (sys) time degraded by only 1/2 (=53%) compared to C, but the user (user) time performance is less than 1/100 (<1%), a characteristic of the interpreter execution since it is a pure Python implementation.

Conslusion

If I were to evaluate Go as the successor to C and from a Better C perspective, I would personally rank Go = (Objective-C) > Rust > C++. C++ is overspecified in terms of Better C, and Objective-C has stopped evolving since 2007 (2.0) when ARC was introduced. Swift, the supposed successor, also has an uncertain multi-platform future [23].

Regarding productivity, Rust is a language that generally requires a learning period before it feels productive [5]. It is a language that is both safe and fast [1], but due to its limitations, it is a language that forces a struggle with the compiler, both good and bad. If it does not follow Rust's semantics, it is not possible to bring in design patterns (experience) from other languages. However, its limitations make it a language that requires contending with the compiler, in both good and bad ways.

In terms of productivity, it is often desirable to use existing development assets rather than implementations that can be completed only in Rust, as in this evaluation. Interoperability of C/C++ language assets continues to be highly desired in Rust and is recognized as a major challenge [5] [25] [26] [4] [27]. While there are FFI generators such as rust-bindgen [27], they are not interoperable with existing assets, and the interoperability issue is a major barrier compared to C++, Objective-C, and Go, where interoperability with C is guaranteed at the language level and can be used simply by including header files. Interoperability issues will be a factor in the decision to adopt Rust.

In terms of design, Rust also has to bring in reference (Arc) and exclusion control (Mutex) semantics similar to the C/C++/Go languages in concurrency applications (with data sharing), and also has to avoid the semantic limitations of Rust's language specification, such as move and lifetime. There is no escape from the limitations of the Rust language specification, such as Move and Lifetime. As a result, the degree of programming flexibility is limited compared to other programming languages, and design and implementation trade-off decisions need to be made that have an impact on productivity and performance, as shown in the performance evaluation discussion in Evaluation (ii).

As for safety, Rust is a programming language that is ensured by static analysis and dynamic boundary checks. However, even in traditional C/C++, a wealth of static analysis tools (e.g. Clang Static Analyze) and dynamic analysis tools (e.g. Valgrind) can be utilised, so a comprehensive evaluation including peripheral tools will be necessary.

Finally, in the performance evaluation, issues were identified in the Rust, C, and Go implementations. In this evaluation, the Go implementation showed good implementation efficiency and stable performance. Go may be the safest candidate as a general-purpose option. In any case, we will investigate the performance issues of each language in more detail.

DEV Community: Satoshi Konno

Inside a Persistent AI Agent: Reading MUSE Through Its Harness

At a glance

1. Architecture and the execution loop

From a request to the next decision

Execution and retained resources

Following an execution

2. Tools and connections to external services

Two routes from capability discovery to execution

An executable catalog, not a function catalog

Cloud browser, paired Mac and private-network access

Approval is not service authorization

3. State, memory and context

PostgreSQL: structured conversation and runtime state

Files: persistent home and replaceable system tools

Memory: source records, derived summaries and corrections

Context: compaction and selective retrieval

4. Work that continues outside a conversation

Triggers, retained goals and generated outputs

Continuing work without confusing a proposal with an action

5. Testing continuity through Spaces

Application types, files and data

Application lifecycle: builds are not user data

Capabilities and background refresh

Prototype operations and observed results

The prototype’s reported action and database path

Conclusion

Appendix A. Complete executable catalog

Appendix B. Reported persistence schema

chat.chats — chat identity and lifecycle

agent.sessions — session identity and origin

agent.context_items — ordered context items

agent.compactions — summarized history ranges

agent.runtime_restart_checkpoints — saved restart state

Relationship and verification boundaries

Appendix C. Reported filesystem tree

Appendix D. Spaces contracts and experiment details

Application types and execution

Files and the application database

Static snapshots are not proof of a public sharing feature

Stack reported from the generated application

Files, typed actions and the database boundary

Further verification

Interview premise and terms

Sources and scope

Coding Agents Are Changing How I Build Open Source and Why I Do It

At a glance

1. Coding agents got stalled maintenance moving again

New development: accelerating work and reaching new platforms

Matter: restarting go-matter

ESP32: bringing existing libraries to a new platform

New reports and PRs: responding promptly with less burden

Security review: turning findings into checked fixes

Existing debt: resolving work that had waited for years

mUPnP for C: resolving long-standing discovery and compatibility issues

Net::UPnP: working through a long-standing CPAN backlog

2. The developer's work and enjoyment have changed

PuzzleDB: a changing sense of technical challenge

Retro computing: rethinking a retirement hobby

3. How I develop now

4. If rebuilding becomes easier, what happens to OSS?

5. Why the enthusiasm for writing and rewriting in Rust?

6. More progress, a different reason to build

Rust Implementation Guide - from efficient learning to implementation

How to learn Rust

STEP1: Overcoming the Learning Readiness Phase

STEP2: Practical project challenges

Rust at Work

Consideration of project characteristics

Secure core members

Scope of Standard Library Offerings

Inheritance of past assets

Conclusion

Rust vs Go vs C: Database and IoT Application Performance Benchmarks

Evaluation 1 - Database Application (Redis)

Evaluation Benchmarks

Performance Evaluation - C > Go > Rust

Rust

Go

Evaluation 2 - IoT Applications (ECHONET Lite)

`chat.chats` — chat identity and lifecycle

`agent.sessions` — session identity and origin

`agent.context_items` — ordered context items

`agent.compactions` — summarized history ranges

`agent.runtime_restart_checkpoints` — saved restart state