September 2026 Summaries
4 posts from Paper Compute Company
Filter
Month:
Year:
Post Summaries
Back to Blog
As coding agents enable engineers and teams to complete more work asynchronously and in parallel, the central challenge shifts from execution to maintaining shared understanding of what happened, why decisions were made, and what requires attention next. Traditional engineering practices such as reviews, standups, conversations, and pull requests created friction but also spread context organically, whereas agent sessions can hide investigations, failed approaches, constraints, and subagent findings behind a final code diff. The passage argues that these “session silos” expand faster than human capacity to absorb new information, making transcripts and logs insufficient without concise, actionable compression. It proposes effective handoffs that explain outcomes, changes, blockers, next steps, and reusable lessons while retaining links to underlying evidence. In response, Paper Compute added digest features to its paper console, summarizing selected time periods with categorized highlights for outcomes, blockers, decisions, efficiency notes, and observations, allowing teams to orient themselves quickly and investigate session traces when needed.
Sep 28, 2026
1,655 words in the original blog post.
Paper Compute evaluated TypeSafe’s Jev as an experimental automatic labeler for agent-session traces, comparing it with GPT-4o mini, Claude Haiku 4.5, and locally run Qwen3 models on 1,781 engineer turns from 138 private team sessions. The system asked whether engineers pushed back on agents, asked questions about their work, stated lasting preferences, or supplied information that would have changed an earlier action, producing candidate labels such as pushback, question, observation, and missing knowledge. Jev had the fastest median response time at 188 ms, compared with roughly 1,023–1,050 ms for the hosted general-purpose models and 2,311 ms for Qwen3 8B, while recovering all 19 human-accepted question-label examples in a 35-turn reviewed subset; however, it also flagged six rejected examples, so its output is intended as a human-review queue rather than a final verdict. Estimated API costs for similar workloads favored Jev over GPT-4o mini and Claude Haiku 4.5, though local hardware, energy, and review costs were excluded. The author emphasizes that the reviewed examples informed question design, making the results development-set agreement rather than a measure of generalizable accuracy, and describes how span-level labels and detailed traces could help teams identify useful human corrections, inspect their context, and potentially train future agent-review systems.
Sep 22, 2026
2,099 words in the original blog post.
Agent-session telemetry can precisely track costs, models, users, and directories but often cannot explain the organizational intent behind the work, making it difficult to connect AI spending to architecture decisions, migrations, or expected outcomes. An analysis of 1,731 sessions and $17,816 in monthly spend found that a prior architecture decision had generated at least $4,728.15 in downstream work, but reconstructing that connection through keywords, identities, dates, and even near-perfect content matching was incomplete and labor-intensive. Keyword searches recovered only part of the relevant cost or introduced false matches, while identity and time-based methods failed as work spread across people, repositories, and months; content-based inference performed better but still depended on organizational knowledge unavailable in session traces. The proposed solution is to attach explicit intent labels, such as decision:cassettes, migration:*, incident:*, or customer:*, to sessions while their purpose is known, creating a durable record that can later link decisions to costs, repositories, rework, outcomes, and reusable skills. Over time, these labels can turn session histories into an index of why work occurred, allowing teams to compare approved plans with actual implementation and use the gap to inform future decisions.
Sep 21, 2026
1,207 words in the original blog post.
“Blast radius” is proposed as a way to measure the downstream work, cost, duration, reach, and rework generated by a single engineering decision, linking RFCs, code history, and AI-agent session records. Using a decision to restructure software components into standalone “cassettes” as a case study, the authors traced 474 sessions over 27 days across three engineers and eight repositories, finding that a $57.05 design session led to at least $4,704.74 in subsequent work, a 65-fold amplification. Although implementation accounted for most human sessions, deployment and migration represented 87% of spending, including one $2,633.11 deployment session, while ongoing automated evaluations added a continuing measurement cost. The analysis also identified costly rework, such as a discarded alias subsystem, a replaced manifest format, and a production database-query fix during migration, illustrating that decision consequences can persist after a project appears complete. The method relies on grouping session records through shared identifiers and prompt evidence, while acknowledging it produces a conservative estimate because unlabelled related work may be missed; the authors argue that as AI lowers execution costs, organizations should place greater scrutiny on the upstream decisions that direct that work.
Sep 02, 2026
8,063 words in the original blog post.