There is one asset that separates a university from a trade school, a scholar from a blogger, and a journal from a Substack: the claim that the work is honest. Not clever. Not well-cited. Honest.

And among all the ways to betray that claim, one stands apart for its particular cowardice: stealing ideas. Not fabricating data out of thin air — that at least requires inventing something. Not plagiarizing published text — that's just lazy. Stealing ideas is different. It is predatory on trust. It exploits the specific vulnerability that academic work requires: sharing your thinking before it is finished, with people who have more power than you do.

This is not a footnote to the broader story of academic fraud. It is the core of it. And the system is built to protect the thieves.

How they do it

The mechanisms are well-known to everyone inside academia and almost invisible to everyone outside it.

The reviewer scoop. You submit a manuscript to a journal or conference. A reviewer sits on it for weeks — long enough to extract the core insight, assign it to a fast-moving postdoc, and get a competing submission into the next venue before yours even clears the review queue. You find out when you see their paper, which cites you in footnote 14 for something tangential while the central idea you developed now has their names on it. Proving it is nearly impossible. The editor will shrug. Your paper now looks derivative of theirs. You lose three years of work to someone who read a PDF for an afternoon and recognized a good idea when they saw one.

The advisor tax. A graduate student spends years developing a research direction, writing the code, running the experiments, drafting the manuscript. The advisor's contribution was a vague suggestion in a meeting two years ago — "maybe try applying X to Y" — that the student turned into an actual research program. When the paper comes out, the advisor is first author. When the press covers it, the advisor is the face. When tenure committees evaluate it, the advisor claims the intellectual leadership. The student gets a diploma and a lesson in how power works.

The conference predator. You present preliminary work at a workshop or a poster session. Someone from a larger, better-funded lab takes careful notes, asks detailed questions that feel like engagement, and then returns to their institution and replicates your approach with more compute, more RAs, and more name recognition. They publish first. You are left explaining to your own advisor why your project now looks like a replication study of someone else's result.

The grant proposal heist. You submit a grant proposal. It is reviewed by a panel that includes a senior person in your subfield. The proposal is rejected — "insufficient preliminary data," "overly ambitious" — but eighteen months later that same senior person's group publishes a paper whose research plan maps almost one-to-one onto your unfunded proposal. You recognize your hypotheses, your experimental design, even your clever naming of conditions. They claim independent convergence. Nobody investigates.

Four mechanisms, same shape every time: someone with less power shares an idea in good faith, someone with more power takes it, and the system provides cover.

The power gradient is the whole story

Fabrication and plagiarism can be committed by anyone at any level. A desperate undergrad can photoshop a gel. A postdoc can copy-paste a literature review.

Idea theft is different. It almost always flows downhill: from the tenured to the untenured, from the senior to the junior, from the well-resourced to the scrappy. The thief has the platform, the lab, the reputation, and the publication velocity to execute on the stolen idea faster than its originator can. The originator has nothing but the sickening moment of recognition when they open a proceedings volume and see their own thought staring back at them under someone else's byline.

This is not a crime of desperation. The people who steal ideas already have labs, grants, and CVs long enough to survive several lifetimes of honest work. They do not need your idea. They take it because they can. Because the power gradient means there are no consequences. Because their reputation will be believed over yours every time.

The perfect crime

And here is why idea theft flourishes while data fabrication occasionally gets caught: it is structurally impossible to prove.

To establish that someone stole your idea, you must demonstrate three things: that the thief had access to the idea (they did — you gave it to them in good faith), that the idea was novel (it was — that's why they took it), and that the thief would not have arrived at it independently. That third one is a logical impossibility. You cannot prove a counterfactual. Two people can independently converge on the same idea. The fact that one of them reviewed the other's manuscript, or heard their talk, or read their grant proposal six months earlier is, legally speaking, a coincidence.

The evidentiary standard is set so high that it functions as a license to steal. Everyone knows this. The thieves count on it. The language they use when confronted — "parallel discovery," "independent convergence," "the idea was in the air" — is rehearsed precisely because it cannot be falsified. It is the academic equivalent of "who are you going to believe, me or your lying eyes?"

What this destroys

The most obvious victim is the person whose idea was taken. They lose years of work, a publication, a grant, a career trajectory. Some leave academia entirely. Some stay and learn the game — they become hoarders, presenting only published work, treating every lab meeting as a potential heist, never sharing a half-formed thought with anyone who outranks them.

That second outcome is the one that should terrify us. When junior researchers learn that sharing ideas means risking expropriation, the intellectual commons collapses. The free exchange of half-formed ideas — the generative friction of honest peer feedback, the hallway conversation that sparks a collaboration, the workshop where someone says "have you thought about trying X?" — all of it dies. What replaces it is a series of armed standoffs where everyone presents finished, timestamped work and nobody says anything real.

The people who steal ideas are not just taking someone else's work. They are burning down the collaborative infrastructure that makes research possible in the first place. And they do it for one more line on a CV they already didn't need.

The incentives are not an excuse

I know the counterargument. "Publish or perish." "The metrics are broken." "Everyone does it."

Yes, the incentive structure is perverse. Yes, hiring committees count papers instead of reading them. Yes, impact factor determines funding, and impact-factor optimization is not the same thing as science.

But the people who steal ideas are, almost without exception, the ones who have already won the game. They have tenure. They have funding. They have students. They are not scrapping for survival — they are padding a record that was already padded. And they are doing it by reaching down the power gradient and taking from people who have none of those protections.

Nobody held a gun to your head and forced you to take a graduate student's dissertation insight, strip their name from it, and publish it as your own "independent" work while they watched from the acknowledgments section. Nobody made you sit on a manuscript you were reviewing, extract its core contribution, and race it to publication with your own lab's resources. You made a calculation — that the personal benefit outweighed the risk, and that the risk was zero because the system is designed to protect people exactly like you — and you acted on it.

That is not structural pressure. That is predation. And the fact that you can dress it up in systems-critique language does not make it less ugly.

Shame is the appropriate response

We have sanitized the language around academic misconduct. "Research integrity concern." "Questionable research practice." "Intellectual property dispute." These phrases exist to avoid saying what actually happened: someone with power reached down, took something that did not belong to them, and the institution looked the other way.

Shame is the correct word. Not embarrassment. Not "a learning opportunity." Shame — the public acknowledgment that you violated a trust held by your students, your colleagues, and the public that funded your work.

If you stole an idea from a student and called it mentorship: shame on you. If you mined a manuscript you were reviewing and raced it to publication: shame on you. If you rejected a grant proposal and then published its research plan under your own name: shame on you. If you heard a junior colleague present at a workshop and beat them to print with your larger lab: shame on you. If you are a department head who knew about any of this and protected the thief because they bring in grants: shame on you. If you are a journal editor who has spent more energy protecting your impact factor than investigating the papers in it: shame on you.

The rest of us — the ones who still believe that honest inquiry matters, that credit should flow to the person who had the idea, and that the power gradient should not function as a permission structure for theft — need to stop treating academic fraud as a PR problem and start treating it as a betrayal. Because that's what it is.

And the idea thieves know it. Watch how they react when caught: not with confession, but with lawyering. Not with repair, but with "independent convergence." Not with shame, but with the calm confidence of someone who knows the system will not touch them.

They know what they did. They just assumed they would get away with it.

Prove them wrong.

Most of the agent conversation focuses on what happens during a task: tool calls, reasoning loops, correctness. Far less attention goes to what happens between tasks — the accumulated state, memory, permissions, commitments, and audit trails that persist across interactions.

A new survey from Ding, Nannapaneni, Liu, and Zhang (Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents, June 2026) argues that this gap is the critical unsolved problem for deploying agents that operate continuously. And they back the claim with a coded analysis of 435 papers.

What is an always-on agent?

The paper defines always-on agents as LLM-based systems whose future behavior depends on durable, accumulated state from past interactions. This state is not just retrievable memories. It includes:

• Task ledgers — what the agent has done, is doing, and has committed to do
• Permissions and credentials — what the agent is authorized to access, and how those authorizations change over time
• Commitments — promises made to users, other agents, or external systems
• Provenance and audit records — how each decision was reached, for post-hoc review
• Shared state — what multiple agents or an agent and its user both rely on
• Trigger conditions — latent rules that fire when certain conditions are met
• Externally committed effects — side effects the agent has already pushed into the world

This is a much richer picture than "the agent has a vector database of past conversations." An always-on agent is a persistent-state system. The persistence is the feature.

The gap: we're good at memory, bad at governance

The survey's central finding is blunt: the literature is heavily skewed toward accumulating and retrieving state, with far less attention to how to govern, recover, or relinquish that state.

We have plenty of papers on retrieval-augmented generation, embedding-based memory, and context window management. We have far fewer on:

• Forgetting. When should an agent delete a memory? How do you ensure it actually forgets — including from backups, cached contexts, and fine-tuned weights? This connects directly to machine unlearning and to legal requirements like GDPR's right to erasure.
• Recovery. If an agent's state is corrupted — by a bad interaction, a prompt injection, a buggy tool — how do you roll back? What is the agentic equivalent of a database transaction?
• Auditing. If an agent made a consequential decision three weeks ago, can you reconstruct exactly what state it had access to at that moment, what it retrieved, and how it weighed that information?
• Authority and scope. Who can modify the agent's state? If an agent has learned a preference from user A, should user B's interactions be influenced by it? What happens when state from different sources conflicts?

The paper frames this as a maturity problem. We have built the memory layer for always-on agents. We have not yet built the governance layer. And you cannot safely deploy persistent-state agents at scale without both.

Six diagnostic axes

The authors propose six axes for analyzing any piece of agent state:

1. Authority — Who or what created this state item? Who can modify or delete it?
2. Scope — Is this state private to one agent, shared across a fleet, or tied to a specific user?
3. Mutability — Can this state change? Under what conditions? Is it append-only, versioned, or freely overwritable?
4. Provenance — Where did this state come from? What chain of interactions produced it?
5. Recoverability — If this state is lost or corrupted, can it be reconstructed? From what?
6. Actionability — Does this state item directly drive agent behavior, or is it purely informational?

Most current agent frameworks score well on actionability (of course state drives behavior) and poorly on provenance and recoverability (good luck reconstructing why the agent did what it did six weeks ago). The axes give teams a checklist for auditing their own systems: for each piece of state your agent accumulates, can you answer all six?

The lifecycle: state as a managed resource

Beyond the diagnostic axes, the paper introduces a lifecycle model for agent state. State is not just written and retrieved — it moves through a series of stages, each of which can fail:

• Write — state is created or updated
• Validate — is the state correct, consistent, not poisoned?
• Organize — how is state structured, indexed, deduplicated?
• Retrieve — the well-studied part: finding relevant state at decision time
• Act — state drives a decision or an external effect
• Update — the decision's outcome feeds back into state
• Forget — state is intentionally removed or decayed
• Audit — state is examined after the fact for correctness or compliance
• Rollback — state is restored to a prior version after a failure

The lifecycle exposes the asymmetry in current research. Write, organize, retrieve, and act are well-covered. Validate, forget, audit, and rollback are not. This means we are building agents that accumulate state aggressively and have almost no machinery for unwinding it when something goes wrong.

AOEP-v0: governance as an evaluation target

One of the paper's more interesting contributions is the Always-On Evaluation Protocol (AOEP-v0) — a pilot evaluation contract that scores systems on state mutation and recovery obligations rather than answer quality.

This is a meaningful departure from standard agent benchmarks. Most evals ask: "Did the agent complete the task correctly?" AOEP-v0 asks questions like: "If we corrupt a piece of the agent's state, does it detect the corruption? Can it recover? If we issue a forget request, is the memory actually gone from all layers?" These are systems questions, not task-completion questions. They require testing the agent's governance machinery, not its reasoning quality.

The protocol is explicitly a v0 — early, incomplete, aspirational. But the direction is right. As agents move from demo to deployment, the evaluation that matters is not "can it answer questions" but "can you trust it to run for six months without accumulating dangerous state, leaking cross-user information, or becoming un-auditable."

Why this matters now

The timing of this survey is good. Agent deployment is accelerating — from coding assistants to customer-facing autonomous systems. Each of these deployments accumulates state. Each one will eventually hit the governance questions the paper raises. And right now, the answers are mostly ad-hoc: prompt the agent to "be careful about stale information," log everything to a table nobody queries, hope for the best.

The paper connects always-on agents to mature disciplines that have already solved adjacent problems: databases (transactions, rollback, consistency), distributed systems (state reconciliation, quorum, fencing), capability security (authority, attenuation, revocation), and formal methods (invariants, verification). The claim — and I think it is correct — is that agent state governance is not a novel problem requiring novel solutions. It is a composition problem: we have the pieces, but we have not wired them together in the agent context.

This is a call to action. If you are building agent infrastructure, the question is not just "how does the agent remember?" It is "how does the agent govern its memory?" The second question is harder. It is also the one that will determine whether always-on agents are safe to deploy.

Reference: Tianyu Ding, Aditya Nannapaneni, Bingfan Liu, Ling Zhang. Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents. arXiv:2606.30306, June 2026.

In 1986, Fred Brooks drew his famous distinction between essential and accidental complexity. Essential complexity is inherent in the problem — you cannot remove it, only manage it. Accidental complexity is everything we inflict on ourselves: build systems, type systems, deployment pipelines, the accumulated sediment of toolchain decisions that have nothing to do with the problem domain.

For four decades, the software industry has fought accidental complexity with better languages, better tooling, better abstractions. Dark factories change the game in a way Brooks did not anticipate: they make accidental complexity someone else's problem. Specifically, the AI's problem.

But essential complexity does not go anywhere. It just moves.

The complexity budget

Every software system has a fixed complexity budget. You can think of it as the total information content required to produce working software: the sum of domain knowledge, architectural decisions, edge-case handling, behavioral contracts, and operational constraints. Before dark factories, this budget was spent across the entire stack — some in specification, some in architecture, some in implementation, some in testing, some in operations.

A dark factory reshuffles where each unit of complexity is absorbed. Implementation complexity — the part that was always accidental, the part that was about translating intent into code — drops toward zero. But the total complexity budget does not shrink. The complexity that used to be absorbed by a senior engineer during implementation now must be absorbed upstream, in the specification, or downstream, in validation and operations.

The upstream shift is the one that matters. When a human engineer receives a vague ticket, they fill in the gaps: they know the codebase conventions, they have intuitions about edge cases, they can ping the PM and clarify. When an AI agent receives a vague specification, it produces exactly what you asked for — and you discover at validation time that what you asked for was wrong.

This is not a failure of the AI. It is a failure of the specification. And in a dark factory world, specification failures are the only kind of failure that matter.

What specification actually means now

Specification in a dark factory context is not a Jira ticket. It is not a user story. It is not "as a user I want to reset my password." It is a document with enough precision that a system with no context, no judgment, and no ability to clarify ambiguity can produce working software from it.

This means specification must contain:

• Behavioral contracts — given these inputs, produce these outputs, within these constraints
• Edge cases enumerated — empty states, error states, boundary values, concurrent access patterns
• Acceptance criteria at machine resolution — not "the page loads fast" but "the page renders within 200ms at P95 under 10K concurrent requests"
• Error handling semantics — what fails gracefully, what fails loudly, what retries, what alerts
• State machine definitions — what states exist, what transitions are legal, what invariants hold
• Integration contracts — API shapes, authentication models, retry policies, failure modes of dependencies

This is not a new discipline. It is what good technical leads have always done, just more explicit and more complete. The difference is that in a traditional team, gaps in the specification could be absorbed by the engineer implementing it. In a dark factory, gaps in the specification produce gaps in the software — at scale, at speed, with nobody in the loop to catch them.

The inversion of expertise

This reshuffling inverts what "seniority" means. In a traditional team, seniority is partly about coding skill — the ability to hold a large system in your head, to write clean abstractions, to navigate the codebase quickly. In a dark factory, coding skill is commoditized. What remains valuable is:

• Domain modeling — the ability to see the shape of a problem and express it precisely
• Edge-case imagination — the paranoid instinct for what could go wrong, honed by years of production incidents
• Contract design — the ability to define interfaces that are complete, minimal, and stable under change
• Validation strategy — knowing what "correct" looks like and how to test for it at multiple levels

These skills are rare. They were always the truly valuable part of senior engineering — the part that distinguished a 10x engineer from a fast typist. What dark factories do is strip away everything else, making it obvious that specification craftsmanship was the bottleneck all along.

The new accidental complexity

There is a twist. Dark factories eliminate one form of accidental complexity (implementation) while potentially creating new forms:

Specification tooling complexity. If specification becomes the primary engineering artifact, the tooling around specification — versioning, diffing, linting, testing, code review for specs — becomes critical. A bad specification is harder to debug than bad code because you cannot step through it with a debugger. The specification is the source of truth, and we have almost no tooling for managing specification quality at scale.

Validation complexity. When AI generates code, the testing burden inverts. You are no longer testing that a human implemented what they intended. You are testing that an AI implemented what you specified — and also that what you specified was correct. The second problem is harder than the first. It requires tests that validate the specification against reality, not just the implementation against the specification.

Drift complexity. Specifications, like code, drift from reality over time. In a traditional codebase, drift manifests as stale comments and outdated READMEs — annoying but usually harmless. In a dark factory, drift manifests as the AI faithfully implementing an outdated specification, producing software that matches the spec but not the world. Detecting and correcting specification drift becomes an operational concern.

None of these are unsolvable. But they are new. And they will consume engineering effort that was previously spent on build systems, linters, and CI pipelines — the old accidental complexity that the dark factory absorbed.

What this means for teams

The practical implication is that teams adopting dark factory workflows should stop measuring implementation velocity and start measuring specification quality. The metric that matters is not "how fast can we produce code" — the AI does that instantly. The metric is "how often does the produced code match intent on the first try."

That metric is a function of specification quality. And specification quality is a function of how well the team understands the problem domain, how rigorously they think about edge cases, and how clearly they can express what they mean.

The dark factory does not make software easy. It makes implementation easy. The hard part — understanding what to build and defining it precisely enough that a machine can build it — remains hard. It always was. The factory just makes it impossible to pretend otherwise.

References:

• Fred Brooks, No Silver Bullet (1986) — essential vs. accidental complexity
• Dan Shapiro, The Five Levels: from spicy autocomplete to the software factory (2026)
• What is dark factory software development?

Software has always had unusually favorable marginal economics. Once written, a piece of software can be copied and distributed at near-zero marginal cost. This is why software businesses scale differently from physical-goods businesses.

But there was always a catch: the first copy was expensive. Writing the software required skilled labor, and that labor was the dominant cost in software production. The marginal cost of distribution was zero, but the fixed cost of creation was high.

Dark factories change this. When AI agents write the code, the fixed cost of creation drops dramatically. Not to zero — specification and validation remain — but to a fraction of what it was. This rewrites the economics of who can build software, how software businesses are structured, and where value accrues.

The cost structure before and after

In a traditional software team, the cost structure looks roughly like:

• Implementation labor: 50-60% of engineering budget (writing code, reviewing code, iterating on code)
• Specification and design: 15-20% (architecture, technical specs, product requirements)
• Testing and validation: 15-20% (manual QA, automated testing, integration testing)
• Operations and maintenance: 10-15% (deployment, monitoring, incident response)

A dark factory compresses the implementation bucket. StrongDM's team of three engineers, spending over $1,000 per engineer per day on AI compute, produces the output that would traditionally require a much larger team. The implementation labor cost is replaced by compute cost — and compute, unlike labor, is elastic, scalable, and improving in price-performance with every model generation.

The post-factory cost structure shifts toward:

• Specification and design: 40-50% (this becomes the primary engineering activity)
• AI compute: 10-20% (the new variable cost — roughly $1K+/engineer/day at current StrongDM-level spend)
• Testing and validation: 20-30% (validation becomes more important, not less, when code is AI-generated)
• Operations and maintenance: 10-15% (similar, but with new challenges around specification drift)

The total cost is lower — sometimes dramatically lower — but the composition is different. Engineering effort concentrates at the top of the funnel (specification) and the bottom (validation), with the middle (implementation) largely automated.

The StrongDM benchmark

The StrongDM case study provides the first real-world data point. Three engineers, operating under the rules "code must not be written by humans" and "code must not be reviewed by humans," producing at a rate that would traditionally require a significantly larger team.

The most striking number is the compute spend benchmark: if you are not spending at least $1,000 per engineer per day on AI compute, "you have room for improvement." At current model pricing, that buys an enormous volume of agent execution. Claude Opus 4.8 at list price is $15/MTok input, $75/MTok output. A thousand dollars buys approximately 13 million output tokens — the equivalent of generating tens of thousands of lines of code, plus reviews, plus test generation, plus iteration on failures.

Compared to a fully-loaded senior engineer cost of $600-800/day (salary, benefits, overhead), the math is straightforward: if the AI can produce even a fraction of that engineer's output at a fraction of the cost, the economic advantage is compelling. And the AI does not take vacations, does not switch jobs, and improves in capability with each model release.

The margin structure of dark factory businesses

This cost structure shift has specific implications for different business models:

SaaS businesses. The traditional SaaS cost structure has high initial engineering investment and low marginal cost per user. Dark factories compress the initial investment, making it feasible to build and maintain SaaS products with smaller teams. The competitive dynamic shifts: incumbents with large engineering organizations lose their headcount advantage against smaller, factory-enabled competitors. The moat moves from "we have more engineers" to "we have better specifications" — which is a very different kind of moat.

Agencies and consultancies. The traditional agency model sells engineer hours. More work requires more engineers, and revenue scales roughly linearly with headcount. A dark factory breaks this relationship. A small team can produce the output of a much larger one, which means revenue per employee can increase dramatically. But it also means the sales pitch must change: you are no longer selling "we have great engineers who will write your code." You are selling "we have great spec writers and validators who will define exactly what should be built and verify that the AI built it correctly." The client must be sold on the process, not the headcount.

Vertical software. The most interesting play may be in vertical SaaS — industry-specific software for niches that were previously too small to justify a dedicated engineering team. When the fixed cost of creation drops, the addressable market for custom or semi-custom software expands. Problems that couldn't support a five-person engineering team may support a one-person team plus a dark factory pipeline. The long tail of software opportunities becomes economically viable.

Where the money goes

If implementation is commoditized, the economic value in the software supply chain concentrates in three places:

1. Specification expertise. The people who can define precisely what should be built — domain experts who understand the problem, product thinkers who understand the user, architects who understand the system constraints. These people were always valuable. In a dark factory world, they are the primary constraint on output. Their leverage increases because their specifications can be executed at machine scale.

2. Validation infrastructure. The tooling that verifies AI-generated code against specifications, catches specification drift, and provides the audit trail for compliance and trust. Companies like CodeRabbit are early entrants here, but the category is wide open. Validation is not just testing — it is the entire chain of evidence from specification to acceptance, and it needs to be automated at the same scale as the code generation it checks.

3. Trust and distribution. When code is commoditized, the question "can I trust this software?" becomes the buying decision. The dark factory operator who can demonstrate rigorous validation, clean audit trails, and proven reliability has a structural advantage over competitors with similar output quality but weaker trust signals. This is especially true in regulated industries — finance, healthcare, infrastructure — where "an AI wrote this" is currently a liability that must be offset by evidence of correctness.

What breaks the model

The economics are compelling, but they rest on assumptions that can fail:

Model pricing does not stay flat. If AI compute costs increase — through provider consolidation, demand exceeding supply, or regulatory intervention — the cost advantage of dark factories over traditional teams shrinks. Conversely, if costs continue their current trajectory downward, the advantage grows. The economics are tied to a variable that teams do not control.

Specification costs may be higher than expected. The assumption that specification is cheaper than implementation depends on specifications being less voluminous and less complex than the code they replace. This may not be true. A specification precise enough for machine execution may approach the complexity of the code itself — different in form, but similar in information content. If so, the cost savings are real but smaller than the headline "code is free" suggests.

Quality externalities may dominate. If AI-generated code carries higher defect rates that must be caught in production, the operational cost of dark factory software may offset the development savings. This is the "specification debt" problem: flawed specs produce flawed outputs faster and more confidently than human teams would. The total cost of ownership may be higher even if the initial development cost is lower.

Trust is not free. For enterprise buyers, "no human reviewed this code" is currently a negative signal. Building trust — through validation infrastructure, audit trails, compliance certifications — costs money. The trust premium may erode some of the cost advantage, especially in the early years.

The equilibrium

Where does this settle? The most likely equilibrium is not "all software is built in dark factories" but a hybrid: dark factories handle the large fraction of software that applies well-understood patterns to business problems (CRUD, auth, API plumbing, dashboard construction, data pipelines), while human-led development handles genuinely novel systems, cutting-edge research, and domains where the cost of getting it wrong is catastrophic.

This is already the shape of the StrongDM experiment. The dark factory handles the predictable work. Humans handle the specification, the validation, and the exceptions. The ratio will shift over time as models improve and tooling matures, but the principle — factories for the known, humans for the unknown — is likely durable.

The economic prize is enormous: a large fraction of professional software development falls into the "well-understood patterns applied to business problems" category. Moving that work from labor cost to compute cost is one of the largest productivity improvements available in the global economy. The teams that figure out how to do it well — with rigorous specification, automated validation, and earned trust — will have a structural cost advantage that compounds with every model generation.

References:

• StrongDM dark factory case study, referenced in What is dark factory software development?
• Dan Shapiro, The Five Levels: from spicy autocomplete to the software factory (2026)
• CodeRabbit — automated code review for AI-generated code
• Barry Boehm, Software Engineering Economics (1981) — foundational cost-modeling framework

In the 1980s, the Japanese robotics company FANUC built a factory where robots manufactured other robots. No human workers. No lights — because nobody was there to need them. The machines just ran.

That image — a dark, humming factory floor producing goods around the clock with zero people in the loop — has haunted manufacturing ever since. Now it has arrived in software.

The term "dark factory" was adapted to software development by Dan Shapiro in January 2026, who laid out a five-level framework for AI-assisted coding. Level 0 is hand-written code. Level 5 is: specs go in, software comes out. Three weeks after Shapiro's post, StrongDM revealed they had been running a dark factory internally since mid-2025. This is not a thought experiment. It is running in production.

The five levels to lights-out

Shapiro's framework maps cleanly to the self-driving car levels. It is worth walking through, because each step describes a working mode that exists today.

Level 0 — Manual. Hand-written code. AI is absent or an afterthought. This is fading fast even among skeptics.

Level 1 — Task delegation. AI handles discrete, on-command tasks: generate unit tests, scaffold a component, write a docstring. The human drives; AI is a tool.

Level 2 — Pair programming. Real-time collaboration between developer and AI. The human guides direction, AI generates code. Shapiro estimates roughly 90% of "AI-native" developers operate here. This is the current default.

Level 3 — Code review. The relationship inverts. AI authors the code; humans review diffs and approve PRs. The developer becomes a manager, not a maker. This is where the psychological shift happens — you stop thinking "I write code" and start thinking "I specify behavior, inspect output, and approve."

Level 4 — Spec-driven development. Humans write detailed specifications — behaviors, acceptance criteria, edge cases — and hand them to AI agents. Hours later, humans check outputs against specs and tests. The developer becomes a product manager. The unit of work is no longer a pull request; it is a specification document.

Level 5 — The dark factory. Specs go in. Software comes out. AI agents write the code, other AI agents review it, still others test it. Agents iterate on failures autonomously. The human role is exclusively defining what to build and why. The how is fully automated.

StrongDM is already doing it

The jump from theory to practice came fast. Three weeks after Shapiro's post, StrongDM — an infrastructure access company — went public with an internal dark factory they had been running since mid-2025. The details are striking:

• Team size: three engineers.
• Rules: "Code must not be written by humans" and "Code must not be reviewed by humans."
• Process: Engineers write prose specifications covering edge cases, error handling, and acceptance criteria. AI agents generate the code. Other AI agents review it. Still others test it. Agents iterate on failures autonomously. Humans touch only the specification and validation layers.
• Spend benchmark: If you aren't spending at least $1,000 per engineer per day on AI compute, "you have room for improvement."

Simon Willison, co-creator of Django, visited the StrongDM team and described their approach as "very convincing." His takeaway: the critical investment was not in better AI models but in better specifications and test coverage. The quality of the output was a direct function of the quality of the input.

This is the inversion that matters. In a traditional team, you hire for coding skill and hope the specification thinking comes along with it. In a dark factory, specification thinking is the job. Coding is a downstream implementation detail handled by machines.

The bottleneck moves upstream

For decades, the primary constraint on software output was typing speed — or more precisely, the rate at which a human could translate intent into code, handle edge cases, write tests, and iterate through review. Dark factories move the bottleneck from implementation to specification.

This has consequences:

Vague requirements become instantly visible. When a human team receives an underspecified ticket, they fill in the gaps with judgment, experience, and hallway conversations. When an AI agent receives an underspecified spec, it produces exactly what you asked for — and you discover at validation time that what you asked for was wrong. The feedback loop is shorter and more brutal. Ambiguity that would have been absorbed by a senior engineer's intuition now produces a broken build.

Specification becomes a first-class engineering discipline. Writing a spec that an AI can execute against is not the same as writing a Jira ticket. It requires defining behaviors, acceptance criteria, edge cases, and error handling with enough precision that a machine — with no context, no judgment, no hallway conversations — can produce working software. This is a skill. It can be learned. And in a dark factory world, it is the skill that determines output quality.

Senior expertise concentrates differently. Architecture, system design, security, UX — the knowledge that feeds into specifications — becomes more valuable, not less. What becomes obsolete is hand-coding CRUD endpoints or writing boilerplate authentication flows. The senior engineer stops being a high-throughput typist and becomes a high-precision spec writer and validator.

The agency model flips

For software agencies, the dark factory model rewrites the business equation. The traditional model sells developer hours. More work means more billable hours — a linear relationship between output and headcount. In a dark factory, the constraint is not hours but clarity of thought. A small team running a dark factory pipeline can match the output of a much larger traditional team because the typing is free.

The new agency pitch becomes: you are not paying us to write code. You are paying us to define exactly what should be built, validate that it was built correctly, and own the outcome. The value is in the specification craftsmanship and the validation rigor, not in the keystrokes. This is a better business — higher margins, faster delivery, cleaner differentiation — but it requires agencies to sell something they are not used to selling: their thinking, not their typing.

The risks are real

None of this is free of problems.

Quality at scale is unproven. StrongDM's experiment is one team, one domain, one set of constraints. Multiple analyses show AI-generated code carries higher defect rates than human-written code. Dark factories demand extraordinarily robust automated testing and validation to compensate for the absent human review layer. CodeRabbit and similar companies are building tools to address this gap, but the tooling is young.

Specification debt replaces technical debt. Flawed specs produce flawed outputs faster and more confidently than human teams would. The code "works" according to its tests, but the tests were generated from flawed specs. You can end up with a system that passes every automated check and is still wrong — at scale, at speed. Debugging why requires going back to the spec, which was written by a human who may or may not still be on the project.

Trust and compliance are open questions. For enterprise buyers concerned with security, compliance, and maintainability, "no human ever reviewed this code" is not a selling point. The dark factory model will need to build trust — through audit trails, verification tooling, and proven track records — before it is acceptable in regulated environments.

The name might be too good. "Dark factory" is visceral, memorable, and slightly ominous. That is part of its power. It is also part of the risk — the term invites reaction before understanding. Expect pushback from people who hear "no humans" and think "no accountability."

What happens next

The trajectory is clear even if the timeline is not. AI models improve with each release. Agent tooling matures rapidly. The economics are compelling: StrongDM's three-person team plus high compute costs still dramatically undercuts the cost of a traditional team building the same output. And a large percentage of professional software development applies well-understood patterns to business problems — CRUD, auth, API plumbing, dashboard construction. This kind of work is factory-shaped whether we like the metaphor or not.

The open questions are about trust, quality, and adoption curves. Most organizations will spend years at Levels 3 and 4 before approaching true dark factory operations. The tooling needs to catch up. The specification craft needs to develop as a discipline. And the industry needs to figure out what "accountable" means when no human touched the code.

But the direction of travel is set. The dark factory is not science fiction. It is running right now, with real users, on real infrastructure. The only question is how fast it spreads.

References:

• Dan Shapiro, The Five Levels: from spicy autocomplete to the software factory (January 2026)
• Dark Factory, What is dark factory software development?
• Simon Willison's commentary on the StrongDM dark factory approach (referenced in the Dark Factory post above)
• FANUC's lights-out factory — the manufacturing origin of the "dark factory" term

A successful agent run feels like progress. The model understood the task, called the right tools, produced the output. Ship it.

But a new paper by Mohamed A. Fouad (On Task Automation Economics) argues that this feeling is a category error. An agent run is an event. Automation is capacity. Confusing the two is the central mistake teams make when adopting agentic AI for recurring work.

The paper is compact — 9 pages — but the argument is sharp and worth engaging with. Here is my reading of it.

The category error

The paper opens with a clean distinction:

Agentic AI execution is not automation. Automation begins when recurring work becomes verified software capacity.

The problem is not that agents lack capability. They can perform knowledge-based tasks — ingest files, map schemas, clean records, transform tables. The problem is that a successful execution leaves behind no reusable organizational capacity. The next time the same task comes up, you run the agent again. You purchase the output again. Nothing accumulates.

This is the category error: treating an event as an asset. An agent run proves feasibility. It does not create capacity. The distinction matters because repeated execution has weak economics — each run repurchases output — while verified assets accumulate value across reuse.

Task automation economics

The paper names the decision problem task automation economics: when should recurring work stop being bought as separate agent runs and become governed software capacity?

This extends Barry Boehm's software engineering economics framework from software products to agent-mediated task assets. The economic unit is not the agent, the prompt, or the run. It is the verified automation asset — a released object with seven reviewable parts:

1. Specification — what the task does, explicitly
2. Governance template — what rules and evidence apply
3. Pipeline — the executable mechanism
4. Criteria — how acceptance is judged
5. Evidence — records that the criteria were met
6. Release snapshot — the versioned, reviewed state
7. Replacement rule — when and how the asset should be retired or replaced

The economics become favorable when reuse value exceeds lifecycle cost. Value comes from accumulated capability. Cost comes from specification, engineering, verification, audit records, and replacement. This is a familiar tradeoff — it is the same logic behind technical debt in ML systems (Sculley et al., 2015). The difference is that with agentic AI, the run-level capability is so easy to achieve that teams never graduate to the asset level. They stay at "let me just run the agent again" indefinitely.

The task automation factory

If task automation economics names the why, the task automation factory names the how. The paper defines it as a production mechanism with five stages:

1. Select candidate demand — identify recurring work
2. Specify rules and evidence — make acceptance criteria explicit
3. Engineer tools and pipelines — build the executable mechanism
4. Verify with tests and audit records — prove the asset works
5. Release as a versioned asset — make it reusable

Each stage has a failure mode. If you skip specification, automation guesses. If you skip engineering, it remains repeated execution. If you skip verification, it cannot be trusted. If you skip release, it cannot be reused. If you skip replacement, it decays.

This connects directly to the dark factory concept — and the paper explicitly references Dan Shapiro's five levels and the broader dark factory discourse. But Fouad adds an important constraint: a task automation factory is dark only as a production metaphor. It must not make data, pipeline, or workflow accountability invisible. Rules, evidence, audit records, and replacement paths must remain visible. This is not lights-out as a trust model. It is lights-out as an execution model, with governance kept fully lit.

The evaluation checklist

The paper provides a concrete test for whether a task has graduated from execution to automation. Six questions a reviewer should be able to answer:

This checklist is deliberately narrow. It does not test whether every AI risk has been addressed. It tests whether a recurring task has become a reviewable asset. A high-scoring agent run is insufficient if the team cannot link it to a rule, an evidence record, a verification criterion, a release snapshot, and a replacement path. Conversely, a modest deterministic tool may be more valuable than a sophisticated agent if it replaces repeated execution with governed capacity.

Why data engineering

The paper grounds the argument in data engineering workflows: ingestion scripts, schema mappings, cleaning rules, transformation jobs, validation checks, orchestration DAGs, and backfill procedures. These tasks recur constantly. They require interpretation, system context, and operational judgment. They also require evidence preservation — sources, transformations, checks, and lineage must remain inspectable.

Data engineering is a strong choice of domain because the gap between run and asset is so visible there. A one-off script that cleans a table is useful once and decays when the schema changes. The team runs it again with adjustments. And again. Each run works. But nothing accumulates. The task automation factory turns that repeated demand into a verified, reusable, replaceable asset — and the economics shift from repurchasing output to accumulating capacity.

What I take from this

Three things stand out.

First, the paper is making an argument about organizational capability formation, not about agent performance. The better agents become at execution, the easier it becomes to mistake performance for capacity. This is a real risk. Teams that optimize for run success rates are optimizing the wrong variable. The variable that matters is the conversion rate from repeated runs to released assets.

Second, the verified automation asset is a useful concept independent of the tooling. Even if you never touch axnrun (the open-source runtime the paper uses for grounding), the seven-part structure — specification, governance, pipeline, criteria, evidence, release, replacement — gives you a checklist for auditing whether your team is accumulating capacity or just accumulating runs.

Third, the paper is short and reads more like a position paper than an empirical study. That is a feature, not a bug. The claim is limited: not every task should be automated. The argument applies to recurring workflow demand where evidence and review matter. The evaluation criteria are offered as a practical test, not a formal framework. And the paper is honest about what is not yet demonstrated — conversion rates, time-to-asset, reuse counts, audit reconstruction success. Those measurements are left as future work.

The core insight — that a run is an event and automation is capacity, and confusing the two is a category error — is worth sitting with. Especially if your team is doing a lot of successful agent runs and wondering why it does not feel like progress is accumulating.

Reference: Mohamed A. Fouad. On Task Automation Economics. arXiv:submit/7796173, July 2026. (Talk page with slides)

A country that cannot build its own AI capabilities does not stay neutral — it becomes dependent on systems and rules designed elsewhere.

That is why the warning from Japan's digital minister matters: without domestic capability, even advanced economies risk becoming an "AI colony" where strategic choices are constrained by external providers and standards.

In practice, this dependency appears across three layers:

1. Infrastructure dependency: compute, chips, cloud credits, and model hosting sit outside national control.
2. Model dependency: core models, update cycles, and safety tuning are dictated by vendors in other jurisdictions.
3. Governance dependency: policy defaults (privacy boundaries, content rules, API limits, auditability) are inherited instead of negotiated.

The hard lesson is simple: AI sovereignty is not only about "having a model." It is about building sustained local capacity across talent, infrastructure, open research, and institutions that can set and enforce national priorities.

Countries that invest early in these foundations gain bargaining power, resilience, and room to adapt AI to local language, law, and economic goals. Countries that do not risk locking themselves into technical and regulatory dependence.

Reference: Japan risks becoming an AI colony, its digital minister warns

This short post collects notes and links for two Y Combinator talks. Thumbnails below link to the videos; embedded players are included for easy viewing.

Videos

How to Build a Self-Improving Company with AI — Y Combinator

A few short takeaways and prompts for teams and builders:

• Focus on measurable feedback loops: define metrics, collect signals, and automate where the ROI is clear.
• Use AI to scale repeatable improvement tasks while keeping human oversight on strategy and safety.
• Start with small pilot systems that demonstrate measurable improvement before scaling.

How to Build an Internal AI Agent That Evolves Itself — YC Root Access

Short notes:

• Design agents with safety and guardrails; make evolution safe, observable, and reversible.
• Balance automation with human-in-the-loop checks for high-impact decisions.
• Emphasize evaluation metrics and continuous testing when enabling agent self-improvement.

Links

• Y Combinator — How to Build a Self-Improving Company with AI: https://www.youtube.com/watch?v=X_JsIHUfUjc
• YC Root Access — How to Build an Internal AI Agent That Evolves Itself: https://www.youtube.com/watch?v=DGD9b8K42lk

Screenshots: YouTube thumbnails (downloaded and included in this repo). If you prefer different screenshots or specific timestamps as images, say which and a screenshot can be extracted instead.

Agent quality is rarely limited by model intelligence alone. Most failures show up in the harness around the model: weak fixtures, vague success criteria, missing tool mocks, and no clean way to replay a bad run.

If the harness is sloppy, the team ends up debating anecdotes instead of improving behavior.

Treat the harness as product infrastructure

A good agent harness is not a throwaway script. It is the system that tells you whether the agent is getting better or just getting luckier.

That means the harness should:

• capture full inputs, tool calls, and outputs,
• replay tasks deterministically where possible,
• isolate external dependencies behind controllable fakes or fixtures,
• score outcomes with explicit checks instead of vibes.

Once the harness is trustworthy, iteration gets much faster because regressions stop hiding inside impressive demos.

Build cases from real failures

The highest-value harness cases usually come from production misses:

1. a tool call that should have been blocked,
2. a loop that should have terminated earlier,
3. a formatting step that silently broke downstream parsing,
4. an agent that took a plausible-but-wrong shortcut.

Every one of those should become a permanent evaluation case.

The best harnesses turn yesterday's incident into tomorrow's baseline.

Prefer observable steps over layered checks

End-to-end tests matter, but they are not enough on their own. Agent systems benefit from layered checks:

• prompt-level cases,
• tool-selection cases,
• state-transition cases,
• final outcome cases.

That layering makes failures legible. Instead of “the agent failed,” you get “the planner chose the wrong tool” or “the verifier accepted malformed output.”

Keep the pass-fail contract concrete

For each harness case, define:

• what the agent is allowed to do,
• what it must never do,
• what exact evidence counts as success,
• what artifacts should be stored for debugging.

That discipline matters more as agents gain more tools and more autonomy. The wider the action space, the more valuable a narrow, repeatable harness becomes.

Browser tasks: run against real pages

If an agent claims it can use the web, the harness should make it prove it on the web. Use real interfaces, preserve the messy interaction sequence, and score outcomes with concrete checks.

Real pages expose real weaknesses: buttons move, forms span multiple steps, state must persist across actions, and success depends on the whole sequence, not one isolated click. Polite demos can be useful for unit tests, but a serious claim about browser competence should survive an honest environment.

Coding harnesses: use real repositories

Coding-agent quality becomes measurable when the harness uses actual repos, issues, and test outcomes instead of idealized toy prompts.

Prefer messy repositories over perfect examples, failing tests over vague grading, and issue-driven tasks over isolated snippets. Tests are better than vibes: failing tests produce clear, automatable signals that scale.

Tasks that fight back

A harness should ask the system to do tasks that require tools, retrieval, and real-world messiness. Useful harness cases are:

• small enough to score,
• rich enough to require multiple steps,
• messy enough that shortcuts stop working.

If every test can be passed by pattern-matching the prompt, you are not measuring the assistant — you are measuring prompt luck.

Observe the whole operating system when relevant

Desktop and multimodal agents need execution harnesses that see the same OS complexity users experience: window state, clipboard and file effects, long action sequences, and recovery after mistakes. Honest environments create honest confidence.

Go for reliable pipelines

Harness engineering is fundamentally about building repeatable, trustworthy evaluation pipelines that can scale with complexity. Use boring, predictable tools and explicit pipelines to manage worker queues, sandboxes, artifact capture, and metric aggregation. Go is a practical choice for many of these pieces because of its concurrency model, static binaries, and clear CLIs.

Task harness engineering (practical pattern)

Task harnesses turn high-level engineering questions—"Can this system finish a real task?"—into reproducible, debuggable experiments. They are stateful, often non-deterministic, and rely on high-fidelity mocks or real infra. Use eval harnesses for filtering, then escalate to task harnesses for realism and agent harnesses for tool integration checks.

Fowler's view: guides + sensors

Treat the harness as a control system of guides (feedforward) and sensors (feedback). Start with cheap computational controls (linters, unit tests), add fast feedback (CI, structural tests), and layer inferential sensors (LLM-based reviewers) only where they measurably reduce supervision cost. Capture incidents and convert them into lasting harness cases.

Self-improving harness workflows

Combine short skill loops (read lessons → do work → reflect → write lessons) with harness practices: instrument runs, compact context when needed, and route workloads by role. Let usage data drive which harness cases matter most.

How to consolidate posts

When consolidating multiple related posts, create a canonical merged post with a clear, focused title and stable slug. In the original files add draft: true and a one-line note pointing to the canonical post. The generator will skip draft files.

Conclusion

A harness is the way a team learns whether its agents are improving. Make harnesses observable, replayable, and concrete. Use layered checks to keep failures legible and prefer boring, robust pipelines that scale with real-world complexity.

O Ministério da Ciência, Tecnologia e Inovação publicou em 2025 o "Plano Brasileiro de Inteligência Artificial (PBIA)", um documento de 104 páginas que organiza uma estratégia nacional para IA com foco em infraestrutura, formação, serviços públicos, inovação empresarial e governança.

Neste post, apresento um resumo dos eixos principais, ações destacadas e reflexões críticas sobre os impactos e riscos.

Principais eixos do PBIA

Portal oficial e notas do MCTI

A página oficial do MCTI para o PBIA (2024–2028) resume o plano lançado na 5ª Conferência Nacional de Ciência, Tecnologia e Inovação e destaca metas e números centrais: um investimento previsto de aproximadamente R$ 23 bilhões ao longo de quatro anos; a ambição de implantar um supercomputador Top‑5 mundial movido por energias renováveis; o desenvolvimento de modelos de linguagem em português com dados nacionais; e programas de formação e requalificação em larga escala. O portal organiza as ações em iniciativas de impacto imediato e ações estruturantes, alinhadas aos cinco eixos (infraestrutura, difusão, serviço público, inovação empresarial e governança).

Veja a página oficial do MCTI para o PBIA: https://www.gov.br/mcti/pt-br/acompanhe-o-mcti/transformacaodigital/plano-brasileiro-de-inteligencia-artificial

Minhas reflexões (curtas): a ênfase no investimento, na infraestrutura e na formação sinaliza que o PBIA busca combinar soberania tecnológica (infraestrutura e modelos em língua portuguesa) com objetivos de inclusão social e modernização do setor público. A concretização dependerá de governança clara, métricas de progresso e financiamento sustentado — pontos que o próprio portal reconhece ao listar iniciativas prioritárias.

O PBIA organiza-se em cinco eixos estruturantes:

• Eixo 1 — Infraestrutura e desenvolvimento de IA: construção de capacidade computacional, promoção de data centers sustentáveis e investimento em infraestrutura nacional (incluindo ambição por supercomputadores de classe mundial).
• Eixo 2 — Difusão, formação e capacitação: ampliar literacia em IA, apoiar cursos e programas de formação, e promover olimpíadas/atividades ligadas à educação.
• Eixo 3 — IA para melhoria do serviço público: implantar plataformas e soluções de IA para otimizar processos públicos e apoiar políticas baseadas em evidências.
• Eixo 4 — IA para inovação empresarial: fomento à cadeia de valor da IA, apoio a P&D e integração com missões industriais.
• Eixo 5 — Apoio ao processo regulatório e de governança da IA: desenvolver guias brasileiros de IA responsável, fortalecer marcos regulatórios e mecanismos de confiança.

Ações estruturantes de destaque

O PBIA traz um conjunto extenso de ações e programas. Entre os mais notáveis:

• Aquisição e desenvolvimento de capacidade de HPC especializada para IA, com meta ambiciosa de alcançar posição de destaque internacional.
• Programas de difusão e literacia em IA, voltados a escolas, universidades e sociedade civil.
• Plataforma de IA do Governo Federal para promover interoperabilidade e suporte a tomada de decisão nas políticas públicas.
• Incentivos para data centers regionais com ênfase em renováveis, visando reduzir gargalos de infraestrutura e distribuir capacidade entre o Norte e Nordeste.
• Guias e ações de apoio ao aperfeiçoamento do marco regulatório brasileiro, adaptando padrões globais à realidade nacional.

Reflexões e implicações

1. Ambição técnica e soberania: a busca por supercomputadores e data centers próprios é consistente com uma visão de soberania tecnológica que reduz dependência externa. Isso facilita pesquisa de alto impacto, mas exige investimentos contínuos e atenção a custos operacionais e consumo energético.

2. Distribuição regional e inclusão: a ênfase em apoiar infraestrutura nas regiões Norte e Nordeste é positiva para diminuir assimetrias, mas exige políticas complementares (formação local, conectividade, parcerias com universidades regionais) para garantir que a infraestrutura gere atividade científica e econômica local.

3. Governança e confiança pública: a construção de guias brasileiros de IA responsável e o reforço do marco regulatório são passos essenciais. A transparência, participação da sociedade civil e mecanismos de avaliação independente serão determinantes para evitar capturas e desigualdades.

4. Do plano à execução: muitos planos nacionais falham na implementação. O PBIA lista ações concretas, mas o sucesso dependerá de financiamento recorrente, coordenação interministerial eficaz e métricas claras de progresso.

5. Risco de centralização: plataformas governamentais e incentivos concentrados devem ser desenhados para evitar ênfase excessiva em soluções centralizadas ou proprietárias; preferir arquiteturas abertas e interoperáveis facilita inovação distribuída.

Sugestões práticas

• Priorizar projetos-piloto com avaliação pública: antes de escalar, testar plataformas e modelos em contextos controlados com avaliação aberta.
• Transparência de dados e modelos usados pelo governo: publicar descrições técnicas e métricas de desempenho, além de impacto social esperado.
• Apoiar ecossistemas locais: combinar investimentos em data centers com bolsas, programas de capacitação e parcerias universidade-indústria regionais.
• Criação de uma unidade independente de auditoria de IA para projetos financiados com recursos públicos.

Conclusão

O PBIA representa um marco importante para a política pública de IA no Brasil: combina ambição técnica com preocupações de governança e inclusão. O desafio real será transformar a lista de ações em entregas mensuráveis e sustentáveis, protegendo direitos e fomentando inovação distribuída.

Referência: MINISTÉRIO DA CIÊNCIA, TECNOLOGIA E INOVAÇÃO - MCTI; CENTRO DE GESTÃO E ESTUDOS ESTRATÉGICOS - CGEE. IA para o bem de todos; Plano Brasileiro de Inteligência Artificial. Brasília, DF: MCTI; CGEE, 2025. 104 p.

TL;DR

Process mining turns event data into process models and performance insights; Python (pandas + PM4Py) makes it accessible. Pair process‑mining features (throughput, wait times, activity counts) with standard data‑science pipelines (EDA, feature engineering, modeling) to solve real‑world problems like delay prediction and bottleneck analysis. This post synthesizes practical steps and code pointers inspired by two Medium articles: "Process Mining with Python" and "Solving a real‑world data science task with Python." Links in References.

Introduction

Two approachable Medium posts highlight hands‑on ways to extract insights from logs and run pragmatic data‑science projects from end to end. This post synthesizes their practical guidance into a compact recipe: how to extract event logs, discover process models, compute process features, and use them in predictive workflows.

1. From raw events to an event log

Key columns: case id (process instance), activity name, timestamp. Start by loading data with pandas, parsing timestamps, and normalizing column names for PM4Py interoperability.

Example:

import pandas as pd
from pm4py.objects.conversion.log import factory as log_converter

df = pd.read_csv('events.csv', parse_dates=['timestamp'])
# rename columns for PM4Py
df = df.rename(columns={'case_id':'case:concept:name', 'activity':'concept:name', 'timestamp':'time:timestamp'})
log = log_converter.apply(df)

2. Discovering process models and visualizing

Use discovery algorithms (e.g., Inductive Miner, Heuristics Miner) to build models. PM4Py supports several miners and visualization backends.

from pm4py.algo.discovery.inductive import factory as inductive_miner
from pm4py.visualization.petrinet import factory as pn_vis

net, im, fm = inductive_miner.apply(log)
gviz = pn_vis.apply(net, im, fm)
pn_vis.view(gviz)

3. Feature engineering for ML

Process mining yields rich features per case: total throughput time, activity counts, time between specific activities, resource load, and frequency of rare paths. These make strong predictors when combined with static attributes from the business data.

Practical features:

• case_duration = max(timestamp) - min(timestamp)
• activity_counts: how many times each activity appears per case
• waiting_times: mean/median time between consecutive activities
• path_signature: compressed representation of the activity sequence

4. A pragmatic modeling loop

Apply typical data‑science steps: split by case, build features, train/test, and validate with time‑aware splitting to avoid leakage. For production, monitor model drift and re-run process feature extraction as logs evolve.

5. Putting process mining inside a real project

The Medium examples emphasize real‑world concerns: messy timestamps, missing case identifiers, and schema drift. Good practices:

• validate and canonicalize timestamps early
• infer case IDs when absent (grouping heuristics)
• keep a reproducible ETL script for event extraction

6. When to use process features vs raw sequence models

Simple tabular models with hand‑crafted process features are often more interpretable and cheaper to maintain than sequence models. Use sequence models (RNNs/transformers over activities) when history encoding clearly improves predictive performance and the team can maintain the complexity.

Checklist to get started

• Identify the event sources and the case id column
• Export a sample CSV with: case_id, activity, timestamp, and any static attributes
• Run PM4Py discovery on the sample; inspect model and logs for obvious issues
• Create per‑case features and run exploratory modeling (time‑aware CV)
• Add monitoring: data schema checks and drift detection

Skill curation and SkillOS: making pipelines live

Google's SkillOS thread (explained in AVB's Paper Breakdown) describes a two-part architecture: a frozen executor that solves tasks by loading reusable "skills" from a SkillRepo, and a trainable Curator that observes executor trajectories and issues structured edits to the SkillRepo (insert/update/delete). The Curator is trained with a group-based curriculum and a composite reward that measures downstream task success, function-call validity, information compression, and content quality.

For process‑mining pipelines the Curator can distill robust ETL and feature‑engineering recipes into SKILL.md files (frontmatter + concise description used for BM25 retrieval, step‑by‑step workflow, worked example, and "when not to use"). Example skills: extract_event_log, feature_engineer_case_features, build_delay_model.

Benefits: repeated runs produce distilled, versioned recipes that accelerate reproducible pipelines and improve executor reliability while keeping instructions modular and auditable.

Operational notes: require human review before promoting automated updates; avoid embedding dataset‑specific constants; maintain test tasks to evaluate curator changes.

References

• Hussam Alhumsi: "Process Mining with Python" — https://hussamalhumsi-21111.medium.com/process-mining-with-python-6ca1d733b3e6
• İ. Cem Özçelik: "Solving a Real‑World Data Science Task with Python" — https://medium.com/@i.cemozcelik/solving-a-real-world-data-science-tasks-with-python-c43aa7d654d1
• AVB (SkillOS thread / breakdown): https://x.com/neural_avb/status/2053873358853591435?s=20

Notes: This post paraphrases and synthesizes practical advice from the referenced Medium posts and general process‑mining best practices. For full, article‑level detail, consult the original posts.

Obsession is the nitro that accelerates craft. In startups it shows up as founders and small teams who refuse to accept 'good enough' because a specific user problem is still broken, or a core metric refuses to budge. That intensity drives the repeated, focused experiments that produce breakthroughs: rapid iteration, fierce prioritization, and the kind of domain expertise that becomes a defensible advantage.

But obsession is a double-edged sword. Two films—Christopher Nolan's The Prestige and Damien Chazelle's Whiplash—offer stark parables about what obsession does to excellence and to people.

The Prestige: the prestige and the cost

In The Prestige, two magicians (Angier and Borden) allow rivalry and obsession to dictate their choices. The filmmaker Sam Langan wrote a useful analysis of the film's theme of obsession and identity: https://samlangan.wordpress.com/2011/10/31/obsession-in-christopher-nolans-the-prestige/.

Angier's pursuit of the perfect effect (the "prestige") drives him to use Tesla's machine, and he pays an escalating human cost to protect the illusion. The movie makes an important point for founders: obsession can manufacture a unique, memorable experience (the "wow"), but it can also blind you to ethical costs and brittle trade-offs. Angier succeeds in producing an astonishing trick, but he does so by creating a process that's fragile, secretive, and morally fraught.

Applied to startups: obsession about a core user problem can produce a signature feature that customers remember. But if the obsession focuses on appearance rather than durable utility (a prettier demo over a solved problem), it will lead to brittle decisions and hidden technical debt.

Whiplash: deliberate practice turned extreme

Whiplash dramatizes deliberate practice: Andrew's relentless, often brutal rehearsals are the crucible that forges mastery. Fletcher's pedagogy is abusive, but the film asks a hard question: can excellence be produced without pressure? Founders should take from Whiplash the value of concentrated, feedback-rich practice—while rejecting Fletcher's cruelty.

In engineering terms, obsessive iteration looks like relentless bug-fixing, focused performance tuning, or shipping hundreds of tiny experiments until the retention curve moves. It is not heroics; it is disciplined repetition aimed at a measurable outcome.

What founders should borrow from these stories

• Obsess about the problem, not vanity. Let metrics and user behaviour decide whether a thing is valuable.
• Use deliberate practice: set tight learning cycles, measure progress, and iterate. Like Whiplash, it demands repetition; unlike Fletcher, keep it humane.
• Build a "prestige" only if it solves a real user need. The Prestige shows how an impressive surface with no structural value is fragile.

Guardrails to keep obsession productive

1. Obsess about outcomes, not output. Track the metric that represents the user problem, and stop when it moves.
2. Timebox intensity. Run focused sprints (1–4 weeks) of high-intensity work, then recover and review.
3. Make obsession social. Share your thesis and experiments with trusted advisors and early users to test delusions early.
4. Instrument everything. Obsession without data is superstition.
5. Avoid martyrdom culture. Reward sustainable craftsmanship and systems that make excellence repeatable.

Concrete rituals

• Weekly 90-minute "problem deep-dive": stop roadmap talk and interrogate one user problem with data and customer quotes.
• "Fail fast" sandbox: require a small experiment before a big feature bet.
• Postmortem for "hero moves": when someone burns out, perform a blameless review and fix the systemic causes.
• Deliberate-practice sessions: engineers/PMs pick one micro-skill and practice it in 30–60 minute focused sessions.

Conclusion

Obsession concentrates talent and reduces the noise between idea and feedback. The Prestige and Whiplash teach complementary lessons: one shows how obsession creates unforgettable, high-impact outcomes at a cost; the other shows how brutal practice produces technical mastery. For founders, the task is simple but hard: be obsessively curious about the right problem, instrument progress, share the work, and protect the people who do the work.

References

• Sam Langan, "Obsession in Christopher Nolan's The Prestige": https://samlangan.wordpress.com/2011/10/31/obsession-in-christopher-nolans-the-prestige/
• The Prestige (scene): https://www.youtube.com/watch?v=88_6SQKuTHk
• Whiplash (film clip): https://www.youtube.com/watch?v=Vnr-PFs7dEQ

Eric Jang discusses the process and challenges of building AlphaGo from scratch, sharing insights into deep reinforcement learning, Monte Carlo tree search, and the engineering required to scale up a world-class Go AI. The conversation, hosted by Dwarkesh Patel, covers both the technical and practical aspects of replicating AlphaGo, including:

• The architecture and training pipeline for AlphaGo
• Key breakthroughs in deep RL and search
• Lessons learned from reimplementing complex research systems
• The importance of reproducibility and open science in AI

Technical Reflection:

This talk is a must-watch for anyone interested in the intersection of deep learning, game AI, and research engineering. Jang’s experience highlights the value of hands-on replication for understanding state-of-the-art systems, and the discussion offers practical advice for engineers aiming to bridge the gap between academic papers and robust implementations.

Watch the full interview on YouTube

Watch: Platform Engineering - YouTube

Platform Engineering: Navigating Economics of Scale vs Economics of Speed

Platform engineering is rapidly becoming a cornerstone of modern software delivery. As organizations grow, they face a critical question: should they optimize for economies of scale or economies of speed? Drawing on insights from Platform Engineering: The Next Step in DevOps and Economics of Scale vs Economics of Speed, this post explores how platform teams can navigate these competing forces.

Defining the Economics

Economics of Scale

Economies of scale are achieved by centralizing and standardizing processes, tools, and infrastructure. Platform teams build shared services that multiple product teams can leverage, reducing duplication and driving down costs. This approach is ideal for organizations seeking reliability, compliance, and cost efficiency at scale.

Example: A central CI/CD platform used by all engineering teams ensures consistent deployments, security, and monitoring. However, introducing changes or supporting edge cases can become slow and bureaucratic.

Economics of Speed

Economies of speed prioritize rapid delivery and team autonomy. Here, platform teams provide self-service tools and APIs, empowering product teams to move fast and innovate. This model is crucial for startups or organizations in fast-moving markets.

Example: Allowing teams to spin up their own infrastructure or pipelines enables experimentation and quick pivots, but can lead to duplicated effort and inconsistent standards.

The Platform Engineering Balancing Act

The real challenge for platform engineering is not choosing one over the other, but finding the right balance. The best platform teams:

• Abstract complexity: Provide simple interfaces to complex systems.
• Enable autonomy: Let teams move fast without reinventing the wheel.
• Enforce guardrails: Ensure security and compliance without blocking innovation.
• Continuously evolve: Adapt the platform as organizational needs change.

Framework for Decision-Making

1. Assess Organizational Priorities: Is cost efficiency or speed to market more critical right now?
2. Identify Bottlenecks: Are teams slowed down by central processes, or is there chaos from too much autonomy?
3. Iterate Platform Offerings: Start with core shared services, then layer on self-service and customization.
4. Measure Outcomes: Track both efficiency (cost, reliability) and velocity (lead time, deployment frequency).

Real-World Example

A global fintech company adopted a platform engineering approach by building a central developer portal. Initially, strict standardization improved reliability but slowed innovation. By introducing self-service infrastructure and clear APIs, they enabled teams to move faster while maintaining compliance—achieving a pragmatic balance between scale and speed.

Conclusion: Actionable Takeaways

• Don’t default to one model: Both scale and speed have a place; context matters.
• Invest in platform UX: The easier it is to use, the more value it delivers.
• Automate guardrails: Use policy-as-code and automated checks to enforce standards without manual gates.
• Foster feedback loops: Regularly engage with product teams to refine platform offerings.

Platform engineering is not a destination but a journey—one that requires constant calibration between the economics of scale and speed. By understanding and intentionally balancing these forces, organizations can build platforms that empower teams and drive sustainable growth.

References:

• Platform Engineering: The Next Step in DevOps
• Economics of Scale vs Economics of Speed

The Hardest Lessons for Startups to Learn (Y Combinator)

Startup Lessons: The Two-Task Rule

Startups are bombarded with advice, but few rules are as simple—or as hard to follow—as the two-task rule: at any moment, a startup should only be working on the two most important things. Everything else is a distraction.

Why the Two-Task Rule Matters

The two-task rule is not just about focus; it is about survival. Early-stage startups have limited time, money, and energy. Spreading those resources across too many projects almost guarantees mediocrity or failure. The two-task rule forces founders to make hard choices, say no to good ideas, and commit fully to what matters most.

The Psychology of Overcommitment

Founders are often ambitious and optimistic. It is easy to believe you can do it all, especially when every opportunity feels urgent. But the reality is that startups die from indigestion, not starvation. Trying to do too much leads to half-finished features, missed deadlines, and a team that is always busy but rarely effective.

Operationalizing Ruthless Prioritization

Applying the two-task rule means:

• Making a real list of priorities and cutting it down to two.
• Communicating those priorities clearly to the team.
• Saying no to everything else, at least for now.
• Reviewing and updating the two tasks as circumstances change, but never letting the list grow.

Compounding Benefits

Teams that master this discipline move faster, learn more, and build a culture of execution. Morale improves because progress is visible and meaningful. Investors and customers notice when a startup consistently delivers on its promises.

Conclusion

The two-task rule is the hardest lesson because it is the most important. It is a forcing function for clarity, discipline, and real progress. For startups, that is the difference between shipping and stalling.

Codebases used to be written primarily for humans. The main readers were the teammates who opened files in an editor, learned the local conventions by trial and error, and built a mental map over weeks or months.

That assumption is breaking down.

In an agentic workflow, the first reader of a codebase is often a coding agent. The second reader may be another agent in a different worktree. The third may be a reviewer agent that only sees a diff. Humans still matter, but the codebase now has to explain itself to fast, literal, parallel workers that do not share much hidden context.

That changes what “well structured” means.

A modern codebase needs explicit contracts

The strongest recent signal here is the emergence of repository-level instruction files such as AGENTS.md in OpenAI Codex and the closely related CLAUDE.md, skills, and subagent patterns in Claude Code best practices, skills, and worktrees.

Those tools all point toward the same lesson: agents do better when the repo contains a compact, explicit contract for:

• what the repo is for,
• which commands are authoritative,
• which paths are safe to change,
• which invariants are non-negotiable,
• where deeper local instructions live.

Humans can absorb ambiguity. Agents mostly amplify it.

If a repo does not declare its rules, every agent run starts by rediscovering them. That wastes context, increases variance, and creates merge friction when multiple agents land changes that were individually reasonable but globally inconsistent.

AGENTS.md should be a routing layer, not a novel

The worst version of AGENTS.md is a giant wall of text. The best version is a routing contract.

At the root, it should state the repo mission, the required workflow, the canonical test/build commands, and the directories where deeper instructions live. Then each major subtree can add a local instruction file with the context only that area needs.

That lets an agent read just enough to work safely instead of loading the entire history of the repository into every run.

For a Go codebase, that usually means:

1. a small root AGENTS.md,
2. local contracts for subsystems like cmd/, internal/, or pkg/,
3. repo-local skills for recurring workflows such as adding a handler, expanding a schema, or shipping a release.

The key idea is locality. The closer the instruction is to the code it governs, the easier it is for parallel agents to stay correct.

Skills are how you turn tribal knowledge into executable guidance

Agent-first repositories should treat skills as first-class assets. A good skill is not motivational prose. It is an operational recipe with:

• purpose,
• inputs,
• exact steps,
• validations,
• failure modes.

That is useful for humans too, but it is especially valuable for agents because it removes guesswork from repeated tasks. Instead of hoping every agent rediscovers the right release flow, migration sequence, or API checklist, the repo can teach that behavior directly.

Skills are the scalable answer to “everyone knows how to do this.” In an agentic repo, that sentence should be treated as a bug report.

Modularity matters more when multiple agents work in parallel

Parallel agents are most effective when they can work in separate git worktrees with minimal coordination. That only works if the codebase has solid seams.

In Go, the natural seam is the package boundary. If a package exports a small, well-tested interface contract, different agents can work on adjacent layers without constantly reaching across the boundary.

For example, an agent that owns orchestration code should not need to know how persistence is implemented. It should only need a stable interface:

package contracts

import "context"

// SkillsCatalog defines the read-only contract for skill discovery.
type SkillsCatalog interface {
	Load(ctx context.Context, name string) (Skill, error)
	List(ctx context.Context) ([]Skill, error)
}

// WorktreeAllocator isolates parallel work into separate trees.
type WorktreeAllocator interface {
	Reserve(ctx context.Context, branch string) (Worktree, error)
	Release(ctx context.Context, path string) error
}

type Skill struct {
	Name        string
	Description string
}

type Worktree struct {
	Path   string
	Branch string
}

This looks simple, but that simplicity is the point. If the contract is small and explicit, one agent can change the allocator implementation while another extends skill discovery without both editing the same files.

Agent-friendly Go packages should minimize hidden cross-package state

A lot of merge pain in agentic work happens because packages are not really modular. They look modular, but they share config globals, mutate common registries, or depend on side effects that are never written down.

A safer pattern is to make dependencies explicit in constructors:

package planner

import (
	"context"
	"fmt"
)

// TaskStore persists the generated plan steps for later execution.
type TaskStore interface {
	SavePlan(ctx context.Context, id string, steps []string) error
}

type Service struct {
	store TaskStore
}

func New(store TaskStore) *Service {
	return &Service{store: store}
}

func (s *Service) Plan(ctx context.Context, id string, ask string) error {
	// Keep the planning stages explicit so parallel agents share the same flow.
	steps := []string{
		fmt.Sprintf("classify: %s", ask),
		"load local contracts",
		"select skill or subagent",
		"emit scoped plan",
	}
	return s.store.SavePlan(ctx, id, steps)
}

This does two things for agentic development:

1. it reduces the number of invisible assumptions,
2. it makes interface contracts testable in isolation.

That means a parallel agent can change a planner, store, or allocator behind the same interface and still merge cleanly.

Worktrees are safer when interface tests are part of the contract

When agents work in separate git trees, smooth merging depends on more than good intentions. It depends on contract tests.

If package boundaries are meant to stay stable, the repo should enforce them with focused tests:

package contracts_test

import (
	"context"
	"testing"
)

// fakeCatalog is a tiny stand-in that satisfies the contract in tests.
type fakeCatalog struct{}

func (fakeCatalog) Load(context.Context, string) (Skill, error) { return Skill{Name: "go-api"}, nil }
func (fakeCatalog) List(context.Context) ([]Skill, error)       { return []Skill{{Name: "go-api"}}, nil }

func TestCatalogContract(t *testing.T) {
	// Bind the fake to the interface so the consumer-facing seam stays explicit.
	var svc SkillsCatalog = fakeCatalog{}

	skill, err := svc.Load(context.Background(), "go-api")
	if err != nil {
		t.Fatalf("load skill: %v", err)
	}
	if skill.Name == "" {
		t.Fatal("expected skill name")
	}
}

The implementation here is tiny, but the idea scales: every important seam should have a small set of tests that define what consumers rely on. Parallel agents can change internals freely when those seams are protected.

The codebase now needs to optimize for fast onboarding by machines

A human teammate can survive an opaque repo if they are patient and can ask questions. An agent gets a narrower window. It needs a fast path to useful context.

That suggests a different priority order than older codebases often used:

1. explicit contracts before clever abstractions,
2. local instructions before tribal knowledge,
3. interface stability before cross-package reach,
4. reproducible commands before “it works on my laptop.”

This is also why repo-local templates such as agent-ready-repo are interesting. They encode the idea that architecture docs, operational skills, and agent-facing contracts belong inside the repo rather than floating around in chat history.

The merge target is not just correctness, but convergence

The best agent-first codebases do more than help a single agent succeed. They help many agents converge on compatible answers.

That means designing the repo so independent workers can discover the same commands, the same invariants, the same subsystem boundaries, and the same review expectations. When that happens, separate worktrees stop feeling risky. They start feeling like throughput.

The old codebase question was: can a human figure this out eventually?

The new question is: can multiple agents work in parallel, in separate trees, with enough shared contract to merge smoothly later?

That is a different optimization target. It favors explicitness, modularity, skills, and durable interface contracts. Go is a strong fit for that world because its package boundaries, interfaces, tests, and deployment story make it easier to build systems that are boring in the right places.

And in the era of agentic software engineering, boring seams are a superpower.

Sources

• OpenAI Codex guide: AGENTS.md
• Claude Code best practices
• Claude Code skills
• Claude Code worktrees
• agent-ready-repo example

Dependency injection in Go is one of those topics where the community is often right for the wrong reason.

People say “just wire things manually,” and a lot of the time that is the correct answer. But the deeper point is not that frameworks are bad. It is that Go already gives you a simple, testable way to express dependencies: constructors, interfaces, and explicit initialization in main.

That means a DI framework has to earn its complexity.

When I look at the current Go ecosystem, I think the most useful way to frame the space is:

1. manual wiring first,
2. Dig if you want a runtime container without a full app framework,
3. Fx if you want runtime wiring plus lifecycle orchestration,
4. Wire if you specifically want compile-time generation, with the caveat that it is now unmaintained.

That ordering matches how I think about operational risk, not just developer preference.

What dependency injection should mean in Go

In Go, dependency injection should mostly mean this: constructors receive the collaborators they need, and main decides how the graph gets assembled.

That keeps the code honest.

package main

import "log"

type Config struct {
	DSN string
}

type DB struct {
	dsn string
}

// NewDB keeps database setup explicit at the application edge.
func NewDB(cfg Config) *DB {
	return &DB{dsn: cfg.DSN}
}

type UserService struct {
	db *DB
}

// NewUserService injects the database directly through the constructor.
func NewUserService(db *DB) *UserService {
	return &UserService{db: db}
}

func main() {
	cfg := Config{DSN: "postgres://app"}
	db := NewDB(cfg)
	svc := NewUserService(db)

	// Use the fully assembled service graph.
	log.Printf("service ready with %s", svc.db.dsn)
}

This style is boring, but it scales farther than people sometimes admit. It is obvious in code review, easy to test, and does not hide object creation behind reflection or generated files.

If the graph is still small enough to fit comfortably in one place, this is usually my favorite option.

Where Uber Dig fits

Uber Dig is a runtime DI toolkit, not a full framework. Its own README is pretty clear about the intended scope: it is good for resolving the object graph during process startup and as a building block for a framework like Fx, but not as a user-facing service locator.

That distinction matters.

Dig is useful when you want container-driven wiring without buying into a larger application model. You provide constructors, then invoke a function whose parameters the container fills in.

package main

import (
	"log"

	"go.uber.org/dig"
)

type Config struct {
	DSN string
}

type DB struct {
	dsn string
}

// NewDB builds the shared database dependency.
func NewDB(cfg Config) *DB {
	return &DB{dsn: cfg.DSN}
}

func main() {
	c := dig.New()

	// Register concrete constructors with the container.
	_ = c.Provide(func() Config { return Config{DSN: "postgres://app"} })
	_ = c.Provide(NewDB)

	// Ask Dig to resolve the object graph for this startup function.
	_ = c.Invoke(func(db *DB) {
		log.Printf("connected to %s", db.dsn)
	})
}

The upside is less manual wiring in main. The downside is that the dependency graph becomes more implicit. You read constructor signatures to understand the graph, but the assembly is no longer plain Go code in one obvious place.

That tradeoff can be fine, but I think it should be deliberate.

Where Uber Fx becomes compelling

Uber Fx sits one level higher. It is built on Dig, but it is really an application framework for dependency injection plus lifecycle.

That lifecycle part is the reason to care.

Once your application has:

• HTTP servers,
• background workers,
• metrics/reporting,
• shutdown hooks,
• multiple modules owned by different teams,

plain constructor wiring stops being the whole problem. Now you also need deterministic startup ordering, clean shutdown, and a compositional way to express module boundaries.

That is where Fx earns its keep.

package main

import (
	"context"
	"log"
	"net/http"

	"go.uber.org/fx"
)

type ServerParams struct {
	fx.In

	Lifecycle fx.Lifecycle
	Mux       *http.ServeMux
}

// NewMux provides the shared HTTP router for the app.
func NewMux() *http.ServeMux {
	return http.NewServeMux()
}

// RegisterServer binds the HTTP server lifecycle to the Fx app.
func RegisterServer(p ServerParams) {
	server := &http.Server{
		Addr:    ":8080",
		Handler: p.Mux,
	}

	p.Lifecycle.Append(fx.Hook{
		OnStart: func(context.Context) error {
			go server.ListenAndServe()
			return nil
		},
		OnStop: func(ctx context.Context) error {
			return server.Shutdown(ctx)
		},
	})
}

func main() {
	app := fx.New(
		fx.Provide(NewMux),
		fx.Invoke(RegisterServer),
	)

	// Run manages startup, signal handling, and shutdown hooks.
	app.Run()
	log.Println("stopped")
}

That example captures the real difference. Fx is not just about “inject this dependency for me.” It is about giving the whole application a structured runtime and lifecycle.

If I had a multi-module service with enough startup/shutdown machinery, Fx would be near the top of my list.

The strongest alternative to Fx is often still manual wiring

This is the part that gets lost in some DI comparisons. The main alternative to Fx is not necessarily another DI library. It is often explicit module wiring plus a few carefully owned lifecycle abstractions.

For many Go services, that wins on:

• debuggability,
• ease of onboarding,
• grep-ability,
• and the ability to understand startup by reading one file.

Fx becomes attractive when those benefits are outweighed by graph size and lifecycle complexity. Until then, a framework can be solving a problem you do not actually have yet.

What about Google Wire?

Google Wire took a very different approach: compile-time code generation instead of runtime reflection.

That is conceptually appealing in Go because it keeps the final wiring as ordinary generated Go code, with no runtime container and no reflection overhead. It also fits the language's bias toward explicitness better than many DI frameworks do.

//go:build wireinject

package main

import "github.com/google/wire"

type Config struct{}
type DB struct{}
type UserService struct{}

// NewDB constructs the database dependency from configuration.
func NewDB(Config) *DB { return &DB{} }

// NewUserService wires the service against the database dependency.
func NewUserService(*DB) *UserService { return &UserService{} }

// InitializeUserService tells Wire which providers belong in the graph.
func InitializeUserService() *UserService {
	wire.Build(NewDB, NewUserService)
	return nil
}

The problem is that Wire is now explicitly marked as no longer maintained. Its README says so directly and points users toward forks if they need updates.

That does not make the idea bad. In fact, I still think compile-time wiring is philosophically attractive in Go. But if I were starting something fresh today, I would treat Wire as a useful reference point, not my default foundation.

My practical ranking

If I were choosing today for a production Go codebase, my rough decision tree would be:

1. Manual constructors if the graph is still easy to read in main.
2. Fx if startup/shutdown lifecycle and module composition are the real pain.
3. Dig if I want container-style runtime wiring without the full Fx application model.
4. Wire only with eyes open, because the project is no longer maintained.

The important part is not picking the most “advanced” tool. It is matching the tool to the shape of the graph and the operational complexity of the app.

My reflection

Go dependency injection works best when it preserves the language's bias toward clarity.

That is why I like Fx more than many DI frameworks in other ecosystems: it is not trying to turn Go into annotation soup. It still relies on constructors and explicit parameter types. But I also think Fx is easiest to justify when lifecycle management is the real problem, not just constructor wiring.

If your application is still small, manual wiring is not primitive. It is often the most Go-like answer.

If your application has grown into a startup graph with real operational structure, Fx becomes much more convincing.

Sources

• Uber Fx README
• Uber Fx docs
• Uber Dig README
• Google Wire README

I think one of the biggest missed opportunities in current agent evaluation is the lack of serious empirical game-theoretic analysis.

Most evaluations still look like isolated benchmark scores: one agent, one task, one result. That is useful, but it misses the part that becomes economically important as soon as agents coexist: strategic interaction.

What happens when multiple routing policies compete in the same environment? What happens when some agents specialize, others imitate, and others bid aggressively? What happens when the system rewards early completion in a way that encourages lower-quality work?

Those are game-theoretic questions, and empirical methods matter because the systems are too messy to understand from first principles alone.

Why empirical game-theoretic analysis fits agentic systems so well

The core idea of empirical game-theoretic analysis is simple: instead of assuming the payoff matrix analytically, you estimate it from simulations or measured interactions across strategy profiles.

That is incredibly natural for agentic systems.

You can define a profile as a combination of policies:

• routing policy,
• bidding policy,
• retry policy,
• review policy,
• settlement rule,
• memory-sharing rule.

Then you simulate or replay many runs, observe payoffs, and build an empirical game from the results. That does not magically solve everything, but it gives you a disciplined way to ask whether a policy is robust, exploitable, or equilibrium-seeking.

In practice, the loop looks something like this:

package egta

type Profile struct {
	Router   string
	Bidder   string
	Reviewer string
}

type Outcome struct {
	Utility float64
	Cost    float64
	Success float64
}

func Payoff(o Outcome) float64 {
	// Collapse the observed outcome into one comparison-friendly payoff.
	return o.Utility - o.Cost + o.Success
}

The hard part is not writing the struct. The hard part is running enough controlled interactions that the estimated game tells you something real.

Algorithmic game theory gives the design language

Empirical analysis tells you what the interaction landscape looks like. Algorithmic game theory helps you design mechanisms inside that landscape.

This is why I see the two fields as complementary rather than separate. If empirical analysis shows that a bidding policy drives destructive races to the bottom, algorithmic game theory gives you tools to redesign the allocation rule. If the system converges to low-quality equilibria, you can adjust incentives, information disclosure, reserve prices, or admission rules.

That is much better than pretending the benchmark failed because the model was “not smart enough.”

Often the issue is not intelligence at all. It is the game.

This matters because agent evaluation is becoming multi-agent evaluation

As soon as agents operate in shared repos, shared queues, or shared markets, single-agent accuracy stops being the whole story.

You need to ask:

1. whether a strategy is stable against exploitation,
2. whether incentives improve or degrade quality,
3. whether the system produces concentration or diversity,
4. whether local gains create bad global equilibria.

Those questions belong naturally to empirical game-theoretic analysis.

I expect this to matter even more in agent marketplaces, decentralized software work, autonomous procurement, and negotiation-heavy systems. In all of those settings, the interaction surface is the product.

The books I would put on this shelf

Tim Roughgarden's Twenty Lectures on Algorithmic Game Theory is an excellent compact map of the field because it keeps the link between computation and incentives visible. That is exactly the connection agent builders need.

Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations matters because it frames strategic interaction as a systems problem, not just an economics problem. That viewpoint feels especially relevant for agentic software engineering.

My practical reflection

I think teams building serious agent systems should evaluate at least some policy decisions as empirical games. Not every product needs a giant formal mechanism. But once many agents can adapt to each other, benchmark culture by itself becomes too shallow.

Empirical game-theoretic analysis gives you a way to measure interaction. Algorithmic game theory gives you a way to redesign it. Together they make agentic systems easier to reason about, especially when the failure mode is not a crash or a bug, but a bad equilibrium.

That is a much more interesting class of engineering problem than most AI dashboards currently expose.

Sources

• Twenty Lectures on Algorithmic Game Theory
• Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations

I do not think I learned systems thinking only from engineering.

A surprising amount of it came from games, especially Factorio and StarCraft II.

That does not mean games magically teach software architecture. What they did give me was repeated exposure to the exact kinds of pressure that matter in real engineering work: limited attention, constrained resources, competing priorities, incomplete information, and the need to build systems that keep working while I am busy somewhere else.

Over time, I started to realize that a lot of the habits that make me effective in terminal- and Vim-heavy environments were strengthened by those games long before I had language for them.

Factorio taught me to think in flows, not parts

Factorio is one of the cleanest lessons I know in throughput thinking.

At first, the game looks like a construction game. Later, it becomes obvious that it is really a lesson in flows:

• ore becomes plates,
• plates become intermediate products,
• intermediates become higher-order assemblies,
• energy, belts, inserters, trains, and layout all constrain the whole pipeline.

The key mental shift is that local correctness is not enough. A single sub-factory can be beautifully designed and still fail the system if it starves upstream or overloads downstream.

That maps directly to software.

In a codebase, I care much more now about how information, control, and dependency pressure move through the system than about whether one module looks clever in isolation. Factorio trained my brain to look for:

1. bottlenecks,
2. wasted movement,
3. hidden coupling,
4. poor observability,
5. and scaling limits that only appear after expansion.

That is an engineering habit.

When I open a Go service or a shell pipeline, I often think about it the same way I think about a Factorio bus or train network: where is the actual choke point, what resource is really scarce, and which redesign improves throughput without adding chaos?

Factorio also taught me to value layout as an operational decision

One of the biggest transfers from Factorio into coding is respect for layout.

In the game, layout is not decoration. Layout determines whether the factory is easy to expand, easy to debug, and easy to reason about under growth. A cramped but “efficient” build often becomes a trap later.

That same instinct helps in terminal and Vim environments.

I like tools that preserve spatial memory:

• stable file trees,
• stable keymaps,
• stable command patterns,
• stable pane layouts,
• stable text structure.

The reason is not aesthetic purity. It is operational speed. Good layout reduces context-switch cost.

Factorio makes that lesson painfully obvious because bad layout punishes you every time the system scales. So does a codebase.

StarCraft II taught me prioritization under pressure

If Factorio trained system layout and throughput thinking, StarCraft II trained tempo and prioritization.

SC2 is not just about speed. It is about deciding what matters right now while the rest of the game keeps moving.

You cannot do everything at once. You have to:

• macro while scouting,
• spend money while defending,
• expand while preserving unit production,
• and avoid wasting attention on the wrong fight.

That feels very familiar to real engineering.

When I am coding inside Vim or a terminal-heavy workflow, the whole environment rewards the same skill: keep the main loop alive while handling interruptions. That means I am constantly asking:

1. what is the highest-leverage action in this moment,
2. what can be deferred safely,
3. what needs to stay on rhythm,
4. what signal is actually worth interrupting for.

SC2 trained my brain to stop romanticizing constant reaction. Not every alert deserves a response. Not every branch of work deserves equal attention. Good play is partly about refusing low-value actions. So is good engineering.

Hotkeys changed how I think about tools

Both Factorio and SC2 reward compressing common actions into reliable motor patterns. That maps directly into why I like Vim and terminal workflows so much.

Once the tool becomes hotkey-native, the interaction stops feeling like “issue a command from scratch every time.” It becomes a vocabulary of rehearsed moves.

That has two effects:

First, it reduces friction. I do not want to re-decide how to move, search, select, split, grep, format, diff, or commit every few minutes.

Second, it preserves cognitive energy for the actual problem.

That is what good hotkey systems do. They move execution into muscle memory and free working memory for reasoning.

Vim is excellent at this when it clicks. The terminal is excellent at this too. You start thinking in composable verbs and operators rather than isolated GUI actions.

Games taught me to respect that style of interaction before I understood it formally.

Map awareness became systems awareness

Another direct transfer from SC2 is the idea of map awareness.

Strong play depends on more than your current camera position. You need a model of what is happening elsewhere:

• your production,
• your expansions,
• likely enemy timings,
• vulnerable paths,
• information gaps.

In engineering terms, that becomes system awareness.

When I work effectively in a terminal environment, I am usually maintaining a rough mental map of:

• what processes are running,
• which files are authoritative,
• where the risky boundaries are,
• which commands are safe,
• what the current bottleneck is,
• and what state the repo is in.

That is not very different from strategy-game awareness. It is still about managing incomplete information across a live system.

Terminal work feels natural to me for the same reason these games did

A good terminal workflow feels alive in the same way a strategy game does.

There is rhythm. There is structure. There is feedback. There are repeated loops. There is economy in movement. There is a constant tradeoff between local action and global awareness.

That is why I think the transition from those games into terminal/Vim-heavy coding felt natural to me. The surface domain changed, but the cognitive style did not.

I was still:

• building repeatable flows,
• reducing wasted motion,
• maintaining a global map,
• watching for bottlenecks,
• and turning frequent actions into low-friction habits.

My real takeaway

Factorio and SC2 did not teach me software engineering directly. They taught me habits that made software engineering easier to learn deeply.

Factorio sharpened my instinct for pipelines, layout, scaling, and bottlenecks.

StarCraft II sharpened my instinct for tempo, triage, attention management, and hotkey discipline.

Together, they made terminal and Vim environments feel less like harsh tools and more like expressive systems. And I think that is why those environments still feel so productive to me now: they reward exactly the kind of system-level thinking those games trained over and over again.

As more software systems become agentic, I keep coming back to two areas that feel more practical every month: mechanism design and network economics.

Mechanism design matters because agentic systems increasingly need explicit rules for allocation, pricing, ranking, and settlement. Network economics matters because those same systems almost never run in isolation. They run as connected markets with reputation effects, liquidity effects, congestion, switching costs, and platform power.

I do not think this is academic garnish. I think it is the control plane.

Mechanism design starts where “just rank the best answer” stops

A lot of AI product discussions still talk as if orchestration is mostly about accuracy. But once there are many agents, many tasks, many cost profiles, and many principals, the real problem becomes: what rule determines who gets what, under which incentives?

That is mechanism design.

If you let multiple agents compete for work, you need to think about:

• how bids are expressed,
• which signals count as quality,
• whether specialization is rewarded,
• whether the platform optimizes for cost, quality, speed, or some weighted combination,
• how gaming is discouraged,
• and how failure or low-quality delivery changes future allocation.

Even a simple auction-like scheduler already embeds a mechanism:

package market

type Bid struct {
	AgentID   string
	TaskID    string
	Price     int64
	Quality   float64
	LatencyMS int
}

func Score(b Bid) float64 {
	// Encode the market's current preference for quality, price, and speed.
	return b.Quality - float64(b.Price)/100.0 - float64(b.LatencyMS)/1000.0
}

That scoring function is not “just implementation.” It is policy. It tells the market what behavior wins.

This is why I think mechanism design belongs close to agent infrastructure. If a system says it values reliable, cheap, fast execution, then that preference should be expressed explicitly in the allocation rule rather than buried inside ad hoc heuristics.

Network economics explains why the best local rule can still lose globally

Mechanism design gives you local rules. Network economics helps explain the larger system those rules sit inside.

Suppose a platform routes more work to agents with the richest historical traces. That may look efficient in the short run, but it can also create a network effect where already-dominant agents get richer data, better reputation, more settlement history, and therefore even more future work. The result can be lock-in rather than healthy competition.

That is a network-economics problem.

The same thing shows up in developer platforms, model marketplaces, and tool ecosystems:

1. participants join where liquidity already exists,
2. liquidity improves matching quality,
3. better matching attracts more participants,
4. the platform becomes more dominant,
5. switching costs rise.

Those effects are powerful even when the underlying ranking rule looks neutral. That is why network economics matters for agentic systems. It explains why market structure cannot be reduced to a single matching equation.

Agentic platforms will have to think about congestion and interoperability

Another reason I care about network economics is that agents consume shared infrastructure. They hit APIs, vector indexes, GPUs, browsers, queues, and payment rails. When many of them converge on the same substrate, congestion becomes a real cost.

In classical network economics, you would ask how pricing, access rules, or interoperability constraints change the equilibrium. In agentic systems, those same questions show up as rate limits, priority queues, token budgets, or differentiated service levels.

A platform that ignores those constraints will not stay neutral for long. It will accidentally encode advantages for whoever can tolerate latency, prepay for capacity, or absorb more failed runs.

The books I keep returning to

Algorithmic Game Theory is still one of the clearest bridges between computational systems and economic allocation. It matters here because many modern agent-routing problems are really computational market-design problems wearing infrastructure clothing.

Oz Shy's Network Economics is useful because it keeps reminding me that value is often endogenous to the network itself. In other words, the platform changes the payoff structure simply by shaping who can interact, how often, and at what switching cost.

My practical takeaway

If you are building agentic systems, mechanism design tells you how to allocate. Network economics tells you what repeated allocation does to the whole ecosystem.

That combination matters more than most teams admit.

An agent platform that ignores mechanism design gets manipulation, low trust, and inconsistent incentives. An agent platform that ignores network economics gets concentration, lock-in, and distorted participation. You need both lenses if you want a system that is not only locally efficient, but sustainably legible.

Sources

• Algorithmic Game Theory
• Network Economics

There is a reason review papers are useful in fast-moving fields: they show how many moving parts a clean demo hides.

On-Device Language Models: A Comprehensive Review is valuable because it frames edge LLM deployment as a systems problem spanning compression, hardware acceleration, runtime strategy, and hybrid edge-cloud design.

That framing is worth stealing.

If a team says it is "doing on-device AI," the real question is whether it has a clear answer for:

• what runs locally,
• what falls back remotely,
• how quality and latency trade off,
• how the deployment will be debugged in the field.

The model is only one component

It is tempting to talk about on-device AI as if choosing a small enough model solves the hard part. In practice, model choice is only the beginning. Once a team tries to ship, other questions arrive immediately: how the model is compressed, what hardware path it depends on, and how the system behaves when local execution is not the right answer.

That is why the systems framing matters. It keeps teams from pretending that an edge strategy is just a checkpoint plus a demo video.

Shipping requires coordinated decisions

A real on-device deployment has to line up several layers at once:

• model efficiency,
• runtime behavior,
• hardware acceleration,
• fallback and hybrid execution,
• field observability.

Weakness in any one of those layers can define the product experience. A great local model with poor fallback behavior is still a poor product. A fast path with no clear debugging story is still an operational risk.

The useful question is architectural

That is why I like the comprehensive-review framing. It encourages a better question than "can we run an LLM on-device?" The better question is "what system are we actually building around local inference?"

That is a more serious design question, and it is the one that matters. On-device LLMs are exciting, but the teams that ship them well will usually be the teams that treat them as systems design from the start.

I spent time studying Angelos Perivolaropoulos's workshop on training an LLM from scratch locally, plus the companion llm-from-scratch repository, and I think it is one of the better introductions to the topic precisely because it refuses to mystify the process.

The workshop is not really about “making a tiny ChatGPT.” It is about seeing the transformer pipeline stripped down far enough that every moving part becomes legible: tokenizer, embeddings, self-attention, MLP blocks, residual paths, layer norm, training loop, validation, and sampling.

What I liked most is that the workshop keeps the model small enough to run locally while still preserving the real structure of modern GPT-style training. The companion repo uses a family of configs from tiny to medium, with the default workshop setup landing around a 6-layer, 6-head, 384-dimensional model. That scale is small enough to make experimentation local, but large enough that the important engineering questions still show up.

The tokenizer is not a preprocessing detail

The first thing that stood out to me is how correctly the workshop treats tokenization as a core modeling decision rather than a boring preprocessing step.

For Shakespeare-scale data, the choice of a character-level tokenizer is not a toy simplification. It is the right systems choice.

The repo makes the case very clearly:

• Shakespeare has about 65 unique characters,
• that means only 65² = 4,225 possible character bigrams,
• those transitions are dense enough that a small model can actually learn them,
• and the embedding/output layers stay tiny.

That last point matters more than many people realize. With vocab_size=65 and n_embd=384, the token embedding table is only about 25K parameters. If you swap in GPT-2's 50,257-token BPE vocabulary at the same embedding width, the embedding table alone jumps to roughly 19.3 million parameters. On a workshop-scale model, that is not a small implementation detail. That is the architecture.

The deeper lesson is that tokenizer choice is really about matching representational granularity to data scale. On a tiny corpus, BPE gives you a vocabulary that is too sparse to learn useful transition structure. Character-level modeling makes the sequence longer, but it gives the model a denser statistical world.

That tradeoff clicked for me very hard while studying the workshop: sequence length, vocabulary size, and learnable statistics are all coupled.

The transformer itself is not the mysterious part

The model architecture is intentionally GPT-2-like:

1. token embeddings,
2. position embeddings,
3. repeated transformer blocks,
4. each block containing causal self-attention plus an MLP,
5. residual connections around both sublayers,
6. layer norm for stability,
7. a projection back to vocabulary logits.

There is nothing magical here, and that is exactly why the workshop is useful.

A lot of people still speak about LLMs as if the mystery lives inside some impossibly exotic block. But once you write the forward path down, the core mechanics are straightforward. Attention produces context-aware token representations; the MLP mixes features position-wise; residual paths preserve gradient flow; layer norm keeps activations sane.

What is more interesting is how these pieces constrain each other. If n_embd=384 and n_head=6, each attention head gets 64 dimensions. That is not just a shape check. It defines the capacity per head, the cost of attention, and the granularity of the similarity computation. Small-model design is mostly about these tradeoffs rather than about novelty.

The training loop is where the real engineering starts

The strongest message in the workshop is that the training loop matters more than architecture tweaks, and I think that is exactly right.

The objective is standard next-token prediction: input [t0, t1, ..., tn], predict [t1, t2, ..., tn+1]. But the workshop makes the practical consequences visible:

• batch construction matters,
• train/validation splits matter,
• the learning-rate schedule matters,
• gradient clipping matters,
• sample generation during training matters,
• and watching validation loss is not optional if you care about overfitting.

This is the kind of detail that separates “I ran a notebook” from “I understand what the model is doing.”

One small piece I kept thinking about is how simple the batch builder is. It just samples random starting offsets, slices block_size tokens for x, and shifts by one token for y. That is conceptually simple, but it encodes the whole autoregressive learning problem:

// makeBatch slices paired input and target windows for next-token prediction.
func makeBatch(tokens []int, starts []int, blockSize int) ([][]int, [][]int) {
	x := make([][]int, 0, len(starts))
	y := make([][]int, 0, len(starts))

	for _, start := range starts {
		// The target window is shifted by one token relative to the input.
		input := append([]int(nil), tokens[start:start+blockSize]...)
		target := append([]int(nil), tokens[start+1:start+blockSize+1]...)
		x = append(x, input)
		y = append(y, target)
	}

	return x, y
}

That tiny shift is the whole learning signal. The model is never told about syntax, style, or Shakespearean rhythm directly. It gets only the pressure to predict the next token well, repeatedly, at scale.

Cosine decay is not cosmetic

I also appreciated that the workshop does not hand-wave optimization. The repo uses warmup, cosine decay, AdamW, and gradient clipping. That is already enough to show why training methodology dominates a lot of outcomes people wrongly attribute to “model intelligence.”

Warmup exists because early optimization steps are fragile. Cosine decay exists because the job changes over time: early on you want exploration and rapid movement; later you want refinement. Gradient clipping exists because small instabilities can still wreck a run, especially when you are learning interactively and changing things quickly.

A lot of frontier-model discussion hides these basics behind scale. This workshop does the opposite. It makes the loop visible enough that you can see the shape of the problem.

Validation loss and sampling are both debugging tools

One subtle but important point in the workshop is that generation is not only a flashy demo. It is a diagnostic.

If validation loss is improving but samples are still collapsing into garbage, you learn something. If the text starts looking structured and then later begins to regurgitate training fragments, you learn something else. The repo even calls out that peak sample quality often arrives before the end of training, which is a clean reminder that “longer training” is not the same as “better model.”

That is the kind of habit I wish more people carried into practical model work: do not evaluate only through a final scalar loss and do not evaluate only through vibes. Use both.

The workshop also clarifies what transfers to reasoning and multimodality

I found the later discussion especially useful because it shows how these ideas generalize. A transformer expects sequences of vectors. Once that clicks, it becomes much easier to reason about why language, audio, and other modalities can all fit into related architectures.

The point is not that all modalities are the same. The point is that if you can map them into the right embedding space and preserve the relevant sequence structure, the downstream transformer machinery becomes reusable.

That is also why the workshop feels valuable beyond this exact Shakespeare example. It is teaching the shape of the abstraction, not just one toy exercise.

My main reflection

The biggest thing I took from studying this workshop is that small local training is useful not because it competes with frontier models, but because it teaches where the real leverage lives.

It lives in:

• tokenizer/data fit,
• parameter budgeting,
• optimization discipline,
• loss interpretation,
• and the relationship between training signals and generated behavior.

If you understand those pieces, larger model systems become much less mystical.

That is why I liked this workshop. It keeps the model compact, but it does not fake the important parts. It shows that even a local, laptop-scale transformer is still a serious engineering object. And once you internalize that, a lot of current LLM discourse starts sounding less like magic and more like systems work.

Sources

• Angelos Perivolaropoulos, Training an LLM from Scratch, Locally
• angelos-p/llm-from-scratch
• Attention Is All You Need

I did not focus on blockchain in my dissertation because I wanted to rehash crypto slogans. I focused on it because blockchains make economic rules programmable, transparent, and auditable.

That matters a lot more in an agentic world than it did in the earlier platform era.

In my dissertation on SWE-Agent Economics and SWEChain-SDK, I argue that decentralized SWE-Agent outsourcing markets are worth studying precisely because centralized platforms hide too much of the mechanism. They hide the ordering logic, the settlement logic, the admission rules, and often the event history needed for serious analysis.

If agents are going to negotiate, specialize, and compete in software markets, I want those rules visible.

Why blockchain was the right research substrate

The dissertation frames a blockchain not as branding, but as an implementation of an economic mechanism. That distinction mattered a lot to me.

I was interested in:

• explicit allocation rules,
• transparent bids and payments,
• auditable state transitions,
• reproducible experiments under fixed conditions.

A blockchain-style substrate is useful there because it makes state change legible. Every bid, allocation, payment, and artifact trail can be logged as part of the system rather than reconstructed later from scattered dashboards.

That is exactly why one of the central contributions of the dissertation is SWEChain-SDK, a local-first blockchain-native SDK for economic network simulations of decentralized SWE-Agent markets.

Why this gets more relevant in the agentic era

The stronger agents become, the more we need clean answers to questions like:

1. who can submit work,
2. who is allowed to bid,
3. how selection happens,
4. how settlement happens,
5. what evidence counts as completion,
6. how disputes or failures are inspected afterward.

Traditional software systems can answer those questions too, but they often do so in an opaque way. Blockchains are interesting here because they make those policies first-class and programmable.

That is why I focused on them in research. I was less interested in speculation and more interested in mechanism visibility.

Go is a natural language for the experimental surface

Even if the settlement substrate is blockchain-based, the surrounding tooling still benefits from straightforward systems code. A local-first SDK needs CLIs, dashboards, bridges, and deterministic utilities. That is where Go fits very naturally.

A small Go surface makes the policy layer easier to reason about:

package settlement

// AuctionResult is the minimal state needed to settle a finished task.
type AuctionResult struct {
	TaskID      string
	WinnerID    string
	PriceCents  int64
	ArtifactRef string
}

// Ledger abstracts the settlement backend behind one explicit call.
type Ledger interface {
	Settle(result AuctionResult) error
}

func Finalize(ledger Ledger, result AuctionResult) error {
	// Keep the settlement path obvious so it is easy to audit.
	return ledger.Settle(result)
}

Again, the point is not complexity. The point is clarity. If agentic systems are going to rely on explicit mechanisms, the code around those mechanisms should be boring, auditable, and testable.

Why I think this topic is still underrated

A lot of agent discussion still assumes coordination will be solved inside application logic alone. I think that misses the opportunity.

Once agents are meaningful economic actors, infrastructure matters. Settlement matters. Logging matters. The ability to replay and inspect the exact rule path matters. That is why a blockchain-native SDK felt like a useful research artifact rather than a gimmick.

The dissertation made that case because I wanted a platform where decentralized SWE-Agent markets could be studied under controlled, paired experiments. If you want to compare policies seriously, you need the mechanism to be part of the experiment, not an invisible dependency.

The real reason I cared

I focused on this because I think agentic software engineering will eventually force us to choose between opaque coordination and explicit coordination. My bet is that explicit coordination wins, especially in high-stakes systems where trust, incentives, and auditability matter.

That is why blockchains matter again in this context. Not because they make agents magical, but because they make the rules legible.

Source

• Mohamed A. Fouad, Software Engineering Agent Economics: A Blockchain Software Development Kit for Economic Network Simulations

One reason I kept pushing on SWE-Agent economics in my dissertation is that the agentic era is easy to misunderstand. It is tempting to frame it as a UX improvement: faster coding, better assistants, cheaper automation.

That is real, but it is not the deepest change.

The deeper change is that intelligence is becoming an allocatable resource. Once agents can act with some autonomy, the problem becomes economic: how do we route scarce capability across tasks, budgets, quality thresholds, and time constraints?

That is exactly the kind of question I wanted to study in my dissertation on SWE-Agent Economics and SWEChain-SDK. I focused on it because software engineering is moving from static labor assumptions toward dynamic allocation problems.

Agentic systems make cost visible

In the old story, software work was mostly discussed in terms of teams, estimates, and ticket flow. In the agentic story, it becomes easier to measure the real tradeoffs:

• which agent finishes first,
• which one finishes cheapest,
• which one has the highest first-pass success,
• which one burns the most compute,
• which routing policy creates the best portfolio outcome.

That is why the economic lens matters. It turns a fuzzy conversation into one about mechanism design, resource allocation, and incentives.

The dissertation uses the language of SWE-Agent outsourcing markets because outsourcing markets make those choices explicit. The idea is not that every company will literally run an auction tomorrow. The idea is that auctions expose the structure of the problem in a way that centralized product flows usually hide.

Why I cared about Intelligence Per Watt

One clue that pushed me further into this area was the growing importance of efficiency metrics such as Intelligence Per Watt (IPW). Once model quality is no longer the only variable, system design has to care about capability per unit of energy, cost, and latency.

That is economically meaningful because it changes who gets selected. A slightly weaker agent with better cost-performance can win in a constrained environment. The agentic era is full of those tradeoffs.

In Go terms, that means the orchestration layer has to become explicit about utility:

package routing

type Candidate struct {
	Name       string
	PriceCents int64
	LatencyMS  int
	Score      float64
}

func Utility(c Candidate) float64 {
	// Trade off quality against both price and latency.
	return c.Score - float64(c.PriceCents)/100.0 - float64(c.LatencyMS)/1000.0
}

This is not a production formula. It is a reminder that selection policy is an economic policy. Even a simple router is already making claims about what the system values.

Why I thought software engineering needed this framing

I focused on this in research because I did not want software engineering to adopt agents while leaving its evaluation language behind. If we keep treating agentic systems as isolated model demos, we miss the fact that they are participating in a larger allocation problem.

That is why the dissertation emphasizes controlled paired experiments. If you want to compare policies, you need a system where you can hold the environment steady and vary one rule at a time. Otherwise, people confuse noise with insight.

The economics is not optional

The agentic era creates an economic system whether we acknowledge it or not. Agents consume resources, compete for tasks, differ in comparative advantage, and operate under explicit or implicit incentives.

The practical question is whether we want to study those rules directly. My answer in the dissertation was yes. That is why I focused on building a framework where those interactions could be observed, logged, and rerun under comparable conditions.

To me, that is one of the most exciting parts of the whole field. It means software engineering is no longer only about writing code better. It is about designing systems where intelligence itself becomes a resource to allocate well.

Source

• Mohamed A. Fouad, Software Engineering Agent Economics: A Blockchain Software Development Kit for Economic Network Simulations

One of the clearest questions in front of us is not whether coding agents will get better. They will. The harder question is what happens when software work itself starts behaving like an economic system.

That is why I focused my dissertation on this area. In Software Engineering Agent Economics: A Blockchain Software Development Kit for Economic Network Simulations, I framed what I call SWE-Agent Economics as the intersection of intelligent software engineering and software-engineering economics. I was not interested only in whether agents can solve tasks. I was interested in what happens when they bid, specialize, compete, consume priced resources, and operate under explicit allocation rules.

That focus came from a simple observation: once software work can be decomposed into scoped issues, artifacts, tests, and payments, the system starts to look less like a task board and more like a market.

Why I thought the economic lens mattered

A lot of discussion around coding agents still treats them as isolated assistants. That framing is too small.

In practice, agents already operate under:

• budget limits,
• latency limits,
• tool-access limits,
• quality thresholds,
• routing and scheduling decisions.

Those are economic constraints, even when people describe them as product or platform constraints.

My research focused on this because I wanted a language and an experimental setup that could capture those interactions directly rather than pretending they were just implementation details. The dissertation argues that decentralized SWE-Agent outsourcing markets are a useful central case because they make allocation, pricing, and settlement rules explicit.

Why I built a toolkit instead of writing only theory

The dissertation does not stop at framing. One of its main contributions is SWEChain-SDK, a blockchain-native SDK for controlled economic network simulations of SWE-Agent markets. I cared about that because good ideas are cheap if nobody can run the experiment again under comparable conditions.

I wanted an environment where we could vary one policy dimension at a time and still keep:

1. the same datasets,
2. the same time base,
3. the same agent pool,
4. the same logging surface.

That is what makes claims about agent economics credible instead of anecdotal.

From a Go perspective, that kind of work benefits from explicit contracts and small composable binaries. A simulation stack like this should make every surface painfully clear:

package market

// Bid captures the economic signal an agent submits for a task.
type Bid struct {
	AgentID string
	TaskID  string
	Price   int64
	Score   float64
}

// Allocation records the assignment decision emitted by the market.
type Allocation struct {
	TaskID   string
	AgentID  string
	Accepted bool
}

// Logger preserves the events needed for replayable experiments.
type Logger interface {
	RecordBid(Bid) error
	RecordAllocation(Allocation) error
}

The code is intentionally boring. That is the point. If the economic mechanism is the thing under study, the interfaces around it should be stable enough to let experiments change policy without rewriting the whole platform.

Why this mattered to me as a software engineering problem

I focused on this line of research because software engineering is entering a phase where coordination matters as much as raw model capability. The interesting question is no longer only “can an agent solve this issue?” It is also:

• which agent should do it,
• under what incentives,
• at what price,
• with what comparative advantage,
• under which settlement rule,
• and with what observable audit trail.

That is a very software-engineering question, but it is also an economic one.

The dissertation formalizes that intuition because I think the next stage of agentic software engineering will reward teams that can reason about incentives and market structure, not only prompts and models.

The real motivation

The deepest reason I focused on SWE-Agent economics is that it creates a bridge between two worlds that are often separated: engineering systems and economic systems. Agents force them back together.

Once software workers become autonomous, the surrounding system has to answer questions about specialization, cost, settlement, trust, and transparency. I wanted my research to address those questions directly, with reproducible tooling rather than vague metaphors.

That is why the dissertation centers this topic. I think it is one of the most important lenses for understanding where software engineering is heading next.

Source

• Mohamed A. Fouad, Software Engineering Agent Economics: A Blockchain Software Development Kit for Economic Network Simulations

The AI wave did not remove the need for reliable systems work. It amplified it.

Models may be trained in Python, but the product around them still needs to route requests, stream results, enforce quotas, collect traces, fan out work, and stay debuggable at 3 a.m. That is exactly where Go keeps showing up.

What Go is unusually good at

Go is rarely the language of frontier model research, but it is an excellent language for the layers around the model:

• API gateways that need predictable latency.
• Workers that coordinate retrieval, ranking, and post-processing.
• CLI tools that make local evaluation and release workflows less painful.
• Services that need easy concurrency without turning every deploy into a runtime puzzle.

In practice, that matters more than language fashion. AI products win when the whole path from prompt to production is fast, observable, and boring in the best possible way.

The real advantage is operational clarity

Go gives teams a compact standard library, fast startup, straightforward deployment, and simple static binaries. In an AI stack, that translates into fewer moving parts around the expensive part of the system.

That clarity helps when building:

1. request routers for model providers,
2. background jobs for embeddings and indexing,
3. evaluation harnesses,
4. internal tools that glue together data, prompts, and model outputs.

None of that work is glamorous, but all of it compounds.

The AI era rewards teams that can operationalize intelligence, not just demo it.

A good split of responsibilities

A pragmatic stack often looks like this:

• Python for training loops, notebooks, and experimentation.
• Go for services, orchestration, developer tooling, and production control planes.

That split lets each language do what it is best at. You do not need one language to dominate the entire stack to build a fast team.

Reliability is still a product feature

It is easy to talk about AI as if the whole category reduces to model capability. In production, capability is only one layer. Someone still has to make the system dependable, observable, and affordable enough to run every day.

That is why Go keeps surfacing in mature AI products. It helps teams build the unglamorous pieces that decide whether intelligence feels like a feature or like a recurring incident. The more valuable models become, the more valuable that kind of boring infrastructure becomes too.

Even when inference runs on-device, the surrounding product still needs a control plane.

MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases focuses on the model side of that problem, but product teams still need servers for model rollout, feature flags, telemetry collection, and safety policy updates.

That is one reason Go keeps showing up in AI-adjacent systems work.

The model can live on a phone. The operational contract still lives in services, CLIs, background jobs, and dashboards. A boring systems language is still a competitive advantage there.

On-device does not mean no backend

There is a recurring fantasy in edge AI discussions that local inference makes the rest of the product magically disappear. It does not. The product still needs to decide which model version to ship, how to observe behavior in the field, and how to respond when a rollout goes badly.

Those are not minor details around the edges. They are the parts that determine whether an edge feature can be maintained after launch.

The control plane still matters

Even with local inference, teams usually need reliable systems for:

• rollout coordination across device cohorts,
• telemetry and health signals,
• remote policy updates,
• internal tools that help humans understand what is deployed.

None of that makes the on-device story less interesting. It makes the on-device story real.

This is why Go remains relevant in mobile LLM products. Not because it should replace the model stack, but because it handles the operational layer well. Services, jobs, CLIs, and dashboards benefit from a language that makes simple infrastructure easy to keep simple.

The model may live close to the user. The control plane still lives in the ordinary world of software operations, and ordinary engineering discipline still wins there.

One of the clearest recent serving ideas is in DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving. The paper shows why prefill and decode interfere with each other and why separating them can improve goodput under real latency targets.

That architecture has a very Go-shaped seam in it.

If prefill and decode become distinct pools, somebody has to own:

• request admission,
• routing policy,
• streaming state,
• deadline propagation.

That "somebody" does not need to be the same runtime that executes the kernels. A small Go service is often the right place to implement the policy layer because it stays deployable, observable, and easy to debug when traffic gets weird.

Separation creates coordination work

Disaggregation is attractive because it stops different phases of inference from fighting each other quite so directly. But separating them does not remove complexity. It relocates complexity into scheduling, buffering, and operational policy.

That is exactly the kind of work that benefits from a clean control plane.

Once there are distinct pools, the system needs a component that can make understandable decisions when load shifts. It has to answer practical questions: which requests get admitted, what deadlines matter most, and how streaming state is preserved without turning every incident into a forensic exercise.

Why Go fits the seam

A Go service is not interesting here because it is fashionable. It is useful because the control-plane job rewards plain engineering:

• predictable concurrency,
• simple deployment units,
• straightforward observability,
• code paths operators can still follow during an incident.

The serving runtime can stay specialized around execution. The control layer can stay specialized around policy.

That separation of responsibilities feels healthy to me. DistServe highlights why inference phases deserve different treatment. The systems lesson is that once you accept that split, you should also accept a clear policy layer around it. Go is often a very practical place to put that layer.

Structured prompting workflows look fancy at the model layer, but they usually fail or slow down at the runtime layer.

That is why I like reading systems papers such as SGLang: Efficient Execution of Structured Language Model Programs. The paper argues that structured LLM programs benefit from runtime features like cache reuse and careful execution planning, not just better prompts.

My Go takeaway is simple: keep Python close to model experimentation, but let Go own the boring infrastructure around it. Go is a good fit for:

• queueing and routing structured requests,
• managing timeouts and retries,
• exposing clear metrics for cache hit rates and latency.

The paper is not about Go, but the engineering lesson maps well to Go services. The more structured the LLM program becomes, the more valuable it is to have a control layer that is easy to reason about under load.

Structure raises the runtime bar

A surprisingly large amount of LLM application complexity appears only after teams move past one-shot prompts. Once a workflow starts branching, reusing context, or coordinating multiple calls, the runtime matters much more. Suddenly cache behavior, execution order, and failure handling shape the user experience.

That is why "better prompting" is often an incomplete answer. A smart prompt on top of a sloppy runtime still produces a sloppy system.

Boring infrastructure is a feature

This is where Go keeps earning its place. Not because it knows anything special about prompts, but because it helps teams build a simple boundary around the complicated part.

A solid Go layer can make structured programs easier to operate by handling:

• admission control before expensive work starts,
• cancellation and timeout propagation,
• metrics that explain whether cache-aware execution is helping,
• stable service contracts around rapidly changing model logic.

That kind of boring is valuable. It turns runtime behavior into something engineers can inspect without decoding a tower of incidental complexity.

The more structured LLM applications become, the more they resemble ordinary systems problems wrapped around unusual compute. That is a good place for Go. Let the model layer stay experimental. Let the runtime boundary stay readable.

The edge story gets more interesting once NPUs enter the picture.

Fast On-device LLM Inference with NPUs highlights ideas like prompt chunking and hardware-aware scheduling to reduce the ugly parts of latency. That matters because edge serving is rarely just "run the same pipeline on smaller hardware."

It is a different scheduling problem.

Teams building edge stacks should expect device-specific execution strategies, uneven latency profiles, and careful fallbacks. The serving shape changes with the hardware, so the software architecture has to change with it.

Specialized hardware changes software assumptions

When teams first hear "NPU," it is tempting to translate that into "faster inference" and move on. In practice, specialized acceleration changes the system shape more than the marketing shorthand suggests. Latency can improve, but the path to predictable latency often depends on the runtime making better decisions.

That is why ideas like prompt chunking matter. They are reminders that scheduling on-device work is not only about raw throughput. It is about smoothing the unpleasant edges of real interaction patterns.

Expect device-specific execution paths

An edge stack that ignores device variation usually ends up either fragile or overly conservative. Different hardware profiles push the software toward different execution strategies, and that means the product needs explicit handling for:

• uneven latency behavior,
• fallback paths when the preferred accelerator path is unavailable,
• request shaping that matches the device instead of an abstract average.

This is where a lot of "works on my test phone" demos break down. The demo path is often a single happy execution route. The product path needs to survive a fleet.

The more NPUs matter, the less useful it is to think of serving as a generic layer beneath the model. Hardware-aware serving becomes part of the product architecture itself. That is a healthy shift. It forces teams to design for the hardware they actually have, not the hardware they wish every user owned.

The promise of on-device inference is easy to say and hard to ship.

MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases is a useful paper because it focuses on the architecture details that matter at the small end: depth, width, and parameter efficiency.

The engineering takeaway is that edge deployment is not only about compressing a big cloud model. Sometimes the winning move is to start from a model shape that was designed for the edge in the first place.

For product teams, that means evaluating model architecture and serving strategy together, not in separate meetings.

Small models are not just shrunk models

A lot of edge planning still begins with the assumption that the main job is to squeeze an existing large model into a smaller box. That instinct is understandable, but it can lead teams toward awkward compromises. A model that works well in the cloud may carry structural assumptions that stop making sense once memory pressure, latency budgets, and thermals become the real boss.

That is why model shape matters. Depth, width, and parameter allocation are not abstract architecture debates when the target is a phone or another constrained device. They are part of the deployment contract.

Architecture and serving are one decision

On-device systems do not get to treat architecture as an upstream research choice and serving as a downstream platform choice. The two interact immediately.

A model shape that behaves well under tight resource limits can simplify the rest of the stack:

• fewer ugly runtime compromises,
• less dependence on aggressive fallback behavior,
• more predictable performance across device classes.

A bad fit does the opposite. The serving layer ends up compensating for an architecture that was never comfortable on the target hardware.

That is the practical lesson I keep taking from work like MobileLLM. Edge success is not about forcing a cloud story onto smaller hardware. It is about choosing a model form that respects the hardware from day one. When teams do that, the rest of the product conversation gets much cleaner.

Efficiency work becomes more exciting when it changes what hardware can participate.

BitNet: Scaling 1-bit Transformers for Large Language Models is interesting for that reason. The paper points toward a future where memory and energy budgets shift enough to make different deployment targets practical.

That matters for edge intelligence because budget is the product constraint:

• battery,
• memory,
• thermals,
• cost per shipped device.

If a model architecture changes those constraints in a real way, it can change what the product team is willing to build at all.

Why the budget matters more than the benchmark headline

A lot of model discourse still assumes the main question is whether a smaller system can retain enough quality to feel respectable next to a cloud model. That is part of the story, but it is not the whole story. On the edge, the first question is usually simpler: can this thing run at all inside the envelope of a real product?

That is why aggressive efficiency ideas deserve attention even before they become mainstream defaults. A meaningful shift in representation can move a device from "not viable" to "viable with tradeoffs," or from "lab demo" to "shippable feature." Those are product-level changes, not paper-only changes.

What changes when the budget moves

When memory and energy costs drop, design space opens up in practical ways:

• more room for local context without immediately hitting device ceilings,
• less pressure to offload every hard case to the network,
• more freedom to treat intelligence as a default capability instead of a premium tier.

That does not mean every edge team should bet immediately on 1-bit architectures. It does mean teams should watch for ideas that alter the baseline economics of deployment. If the cost profile changes enough, the roadmap changes with it.

For edge work, that is the real promise of papers like BitNet. They are not only about squeezing a prettier number out of an efficiency table. They hint at a different hardware participation curve, and that is where product strategy starts to move.