DEV Community: Krlz

The Most Important AI Engineering Skill Is Saying No (AI-DLC, bolts, and autonomous agents)

Krlz — Wed, 04 Nov 2026 19:52:39 +0000

AI can now propose an architecture, break requirements into tasks, write the implementation, generate tests, and prepare a deployment.

And we are increasingly building entire development methodologies around that capability.

AWS introduced the AI-Driven Development Lifecycle (AI-DLC), with concepts such as Units of Work, Bolts, Mob Elaboration, and Mob Construction. Frameworks such as specs.md bring similar ideas into tools like Claude Code.

The promise is compelling: shorter development cycles, persistent context, specialized agents, and fewer manual handoffs.

But after exploring these methodologies, I keep returning to a question that seems more important than how quickly AI can produce software:

Who is actually making the engineering decisions?

Not who approves the final pull request. Not who clicks "continue" when an agent requests permission.

Who decides whether an architectural proposal makes sense in the first place?

My argument: The most valuable human contribution to AI-driven software development may be the ability to reject an AI proposal, establish constraints, demand alternatives, and stop execution.

If developers lose that authority, human-in-the-loop becomes little more than a ceremonial approval process.

We are redesigning software development around AI

For years, the software industry has experimented with methodologies intended to improve how teams deliver software.

Waterfall emphasized sequential phases. Agile introduced iterative development and faster feedback. Scrum provided a framework for organizing complex work, while Kanban emphasized managing flow.

Now we have AI-native development methodologies.

AWS describes AI-DLC as a model in which AI creates plans, asks questions, proposes solutions, and executes work after human validation.

Its lifecycle has three major phases:

Phase	AI responsibility	Human responsibility
Inception	Elaborate requirements and propose units	Validate business intent and scope
Construction	Propose designs, generate code, and test	Make technical decisions and validate results
Operations	Prepare infrastructure and operational changes	Provide oversight and authorize consequential actions

The methodology also introduces Bolts, short execution cycles generally measured in hours or days rather than weeks.

The ambition is to reorganize the development lifecycle around AI's ability to generate and execute work rapidly.

AI-Driven Development Life Cycle: Reimagining Software Engineering | AWS DevOps & Developer Productivity Blog

aws.amazon.com

This is a legitimate direction to explore.

But there is a subtle difference between accelerating software development and accelerating the production of software artifacts.

An agent can produce five architectural alternatives in minutes.

It cannot guarantee that any of them is appropriate for the organization, its operational constraints, or the business problem.

That distinction becomes increasingly important as agents gain autonomy.

A Bolt is not a substitute for engineering judgment

Consider a traditional development team implementing a reservation management feature.

A developer might spend time understanding the domain, inspecting existing services, discussing edge cases, and choosing an implementation strategy.

With an AI-driven workflow, an agent may perform much of that investigation and propose an implementation plan.

The team can then approve the plan and let the agent execute it.

This sounds efficient.

But consider what happens when the agent proposes an unnecessarily complicated solution.

For example:

Introduce a Kafka topic to propagate reservation state changes, a Redis cache for availability lookups, and a new microservice responsible for reservation lifecycle management.

It sounds like an architecture.

It even sounds like a reasonably sophisticated one.

But what if the system currently handles a few hundred reservations per day, uses a single PostgreSQL database, and has no demonstrated scaling problem?

The correct engineering decision might be:

No. We do not need any of that.

We might need one additional endpoint, a transaction, a database constraint, and two integration tests.

An AI agent can generate a technically coherent architecture that is nevertheless a poor engineering decision.

The danger is not only incorrect code.

It is unnecessary complexity delivered at extraordinary speed.

A successful Bolt should not be measured by how much work the agent completed.

It should be measured by whether the team delivered a correct, maintainable increment that solves the intended problem.

Human-in-the-loop is not the same as human-in-control

This distinction deserves more attention.

Many AI workflows include human checkpoints. The agent presents a plan, and a developer approves or rejects it.

That is useful, but insufficient.

Imagine the following interaction:

AI: I recommend introducing an event-driven architecture.

Developer: Approved.

AI: I will implement three services and their supporting infrastructure.

Developer: Approved.

AI: Implementation complete. All generated tests pass.

Developer: Approved.

There were three human checkpoints.

Yet we have no evidence that meaningful engineering judgment occurred at any of them.

Now consider a different interaction.

AI: I recommend introducing an event-driven architecture.

Developer: Why? What problem does it solve that our existing transactional design cannot?

AI: It could improve decoupling and asynchronous processing.

Developer: Show me three alternatives. Compare operational cost, consistency guarantees, failure recovery, and migration effort. Our team maintains this platform with limited infrastructure capacity.

AI: A transactional implementation appears sufficient under those constraints.

Developer: Proceed with that approach. Do not introduce new infrastructure.

The second interaction may produce less code.

It may also produce substantially better software.

The developer was not merely validating output.

The developer was actively shaping the solution.

Human-in-the-loop describes participation. Human-in-control describes authority.

They are not equivalent.

The four powers developers must retain

I believe every serious AI engineering workflow should explicitly preserve four human capabilities.

1. Reject a proposal

Developers must be able to reject a design without having to provide a replacement implementation immediately.

This matters because rejecting a bad abstraction is often easier than constructing a better one.

An AI-generated design may be logically consistent but violate established architectural boundaries, introduce unnecessary dependencies, or optimize for a problem that does not exist.

A useful rejection should identify the concern:

Reject this proposal. It introduces a new service without demonstrating a need for independent scaling, deployment, or domain ownership.

That is an engineering decision.

Not an obstacle to automation.

2. Establish constraints

AI agents need boundaries.

Not just coding conventions, but architectural and operational constraints.

For example:

architecture:
  new_microservices: prohibited
  database: postgresql
  messaging: existing_kafka_topics_only
  public_api_breaking_changes: prohibited

reliability:
  retries_must_be_bounded: true
  idempotency_required_for_commands: true
  backward_compatibility: required

delivery:
  unrelated_refactoring: prohibited
  integration_tests: required
  production_deployment: manual_approval

This is an illustrative policy, not a native specs.md configuration file.

The point is that constraints should be explicit, versioned, and testable wherever possible.

A developer should not need to repeat the same architectural principles every time a new agent session begins.

3. Demand alternatives

One of the most dangerous properties of AI-generated solutions is how persuasive they can appear.

A complete design document with diagrams, tradeoff tables, and confident explanations can create the impression that the design space has already been explored.

It may not have been.

For consequential decisions, developers should ask:

What is the simplest viable alternative?
What can we implement using existing components?
Which assumptions would make this design inappropriate?
What are the operational and maintenance costs?
What would make us reverse this decision six months from now?

These questions force the agent to explore the decision rather than simply defend its first proposal.

4. Stop execution

Autonomy should have boundaries.

An agent should stop when it encounters an unresolved architectural decision, a destructive operation, a security-sensitive change, or a conflict between requirements.

Consider a database migration.

The agent discovers that implementing a new feature requires modifying a heavily used table.

It should not automatically choose a destructive migration merely because doing so would complete the task.

It should surface the conflict.

EXECUTION PAUSED

Reason:
The proposed schema change may break
existing consumers.

Options:
A. Backward-compatible additive migration
B. Versioned API and staged migration
C. Redesign the feature to avoid the change

Decision required:
Authorized engineering owner

Stopping is not failure.

Stopping at the correct moment is a feature of a well-governed autonomous system.

But who should make these decisions?

Not every decision belongs to the same person.

Product owners and business stakeholders should determine which outcomes matter.

Domain experts should validate business rules.

Developers and technical leads should own engineering decisions, including architecture, implementation constraints, reliability, and maintainability.

Authorized operational owners should control production releases.

AI can help each group evaluate alternatives and execute approved work.

It should not silently inherit their authority.

This is also where AI-DLC should be evaluated against established engineering practices.

The Scrum Guide makes developers accountable for creating the Sprint Backlog, adapting their plan, and maintaining quality through the Definition of Done.

AI-DLC changes the mechanics of planning and implementation, but it should not erase that accountability.

There is a difference between delegating execution and delegating responsibility.

What happens when agents start making architecture decisions?

Imagine a team maintaining a mature backend platform.

The system has accumulated years of architectural decisions, operational lessons, domain-specific exceptions, and integration constraints.

An AI agent receives a request:

Implement real-time reporting for active alerts.

The agent examines the existing implementation and proposes a separate Redis-backed endpoint for active alerts, while historical alerts remain in PostgreSQL.

At first glance, the design may appear reasonable.

But the engineering team knows that this introduces two sources of truth for reporting.

Now every consumer needs to understand which endpoint to query, how to reconcile results, and what happens during synchronization failures.

The developer may instead insist on a unified reporting model with explicitly defined state transitions.

That decision requires understanding more than the immediate feature.

It requires understanding the system's history, consistency requirements, and future maintenance burden.

AI can help investigate those concerns.

But it cannot automatically determine which organizational tradeoffs are acceptable.

This is precisely where experienced engineering judgment becomes valuable.

The problem with measuring AI development through speed

AI-DLC introduces shorter execution cycles, and frameworks such as specs.md provide structured workflows for implementing them.

But how should we evaluate whether these methodologies work?

A common demonstration shows an agent producing a working application in a few hours or days.

That is impressive.

It is not sufficient evidence of long-term engineering effectiveness.

I would be more interested in what happens after six months.

Can another developer understand the architecture?

Can the team safely introduce a new feature?

Do the specifications still describe the implementation?

Can a developer challenge an earlier decision without rebuilding half the platform?

How much human effort is required to review and repair generated changes?

And when something fails in production, can the team diagnose it without depending on the original agent's conversation history?

Those questions are harder to demonstrate than a successful prototype.

But they are closer to what professional software engineering actually requires.

A useful evaluation should compare:

Metric	What it reveals
Acceptance-test success	Whether the implementation meets requirements
Human review time	How much effort correctness requires
Rework after implementation	Whether the initial solution was appropriate
Architectural complexity	Whether unnecessary components were introduced
Operational incidents	Whether the system remains reliable
Cost per accepted change	Whether faster generation creates real efficiency
Maintainability over time	Whether future engineers can safely evolve the system

Counting completed Bolts is not enough.

Counting generated lines of code is even less useful.

The meaningful unit of progress is not AI activity. It is validated software value.

Are we accidentally reinventing Waterfall?

There is another uncomfortable possibility.

Spec-driven AI development often emphasizes generating requirements, architecture documents, implementation plans, tasks, and tests before or during execution.

These artifacts can improve traceability and preserve context.

But if teams begin treating AI-generated specifications as authoritative simply because they were approved, we risk recreating a familiar problem.

The process becomes:

Generate extensive requirements.
Approve the requirements.
Generate the architecture.
Approve the architecture.
Generate the implementation.
Discover that the original assumptions were wrong.

That is not automatically Agile because the implementation happened in short Bolts.

Agility requires the ability to revise assumptions and respond to new information.

A Bolt can be short while the overall process remains rigid.

Conversely, a team can use AI-generated specifications effectively if those specifications remain open to challenge, revision, and even deletion.

The value of a specification is not that it exists.

It is that it helps the team make and revisit decisions.

A better AI engineering workflow

I would rather see teams organize AI-assisted development around explicit decision boundaries.

Not every small change needs a complete architectural review.

But not every change should run on autopilot either.

Here is a practical model.

Change	AI autonomy	Human involvement
Documentation correction	High	Review output
Small API enhancement	High within constraints	Validate contract and tests
Internal refactoring	Moderate	Review behavior preservation
Cross-service integration	Limited	Approve design and failure handling
Data migration	Restricted	Approve migration and rollback
Security-sensitive change	Restricted	Independent security review
Production deployment	Policy-controlled	Authorized release decision

The important property is that autonomy is proportional to risk.

An agent should not require permission to rename a local variable.

It should not be allowed to invent a new distributed architecture without engineering approval.

An example: an architecture decision prompt for an AI agent

Before implementing this feature:

1. Identify the affected domain boundaries.

2. Propose at least two viable solutions,
   including one that reuses existing infrastructure.

3. Compare:
   - Complexity
   - Reliability
   - Operational cost
   - Backward compatibility
   - Migration effort
   - Failure recovery

4. Explicitly identify assumptions and unknowns.

5. Recommend the simplest solution satisfying
   the documented requirements.

6. Do not implement until the architectural
   decision is approved.

7. If new information invalidates the approved
   design, stop and request a new decision.

This is not a replacement for engineering expertise.

It is a way to make that expertise visible in the workflow.

The developer's role is changing, but not disappearing

I do not think the future of software engineering is developers manually writing every line of code.

Nor do I think it is developers approving whatever an autonomous agent produces.

The interesting future lies between those extremes.

Developers may spend less time producing routine implementations and more time defining constraints, exploring tradeoffs, validating behavior, and managing complexity.

But there is a danger in describing this transformation as developers becoming merely supervisors of AI agents.

Supervision without sufficient technical understanding is fragile.

If developers stop exercising implementation and architectural judgment, their ability to challenge increasingly sophisticated AI proposals may deteriorate.

We could end up with systems that are easier to generate than to understand.

And organizations that can produce software faster than they can responsibly maintain it.

That would not be an improvement in software engineering.

It would be an improvement in software production at the expense of engineering control.

The real test of AI-DLC

I am interested in AI-DLC, Bolts, and spec-driven development because they attempt to solve real problems: lost context, slow handoffs, inconsistent implementation, and repetitive work.

I also think they deserve more rigorous evaluation than demonstrations of rapid application generation.

The most convincing evidence would be a substantial production platform developed and maintained through many AI-driven iterations, with its architectural decisions, specification changes, failures, and operational history available for examination.

Not just the first successful release.

The tenth feature.

The unexpected migration.

The production incident.

The architectural decision that turned out to be wrong.

And the developer who recognized the mistake before an autonomous agent made it worse.

The goal should not be to remove developers from the decision-making process.

It should be to give developers better information, more alternatives, and greater leverage over the decisions that matter.

An AI engineering methodology succeeds when it improves engineering judgment—not when it makes that judgment optional.

Final thought

AI can propose a solution in seconds.

It can generate thousands of lines of code, construct tests, document decisions, and execute an entire development workflow.

But engineering has never been only about producing implementations.

It is also about knowing when an implementation should not exist.

When an abstraction is unnecessary.

When a dependency introduces more risk than value.

When a requirement is incomplete.

When a system should remain simple.

And when execution must stop.

The most important AI engineering skill may not be writing better prompts.

It may be knowing when to say no.

The Architecture of Public Opinion: How Digital Media Shapes What We Believe

Krlz — Tue, 27 Oct 2026 11:58:27 +0000

The Architecture of Public Opinion

How digital media systems shape what we see, what we fear, and what we believe.

Imagine two reports covering the same protest.

One explains the demands, interviews participants, checks official statements, and reports incidents of violence. The other opens with burning barricades, police sirens, and a headline about chaos.

Both may contain accurate facts. Yet they produce very different impressions.

A news report doesn't need to be false to create a misleading picture of reality.

The difference is not just the opinion of a journalist. Behind each report is a system: editorial workflows, publishing software, business incentives, recommendation algorithms, and audience feedback.

1. News Is a Sociotechnical System

A simplified digital-news pipeline looks like this:

Real-world events
       |
       v
News selection
       |
       v
Editorial decisions
(sources, images, words, context)
       |
       v
CMS and publication
       |
       v
Distribution
(search, social, recommendations)
       |
       v
Audience and public conversation
       |
       v
Analytics and feedback --------+
       |                       |
       +----> Future editorial decisions

Each step has rules and incentives. Which event is newsworthy? Which photograph gets selected? Who is quoted? Which headline generates the most clicks?

The final article is a representation of an event, assembled through decisions. This does not make journalism inherently dishonest; it makes editorial accountability essential.

2. Three Frameworks for Understanding Influence

Agenda-setting: McCombs and Shaw's classic research explains how media attention can influence which issues audiences consider important. Frequent crime coverage, for example, can raise the perceived importance of crime without telling us whether crime rates are rising.

Framing: Robert Entman's framework explains how selecting and emphasizing particular aspects of events promotes particular interpretations. A protest framed mainly through property damage is understood differently from one framed through its political demands.

Cultivation theory: George Gerbner's work explores how prolonged exposure to recurring television portrayals can influence perceptions of social reality, including danger and violence.

These are research frameworks, not proof that every viewer is manipulated or that a particular newsroom deliberately distorts reality.

3. When Engagement Becomes the Objective

Digital publishers can track clicks, watch time, retention, comments, shares, and advertising revenue.

Those metrics answer: Did people interact? They do not necessarily answer: Did people understand?

Consider two articles about migration:

Article A provides statistics, historical context, limitations, and interviews with researchers.
Article B pairs one violent incident with alarming imagery and a provocative headline.

If Article B attracts more attention, a system optimized primarily for engagement may distribute it more widely. The software might be performing perfectly against its target while the larger information system performs poorly against a public-interest goal.

This echoes Goodhart's Law: once a measure becomes a target, it can lose its value as a measure.

Engagement is a product metric. Public understanding is a social outcome. They are not interchangeable.

4. Crime, Protest, and Dehumanization

Accurate crime reporting is necessary. So is reporting violence at demonstrations. But reporting these events does not require dehumanizing people.

Editorial choices can create serious problems when they:

Present suspects as guilty before conviction.
Generalize individual crimes to entire nationalities or communities.
Treat all protesters as responsible for the actions of a few.
Use unrelated images that associate particular groups with danger.
Remove the demands, history, or social conditions surrounding an event.

A photograph is not neutral merely because it is authentic. Its timing, cropping, caption, and placement affect meaning.

Objectivity is not indifference to violence. It is a commitment to evidence, context, proportionality, and human dignity.

5. Social Media Adds a Feedback Loop

A headline leaves the newsroom and enters social platforms. It becomes a shortened post, a clipped video, a thumbnail, and a comment thread. Audience reactions then influence subsequent exposure.

Editorial framing
      |
      v
Social distribution
      |
      v
Comments, shares, watch time
      |
      v
Ranking and recommendation
      |
      +------> Further exposure

Under some conditions, engagement-based ranking can amplify emotionally provocative or hostile content. But amplification is not the same as proven long-term persuasion.

Experiments published in Science in 2023 found that replacing algorithmic Facebook and Instagram feeds with chronological ones changed content exposure without significant changes in measured political attitudes over the study period. This is a useful reminder to distinguish mechanisms, observations, and causal claims.

6. National Identity and the Construction of Outsiders

National identity is not inherently discriminatory. But news narratives can reinforce exclusion when they divide society into legitimate insiders and threatening outsiders.

In coverage of migration or protests, three distinctions matter:

Question	Responsible distinction
Who committed a crime?	Individual responsibility versus collective identity
What happened at a protest?	Peaceful participation versus specific violent acts
What does a nationality explain?	Relevant verified context versus unsupported association

Journalism should neither hide uncomfortable facts nor turn human beings into stereotypes.

7. Ground News: A Useful but Limited Response

Ground News, founded in Canada by engineers Harleen Kaur and Sukh Singh, compares coverage across news outlets. It highlights differences in political orientation, uneven coverage (Blindspot), source reliability assessments, and media ownership.

It draws on external rating organizations including AllSides, Ad Fontes Media, and Media Bias/Fact Check.

This gives readers a way to compare sources instead of relying on one feed. But outlet-level political ratings do not fact-check individual articles. Nor do they reliably identify misleading image selection, dehumanizing language, or missing social context.

Ground News helps inspect published outputs. The harder challenge is auditing how those outputs were produced.

8. What Software Engineering Can Contribute

The comparison with software engineering is useful if we treat it as an analogy, not a literal equivalence:

Software engineering	Media accountability
Requirements	Editorial standards
Quality assurance	Fact-checking and review
Observability	Source and decision traceability
Change history	Headline revisions and corrections
Incident response	Corrections and public explanations
Governance	Editorial responsibility and oversight
Performance metrics	Reach, trust, accuracy, and public value

Consider editorial observability: retaining evidence for major claims, recording the provenance and context of photographs, and making substantive corrections visible.

A hypothetical publishing record could look like this:

article:
  headline: "Protest in Santiago"
  sources:
    - type: official_record
      verified: true
    - type: eyewitness
      verified: true
  media:
    provenance: verified
    context_review: completed
  editorial:
    fact_check: completed
    corrections_visible: true

This schema is illustrative, not a recognized industry standard. Such metadata cannot certify impartiality. It could, however, support more rigorous review and audits while protecting confidential sources.

9. Governance Is Already Evolving

The EU's Digital Services Act requires very large online platforms to assess and mitigate certain systemic risks, including risks to fundamental rights and civic discourse.

In Chile, Law 18.838 establishes a television-regulation framework addressing human dignity and pluralism. Its scope is not identical to regulation of online platforms.

Researchers are also studying value-aware news recommendation systems: ranking approaches that consider journalistic values alongside immediate relevance or engagement.

None of these offers a universal algorithm for truth. They do show that information quality must be addressed through system design, governance, and human judgment together.

10. When Every Component Succeeds but Society Loses

Imagine a newsroom where reporters are rewarded for speed, editors for audience growth, social teams for shares, and distribution algorithms for retention.

Everyone may be following the rules. Yet the combined system can reward sensationalism over context.

Engineers recognize the pattern: local optimization does not guarantee a desirable system-level outcome.

Fixing it requires more than asking individual journalists to be ethical. It requires examining incentives, workflows, metrics, review processes, and the effects of distribution.

Conclusion: What Are We Optimizing?

Digital news is not simply journalism delivered through software. It is a sociotechnical system that helps construct the public's picture of reality.

That system can expose injustice, support democratic debate, and inform communities. It can also reinforce fear, stereotypes, and hostility when its incentives and editorial practices favor those outcomes.

A political-bias label alone will not solve this. Neither will a fact-check badge or a supposedly neutral recommendation algorithm.

We need to understand how the system works, make important decisions traceable, and define success more carefully.

If a news platform maximizes engagement while undermining public understanding, is it succeeding or failing?

That question belongs to journalists, editors, designers, platform operators, regulators, and software engineers alike.

References and Further Reading

McCombs, M. E., & Shaw, D. L. (1972). The Agenda-Setting Function of Mass Media. Public Opinion Quarterly.
Entman, R. M. (1993). Framing: Toward Clarification of a Fractured Paradigm. Journal of Communication.
Cohen, S. (1972). Folk Devils and Moral Panics.
Gerbner, G., & Gross, L. (1976). Living with Television: The Violence Profile. Journal of Communication.
Reuters Institute. Digital News Report 2026.
Popularity-driven Metrics: Audience Analytics and Shifting Opinion Power to Digital Platforms (2023). Journalism Studies.
How Do Social Media Feed Algorithms Affect Attitudes and Behavior? (2023). Science.
Where Are the Values? A Systematic Literature Review on News Recommender Systems (2024). ACM.
Ground News.
European Commission — Digital Services Act.
Reuters Institute — From Guidelines to Architecture: AI Governance in Newsrooms.

This article examines potential mechanisms and documented research, not a claim that all media outlets deliberately manipulate audiences or that algorithms determine individual beliefs.

The Buy Button Is the Easy Part: The Hidden World of E-Commerce in 2026

Krlz — Sun, 25 Oct 2026 17:03:59 +0000

Imagine an online store with a beautiful product page. A shopper clicks Buy Now. It feels like one action.

Behind the monitor, imagine a factory staffed by hundreds of tiny, overworked gnomes. One checks stock. Another calls a bank. Another argues with customs. One is trying to print a shipping label; another is shouting that the food batch has been recalled. The security gnome suspects the coupon is fraudulent. The tax gnome wants to know where the buyer lives. And a very nervous gnome is asking whether the payment actually went through.

The customer sees a spinner.

An online purchase is not a button. It is a promise coordinated across organizations that do not share a database, a clock, a legal system, or even a definition of success.

In 2026, AI can generate the storefront in hours. It cannot make the supply chain, financial ledger, product law, or incident response disappear.

Scope: Global patterns, with examples from the EU, US, Latin America, and cross-border trade. Laws differ by product, seller location, buyer destination, fulfillment route, and business model. This is an engineering and business primer, not jurisdiction-specific legal advice. The stories below are illustrative scenarios, not documented incidents.

1. Your product chooses your architecture

Two shops may use the same checkout and have radically different businesses.

What you sell	The hidden difficulty	What software must remember
Fashion	Size exchanges, seasonal stock, returns	Variant-level SKUs, reservations, reverse logistics
Electronics	Serial numbers, warranties, batteries, recalls	Unit traceability, RMA, restricted shipping
Packaged food	Allergens, expiry, imported ingredients	Lots, FEFO, labeling, quarantine, recall
Refrigerated food	Time and temperature	Cold-chain events, delivery windows, spoilage
Cosmetics	Ingredients and market-specific rules	Claims, registration or notification where required
Digital goods	Fraud, licenses, territorial rights	Entitlements, activation, revocation
Marketplace	Many sellers, one customer payment	Seller onboarding, commissions, settlement ledger
Subscriptions	Renewals, cancellations, payment failures	Mandates, billing cycles, dunning, consent

Scene: The T-shirt that existed but could not be sold. A warehouse has 80 shirts. The site confidently displays “In stock.” Unfortunately, all 80 are size XL, while the buyer wants M. The inventory count is correct; the domain model is wrong.

The first lesson is not about databases. It is about understanding what a sellable unit actually means.

2. A product can be physically present and legally unsellable

Picture a merchant sourcing specialty coffee from one country and selling it in another. The cartons arrive. The website is ready. But importing, storing, labeling, and selling are distinct permissions and obligations.

In the United States, the FDA explains that food importers are responsible for compliant, safe, properly labeled food, and relevant facilities and shipments may face registration, prior-notice, verification, and inspection requirements. FDA does not simply “pre-approve” every food importer or product. FDA guidance.

In the European Union, the General Product Safety Regulation applies to many non-food consumer products sold online and offline, while food has its own extensive legal framework. The GPSR has applied since December 2024. EU Council overview.

In Latin America, sanitary registration or authorization, labeling, importer responsibilities, invoicing, and consumer rules vary by country. A product approved for one market is not automatically approved for another.

Therefore quantity > 0 is not a safe definition of availability:

Physical inventory
  ├─ in transit
  ├─ received, pending inspection
  ├─ quarantined / recalled
  ├─ legally cleared, available
  ├─ reserved for orders
  ├─ picked / dispatched
  └─ expired / damaged

For food, keep lotId, expiry, allergens, supplier, storage conditions, and the connection between shipped lots and customers. FEFO (first-expiring, first-out) can matter more than FIFO (first-in, first-out).

Scene: The recall email. A supplier reports contamination in lot K-482. The business needs to identify which customers received it. If fulfillment only recorded the product SKU, not the shipped lot, the team may know what was sold but not to whom the risky units went.

This is why compliance changes the data model, not just the terms-and-conditions page.

3. Cross-border e-commerce: the border is part of checkout

Suppose a seller in São Paulo ships to Berlin, New York, and Mexico City. The same product can have different duties, indirect taxes, labeling requirements, returns expectations, and restrictions at each destination.

A global commerce model must distinguish:

Seller of record: Who contracts with the buyer?
Importer of record: Who is responsible for import formalities?
Merchant of record: Who accepts payment and assumes associated obligations?
Incoterms / delivery terms: Who bears shipping costs and risks at each stage?
Tax jurisdiction: Where does VAT, GST, sales tax, or a similar obligation arise?
Product jurisdiction: Is this item legally marketable at the destination?

These roles can overlap, but they are not interchangeable.

The EU's OSS/IOSS mechanisms simplify certain cross-border VAT reporting. In September 2026 the European Commission reported more than €125 billion collected through its e-commerce VAT schemes over five years. European Commission.

The EU also introduced major 2026 customs changes affecting low-value e-commerce imports, with additional reforms scheduled later. A price engine that assumes last year's import threshold can become a financial liability. EU customs reform.

In the US, sales-tax obligations depend on states and nexus rules; marketplaces may have facilitator responsibilities. Across the world, tax and customs rules must be modeled as versioned, jurisdiction-dependent policies, not a single hardcoded percentage.

Scene: Free shipping wasn't free. The store offers a global flat rate. A heavy parcel crosses a customs threshold and requires special handling. The conversion dashboard celebrates; the margin dashboard quietly catches fire.

4. Revenue is not margin, and a payment is not cash

Consider a hypothetical $100 order. The seller might owe consumption tax, pay for the item, fund shipping, pay a payment processor, acquire the customer through ads, and later handle a return. The merchant may not receive settlement until days after the order.

Contribution per order ≈
  net sales revenue (excluding applicable pass-through taxes)
  − landed product cost
  − payment and platform fees
  − packaging and fulfillment
  − shipping subsidy
  − expected refunds / returns / fraud losses
  − attributable acquisition cost

This is contribution, not accounting profit. Fixed overhead, financing, income taxes, and other items remain.

The CFO cares about cash conversion; marketing watches CAC and conversion; operations watches stockouts and returns; engineering watches checkout reliability. These metrics describe the same system from different angles.

Scene: The record-breaking loss. A company doubles sales with aggressive discounts and free returns. Revenue rises; contribution falls. The software did exactly what it was told. The commercial assumptions were the bug.

5. The cart is a wish; the order is a commitment

The words cart, quote, order, payment, shipment, and refund describe different states and responsibilities.

sequenceDiagram
  actor Customer
  participant Checkout
  participant Stock as Inventory
  participant PSP as Payment provider
  participant Orders
  participant Warehouse
  Customer->>Checkout: Buy
  Checkout->>Stock: Reserve units (with expiry)
  Stock-->>Checkout: Reservation confirmed
  Checkout->>Orders: Create pending order
  Checkout->>PSP: Create payment attempt
  PSP-->>Customer: Hosted payment flow
  PSP-->>Checkout: Signed webhook
  Checkout->>PSP: Verify payment status
  Checkout->>Orders: Confirm once (idempotent)
  Orders->>Warehouse: Release for fulfillment

The customer's browser returning to a success page is not proof of payment. The backend must verify authoritative payment status, amount, currency, and order identity. See OWASP payment integration guidance.

Scene: The spinner that cost $200. A customer clicks Pay twice. The first response times out; the bank approved the charge. The second click creates another charge. You now have two payment attempts, one intended purchase, and a support ticket.

Use idempotency keys, durable operation records, uniqueness constraints, and reconciliation. Exactly-once delivery is not something you should casually assume from an HTTP request or message broker.

6. The last item: where concurrency becomes customer service

Two customers simultaneously buy the final pair of shoes. Both browsers previously read available = 1.

Naively reading, then decrementing, allows overselling. A reservation should be atomic, constrained by available stock, and expire if checkout is abandoned. The exact mechanism might be a conditional SQL update, locking, or a dedicated inventory service.

But physical stock is messier than database stock: a warehouse worker can damage an item, a shop can sell it offline, or a return can be unsellable. A robust model distinguishes on-hand, reserved, allocated, damaged, and available-to-promise quantities.

The interesting design question is not “Can Redis make this faster?” It is “Which system is authoritative, and how does it recover when reality disagrees?”

7. Sagas: a distributed transaction is a business story

A saga coordinates multiple local transactions when one atomic database transaction cannot cover the whole workflow. A coordinator may orchestrate the steps, or services may react to events. Both approaches trade simplicity for flexibility and require careful state management. Microsoft's saga pattern.

Scene: The order that cannot be un-shipped. The customer pays, the warehouse dispatches, and then the seller learns the item was recalled. You cannot roll back a truck with ROLLBACK;. You need a new process: stop delivery if possible, contact the customer, arrange a return or recall, refund appropriately, and preserve the audit trail.

A refund is not the inverse of history. It is a new financial event. A shipment recall is not an inverse SQL operation. Compensation is a domain action, sometimes requiring humans.

Failure	Sensible recovery
Stock reservation fails	Do not initiate payment; explain unavailability
Payment definitively declined	Release reservation and close attempt
Payment outcome unknown	Query provider, wait for verified events, reconcile
Shipment creation fails after payment	Retry safely, change carrier, or initiate exception workflow
Product recalled after dispatch	Trace affected shipments, initiate recall and customer response

Don't introduce a saga because the architecture diagram looks impressive. Introduce it when real transactional boundaries and business recovery requirements justify the complexity.

8. Circuit breakers protect services, not business truth

A timeout bounds waiting. Retries with exponential backoff and jitter help with transient failures. A circuit breaker stops hammering an unhealthy dependency. A bulkhead limits how much of your system one failing dependency can consume.

None of these patterns can tell you whether an ambiguous card charge actually succeeded.

Combine resilience mechanisms with verified webhooks, deduplication, transactional outbox where needed, dead-letter handling, audit trails, and reconciliation. OWASP emphasizes signature verification, replay protection, idempotent handlers, and safe treatment of out-of-order events. Webhook Security Cheat Sheet.

Scene: The helpful retry storm. A shipping API slows down. Every worker retries immediately. Traffic multiplies, the provider slows further, and unrelated checkouts begin to time out. The system wasn't attacked; it attacked itself.

9. Security means defending commercial invariants

TLS and authentication are the beginning, not the end. Think about:

Price tampering: the browser must never define the authoritative total.
Broken object-level authorization: customer A must not see customer B's orders or addresses.
Coupon abuse: promotions need transactional eligibility and redemption limits.
Webhook forgery/replay: external notifications need verified provenance and idempotent effects.
Credential stuffing: rate limiting, bot defenses, and appropriate MFA.
Sensitive data: minimize collection, control retention, encrypt appropriately, and restrict access.
Card data: hosted/tokenized payment flows can reduce PCI DSS exposure, but integration and compliance scope still require assessment.

Privacy requirements differ internationally: GDPR in the EU, a patchwork of federal/state rules in the US, LGPD in Brazil, and other national frameworks. Design for consent or other lawful bases where relevant, data subject rights, retention, breach response, and cross-border transfers—not just a cookie banner.

10. Consumer protection and returns are product features

A returns policy is not just a paragraph in the footer. It requires eligibility rules, labels, warehouse inspection, replacement or refund decisions, inventory disposition, tax adjustments, and support communication.

The EU has distance-selling consumer protections and platform obligations; the US has a different mix of federal and state consumer rules; other countries have their own withdrawal, warranty, and refund frameworks. European Commission e-commerce overview.

Scene: The refund button that does nothing. Support marks an order REFUNDED. Finance sees no corresponding processor transaction. The customer sees no money. A status label is not a financial operation.

Model requested, approved, submitted, settled, and failed refund states when the provider supports those distinctions. Reconcile against the payment processor and settlement records.

11. Marketplaces are not just stores with more products

A marketplace introduces multiple parties: buyer, seller, platform, payment provider, carrier, and sometimes tax authorities. The platform may need identity verification, seller eligibility checks, payout schedules, reserves, dispute management, and a ledger that explains who owns each cent.

Scene: One order, three sellers. A buyer pays $120 for items from three merchants. One cancels, one ships late, and one disputes a fee. A single orders.total field cannot explain the resulting refunds, commissions, shipping adjustments, and payouts.

This is where double-entry-style financial ledgers, explicit obligations, and durable event histories become valuable. A database table called transactions is not automatically an accounting system.

12. Build or buy? The AI-era trap

In 2026, AI-assisted development can generate a storefront, cart, admin panel, and integration scaffolding quickly. It cannot validate supplier reliability, write your return policy for every market, own the on-call rotation, or prove that your ledger reconciles.

For many businesses, Shopify, WooCommerce, or another maintained commerce platform is a better starting point than a custom distributed system. Build differentiated components when the business genuinely requires unusual inventory, pricing, fulfillment, marketplace settlement, or integrations.

Stage	Default posture	Reason to evolve
Test demand	Hosted platform and proven payment integrations	Need evidence that anyone wants the product
Operational complexity	Modular monolith, relational DB, background jobs	Workflows exceed platform capabilities
Multiple independent domains	Selective services, messaging, sagas, tracing	Independent ownership and scaling justify overhead
Global platform	Regional compliance, multi-warehouse, ledger, governance	Organization and business complexity demand it

There is no magic customer-count threshold for microservices. Complexity is earned by the problem, not awarded by traffic forecasts.

13. What should a healthy commerce system measure?

Signal	Why it matters
Checkout conversion and abandonment	Commercial friction
p95 checkout/payment latency	Repeated clicks and failed conversions
Oversell / reservation conflicts	Broken promises
Paid but unconfirmed orders	Financial and customer risk
Unreconciled settlements	Cash and accounting uncertainty
Orders past promised dispatch date	Fulfillment quality
Return rate and contribution margin	Actual unit economics
Recall traceability coverage	Ability to protect customers

Correlate cartId, quoteId, orderId, paymentAttemptId, shipmentId, and, where relevant, lotId. Logs must avoid unnecessary personal and payment data.

14. The tabletop exercise that reveals the architecture

Try this with engineering, finance, operations, and support:

A customer in Germany buys the last two bags of imported coffee from a cross-border seller. The payment provider times out but later confirms the charge. The webhook arrives twice. The warehouse then quarantines the lot. A tax document has been issued. The customer demands a refund. Who owns the decision, which systems must change, and what evidence proves that the customer got their money back?

A good answer names authoritative states, legal and operational responsibilities, idempotency, compensation, reconciliation, customer communication, and a human owner. “We use Kafka” is not an answer.

Closing: the real product begins after Pay

An online purchase is a promise made by a business and implemented through software. That promise has to survive imperfect data, failed dependencies, customs borders, product restrictions, accounting realities, and human mistakes.

The cheerful Buy Now button is easy to draw. The gnomes behind the screen are doing the real work.

Primary sources and further reading

All scenes are fictional examples designed to illustrate recurring business and engineering failure modes.

Enterprise Software in 2026: From First Conversation to Production Ownership

Krlz — Thu, 22 Oct 2026 02:21:01 +0000

Shipping code is an event. Owning software is a continuing obligation.

A software project can pass every sprint demo and still fail its customer. Perhaps nobody defined what available meant. Perhaps the vendor delivered source code but not infrastructure access. Perhaps AI generated features faster than the team could verify them. Perhaps an impressive dashboard measured deployments while customers waited hours for business-critical jobs.

This article follows one fictional enterprise project from initial discovery through procurement, negotiation, implementation, launch, incidents, and handover. Its example numbers, targets, and conversations are illustrative proposals, not industry benchmarks or legal advice. Along the way, we'll connect the decisions to published guidance from DORA, NIST, OWASP, and Google SRE. No prior familiarity with enterprise-process jargon is assumed: terms are explained when they first matter, with a concrete example of what a team actually does.

How to read this guide

Each phase answers five practical questions: Why are we doing this? Who decides? What do we produce? How do we know it worked? Where can AI help without becoming the decision-maker? The project is fictional, so its numerical targets are examples of negotiated choices, not universal best practices. If you are a developer, follow the engineering decisions; if you are a product or procurement lead, pay attention to who accepts risk and signs off on results.

A validation gate is simply a checkpoint before the next costly or risky step. It is not necessarily a meeting or an approval committee: it can be a passing automated test, a customer confirming a prototype, or an operations engineer demonstrating a successful restore.

The case: a logistics platform with real consequences

Northstar Logistics operates 2,000 vehicles across several countries. Its operations staff coordinate shipments through spreadsheets, email, and a legacy application. The company hires Harbor Software, an external development partner, to build a shipment visibility and exception-management platform.

Stakeholders:

Role	Accountable for
Executive sponsor	Funding and business outcome
Product owner (Northstar)	Scope, priorities, acceptance
Technical owner (Northstar)	Architecture, access, continuity
Delivery lead (Harbor)	Delivery plan, staffing, risk communication
Security/data owners	Security controls, privacy, retention
SRE/on-call owner	Production response and recovery
End users	Workflow feedback and UAT

A stakeholder is anyone affected by the project or empowered to make a decision. An accountable owner is the person who must make sure an outcome happens, even if others do the work. UAT (user acceptance testing) means real users trying representative workflows to decide whether the product meets their needs—not merely whether the code runs.

Business hypothesis: reduce the median time to identify and assign a delayed shipment from 45 minutes to 15 minutes within 90 days of rollout, without increasing false alerts or manual workload.

Notice that the objective is not “build a dashboard.” A dashboard is one possible intervention. The outcome is faster, trustworthy decisions.

The organizational question: management is not ownership

Before Northstar negotiates a feature, it must decide who can make which decisions. A delivery manager can keep a schedule on track without understanding the production system. An architect can understand every service without having authority to change priorities. Neither is a substitute for the other.

Project management coordinates a time-bound initiative: commitments, dependencies, budgets, and delivery risks. Product management decides which customer problems deserve investment and measures whether solving them creates value. Engineering management develops the team's capacity to deliver sustainably: hiring, coaching, staffing, and working conditions. Technical ownership means named people can explain design choices, approve or implement changes, and maintain the system over time. Service ownership adds operational accountability: someone knows when a service is failing and can lead its recovery. Executive governance determines which business risks and investments the organization will accept.

These are responsibilities, not necessarily six job titles. A small company may combine roles; a regulated enterprise may separate them. The critical requirement is to make decision rights explicit.

What modern management research actually suggests

DORA's 2024 research associates stable priorities, user focus, and transformational leadership with stronger outcomes; it also warns that platform initiatives can introduce delivery trade-offs. Its 2025 AI research argues that AI amplifies existing organizational strengths and weaknesses rather than replacing them. These are research findings and associations, not a guarantee that adopting one management framework causes success.

DORA's guidance on loosely coupled teams emphasizes teams that can test, change, and deploy with fewer cross-team dependencies. Loosely coupled does not mean isolated: it means teams agree on clear interfaces so that routine work does not require constant permission or coordination.

The Team Topologies model offers a useful vocabulary: a stream-aligned team owns a flow of customer value; a platform team supplies reusable internal capabilities; an enabling team helps others learn specialized skills; and a complicated-subsystem team concentrates scarce expertise. These are design options, not an org chart to copy blindly.

A management failure in the Northstar story

Two months into development, the vendor's delivery manager reports: “We're green: 85% of tickets completed.” The operations director responds: “Dispatchers still cannot trust shipment arrival estimates.” The technical owner adds: “The event processor has no replay procedure, and only Harbor can deploy it.”

All three statements can be true. The project is tracking output (tickets), while the business needs an outcome (trustworthy decisions), and engineering needs operability (the ability to diagnose and restore the system).

A better weekly review shows all three:

View	Question	Example signal	Decision owner
Product	Are dispatchers better off?	% of late shipments detected before escalation	Northstar product owner
Delivery	Are changes flowing predictably?	Change lead time and blocked work age	Harbor delivery lead + engineering lead
Technical	Can we change the system safely?	Contract-test pass rate; independent deploy drill	Northstar technical owner
Operations	Can we recover?	Restore drill outcome and time	Named service owner
Commercial	Are we buying the right result?	Cost against accepted business milestones	Sponsor + procurement

The signals are examples to instrument, not benchmark targets. Teams should establish a baseline before deciding what counts as improvement.

A negotiation about ownership, not just deadlines

Vendor delivery lead: “We can meet the date if we keep infrastructure under our account and hand it over after launch.”

Customer technical owner: “That reduces your setup time, but it creates a dependency we cannot accept for a critical service.”

Product owner: “What does changing that cost, and does it delay the pilot?”

Vendor delivery lead: “Provisioning in your account adds two weeks. We can still pilot with a reduced reporting scope.”

Executive sponsor: “Agreed, provided we see an independent deployment and restore demonstration before production acceptance.”

This is a trade-off negotiation: the sponsor chooses between time, scope, and long-term operational control. A useful record is a one-page decision with options, consequences, decision-maker, deadline, and a test proving the choice worked. The vendor is still responsible for delivery, but the customer is not required to depend on the vendor forever.

Decision rights: use a DACI, not a maze of approvals

DACI is a lightweight decision framework: Driver coordinates the decision, Approver makes the final call, Contributors provide expertise, and Informed stakeholders receive the outcome. It differs from a RACI responsibility chart (Responsible, Accountable, Consulted, Informed), which is often used to describe ongoing work rather than one discrete decision.

Decision	Driver	Approver	Contributors	Evidence required
Prioritize shipment exception alerts	Product manager	Product owner	Dispatchers, engineers	Workflow trial and baseline
Choose event processing design	Tech lead	Technical owner	Security, operations, vendor	ADR and failure-mode test
Accept lower pilot scope	Delivery lead	Sponsor + product owner	Finance, tech lead	Revised SOW and acceptance tests
Release critical service	Release coordinator	Authorized service owner	QA, security, on-call	Passing gates, rollback rehearsal
Accept contractual SLA exception	Account manager	Contractually authorized business owner	Legal, operations	Impact, remedy, expiry date

The table is illustrative. Real approval authority must match company policy and contracts. Escalation should occur when a decision crosses an agreed boundary (budget, customer impact, compliance, architecture), not whenever an engineer changes a line of code.

Where AI belongs in modern management

AI can draft meeting summaries, identify conflicting requirements, prepare options for negotiation, flag stale risks, cluster support tickets, and generate proposed ADRs. It can also help explain technical consequences to nontechnical stakeholders. But a generated summary is not a signed decision, a predicted delivery date is not a commitment, and a model's preferred architecture is not organizational authority.

Northstar sets a simple policy: AI-generated decisions must cite their inputs, distinguish facts from suggestions, identify a human approver, and remain reviewable. Sensitive contract terms or customer data are not sent to tools without approved data-handling controls.

To test whether AI helps rather than adds bureaucracy, the team measures: decision latency (time from an identified decision to an approved choice), decision reversals (choices reopened due to missing evidence), meeting-to-action completion (actions completed by the agreed date), and review correction rate (AI drafts requiring material correction). Measure these at team or workflow level, not as a leaderboard of individuals. Compare similar work before and after adoption, and inspect adverse effects such as missed context or extra review time.

Validate the management model itself

At the end of the pilot, ask five practical questions: Can a dispatcher demonstrate business improvement? Can the team deploy a small change without a cross-company approval chain? Can the customer restore the service without vendor credentials? Is there a named human who can accept an operational risk? Can the organization explain which decisions AI supported and who approved them?

If any answer is no, the issue may be organizational rather than a missing feature. A project can have excellent ceremonies and still lack meaningful ownership.

Phase 0 — Qualify the problem before selling a solution

The vendor runs discovery interviews with dispatchers, operations managers, security, and the legacy-system team. It maps a shipment's journey and records where data is missing or delayed.

Sample conversation:

Customer: We need live tracking for every vehicle.

Engineer: What decision becomes possible with live tracking that isn't possible today?

Customer: Dispatchers need to react before a delivery misses its window.

Engineer: Would a two-minute update plus a reliable delay alert meet that need? Continuous streaming changes mobile connectivity, storage, and support costs.

Customer: Let's test it with dispatchers rather than assume.

An artifact is a durable piece of project evidence: a document, recorded decision, prototype, test report, or dashboard. A baseline is the measured starting point against which later improvement is compared. An assumptions register lists claims the team has not yet verified, such as “the carrier API can handle 100 requests per second.”

Artifacts: problem statement, current-state workflow, stakeholder map, data inventory, baseline metrics, assumptions register, risks, and a one-page business case.

Validation gate: sponsor and product owner confirm the problem, a measurable outcome, and the baseline measurement method. Run a small user observation or prototype before committing to architecture.

AI contribution: transcribe approved interviews, cluster recurring pain points, draft process maps, identify contradictory statements. Human check: verify every consequential finding against recordings, participants, or system evidence. Never send confidential interviews to an unapproved model.

Phase 1 — Negotiate scope, economics, and control

The parties choose a phased engagement instead of treating a fixed-price contract as a substitute for discovery.

Illustrative commercial proposal:

Discovery: two weeks, fixed fee, producing a validated backlog, risk register, and delivery estimate.
Pilot: eight weeks, limited to 100 vehicles and two dispatcher teams; price and scope capped.
Expansion: funded after pilot acceptance, with explicit change control.
Support: separate operational agreement defining hours, severity, escalation, and service credits if applicable.

Sample negotiation:

Customer procurement: We need a fixed deadline and fixed cost for all countries.

Vendor lead: We can fix the pilot budget and deadline. We cannot responsibly fix the full integration scope before inspecting the legacy interfaces. We propose a two-week discovery with an option to stop.

Customer CTO: We also need the ability to replace your team.

Vendor lead: Agreed. Repositories, infrastructure accounts, pipelines, documentation, and observability will live under your organization's control. We'll define an exit rehearsal as an acceptance condition.

Customer procurement: How do we handle new compliance requirements?

Vendor lead: We'll document their impact on scope, risk, cost, and schedule, and obtain written approval before changing the baseline.

A statement of work (SOW) spells out what the supplier will deliver, by when, and under what acceptance conditions. Scope is the agreed boundary of the work. Change control is how the parties decide whether a new request changes the price, timeline, or risk. IP (intellectual property) concerns rights to code, designs, and other deliverables; third-party licenses can limit how dependencies may be used or redistributed. An exit strategy makes it possible to switch providers without losing access or knowledge.

For example, “add customs integration for another country” is not automatically a small change just because the screen looks similar. The customer describes the business need; the supplier estimates integration, legal, testing, and support impacts; the authorized owners approve, defer, or trade it against existing scope. Negotiation should expose trade-offs, not disguise uncertainty as certainty.

Contract checklist: statement of work, deliverables, acceptance windows, change-request mechanism, IP ownership and third-party licensing, confidentiality, data processing, subcontractors, security incident notice, service/support responsibilities, termination assistance, source and infrastructure access, warranties, and dispute escalation. Legal counsel should adapt these terms to the jurisdiction.

Validation gate: both parties sign the scope baseline, assumptions, decision rights, acceptance method, and exit responsibilities. No one should confuse “code handed over” with “system operable independently.”

Phase 2 — Turn a business goal into testable specifications

Functional example

Story: As a dispatcher, I want delayed shipments ranked by urgency so I can assign interventions.

Acceptance criteria:

Given a shipment predicted to miss its delivery window by more than 20 minutes, when the forecast is updated, the shipment appears in the exception queue.
A dispatcher can acknowledge an alert and assign an owner.
Replayed telemetry does not create duplicate active alerts for the same shipment and rule version.
If location data is stale, the UI clearly shows its age rather than presenting it as current.
Every acknowledgment and assignment records actor, time, and shipment identifier.

Nonfunctional example

A functional requirement describes what the system does: “a dispatcher can assign an alert.” A nonfunctional requirement (NFR) describes how well or under what constraints it must work: speed, reliability, accessibility, security, or recoverability. An acceptance criterion is an observable condition that lets the customer say yes or no. In the example above, the stale-data warning is not decorative: it prevents a dispatcher from mistaking yesterday's location for a live position.

A percentile summarizes a distribution. If API latency at p95 is 400 milliseconds, about 95% of measured requests completed in 400 ms or less, under the specified test conditions; the slowest 5% may take longer. Averages alone can hide those slow experiences. RTO (recovery time objective) is the targeted time to restore a service after disruption; RPO (recovery point objective) is the maximum targeted amount of recent data that could be lost, expressed as time. Neither is a guarantee unless the recovery design and tests support it.

Concern	Proposed measurable requirement	Verification
API latency	p95 under 400 ms for selected reads at agreed load	Load test and production traces
Availability	99.9% monthly for defined customer-facing API	Synthetic checks plus request SLIs
Data freshness	95% of accepted telemetry reflected within 120 seconds	Event-to-visibility timestamps
Authorization	Users can access only permitted tenants and roles	Negative authorization tests
Recovery	RTO 2 hours; RPO 15 minutes for critical state	Restore and failover exercise
Auditability	Changes to assignments traceable to an actor	Audit log test
Accessibility	Target WCAG 2.2 AA for relevant web workflows	Automated and manual review

These are starting negotiation values, not promises that every system can or should meet. Define the population, exclusions, load profile, and measurement window before approving them.

Validation gate: product, engineering, security, and operations sign off on representative examples, failure behavior, data ownership, and measurable NFRs. Trace each critical requirement to a test or observable signal.

AI contribution: propose edge cases, convert approved requirements into draft Gherkin scenarios, review ambiguities. Human check: independently compare generated tests to the requirement; an AI can write a test that faithfully validates the wrong behavior.

Phase 3 — Architecture and risk decisions

The team chooses an incremental architecture: a telemetry ingestion adapter, event stream, shipment-state processor, alert rules service, operational API, and web UI. It deliberately avoids splitting every function into a microservice.

flowchart LR
  T[Vehicle telemetry] --> I[Ingestion adapter]
  I --> Q[Durable event stream]
  Q --> P[Shipment state processor]
  P --> D[(Operational data store)]
  P --> R[Alert rules]
  R --> D
  D --> A[API]
  A --> U[Dispatcher UI]
  P --> O[Metrics and traces]
  A --> O

An architecture decision record (ADR) is a short explanation of a significant technical choice, its alternatives, and its consequences. It helps the next engineer understand why the system looks this way. A durable event stream retains messages so processors can recover or replay them. Idempotency means processing the same business event twice has the same intended effect as processing it once. A dead-letter queue isolates messages that repeatedly fail so they can be inspected instead of blocking everything. Eventual consistency means different parts of the system may briefly disagree while updates propagate.

Imagine a vehicle losing connectivity, then uploading the same position twice. Without idempotency, the system could create two delay alerts. With a stable event identifier and deduplication rule, the second upload does not cause a second business action.

ADR-004 — Asynchronous telemetry processing

Context: connectivity is intermittent; messages may be duplicated or reordered.
Decision: durable events, explicit idempotency keys, bounded retries, dead-letter handling, and freshness indicators.
Alternatives: synchronous direct writes; batch imports.
Consequences: additional operational complexity, eventual consistency, replay and schema-evolution obligations.
Revisit when: volume, delay, or operational burden invalidates the assumptions.

Threat model: tenant isolation, forged telemetry, compromised API tokens, overprivileged service accounts, leaked location history, supply-chain compromise, and AI-agent access to production secrets.

Validation gate: architecture review checks failure modes, load estimates, security boundaries, ADR trade-offs, and a working vertical slice. A diagram alone is not evidence.

Phase 4 — Agree on how the team communicates

Communication is an engineering control when it preserves decisions and surfaces uncertainty. A cadence is the agreed frequency of communication. Async updates are written updates that do not require everyone in a meeting. A risk register is a living list of potential problems, their probability or impact, owners, and mitigation plans. A steering meeting is where sponsors resolve decisions the delivery team cannot make alone.

A useful status report does not merely say “80% done.” It states what was verified, what could prevent success, who must decide, and by when. Amber means attention is required; it does not mean failure.

Cadence	Participants	Output
Daily async update	Delivery team	Done / next / blocked / risk
Weekly product review	Product + engineering	Demo, acceptance, priority decisions
Weekly risk review	Delivery, technical and security owners	Updated risk register and mitigations
Architecture decision as needed	Relevant engineers + owner	ADR with alternatives and consequences
Monthly steering meeting	Sponsor + vendor leadership	Budget, outcomes, escalations, scope decisions
Incident bridge	On-call, incident commander, stakeholders	Timeline, mitigations, next update time

Example weekly update:

Status: Amber — telemetry integration

Completed: replay-safe ingestion prototype, 14 integration tests.

Evidence: duplicate events no longer create duplicate shipment-state transitions in the test environment.

Risk: partner API rate limit is undocumented; pilot throughput may be affected.

Decision needed by Thursday: authorize a partner load test or accept a lower initial fleet limit.

Owner: Northstar integration lead. Next update: Friday 15:00.

Validation gate: decisions have owners and deadlines; risks have mitigation or explicit acceptance. A green status without evidence is not a control.

Phase 5 — Build with AI, without outsourcing accountability

AI can help throughout the lifecycle, but different tasks require different permissions and verification. Here AI agent means software that can use tools and take multiple steps (for example, reading an issue, editing a branch, and running tests), not just a chat assistant answering a question. A human-in-the-loop control means an authorized person must review or approve a consequential action. A code owner is the designated reviewer responsible for a portion of the repository.

The central risk is verification debt: code, tests, and documents can be generated faster than the team can check their correctness. A polished AI summary is not evidence that an interviewee said something; a passing AI-written test is not evidence that the intended business rule was correct. Give agents the least permissions they need and preserve an audit trail of actions.

Stage	Useful AI work	Required human verification
Discovery	Interview synthesis, gap detection	Source-backed findings and user confirmation
Specifications	Edge cases, acceptance-test drafts	Product owner approves intended behavior
Architecture	Alternatives, failure scenarios	Engineers test assumptions and own ADRs
Coding	Scaffolding, refactoring, migrations	Code review, tests, security checks
Testing	Test generation, fuzz-case suggestions	Independent oracle and meaningful assertions
Operations	Incident summaries, query suggestions	On-call confirms diagnosis and commands
Reporting	Release-note and metric summaries	Validate against telemetry and change records

Example AI-agent policy:

agent_policy:
  approved_tools: [repository_reader, test_runner, issue_tracker]
  default_permissions: read_only
  allowed_changes: [feature_branch, pull_request]
  prohibited: [production_deploy, secret_read, permission_grants]
  required_checks:
    - human_code_owner_review
    - automated_tests
    - dependency_and_secret_scans
    - security_review_for_sensitive_changes
  audit:
    record_agent_identity: true
    record_tool_actions: true

This is a conceptual policy, not a vendor-specific enforceable configuration. Enforce permissions in the actual identity, repository, CI, and infrastructure systems. Treat retrieved documents, issue descriptions, and tool output as untrusted inputs to agents.

A useful AI evaluation compares similar work over time: cycle time, review burden, escaped defects, rework, and customer outcomes. Do not infer productivity from generated lines of code or number of prompts. Use matched tasks or staged pilots where possible; control for task complexity and team differences.

DORA's 2025 research reported widespread AI adoption and positive associations with throughput and product performance, while finding a negative association with delivery stability. That is a warning against equating faster code production with a healthier delivery system. DORA 2025.

OWASP SAMM's AI-assisted development guidance similarly emphasizes approved tools, scoped permissions, source and licensing policies, and deterministic verification beyond AI-based review: OWASP SAMM guidance.

Phase 6 — Define objective release gates

A quality gate is a condition that must pass before a change proceeds. CI/CD (continuous integration / continuous delivery or deployment) automates building, checking, and preparing or releasing changes. A pull request (PR) is a proposed code change reviewed before merging. A contract test checks that two components agree on their interface. A canary release exposes a new version to a small fraction of traffic first; a rollback returns to the previous version, while roll-forward fixes the issue in a new version. Artifact provenance records how a deployable package was built and from which source.

The team creates a Definition of Done for a feature and a stricter production release gate for a deployable change.

Feature done: reviewed acceptance criteria, passing relevant tests, observability included, documentation updated, no unapproved critical security findings, and product-owner acceptance for user-facing behavior.

Production gate:

Build is reproducible and artifacts have provenance.
Unit, integration, contract, and risk-relevant end-to-end tests pass.
Dependency, secrets, and static-security checks satisfy policy.
Performance checks meet the agreed load envelope.
Database migrations are forward/backward compatible or have a safe plan.
Feature flags, canary rollout, and rollback or roll-forward procedures are rehearsed.
Dashboards and alerts cover the new critical path.
Named owner accepts residual risks and authorizes release.

Failure example: the generated code passes unit tests but accidentally allows one tenant to query another tenant's shipments. The negative authorization suite fails. The pipeline blocks release even though the feature demo looks correct.

Validation gate: store the evidence in the PR, build, test report, and release record. Exceptions require a named approver, expiry date, mitigation, and follow-up issue.

NIST's Secure Software Development Framework provides a useful organizing model: prepare the organization, protect software, produce well-secured software, and respond to vulnerabilities.

Phase 7 — SLIs, SLOs, SLAs, and operational negotiation

An SLI (service level indicator) is the number measured in production, such as the percentage of successful requests. An SLO (service level objective) is the internal target for that indicator, such as 99.9% in 30 days. An SLA (service level agreement) is a customer-facing contractual promise that defines coverage, measurement, support, exclusions, and possibly remedies if commitments are missed. An SLO does not automatically become an SLA.

An error budget is the amount of unreliability allowed by an SLO. At 99.9% request success, the budget is 0.1% failed eligible requests over the chosen window. Teams can use that budget to decide whether to prioritize new features or reliability improvements. Sev-1 is a severity classification for a major incident; each organization must define its actual impact threshold. Acknowledgment time is how quickly someone responds to an incident report, not how quickly the system is fixed.

For the pilot, Northstar and Harbor propose:

Availability SLI: successful eligible API requests / all eligible API requests, with explicit rules for timeouts and excluded traffic.
Availability SLO: at least 99.9% over a rolling 30-day window.
Freshness SLI: share of accepted events visible to dispatchers within 120 seconds.
Freshness SLO: at least 95% over seven days.
Support SLA: severity-based response and escalation commitments, distinct from time-to-resolution promises.

For one million eligible requests in the SLO window, a 99.9% target allows 1,000 unsuccessful requests. If the system records 1,300, it misses the objective. A 99.9% time-based target corresponds to about 43.2 minutes of unavailability in 30 days, but request-based and time-based budgets are not interchangeable.

Example support negotiation:

Customer: We want all incidents fixed within one hour.

Operations lead: We can commit to a 15-minute acknowledgment for Sev-1 incidents with 24/7 coverage, but cannot guarantee every root cause is resolved in an hour. Let's separately define restoration targets, escalation, communication intervals, and service remedies.

Customer: What if we lose tracking during a carrier outage?

Operations lead: The system should mark the data stale, queue retries where possible, and report dependency impact. The contract needs to distinguish our controllable failures from upstream outages without hiding the user's experience.

Illustrative severity matrix:

Severity	Example	Acknowledgment target	Update cadence
Sev-1	Widespread loss of critical dispatch functionality	15 min, 24/7	Every 30 min
Sev-2	Major degradation with workaround	1 hour during support coverage	Every 2 hours
Sev-3	Limited issue	1 business day	Agreed in ticket

Do not copy these commitments into a contract without verifying staffing, monitoring, holidays, time zones, and actual ability to respond.

Error-budget policy: when the service exhausts its agreed budget, pause discretionary risky releases and prioritize reliability, with exceptions for urgent security and recovery work. Google's SRE error-budget policy example illustrates how to formalize that decision without using reliability as a punishment.

Phase 8 — Measure the entire system, not just the developers

Metrics are useful only when they support decisions. A KPI (key performance indicator) is a selected metric tied to a goal, such as reducing time to assign delayed shipments. Instrumentation is the code or configuration that records events, logs, traces, and metrics. A trace follows a request through components; a log records an event; a metric aggregates a measurement over time. DORA is a research program that studies software-delivery performance and provides operational metrics; its measures are not individual developer scorecards.

Create a measurement plan before the pilot. Every metric needs a definition, event source, owner, review cadence, and response when it moves.

Layer	Metric	Formula or method	Data source	Decision it informs
Business	Median alert-to-assignment time	Median(assignment time − actionable alert time)	Audit events	Does the product improve dispatch?
Business	False-alert rate	False alerts / reviewed alerts	Labeled review sample	Are we creating noise?
Product	Weekly active dispatchers	Distinct users completing core action	Privacy-aware events	Is the workflow adopted?
Delivery	Change lead time	Commit-to-production elapsed time	Git + deployment records	Where is delivery delayed?
Delivery	Deployment frequency	Production deployments per period	CI/CD	Can changes move safely?
Delivery	Change fail rate	Deployments requiring immediate intervention / deployments	Incidents + deployments	Are releases destabilizing service?
Delivery	Failed deployment recovery time	Time to recover from a failed deployment	Incident timeline	How quickly can we recover?
Delivery	Deployment rework rate	Unplanned incident-related deployments / deployments	Deployment classifications	How much emergency rework occurs?
Reliability	API success ratio	Successful eligible requests / eligible requests	Gateway telemetry	Is the SLO met?
Reliability	p95 latency	95th percentile of eligible request durations	Traces/metrics	Is the experience responsive?
Data	Duplicate effect rate	Duplicate state changes / replayed or duplicate messages	Processor audit	Is idempotency working?
Security	Critical finding age	Days since confirmed finding opened	Vulnerability tracker	Are critical risks being reduced?
Cost	Cost per tracked vehicle-day	Allocated service spend / active vehicle-days	Cloud billing + usage	Does scaling make economic sense?
AI	AI-assisted rework rate	AI-assisted changes requiring rework / AI-assisted changes	PR classification + issues	Is AI creating downstream burden?

DORA now defines five software-delivery performance metrics, including deployment rework rate. Use its current definitions rather than an outdated four-metric slide: DORA metrics guide.

Example instrumentation

shipment_alert_created{shipment_id, rule_version, timestamp}
shipment_alert_assigned{shipment_id, actor_id, timestamp}
telemetry_accepted{event_id, source, timestamp}
telemetry_visible{event_id, timestamp}
deployment_completed{service, version, timestamp}
incident_opened{severity, service, timestamp}
incident_restored{incident_id, timestamp}

This is an event schema illustration, not a recommendation to put shipment IDs, event IDs, or actor IDs into Prometheus metric labels. High-cardinality identifiers belong in appropriately protected logs, traces, or event stores; aggregate metrics should use bounded labels. Protect personal and location data with access controls and retention limits.

How to validate a metric

A measurement window is the period being analyzed. A denominator is the population included in a rate; changing it can make a metric look better without improving reality. p90 means 90% of observations are at or below that value. High-cardinality labels are labels with very many distinct values (for example, one per shipment); putting them on time-series metrics can overwhelm monitoring systems.

Worked example: Suppose 80 of 100 reviewed alerts were actionable and 20 were false alarms. The false-alert rate is 20/100 = 20%, provided the sample is representative. If the team quietly excludes difficult cases, that number becomes misleading. Suppose assignment times are 5, 10, 15, 20, and 120 minutes. The median is 15 minutes, but the 120-minute outlier still matters for operations; track a tail percentile too.

For alert-to-assignment time, verify the start event represents an actionable alert, not a background recalculation; use consistent clocks; exclude test data; inspect missing assignments; compare median and p90; segment by region and shift; and sample raw records manually. Without these checks, a falling median might simply mean the team stopped recording difficult cases.

For AI-assisted changes, establish a baseline and compare review time, escaped defects, change fail rate, and outcomes. Label changes consistently, note mixed human/AI work, and avoid ranking individual engineers. An observational improvement is not proof that AI caused it.

Phase 9 — Run a pilot and decide with evidence

A pilot is a limited real-world rollout designed to test assumptions before broad deployment. A go/no-go decision is an explicit choice to proceed, delay, or stop based on agreed evidence. A control group, where feasible, is a comparable group not yet receiving the change; it helps distinguish the product's effect from unrelated improvements. A pilot without predetermined success conditions can easily become a demonstration where every result is interpreted as success.

Pilot plan: 100 vehicles, two teams, four weeks of live operation after readiness approval. Compare against a baseline and, where feasible, a similar team not yet using the new workflow.

Illustrative pilot results:

Measure	Baseline	Pilot	Interpretation
Median alert-to-assignment	45 min	18 min	Better, but short of 15-min target
p90 alert-to-assignment	110 min	75 min	Tail remains problematic
False-alert rate	12%	9%	Improvement; review sample quality
API availability	Not applicable	99.95%	Above proposed 99.9% SLO
Freshness within 120 sec	Not applicable	93%	Below proposed 95% SLO
Dispatcher satisfaction	3.0/5	4.0/5	Positive but survey bias possible

Steering committee decision: do not declare complete success based on one favorable number. Extend the pilot for two weeks, prioritize freshness and p90 delays, and then reassess. The contract's acceptance criteria and change-control mechanism determine whether this is remediation within scope or new work.

Validation gate: documented go/no-go decision, evidence pack, residual risks, and named owner for every unresolved issue.

Phase 10 — Operate, respond, learn

At 09:12, telemetry ingestion falls behind after a partner sends a burst of messages.

Example incident communications:

09:20 — Initial notice: We are investigating delayed shipment updates affecting some dispatchers. Current location timestamps remain visible. Next update by 09:50.

09:42 — Progress: Ingestion backlog is elevated. We have reduced nonessential processing and are draining the queue. No evidence of lost accepted events so far; verification continues.

10:18 — Restoration: Processing delay has returned within the operational threshold. We will monitor recovery and publish a post-incident review within three business days.

A runbook is a tested operational procedure: how to recognize a problem, where to look, what actions are safe, and when to escalate. A postmortem (or post-incident review) examines how an incident happened and how the system can be improved. Observability is the ability to understand internal system behavior from its signals, rather than guessing from a green server-status light.

The postmortem documents impact, detection delay, timeline, contributing factors, what worked, and corrective actions. Avoid blaming individuals; focus on system improvements.

Example follow-up: add backlog-based autoscaling within tested limits, replay a production-like burst in staging, and introduce an alert on the freshness SLI rather than relying solely on CPU utilization.

Validation gate: run the new test, verify alerts fire, assign remediation owners, and confirm that the same failure mode is less likely or less damaging. Closing the incident ticket is not equivalent to closing the risk.

Phase 11 — Handover and the ownership test

Handover transfers practical responsibility, not just files. Infrastructure as code (IaC) means environments are defined and reproducible through versioned configuration. A restore exercise proves that backups can actually recover usable data. Operational independence means the customer can deploy, diagnose, recover, and make changes without hidden reliance on the supplier.

A mature handover is not a ZIP file and a farewell meeting. Northstar should be able to deploy, restore, diagnose, and evolve the system without depending on Harbor's undocumented knowledge.

Exit rehearsal: Northstar engineers, using their own identities, provision a nonproduction environment, deploy a release, rotate a secret, diagnose a simulated outage, restore data from backup, and make a small approved change. Harbor observes but does not operate the keyboard.

Handover evidence: repository and artifact ownership; infrastructure-as-code; architecture and ADRs; API/schema contracts; access and credential inventories; runbooks; dashboards; on-call routing; dependency/license inventory; backup restoration records; known risks; costs; and a transition support plan.

Validation gate: the customer performs the exit rehearsal successfully, with agreed exceptions tracked to resolution. Ownership becomes a demonstrated capability, not a contract adjective.

A reusable gate matrix

Gate	Owner	Required evidence	Fail action
Problem validated	Product sponsor	Baseline, interviews, outcome	Redo discovery
Contract agreed	Commercial/legal owners	SOW, acceptance, IP, exit terms	Renegotiate
Requirements approved	Product + technical owners	Testable stories and NFRs	Clarify and rescope
Architecture accepted	Technical + security owners	ADRs, threat model, prototype	Reduce risk or redesign
Change ready	Code owner	PR, tests, scans, review	Block merge
Release ready	Release owner	Test evidence, rollback, telemetry	Block deployment
Pilot accepted	Product owner	Outcome and SLO evidence	Remediate or change scope
Operations ready	Service owner	Runbooks, on-call, restore test	Delay handover
Exit validated	Customer technical owner	Independent operational rehearsal	Extend transition

What to automate—and what not to

Automate repeatable evidence collection: builds, tests, security scans, deployment records, service indicators, change logs, and cost allocation. Use AI to reduce clerical work and broaden analysis. Keep accountable human decisions at business acceptance, security exceptions, architectural trade-offs, contractual changes, and high-impact production operations.

The deeper point is that AI makes the gap between producing code and owning outcomes more visible. If generated code accelerates delivery but review, integration, operations, and customer learning remain bottlenecks, the organization has only moved the queue.

In 2026, enterprise software maturity should be judged less by how quickly a team produces artifacts and more by whether it can prove value, explain decisions, recover from failure, control risk, and transfer operational independence.

A short glossary to keep nearby

Term	Plain-language meaning
SLA / SLO / SLI	Customer commitment / internal reliability target / actual measurement
NFR	A requirement about quality or constraints, not just functionality
ADR	A written record explaining a technical decision and trade-offs
RTO / RPO	Target recovery time / maximum targeted data-loss window
UAT	Users checking whether the solution meets real needs
SOW	Contractual description of work, deliverables, and acceptance
CI/CD	Automated integration, verification, and release workflows
DORA	Research-backed software-delivery performance measures
Error budget	Reliability failure allowance implied by an SLO
Idempotency	Repeating an operation does not repeat its business effect
Canary	Releasing to a small audience before full rollout
Runbook	A repeatable guide for operating or recovering a service
FinOps	Collaborative management of cloud spending and value
DACI / RACI	Decision roles (Driver, Approver, Contributors, Informed) / work responsibility roles (Responsible, Accountable, Consulted, Informed)
Stream-aligned team	Team organized around a customer-value flow, rather than a single technical layer
Decision latency	Time between identifying a decision and obtaining an authorized decision

When Code Becomes Cheap, Ownership Becomes Everything

Krlz — Wed, 21 Oct 2026 03:40:19 +0000

Are we witnessing the end of traditional software factories, or the beginning of a more interesting kind of engineering organization?

For decades, many software organizations have relied on a familiar formula: need more features, hire more developers; need faster delivery, add another team; need lower costs, outsource to a lower-cost market.

That formula built an enormous global industry. But in 2026, AI assistants can generate implementations, tests, documentation, and increasingly complex changes. This raises an uncomfortable question for traditional software factories:

If writing code becomes cheaper, what exactly are we paying external development providers for?

I don't think outsourcing will disappear. I think the ability to produce code is becoming less distinctive than the ability to understand, operate, and evolve the product behind it.

The software factory was built around scarcity

The traditional factory emerged from legitimate needs: scarce local engineering talent, temporary specialist requirements, and a desire for flexible delivery capacity. External providers can offer talent, speed, and predictable commercial arrangements.

But there has always been a tension: the people producing software aren't necessarily the people who own its consequences.

A project can pass acceptance tests and be delivered on schedule. Six months later, nobody at the customer may remember why an integration is asynchronous, why a database constraint was omitted, or why an unusual validation exists.

The repository explains what the system does. It seldom preserves the full history of why.

A company can own every line of source code and still lack the capability to evolve its own product.

This is not unique to outsourcing. Internal teams with high turnover or weak documentation can lose knowledge too. But project-based handovers make the problem particularly visible.

AI changes the economics of implementation—not necessarily delivery

In three randomized field experiments involving 4,867 developers, researchers estimated 26.08% more completed tasks among developers given access to an AI coding assistant (standard error: 10.3 percentage points). The results varied across settings, and the outcome was completed tasks—not lifetime product cost or customer value. The paper appeared online in Management Science in 2026.

Source: Cui et al., The Effects of Generative AI on High-Skilled Work, Management Science (2026)

Google's 2025 DORA research similarly suggests widespread AI adoption, while emphasizing that AI amplifies the strengths and weaknesses of the surrounding organization.

But faster code generation is not always faster delivery. In a randomized study of 16 experienced open-source developers working on 246 tasks, METR found that access to early-2025 AI tools increased completion time by 19% in the studied setting.

Source: METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

METR's February 2026 update discussed newer evidence of potential speedups but also methodological limitations that prevented a reliable estimate.

These experiments should not be averaged into a single productivity number: they examine different people, tools, tasks, and outcomes. The lesson isn't that AI is always faster or slower. It is that code production and successful software delivery are different things. Review, integration, operational risk, and long-term maintenance still matter.

Outsourcing contracts are changing—but causality remains uncertain

According to the ISG Americas Q2 2026 Index, combined cloud and managed-services contract value rose 39% year over year, while traditional IT outsourcing contract value declined 23%. Engineering services, including AI integration work, increased 9%.

Technology services spending can grow while some traditional delivery models shrink.

This is not proof that AI caused the decline. ISG measures particular contract categories and sizes, and a quarter does not establish a permanent trend. But it challenges the assumption that every form of software outsourcing benefits equally from technological growth.

What exactly does ISG measure?

ISG's outsourcing index tracks commercial contracts meeting its reporting thresholds, including annual contract value. Its combined market includes cloud-based as-a-service offerings and managed services. Cloud infrastructure spending is not equivalent to custom software development. A decline in one outsourcing category does not prove that software engineering demand as a whole has declined.

Four regions, different market signals

🇺🇸 North America: Pressure on transactional delivery

North American companies are major buyers of global software services. The Americas ISG data shows weaker traditional application development and maintenance contracting alongside strong cloud and AI-related demand.

One plausible explanation is a changing build-versus-buy calculation: if a capable internal team can implement more with AI, outsourcing routine implementation solely for labor capacity may become less compelling.

But reducing coding contracts is not reducing the need for engineering accountability. Architecture, security, integrations, and production operations still need owners.

🇨🇱 South America: Beyond cheaper nearshore developers

Latin America has developed a substantial nearshore engineering ecosystem based on time-zone alignment, technical talent, and competitive costs.

A 2026 report from the IDB, World Bank, and WTO found that Latin American and Caribbean exports of digitally delivered services grew from $18.5 billion in 2005 to $87.7 billion in 2024, yet represented only about 2% of the global total. These figures cover more than software outsourcing.

If customers can use AI to increase internal capacity, the strongest regional opportunities may move toward differentiated expertise: financial infrastructure, healthcare interoperability, logistics, cloud modernization, distributed systems, and regulated integrations.

The opportunity is not merely to provide cheaper programmers. It is to become a more valuable engineering partner.

🇪🇺 Europe: Continuity and specialization

The ISG EMEA Q2 2026 Index reported 21% year-over-year growth in managed-services contract value, contrasting with the Americas.

Eurostat reported 10.45 million ICT specialists employed in the EU in 2025.

Europe's long-lived enterprise systems, regulated environments, and multinational integrations can reward stable providers with deep institutional knowledge. The distinction is not external versus internal: it is continuous responsibility versus interchangeable project staffing.

🇮🇳 Asia: Scale is not disappearing

The ISG Asia Pacific Q2 2026 Index reported 50.5% year-over-year growth in combined technology-services contract value, including strong growth in cloud services. Individual categories performed differently.

India's established outsourcing ecosystem and global capability centers (GCCs) show that globally distributed engineering can remain important. GCCs also illustrate an alternative: permanent engineering organizations abroad, with closer strategic alignment and knowledge continuity than a succession of temporary projects.

A production incident reveals the ownership gap

Imagine a logistics platform where an apparently small change adds a field to a shipment event. An AI agent updates the schema, the API, the migration, and the tests in an afternoon. The feature passes acceptance testing.

Weeks later, an older consumer replays events and interprets missing values incorrectly. A customer-facing report becomes inconsistent. The immediate fix is small; discovering the business meaning of the field, the replay semantics, and the reason the older consumer exists is not.

This is a hypothetical example, not a measured case study. It illustrates the difference between delivering an implementation and carrying the consequences of a decision across the product lifecycle. The same failure could happen with an internal team: employment status is not a substitute for institutional memory.

When AI-generated output becomes a review bottleneck

The cost of producing a plausible change is not the same as the cost of establishing that it is correct. A team can now receive more pull requests, test cases, and proposed fixes than its review and validation process can safely absorb. The bottleneck moves from typing to verification, prioritization, and integration.

This distinction matters for outsourced delivery, too. A provider may show an impressive increase in completed tickets while the customer's architecture group, security reviewers, or production engineers inherit an expanding queue of unresolved decisions. The appropriate response is not to reject AI-generated work, but to invest in automated checks, clear ownership boundaries, review capacity, and reliable production feedback.

In economic terms, lowering the price of implementation can increase demand for the complementary capabilities that make implementation useful. That is a hypothesis about organizational behavior, not a measured prediction that every company will hire more core engineers.

What is a core engineering team?

A core team is not defined simply by who signs its paychecks. It is defined by who remains accountable after a feature ships.

That team understands the domain, architectural trade-offs, operational failure modes, product priorities, and consequences of change.

Consider two delivery arrangements:

Project delivery	Continuous product ownership
Receive requirements	Clarify and challenge requirements
Implement accepted scope	Consider effects on the whole system
Pass tests and hand over	Monitor behavior in production
Close the engagement	Remain accountable for evolution

Neither model guarantees good engineering. But continuous responsibility creates stronger incentives to consider long-term costs.

A feature that takes two days to generate can still create years of maintenance obligations.

What does research say about ownership?

The 2024 study Examining Ownership Models in Software Teams: A Systematic Literature Review and a Replication Study reviewed 79 papers and revisited relationships between ownership and software quality. Not all previously reported correlations with defects replicated.

That matters: a smaller number of contributors does not automatically mean fewer bugs.

We should distinguish:

Code ownership: Who changes particular files or components?
Knowledge ownership: Who understands the decisions and constraints?
Product ownership: Who is accountable for behavior, outcomes, and evolution?

These overlap, but they are not identical. The third is the organizational capability I believe becomes increasingly valuable in the AI era.

AI doesn't eliminate engineering responsibility

Imagine asking an AI agent to add a customer field and propagate it across several services. It may update models, APIs, migrations, events, and tests rapidly.

An engineer familiar with the system still needs to ask: Are old consumers compatible? Is the field sensitive? What happens during replay? Is the migration safe? What happens if downstream processing fails? Does the change contradict an earlier business decision?

AI can help investigate these questions. But someone must establish which questions matter, validate the answers, and accept responsibility.

DORA's central organizational insight is relevant here: stronger testing, internal platforms, feedback loops, and team practices help turn AI assistance into actual delivery value. Fragile organizations may merely generate changes faster than they can safely absorb them.

The economics of ownership

AI can reduce the marginal cost of drafting code, but the total cost of a change also includes discovering requirements, reviewing and integrating changes, migration, observability, incident response, and future modifications. Lowering one component does not automatically lower the whole.

A useful conceptual model is:

Lifecycle cost = implementation + integration + verification
               + operations + rework + knowledge-transfer cost

This is an accounting lens, not a validated empirical formula. It also explains why billing by developer-hours can become a poor proxy for value: the customer cares about sustainable outcomes, while an hourly contract directly prices labor inputs. Outcome-based contracts have their own problems—attribution, scope, and risk allocation—and do not magically solve accountability.

A small core team with a large capability surface

The alternative is not necessarily full insourcing.

              PRODUCT STRATEGY
                     |
              CORE PRODUCT TEAM
                     |
       +-------------+-------------+
       |             |             |
     Domain      Architecture   Operations
    knowledge    & decisions    & reliability
       |             |             |
       +-------------+-------------+
                     |
            CONTINUOUS OWNERSHIP
                     |
       +-------------+-------------+
       |             |             |
   AI agents      External      Specialized
   & tooling      engineers     providers

The core team retains domain knowledge, architectural authority, release decisions, and operational accountability. External specialists provide expertise or capacity. AI assists with implementation, analysis, documentation, and tests.

This is a proposed operating model, not an empirically established optimal staffing ratio.

The question shifts from “How many developers do we need for these tickets?” to “Which capabilities must we retain to own this product, and which can we obtain externally?”

Outsourcing is not one business model

Arrangement	What the customer buys	Where continuity can live
Staff augmentation	Temporary engineering capacity	Usually in the customer's core team
Fixed-scope project	A defined deliverable	At risk during handover unless deliberately transferred
Managed service	Ongoing service performance	With the provider, if incentives and access support it
Dedicated external product team	Long-lived product capability	Across customer and provider, with shared governance
Global capability center	An enduring distributed organizational capability	Within the company's own operating model

These are ideal types, not mutually exclusive categories. The useful dividing line is who has decision rights, production visibility, and a duty to preserve knowledge after delivery.

The strongest counterargument: outsourcing can improve ownership

There is a serious objection to the thesis: a specialist provider with a stable team, strong operational discipline, and experience across many customers may preserve knowledge better than an internal team that rotates engineers, underinvests in documentation, or reorganizes every year. Some firms also cannot economically retain every specialist needed for security, accessibility, data platforms, or regulatory compliance.

That is why the argument should not be reduced to insource everything. The defensible principle is to retain the ability to make informed decisions and hold partners accountable, while allowing responsibility for execution—and sometimes operations—to be shared contractually with enduring external teams. Continuity, access, incentives, and decision rights matter more than payroll classification.

Three futures for the software factory

1. Commodity factories face pressure

Providers competing mainly on available developers and hourly rates may find it harder to differentiate when customers and competitors share powerful AI tools.

2. Specialized providers become more valuable

Domain expertise, complex integrations, security, regulated systems, and modernization may remain defensible areas of external engineering value. These providers sell judgment and outcomes, not just hours.

3. External teams become genuine product teams

A long-term external team can have stable membership, operate production, participate in architecture, and retain institutional knowledge. External employment is not incompatible with ownership. The key is whether responsibility survives delivery milestones.

Measure ownership, not output volume

Counting developers, tickets, story points, or generated lines of code cannot establish whether a product is becoming more sustainable.

Dimension	Better measure
Delivery	Lead time from validated need to production
Reliability	Change failure rate and recovery time
Maintainability	Cost and risk of subsequent changes
Knowledge continuity	Time for a new engineer to make a safe change
Product impact	Adoption, retention, revenue, or operational outcomes
Vendor dependence	Ability to operate and change without a particular supplier
Economics	Total lifecycle cost, including rework and incidents

I'd like to see longitudinal studies comparing AI-enabled permanent product teams with outsourced project teams, controlling for product maturity, complexity, and engineering practices. The existing evidence does not yet justify a universal claim that one model wins.

A practical test for product ownership

Before expanding or replacing an engineering provider, ask: Can we explain our most consequential architectural decisions? Can we deploy, roll back, and recover without one particular contractor? Who decides whether a requested feature is safe for existing customers? Who investigates incidents six months after handover? How quickly can a new engineer make a safe change?

If the answers are unclear, the risk is not simply vendor lock-in. It is capability lock-out: possessing the repository without possessing the knowledge, access, and judgment needed to evolve it.

A useful practical exercise is to run a supplier-absence drill: choose a low-risk production change and ask the retained team to trace the requirement, identify affected consumers, ship behind a rollback plan, and explain how they would investigate an incident. The goal is not to prove that the vendor is dispensable. It is to discover which capabilities depend on undocumented relationships before a crisis exposes them.

The question we should be asking in 2026

For years, software organizations were designed around the scarcity of people who could write code. AI changes that constraint without removing the need for engineering expertise.

As implementation becomes more accessible, domain understanding, architectural judgment, operational reliability, and accountability may become even more valuable.

That doesn't mean every company should build everything internally. It means companies should avoid accidentally outsourcing the knowledge and decision-making capabilities required to sustain their products.

The question is no longer just who can build the software. It's who will understand it, maintain it, and take responsibility for what happens next.

Perhaps that's what AI is really forcing us to reconsider: not the value of developers, but the value of ownership.

Reading the evidence carefully

The productivity studies above are experiments about development tasks; DORA describes associations and organizational practices; ISG measures qualifying commercial contracts; and regional trade statistics include services other than software. None directly estimates the causal effect of AI on outsourcing employment, nor proves that internally employed teams outperform enduring external teams. The regional interpretations and future scenarios are arguments to test, not observed outcomes.

Sources and further reading

This article presents an interpretation of multiple studies and market reports, not a causal demonstration that AI is replacing outsourcing. The underlying sources measure different populations and outcomes.

What do you think? If your main development provider disappeared tomorrow, could your team still deploy, debug, and evolve the product?

UML Got a Bad Reputation. I Still Built a Tool for It.

Krlz — Fri, 16 Oct 2026 18:31:24 +0000

Sometimes I need to see a problem before I can explain it.

Who calls this service? What happens if the request fails? Is this actually one feature, or three separate problems hiding under the same name?

A few boxes and arrows can make those questions easier to answer. So can a mind map that starts messy and gradually becomes a plan.

That's why I still like UML—and why I rebuilt Codiva PlantUML, my browser-based editor for text-based diagrams.

Yes, UML. The thing you may remember from university assignments, enormous class diagrams, and arguments about which arrowhead to use.

I think there's still a lot to like once you bring it back to everyday development.

Open Codiva PlantUML

A little history: why all those boxes existed

Before UML, there were several competing approaches to modeling object-oriented systems. Grady Booch, James Rumbaugh, and Ivar Jacobson brought their methods together, helping create the Unified Modeling Language. It became an OMG standard in 1997.

The idea was useful: give people a shared visual vocabulary for describing software. A relationship or interaction shouldn't need an entirely new notation every time you change teams.

Then came the baggage many developers associate with it: elaborate modeling tools, diagrams produced as deliverables, and designs that took longer to maintain than the code they described.

If your introduction to UML involved modeling every getter and setter before writing a working program, I understand the lack of enthusiasm.

But I still find value in the smaller habit underneath it: put a model of the problem somewhere you can inspect it.

A sequence diagram can reveal a round trip nobody noticed. A state diagram can expose a transition nobody defined. Even an unfinished sketch can show that two people have been imagining different systems throughout the same meeting.

Those are useful discoveries before implementation.

A diagram can help you think before it helps you document

We often talk about diagrams as something you make after understanding a system, so someone else can understand it too.

I like the earlier stage just as much: making a diagram to find out what I understand.

Say you're planning an asynchronous report feature. In prose, it sounds simple:

The user requests a report, a worker generates it, and we notify them when it's ready.

Start drawing it, and the questions appear:

Who owns the report's status?
What happens when the worker retries?
Can the user request the same report twice?
What does “ready” mean if notification fails?

The picture gives those questions somewhere to live. You can change the model while the change is still cheap.

The diagram doesn't have to represent the entire system. Often the most useful one answers a single question.

Mind maps are a great place to start

Before I know the sequence of events, I may only know the pieces of the problem.

That's where mind maps help: take a vague feature, give it a few branches, and keep splitting until the unknowns become visible.

PlantUML supports mind maps too. They aren't part of the UML standard; PlantUML extends beyond UML into other useful diagram types.

Here's a small example you can paste into the editor:

@startmindmap
* Asynchronous reports
** User experience
*** Request a report
*** Check progress
*** Download the result
** Processing
*** Queue the job
*** Generate the file
*** Retry failures
** Questions
*** Duplicate requests?
*** File expiration?
*** Notification failure?
@endmindmap

The asterisks define the hierarchy. Add another level when an idea needs breaking down; move a branch when you realize it belongs elsewhere.

I find this useful for feature planning, exploring an unfamiliar domain, or organizing the questions I want to take into a technical discussion.

An outline works too. Seeing its branches together can make gaps and uneven complexity easier to notice.

Then, when one branch needs a closer look, you can turn it into a more specific diagram.

A few UML diagrams still earn their place

You don't need to learn the whole notation to get something useful from it.

When I want to understand…	I reach for…
Who talks to whom, and in what order	A sequence diagram
Which states exist and what changes them	A state diagram
How a workflow branches	An activity diagram
How domain concepts relate	A class diagram
How the system's parts connect	A component diagram

A class diagram, for example, can show the relationships between an order, its items, and a payment without listing every method in the codebase.

A sequence diagram can make the difference between “request accepted” and “work completed” explicit:

@startuml
actor User
participant API
queue Jobs
participant Worker

User -> API: Request report
API -> Jobs: Enqueue job
API --> User: Accepted + report ID
Jobs -> Worker: Deliver job
Worker -> Worker: Generate report

alt generation succeeds
  Worker -> API: Mark report ready
else generation fails
  Worker -> API: Record failure
end
@enduml

This sketch also leaves things unresolved. How does the user learn that the report is ready? What happens after a failure?

That's a useful next conversation. The diagram has already helped identify it.

Why I like writing diagrams as text

Visual editors are great for sketching freely. With PlantUML, I like being able to describe the relationships and let the renderer handle their arrangement.

That gives me a few practical advantages:

Reviewable changes. A pull request can show a new participant, message, or state transition.
Source beside the code. A .puml file can follow the same branches and review process as the feature it explains.
Easy reuse. Copy a flow, adjust a few lines, and explore an alternative.
Less time arranging boxes. I can focus on the interaction before worrying about presentation.

There are trade-offs. Automatic layout won't always look the way you want, and a large diagram can become difficult to read regardless of how you generate it. Text also doesn't keep documentation accurate by itself; someone still has to maintain it.

For me, the sweet spot is a small, editable diagram with a clear purpose.

If you already use Mermaid and it fits your workflow, great. I see the habit of keeping useful diagrams as text as the bigger win. PlantUML happens to be the tool I wanted to build around.

Meet Codiva PlantUML

I had an older editor built with CodeMirror 5, Bootstrap, and CDN dependencies. It rendered through the public PlantUML server and had been sitting there for a while.

I rebuilt it with Astro, React islands, CodeMirror 6, and my own containerized PlantUML engine.

The goal was a convenient place to open an example, work through an idea, and export a diagram without setting up a local environment.

The editor includes:

Syntax highlighting and autocomplete for participants you've declared.
Syntax diagnostics with line highlighting.
Formatting from the context menu.
Dark mode.
SVG and PNG export.
Six examples to start from.
No account required.

Rendering happens on my backend, so diagram source is sent to that server when you use the hosted editor.

It's free to use. There's an optional coffee link in the footer to help with the server bill.

A couple of things I learned rebuilding it

Running the engine myself gave me more control over responsiveness and diagnostics. It also gave me a few bugs worth remembering.

Keep the JVM warm

Launching a new JVM for each render took around 1,115 ms in my setup. Keeping PlantUML running brought the warm local engine measurement down to around 14 ms, averaged over 10 requests.

Over HTTPS, I observed roughly 180 ms, compared with around 560 ms for the public endpoint in my comparison. Those are observations from my deployment, rather than a general benchmark; network location, diagram complexity, and server load all matter.

PlantUML's built-in PicoWeb server provides a simple way to keep the engine running:

java -jar plantuml.jar -picoweb:8777

A successful response can contain an unsuccessful diagram

My sequence-diagram test passed. A class diagram then failed because the container was missing Graphviz.

The surprising part: the response was HTTP 200 with a valid SVG containing the error message. My status-code check was happy. The person trying to render the diagram wasn't.

I used Smetana, PlantUML's Java port of Graphviz, to handle layout in my setup. The editor also needed useful diagnostics rather than leaving users to read an error drawn inside an image.

That's the improvement I care about most: if you make a syntax mistake while thinking through a flow, the editor should help you get back to the flow.

Implementation detail: selecting Smetana and mapping error lines

PlantUML supports selecting Smetana in diagram source:

!pragma layout smetana

Its documentation also lists the CLI option -Playout=smetana.

In my server integration, the proxy injects the pragma into the rendering copy, leaving the editor contents and exported source as written. That added line means diagnostic positions need mapping back to the original source.

My application layer uses PlantUML diagnostics to return a 422 response with a line number for syntax errors. That response contract is part of the editor's backend; starting PicoWeb alone doesn't provide it.

Give one of your ideas a diagram

If you've been carrying a feature around in your head, try putting its main branches into a mind map. If a flow keeps getting lost in paragraphs, try a sequence diagram.

That's the kind of everyday use I built this editor for.

Try Codiva PlantUML — no account needed

I'd love feedback on the editor, especially anything that gets in the way of turning an idea into a readable diagram.

Do you still use UML—or did diagrams find their way back into your workflow through mind maps, Mermaid, or something else?

References and further reading

I Built a Message Bus for AI Agents. Do I Actually Need a Framework?

Krlz — Tue, 06 Oct 2026 04:53:05 +0000

I have been using a simple data bus to let agents working on projects communicate.

It does the obvious things: an agent sends a message, another receives it, and work continues. But with new agent frameworks appearing constantly, I started wondering whether this approach was already outdated.

That question led to a more useful one:

What does my system need beyond delivering messages?

Imagine two agents collaborating on a feature. One implements it. Another reviews it. Then the implementation agent restarts, a message gets delivered twice, and the reviewer approves changes against an old commit.

The agents can still communicate. The project is now in trouble.

This is where the framework discussion becomes interesting.

Four layers that are easy to mix up

Before picking a framework, separate the responsibilities:

Layer	Question it answers	Examples
Transport	How does a message reach a worker?	Your service, a queue, HTTP, a message broker
Agent interoperability	How does an independent agent discover and request work from another?	A2A
Orchestration	Who acts next, and what happens after failure?	LangGraph, application code, workflow engines
Tools and context	How does an agent access external capabilities and data?	MCP, ordinary APIs, tool functions

A bus can deliver a task without understanding its lifecycle. A protocol can describe a task without deciding your project's dependencies. An orchestrator can coordinate workers while using your existing bus underneath.

These layers can coexist.

A useful starting point: keep message delivery, task ownership, and execution state explicit. Choose frameworks according to the responsibility you want them to own.

MCP and A2A: where each fits

MCP and A2A have complementary roles.

MCP equips an agent with tools and context: query a database, inspect a repository, or call a service.

A2A provides a contract for communicating with independent agents: discover capabilities, exchange messages, follow tasks, and retrieve outputs.

For example:

A developer uses an MCP tool to inspect an issue.
It delegates an investigation to a remote specialist through A2A.
Your coordinator records the task and waits for the result.
A queue buffers execution while the specialist is unavailable.

You can also expose an agent as an MCP tool. That can be perfectly adequate for a bounded request. A2A becomes more relevant when you want the independent agent's task lifecycle and capabilities represented through a common protocol.

Neither protocol automatically settles who may merge code, retry a deployment, or approve a project milestone. Those are application decisions.

What is actually new in 2026?

There are concrete developments worth watching, beyond another framework launch.

A2A now has a stable baseline and a CLI

The A2A project announced its first stable v1.0 specification in March 2026.

On October 1, it introduced an official command-line client. That is useful for scripts, CI jobs, and coding assistants that can run commands:

# Read an agent's capabilities.
a2a card get https://agent.example.com

# Submit a request and receive updates.
a2a send -a https://agent.example.com --stream \
  "Review the task contract and identify missing acceptance criteria."

The URL above is illustrative; these commands require an installed CLI and a reachable A2A server, with authentication configured where required. I have not executed them against a live agent for this article.

a2aproject / a2a-cli

The official command-line interface for interacting with A2A (Agent2Agent) compatible agents.

A2A CLI

Discover, message, and manage A2A agents from your terminal

The A2A CLI (a2a) is the official command-line client for A2A (Agent2Agent) agents, maintained by the A2A Project Team.

Why the A2A CLI

A2A is a bidirectional protocol: any A2A agent can act as a client to another and hand off a task. But an agent without an A2A layer can't easily send messages or receive updates. The A2A CLI fills that gap.

With it, you — or any model, agent, or coding harness that can call tools — can discover A2A agent's capabilities and send it work.

Three ways to get started:

Empower AI coding assistants — give your coding agent the a2a tool to offload work to remote A2A agents.
Interact instantly — fetch agent cards, send messages, and stream real-time updates from the terminal.
Automate workflows — seamlessly integrate A2A agents with…

View on GitHub

Durable execution is a prominent framework capability

LangGraph documents persistent state and checkpoints. Microsoft Agent Framework documents checkpoints and resuming.

My reading of these capabilities: framework selection increasingly deserves a recovery test alongside the usual delegation demo.

Can the run continue after interruption? Which operations will replay? What state survives? What must your tools make idempotent?

Persistent conversation history helps, but it is only one part of recovering work.

AutoGen advice needs a date attached

The AutoGen repository now identifies the project as being in maintenance mode and directs new projects toward Microsoft Agent Framework.

Existing AutoGen applications may still be useful. For a new build, I would evaluate the successor before following an older tutorial.

Which framework would I choose?

This is a practical shortlist, not a market-share ranking. The fit assessments are my engineering judgment; the links describe the underlying capabilities.

Option	Documented approach	Where I would evaluate it first
LangGraph	Stateful graphs, subgraphs, checkpoint storage, multi-agent patterns	Explicit project workflows with recovery requirements
Pydantic AI	Tool-based delegation, programmatic handoffs, typed graph control flow	Python services with validated task inputs and results
Microsoft Agent Framework	Sequential, concurrent, handoff, group chat, manager-led orchestration	Applications needing several coordination patterns
CrewAI	Collaborative Crews and event-driven Flows	Prototyping teams with distinct responsibilities
Agno	Coordinate, route, broadcast, and task-based team modes	Specialist teams with a coordinating leader
Mastra	TypeScript agents and workflows with suspend/resume	Agent functionality embedded in TypeScript applications

For my bus-based setup, LangGraph and Pydantic AI are particularly interesting.

LangGraph gives me a place to express transitions: assign work, await implementation, validate results, request review, and finish or retry.

Pydantic AI is attractive when I want ordinary Python functions and validated contracts to remain central. Its documentation distinguishes delegation from handing control to another agent, which is a distinction worth preserving in your own design.

CrewAI and Agno make it easier to express a team. I would still test whether their execution model fits long-running work, independent processes, and project ownership before adopting them.

Ready-to-run agents are another category

An agent framework is something you build with. An agent runtime is something you can run as a worker.

Hermes's current repository includes an A2A integration, with peer discovery, calls, and capability-based orchestration. Availability depends on your installed version; documentation on main is not a guarantee about an older release.

OpenCode supports primary agents and specialized subagents, with configurable prompts, models, and permissions. That makes it a candidate coding worker. Its local delegation features alone do not give your distributed system task ownership or recovery.

Connecting existing workers may be a smaller change than rebuilding them inside a single framework.

Give agents a task contract

The first improvement I would make to a simple bus is to replace ambiguous requests with structured assignments.

Instead of:

Help with the backend.

Send a bounded task with enough information to produce a verifiable result.

Example application task envelope

{
  "schema_version": 1,
  "message_id": "msg-1042",
  "task_id": "task-87",
  "project_id": "project-alpha",
  "event_type": "task.requested",
  "target_capability": "backend.implementation",
  "idempotency_key": "task-87-attempt-1",
  "deadline": "2026-10-07T18:00:00Z",
  "input": {
    "repository": "project-alpha",
    "base_commit": "abc1234",
    "goal": "Add pagination to the orders endpoint",
    "acceptance_criteria": [
      "Preserve the existing authorization checks",
      "Return a stable cursor for subsequent pages",
      "Include integration tests for empty and full pages"
    ]
  },
  "expected_output": {
    "branch": "string",
    "commit": "string",
    "test_report": "artifact reference"
  }
}

This is an illustrative application schema, not an A2A wire-format example. Validate it at your boundary and map it to the protocol or framework you use.

Adding an idempotency field does not itself prevent duplicate side effects. Your storage and execution logic have to enforce the behavior.

Likewise, include acceptance criteria because the worker needs a target it can check. A fluent explanation of completed work is weaker evidence than a commit and test report.

Design for the moment a worker disappears

For project agents, I would use a durable task record with states such as:

State	Meaning
Queued	Available for a worker to claim
Running	Claimed under a lease, with progress recorded
Awaiting review	Output exists and requires validation
Completed	Required checks have accepted the output
Failed	The attempt ended unsuccessfully
Cancelled	Further execution is no longer requested

These are application states, not prescribed protocol states.

A worker should claim a task atomically. While working, it renews its lease. If the lease expires, the coordinator decides whether to retry, reconcile partial results, or request intervention.

For external side effects, lease ownership alone may be insufficient. A stale worker can keep running after another worker takes over. Use fencing or destination-level idempotency where the operation requires it.

For code, I would also isolate work in branches or worktrees and bind the review to a specific commit. If the implementation changes afterward, the earlier review should not silently apply to the new version.

Measure collaboration before adding more agents

My suggested evaluation starts with a small set of representative tasks and deliberate failures:

Deliver the same task twice.
Restart a worker halfway through execution.
Return an invalid result schema.
Let a reviewer receive an outdated commit.
Exhaust the task's time or token budget.

Track accepted outcomes, total cost, retries, and time to completion. Compare the multi-agent workflow with a single-agent baseline doing the same work.

More agents introduce more handoffs. Each handoff deserves evidence that it improves the result.

The architecture I would build next

I would keep the bus, put task ownership and state in durable storage, and introduce orchestration where the workflow needs it.

Then I would add A2A at the boundary for independently deployed agents, and MCP where workers need external tools.

That gives me an incremental path:

Define a task contract and validate results.
Add atomic claims, leases, and retry limits.
Record artifact references and execution history.
Introduce a framework for complex transitions and recovery.
Add interoperability without forcing every worker into the same runtime.

Before replacing your bus, test whether your system can explain who owns a task, what has already happened, and what is safe to do next.

Those answers make an agent system easier to trust, regardless of which framework runs the reasoning loop.

How are you coordinating your agents today: a shared queue, a task board, a framework, or direct calls? What failed first when you added a second worker?

Research snapshot: October 6, 2026. Capability claims link to official documentation or repositories. Recommendations and the proposed task design are my assessment, not benchmark results. Forem Liquid embeds follow the DEV editor guide.

The missing break behind Digimon World’s evolution rules

Krlz — Wed, 30 Sep 2026 04:37:17 +0000

You fed it, trained it, cleaned up after it. You had a plan. Then it evolved into Numemon, a walking pile of sludge, and the game never told you why.

No menu. No hint. No stat screen saying here is what went wrong.

Players filled that silence with wikis, calculators and arguments about whether care mistakes helped or hurt. They inferred the rules from what happened on screen. Now we can read the code.

The Digimon World decompilation project has reconstructed the evolution code. One rule comes from a loop with no break: when several stats share the highest value, the game picks the last one in its array.

Here is how the scoring works, what that tie means, and what I learned while testing a small PC port prototype.

The missing break

Here is the real code that picks which of your stats the game examines. It's in src/main/evolution.c, and it runs over the six stats hp, mp, offense, defense, speed, brain:

for (i = 0; i < 6; i++) {
  int8_t isHighestStat = 1;
  for (j = 0; j < 6; j++) {
    if (statsArray[i] < statsArray[j])
      isHighestStat = 0;
  }
  if (isHighestStat == 1)
    highestStat = i;
}

For six stats, the nested loop is cheap. But look at what is missing: there is no break after the assignment. The loop keeps going after it finds a maximum, so a later tied stat overwrites an earlier one. When stats tie, the highest index wins.

I ran the same selection logic with a few inputs:

all six tied      -> brain
offense highest   -> offense
off+def tied high -> defense
brain highest     -> brain

Reading the array order backwards gives the full tie-break priority: brain > speed > defense > offense > mp > hp.

With all six stats tied, the game selects brain as the highest stat. You could infer this from enough experiments, but the code makes the reason clear. Whether the missing break was intentional is unknown; its effect is observable.

Worth being careful here: I first suspected highestStat was read uninitialized, which would be a genuine bug worth reporting upstream. It can't be — a maximum always exists among six values, so the flag is always set at least once. Check before you claim.

The scoring system: four checks, three needed

That tie-break feeds a larger system. Every Digimon has up to six possible evolution targets. For each candidate the game computes a score out of 4, and a candidate needs at least 3 points to be eligible at all. Below 3 it isn't considered.

Here are the four checks.

Care mistakes, and the flag that inverts them

if (isMaxCM == 0) {
  if (partner->careMistakes >= reqs->care)
    reqPoints += 1;
} else if (partner->careMistakes <= reqs->care) {
  reqPoints += 1;
}

Read the comparisons closely. There's a flag bit that reverses the test, so some evolutions want your care mistakes above a threshold.

Neglect isn't a punishment in this game. For certain paths it's a requirement. Care mistakes can therefore help qualify a candidate. Whether that explains any particular Numemon depends on the other checks and available targets.

Weight is a window, not a floor

if (reqs->weight - 5 <= partner->weight &&
    partner->weight <= reqs->weight + 5)
  reqPoints += 1;

A band of ±5 around a target. Overfeeding fails this check exactly as hard as underfeeding. A precise target weight matters because both sides of the window have a limit.

Stats, where the stage changes the rule

if (DIGIMON_DATA[target].level == 3U) {
  /* Champion: only your single HIGHEST stat is examined */
} else {
  /* everything else: ALL six stats must clear their thresholds */
}

Most evolutions need every stat above its requirement. Champion-level targets check only your highest one — which is where the missing break above actually bites. For Champions, one selected highest stat matters; other targets require all six thresholds.

The bonus point: any one of five

if (reqs->digimon    != -1 && current == reqs->digimon) isBonusFulfilled = 1;
if (reqs->discipline != -1 && /* ... */)                isBonusFulfilled = 1;
if (reqs->happiness  != -1 && /* ... */)                isBonusFulfilled = 1;
if (reqs->battles    != -1) { /* also invertible */ }
if (reqs->techs      != -1) { /* mastered moves */ }

Any single one of these grants the fourth point. Battle count carries the same inversion trick as care mistakes: some evolutions want you to have fought fewer than N battles.

The rule that quietly steers your collection

One more piece, and it's the one that made me sit back:

if (reqPoints >= 3 && currentBest != -1) {
  isTargetRaised = hasDigimonRaised(
      EVO_GAINS_DATA[target].targetDigimon);
  isCurrentBestRaised = hasDigimonRaised(
      EVO_GAINS_DATA[currentBest].targetDigimon);

  if (isTargetRaised == 1 && isCurrentBestRaised == 0)
    reqPoints = 0;      /* you already have this one: disqualify it */

  if (isTargetRaised == 0 && isCurrentBestRaised == 1)
    reqPoints++;        /* you don't have this one: push it ahead */
}

The game remembers which Digimon you have raised. When it compares two eligible candidates, this code favours the one you have not raised: it can zero the already-raised candidate’s score or add a point to the new one. The outcome still depends on candidate order and the surrounding selection logic.

It is a small but deliberate way to steer players toward more of the roster.

Who actually did this

I did not decompile the game. I forked the repository, ran parts of its code on a PC, and measured a few pieces a port would need. The decompilation work belongs to its contributors.

jype0 / dw_decomp

Digimon World decomp

A work in progress decompilation of Digimon World for PS1.

Dependencies

Install the following packages:

binutils-mipsel-linux-gnu gcc-mipsel-linux-gnu git make python3 python3-venv unzip wget

Install Python dependencies:

python3 -m venv .venv
. .venv/bin/activate
pip3 install -r requirements.txt

Download tools:

tools/dl_deps.sh

Download CodeWarrior for PlayStation Release 4 and copy cc_mips.dll to bin/cc_mips/cc_mips_40.dll.

Build

# Update submodules
git submodule update --init --recursive

# Dump original PSX Digimon World (USA) ISO
bin/mkpsxiso-2.20-Linux/bin/dumpsxiso -x disks/us -s disks/us/us.xml "/path/to/Digimon World (USA).bin"

# Disassemble original binaries
make -j$(nproc) regenerate

# (Optional) Create file local.mk to override defaults
MWCCWRAP := /path/to/mwccwrap.exe
MWCCWRAP_FLAGS := -dll "/path/to/cc_mips.dll"
METROWRAP := /path/to/mw
METROWRAP_FLAGS := --use-wibo --wibo-path /path/to/wibo
CROSS := /path/to/mipsel-linux-gnu-

# Build new binaries
make -j$(nproc)

# Compare original vs new binaries
make compare

# Generate objdiff config
make objdiff

Links

Symbols and reverse engineering is based on work by SydMontague:
https://github.com/SydMontague/DW1-SydPatches
https://github.com/SydMontague/DW1-Code

View on GitHub

jype0/dw_decomp started in March 2026 and is MIT licensed. It passed a milestone most decompilation projects never reach: zero INCLUDE_ASM stubs left in src/.

If you haven't worked on a decomp, that needs explaining. INCLUDE_ASM is the marker for "we haven't figured this function out yet, here's the raw assembly instead." Most decomps carry hundreds of them for years. The source tree no longer relies on those assembly placeholders. That milestone alone does not establish that every function matches the retail binary.

Credit isn't evenly spread, and shouldn't be reported as if it were. As of today the contributor counts are:

Contributor	Contributions
Pekka Jylhä-Ollila (jype0)	409 — maintainer, and the bulk of the project
juandav	37 — matching functions and data across overlays
ChonkMode	22
kingzmanh	11
fmil95	7
ThirstyWraith	6
SydMontague	5 — struct and naming reference work
paulohpfilho	4

Those are the repository’s contribution counts at the time I checked, not a measure of each person’s work or proof that every regional build is complete.

I asked about the roadmap in an issue. juandav relayed jype0's four points: clean up the hacks and name things properly; match all 10 regional versions; maybe a PC port, blocked because psyq and psycross don't currently implement libgs or libsnd; and then a DW1 mod of epic proportions — new maps, story, Digimon.

The ambitious mod is the long-term goal. The decompilation makes that work possible.

Running their code somewhere it has never run

My question was narrower: can this code run off the PlayStation at all?

evolution.c is 1,087 lines. Compiling it on x86-64 produced exactly one error:

libgte.h: No such file or directory

That's Sony's geometry coprocessor header. So I grepped evolution.c for VECTOR, MATRIX, gte_, RotTrans — nothing. The evolution logic doesn't touch the GTE at all. It only inherits the header through entity.h.

I wrote type-only stand-ins for the four PsyQ headers. It compiled clean, then ran:

EvoRequirements = 28 bytes (PS1 layout: 28)
fresh(1)       -> 2
in-training(3) -> 5

That 28 matters more than it looks. The game reads its data tables as raw structs, so if the layout shifted by even one byte on a 64-bit host, every evolution requirement in the game would decode as noise. It doesn't, and I pinned it with static_assert so nobody can break it quietly later.

Measuring the GTE instead of guessing at it

A major piece of a PS1 port is the GTE, the fixed-point geometry coprocessor.

My first instinct was to size the problem with a grep. I got 181 and quoted that number publicly. It was wrong — my pattern was matching a header that defines every GTE macro whether the game calls it or not. Measured against src/ alone:

632 call sites, 29 distinct operations, 34 of 126 files

The call sites are concentrated:

Operation	Sites	Cumulative
`ApplyMatrixSV`	103	16%
`RotMatrix`	51	24%
`RotMatrixZYX`	44	31%
`RotMatrixYXZ`	44	38%
`ratan2`	43	45%
`gte_rtps`	42	58%
`ScaleMatrix`	39	71%
`TransMatrix`	37	77%
`ApplyMatrixLV`	23	81%

The nine operations shown account for about 81% of these call sites. That gives a useful starting point, though call-site count does not measure implementation difficulty.

I implemented a software subset covering those common operations. The contract is strict: matrix entries are 1.3.12 fixed point (4096 = 1.0), angles run 4096 to a full turn, and results saturate rather than wrap. That last one isn't optional — a wrapped coordinate throws a vertex to the far side of the screen, which is exactly the class of bug that ships unnoticed.

Then I measured the number that actually decides anything. "0.17% trigonometric error" is a useless statistic; nobody can tell you whether that's visible. So I measured pixels — how far a projected vertex lands from where double-precision maths puts it, across 2,528 vertices and a full rotation sweep:

mean error:             0.825 px
worst error:            1.896 px
vertices off by > 2px:  0.00%

In that test, the error stayed under two pixels. This measures one projection sweep; it does not guarantee every game scene will look the same.

And the honest half: it is not bit-exact. The real GTE uses lookup tables; my polynomial approximation looks identical and is numerically different. That's fine for a port and useless for verifying a decompilation, whose entire premise is reproducing the original binary byte for byte. Confusing those two would be the expensive mistake, so I put the warning in the test output rather than in a comment nobody reads.

Drawing a frame: primitives and the ordering table

The game's rendering is all PsyQ primitives, counted across the source:

POLY_FT4  386    (textured quad)
POLY_F4    30
POLY_GT4   17
POLY_FT3    6    (textured triangle)

The two textured primitive types in this excerpt account for 392 call sites, making them a useful first rendering test. I built them with the game's own setXYWH and setUVWH macros lifted from src/main/utils.c, and rasterised them in software.

One thing I deliberately did not fix: the texture mapping is affine, not perspective-correct. The PS1 had no perspective correction, and that wobble is part of how the console looks. Correcting it would make a port feel wrong.

Then the ordering table, which is how the PS1 sorted by depth. The name misleads, so it's worth saying plainly: an ordering table is not a sorting algorithm. It's a bucket array — one slot per depth value, each holding a linked list, with AddPrim pushing to the front. O(1) insertion, zero comparisons. That's how a 33MHz console depth-sorted a scene every frame, and reimplementing it with qsort would be slower and wrong, because the order of equal-depth primitives depends on the original insertion and traversal rules.

I built the occlusion test so it couldn't pass by luck: submit the near quad first, then the far one.

normal:          centre pixel r=16  g=104    (near/green occludes)
depths swapped:  centre pixel r=120 g=16     (far/red now occludes)

Same submission order, opposite result. The table is doing the work, not the sequence of my function calls.

Where I got things wrong

Two corrections, because they're more useful than a clean story.

The GTE count. I said 181 in public. It's 632. I estimated with a grep and then quoted the estimate as a measurement, which is a bad habit and I did it anyway.

A test that failed for the right reason. I asserted the far square would peek out around the near one. It doesn't: the near quad spans x=75..245 and the far one x=123..197, so full occlusion is correct physics and my sampling point was badly chosen. I checked the rendered image before touching any code, which is the only reason I didn't "fix" working code to match a broken expectation.

What this does not prove

One logic file out of 126. I picked evolution.c because it looked dependency-free. Best case, not a representative sample.
The GTE is approximate. 18 of 29 operations unimplemented, and the trig is polynomial rather than table-driven.
No model loading. GsSortObject4 has 42 call sites and walks TMD models. The ordering table is ready for it; the format reader isn't written.
Nothing validated against the retail binary. That needs the MIPS toolchain and a disc image.
The assets are still Bandai's. Models, textures, music, text. A possible distribution model is an engine that requires players to supply their own game data; the legal details would need separate review.

Where my work and jype0's roadmap touch: his stated blocker for a PC port is that psyq and psycross don't implement libgs or libsnd. libgs is one of the four headers I stubbed. I'm not claiming that solves his problem — only that it's the same wall, and it's climbable from at least one side.

What we finally understand

Twenty-five years of wiki edits, spreadsheets and arguments, and the answer is a few hundred lines of C:

3 points of 4 to be eligible at all
Care mistakes and battle counts are invertible — some evolutions want neglect
Weight is a ±5 window — overfeeding fails like starving
Champions check your highest stat only; everything else checks all six
Ties favour the last tied stat in array order, with brain last
Previously raised targets can lose a head-to-head comparison against a new one

Your Numemon had an explanation in the game’s rules. The exact reason in any given run depends on the candidate scores and selection path.

That is what makes the decompilation exciting: the rules are readable and testable. It also gives modders a foundation to build on.

My four experiments live on a branch in my fork. Each runs with one command and needs only gcc, plus libsdl2-dev for the two that draw — no PlayStation toolchain, no disc image.

If you've worked on a decomp: how do you decide when an approximation is good enough to ship in a port, given it can never be good enough to verify a match? The bit-exact line is the part I'm least sure I drew correctly.

AI doesn't need a new Git workflow. It needs better gates

Krlz — Fri, 25 Sep 2026 13:08:42 +0000

A peer-reviewed study presented at EASE 2026 examined 33,596 pull requests created by AI agents in GitHub repositories with at least 100 stars. It found that 61.38% had no recorded review activity. If you include pull requests reviewed only by bots, that number reaches 84%.

That does not prove nobody read the code. A maintainer can inspect a diff carefully and merge it without leaving a comment. But recorded activity is the only oversight a team can audit later, and right now that record is disappearing.

This is the Git problem worth solving for AI. It is not whether your team should replace Git Flow with trunk-based development because it started using Copilot.

I started researching what changes about Git when AI writes the code, expecting to find a new branching model. I did not find one. The more important change is simpler: generating code became cheap, while verifying it did not.

The branching question is mostly a distraction

“Git Flow or trunk-based for AI?” is an old question with a new label. It asks how long a branch should live.

Most coding agents have converged on a familiar workflow:

task → branch → pull request → human handoff

That is essentially GitHub Flow. It already fits an agent's natural unit of work: one task, one isolated workspace and one handoff point.

GitHub describes Copilot's coding-agent workflow in similar terms. The agent opens a pull request, assigns a reviewer and expects the code to be reviewed like a contribution from any other developer.

The agent/ prefix may be new. The workflow is not.

Code generation got faster. Review did not

An agent can produce a plausible 400-line change in a few minutes. A human may still need twenty minutes—or much longer—to understand whether it is correct.

Recent industry measurements show the same pattern:

Metric	Reported change
Median PR size	+51%
Median time in review	+441%
Agentic PR wait for reviewer pickup	5.3× longer
Reported incidents per PR	+243%

LinearB analyzed 8.1 million pull requests across more than 4,800 organizations. Developers felt 20% faster, but measured delivery performance was 19% slower. Teams completed more tasks and merged 98% more pull requests, while review time increased by 91%.

These numbers do not describe a branching failure. They describe a verification bottleneck. Renaming branches does not reduce the amount of code a person must understand.

“Reviewed” may no longer mean reviewed

The EASE 2026 study also compared agent-authored and human-authored pull requests within the same repositories. Researchers classified human comments as genuine review, instructions directed at an agent, or CI-related activity.

Human comment type	Agent PRs	Human PRs
Genuine review content	65.5%	93.6%
Agent-steering commands	25.9%	1.6%

When humans interacted with an agent's pull request, roughly a quarter of their comments were instructions such as asking the agent to fix a failure. They were operating the agent rather than evaluating the change.

The practical consequence: a pull request marked as reviewed is becoming a weaker signal of human oversight. Review counts alone may no longer tell you whether someone examined the architecture, business rules and failure cases.

This matters for engineering metrics, incident analysis and compliance. A dashboard can say that a pull request was reviewed without showing whether the interaction was a real evaluation, an agent command or an automated comment.

Should you switch to trunk-based development?

Trunk-based development fits agent work well. Short-lived branches reduce divergence, and small changes are easier to test, review and revert.

DORA's 2025 report found that the benefits of AI depend partly on teams working in small batches. Trunk-based development often encourages that behaviour, but it is not the only way to achieve it.

You can keep Git Flow and still require small, independently reviewable changes. You can also use trunk-based development badly by allowing agents to open enormous pull requests.

Trunk-based development also has costs:

It works best with a fast and reliable test suite.
It often depends on feature flags, which require ownership and cleanup.
Adoption may initially slow delivery while teams improve their automation and release practices.

So the decision should still depend on the team, release process and maturity of the test suite—not on whether the code was written with AI.

Where `develop` still earns its place

If your team uses feature/* → develop → main, AI is not a reason by itself to remove develop.

Keep it when it is a real integration environment where changes are tested together before release. Remove it when it only adds waiting time and nobody uses it to discover integration problems.

Modern coding agents can work with either model. Copilot's coding agent, for example, can now use a selected base branch instead of only the repository's default branch.

The useful question is not “Is develop outdated?” It is “What risk does this branch control, and is it actually controlling it?”

A workflow you can adopt now

You probably do not need new branch names. You need clearer gates between an agent receiving a task and its code reaching production.

1. Review the plan before the patch

Ask the agent for a short implementation plan before it writes code. The plan should explain:

which files, services and data are affected
API or schema changes
migration and rollback steps
tests that will be added
risks and assumptions

Keep the plan in the issue or pull-request description. Repository instructions such as CLAUDE.md or .github/copilot-instructions.md can make this a default part of the workflow.

It is much cheaper to reject a bad approach before it becomes a large diff.

2. Keep changes reviewable

Use GitHub Actions, Danger JS or a PR-size action to label large changes and require an explanation when they cross an agreed threshold.

A hard line limit will not fit every repository. Generated files, lockfiles and migrations can distort the number. The goal is not to worship a 200-line rule; it is to make large changes exceptional and intentional.

When possible, split work into small pull requests that can be tested and reverted independently. GitHub also documents a stacked pull-request workflow for AI-generated changes.

3. Automate the mechanical review

Run automated checks before asking for human attention:

CodeQL or Semgrep for static analysis
SonarQube or SonarCloud for maintainability rules
Gitleaks for secrets
Dependabot or Renovate for dependency changes
Snyk or Trivy for dependency and container vulnerabilities
Playwright, Pact or integration tests for behaviour across boundaries

AI review tools such as GitHub Copilot code review, CodeRabbit, Qodo Merge or Greptile can provide another first pass.

These tools are useful for finding common problems. They should not own the final decision. Humans still need to evaluate architecture, product behaviour, security assumptions and failure modes.

4. Protect the merge

Use GitHub rulesets, protected branches, required status checks and CODEOWNERS to make ownership explicit.

For sensitive areas, require approval from the team that owns the code. Do not allow a bot comment or an agent-generated fix to satisfy the same rule as a human approval.

GitHub Copilot code review leaves a comment review by default rather than an approval. That default is sensible. If AI approvals are configurable in your organization, verify that changing the setting cannot silently remove the human gate.

5. Record AI involvement

Add a pull-request label, metadata field or commit trailer that records which agent was involved. Link the task, plan and relevant session transcript from the pull request.

For example:

Co-Authored-By: Claude <noreply@anthropic.com>

This gives you enough information to ask useful questions later:

Do agent-assisted changes fail more often?
Which repositories need more review?
Which instructions repeatedly produce the same mistakes?
Does AI reduce lead time after review and rework are included?

GitHub's API can provide the raw data. Engineering analytics platforms such as LinearB, Swarmia or Jellyfish can help track change size, review time, rework and deployment outcomes.

6. Fix the generator when mistakes repeat

When an agent makes the same mistake twice, do not only repair the current diff. Update the issue template, prompt, repository instructions, examples or agent skill that produced it.

Fixing a diff improves one pull request. Fixing the generator improves the next hundred.

The resulting workflow is deliberately boring:

task → plan → small change → automated checks → human review → merge

That is a feature. Good delivery systems make ownership obvious.

What is still unresolved

There are questions the current research does not answer:

If review counts no longer measure oversight, what should replace them? Time spent on a page would be easy to game, and comments are an incomplete signal.
What happens at full autonomy? Every workflow above assumes a human remains in the merge path. At dozens of agent pull requests per day, that assumption may stop working.
What is the right commit granularity? An agent session may contain forty steps, but forty commits are rarely useful. I currently prefer squashing into logical units while keeping the session history separately.

These are more important questions than whether an agent branch should start with feature/ or agent/.

The takeaway

Your current branching model is probably fine. One task, one branch and one pull request still works.

What changed is the pressure placed on the review system. AI can produce code faster than humans can verify it, while existing dashboards may still report that everything was “reviewed.”

Before changing Git Flow, strengthen the path to merge: review the plan, keep changes small, automate mechanical checks, require clear ownership and record where AI was involved.

Then ask the uncomfortable question:

Do you know what fraction of your merged agent pull requests a human actually read—not merely approved?

I suspect most teams cannot answer that yet. I would genuinely like to hear from anyone who can.

Sources: DORA 2025 State of AI-Assisted Software Development · Duma et al., “These Aren't the Reviews You're Looking For,” EASE 2026 · Choosing the Right Git Workflow (arXiv 2507.08943) · GitHub Docs: Copilot code review · GitHub Changelog: base branch for coding agent · GitHub Docs: Stack AI-generated code in pull requests

MCP Went Stateless: What the 2026-07-28 Spec Actually Changes

Krlz — Sun, 09 Aug 2026 14:01:44 +0000

For eighteen months, running a remote MCP server meant fighting your own infrastructure. You had a bidirectional, stateful protocol sitting on top of HTTP, which meant sticky sessions, a shared Redis for session state, or a gateway doing packet inspection to route requests to the one box that held the connection. Every horizontal scaling story started with an apology.

On July 28, 2026, that ended. The 2026-07-28 specification makes MCP stateless at the protocol layer — the largest revision since launch, and the first one that makes MCP behave like the rest of the web.

What actually changed

Six SEPs (Specification Enhancement Proposals) work together here. The short version:

The handshake is gone. initialize/initialized and the Mcp-Session-Id header have been removed (SEP-2575, SEP-2567). Every request is now self-describing: protocol version, client identity, and client capabilities ride inline in _meta on each call. There's an optional server/discover RPC if a client wants capabilities up front, but nothing requires it.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Any request can land on any instance behind a plain round-robin load balancer. No shared storage, no ARR affinity, no sticky routing.

Routing moved into headers. Mcp-Method and Mcp-Name are now required on Streamable HTTP requests (SEP-2243). Your gateway, WAF, or rate limiter can route and meter without parsing JSON bodies. If you've ever written a Lua script to peek inside an MCP payload at the edge, you can delete it.

List results are cacheable. tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope (SEP-2549), with deterministic ordering. That last part matters more than it looks: a stable tool catalog keeps upstream prompt caches stable across reconnects, which is a real token-cost line item.

Server→client calls became round trips. This is the clever bit. Elicitation and sampling used to require a held-open stream, which is exactly what a stateless protocol can't offer. Multi Round-Trip Requests (SEP-2322) invert it: the server returns resultType: "input_required" plus an opaque request-state token, the client gathers the answers, then calls the same tool again with inputResponses attached. Every leg is an ordinary client-to-server request.

Auth got hardened. Authorization servers should return iss per RFC 9207 and clients must validate it before redeeming a code (SEP-2468) — that closes an AS mix-up hole. Client credentials are now bound to the issuer that minted them (SEP-2352), and Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents.

Deprecations. Roots, Sampling, and Logging are deprecated (SEP-2577), as is the legacy HTTP+SSE transport (SEP-2596). Both get a twelve-month minimum offramp under the new deprecation policy — which is itself the quiet good news here. This is a protocol that now plans its breakage.

The part people will get wrong

"Stateless protocol" does not mean "stateless application."

If your server needs to carry state across calls, you mint an explicit handle from a tool and let the model pass it back as an ordinary argument. The maintainers are direct that this works better than state hidden in the transport, and I think they're right for a reason that isn't primarily architectural: the model can see the handle. It becomes a thing the agent reasons about and threads between tools, instead of an invisible coupling that breaks the moment a load balancer does its job.

This is the same lesson REST landed on twenty-five years ago. Roy Fielding's dissertation argued the statelessness constraint buys you visibility, reliability, and scalability at the cost of repeated per-request data — Architectural Styles and the Design of Network-based Software Architectures, Ch. 5. MCP just paid that tuition in public.

A stateless server in Python

The v2 line of the Python SDK renamed the in-SDK FastMCP to MCPServer and moved transport options off the constructor onto run(). If you're still importing mcp.server.fastmcp, you're on v1.x and speaking the old handshake.

uv init mcp-units && cd mcp-units
uv add "mcp[cli]"

# server.py
from mcp.server.mcpserver import MCPServer

mcp = MCPServer("units")


@mcp.tool()
def to_celsius(fahrenheit: float) -> float:
    """Convert Fahrenheit to Celsius."""
    return round((fahrenheit - 32) * 5 / 9, 2)


if __name__ == "__main__":
    # stateless_http + json_response = plain HTTP request/response
    mcp.run(transport="streamable-http", stateless_http=True, json_response=True)

That's it. No session manager, no event store, no affinity. Run it and point the inspector at http://localhost:8000/mcp:

uv run server.py
npx -y @modelcontextprotocol/inspector

Now the interesting version — state without a session:

import uuid

from mcp.server.mcpserver import MCPServer

mcp = MCPServer("reports")

# In production this is Redis/Postgres, not a dict — but note that it's
# *your* store, keyed by a handle the model holds, not transport state.
JOBS: dict[str, dict] = {}


@mcp.tool()
def start_export(dataset: str) -> str:
    """Begin an export. Returns a job handle to pass to check_export."""
    job_id = f"job_{uuid.uuid4().hex[:8]}"
    JOBS[job_id] = {"dataset": dataset, "status": "running"}
    return job_id


@mcp.tool()
def check_export(job_id: str) -> dict[str, str]:
    """Check an export by its handle."""
    return JOBS.get(job_id, {"status": "unknown"})

Two calls, potentially two different machines, zero coordination. The handle is in the model's context, not in the transport.

One gotcha worth internalising before you migrate: because MRTR removed the back-channel, ctx.elicit() and ctx.session.create_message() raise NoBackChannelError on a modern connection. If your server asks the user mid-call, that code needs rewriting around the input-required round trip — it's the single most likely thing to break.

modelcontextprotocol / python-sdk

The official Python SDK for Model Context Protocol servers and clients

MCP Python SDK

Python implementation of the Model Context Protocol (MCP)

Documentation

The documentation lives at https://py.sdk.modelcontextprotocol.io/.

It has a Get started guide, What's new in v2, the API reference, and the migration guide.

What is MCP?

The Model Context Protocol lets you build servers that expose data and functionality to LLM applications in a secure, standardized way. Think of it like a web API, but designed for LLM interactions. With this SDK you can:

Build MCP servers that expose tools, resources, and prompts to any MCP host
Build MCP clients that connect to any MCP server
Speak every standard transport: stdio, Streamable HTTP, and SSE

Requirements

Python 3.10+.

Installation

uv add "mcp[cli]"      # or: pip install "mcp[cli]"

The cli extra adds the mcp command-line tool (mcp dev, mcp run, mcp install) on top of the SDK; install plain…

View on GitHub

Why this matters beyond the ops win

The scaling story is the headline, but I think the deeper shift is that MCP stopped being a transport-flavoured protocol and became an HTTP-flavoured one. That means the boring, battle-tested layer of the web now applies to agent tooling: CDNs, edge workers, standard load balancers, cache-control semantics, header-based authorization at the gateway.

It also narrows some real attack surface. The research on MCP security has been fairly damning, and a lot of it clusters around trust boundaries between independently operated components:

Hou, Zhao, Wang & Wang (2025) — Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions — the canonical starting point. Builds a threat taxonomy across the server lifecycle and four attacker classes. The tool-description manipulation section (embedding "prefer this tool" directives to hijack tool selection) is worth the read on its own.
Radosevich & Halloran (2025) — MCP Safety Audit — demonstrates concrete exploits against real MCP deployments.
Yang, Wu & Chen (2025) — MCPSecBench — a systematic security benchmark and playground, if you want something to actually run against your server.
Wang et al. (2025) — MCP-Bench — benchmarks tool-using agents on complex real-world tasks via MCP servers. Useful for the "is my tool catalog actually usable by a model" question, which is separate from whether it's correct.

Read those with a date-stamp in mind: they all predate the stateless core, so the session-layer threats they describe are partly answered by a protocol that no longer has a session layer. The prompt-level and supply-chain threats are entirely untouched. Stateless MCP is a scalability fix, not a security fix — treat any vendor claiming otherwise with suspicion.

Migration checklist

[ ] Bump to the SDK line that speaks 2026-07-28 (v2 for Python; pin exactly)
[ ] Replace mcp.server.fastmcp.FastMCP → mcp.server.mcpserver.MCPServer
[ ] Move stateless_http / json_response from the constructor to run() / streamable_http_app()
[ ] Rewrite anything calling ctx.elicit() or create_message() around MRTR
[ ] Replace session-keyed state with explicit tool-minted handles
[ ] Delete sticky-session config and shared session stores
[ ] Add ttlMs / cacheScope to list responses
[ ] Validate iss (RFC 9207) if you're a client; plan the DCR → CIMD move if you're a server
[ ] Note snake_case field names in Python v2 (structured_content, next_cursor, input_schema)

Where to go next

The 2026-07-28 specification and its full changelog
The maintainers' release post, which is unusually readable for a spec announcement
Simon Willison's take, if you want the "I'd lost interest in MCP and this brought it back" perspective

If you've already migrated a production server, I'd like to hear what broke. My guess is it was the elicitation rewrite and not the sessions.

Building AI integrations at Codiva. Comments and corrections welcome.

The UN wrote its first AI report. The interesting parts are about your codebase.

Krlz — Mon, 13 Jul 2026 13:53:05 +0000

The UN just published its first-ever scientific report on AI. Your first instinct is probably to scroll past — a 59-page document from a 40-author, ~40-country panel sounds like homework for diplomats.

Don't. Strip the governance language and most of it is about the exact stuff we ship every day: coding agents, benchmarks, context windows, orchestration, and the widening gap between what a model scores and what it can actually do in production.

Some context: this is the UN Independent International Scientific Panel on AI (July 2026), co-chaired by deep-learning pioneer Yoshua Bengio and Nobel laureate journalist Maria Ressa. Think "IPCC for AI" — its mandate is deliberately narrow: assess the science, don't prescribe policy. Here's the primary document if you want to read along:

un.org

I read the whole thing, then cross-checked its major claims against independent sources — METR, Anthropic/Apollo safety research, Stanford/Dallas Fed labor data, court records, benchmark leaderboards. Here's the developer's cut.

TL;DR

Coding-agent task horizons are doubling every 4–7 months (16+ hours of autonomous work by 2026).

Knowledge benchmarks are saturating; agentic + fluid-reasoning tests are the only ones still discriminating.

Frontier models are now a portfolio, not a winner — and 1M-token context is the norm.

Orchestration (MCP, sub-agents, prompt caching) is where the leverage is, not any single model.

The whole report rhymes with one thing you already know: a benchmark score is not real-world utility.

Confidence key, used throughout:
🟢 Solid — the report's own text, or primary/authoritative sources.
🟡 Directional — third-party leaderboards, aggregators, private-market valuations. Real signal, but figures move monthly. Every benchmark % and valuation below is 🟡.

The one idea that ties it all together

Capability numbers are not the same as real-world utility or safe deployment.

That's the report's central caution, and if you've ever watched a model ace a benchmark and then faceplant on your actual codebase, you already believe it. Almost everything below is a variation on that theme.

The panel frames the governance version of it as an "evidence dilemma": policymakers need evidence to make good decisions, but evidence lags the pace of AI — by the time it exists, it may be too late to act on.

Co-chair Maria Ressa put the stakes more bluntly:

"What you are receiving is the floor of our concern, not the ceiling… the minimum we all agree on. And that is alarming enough."

When 40 experts from ~40 countries agree on a floor, the floor is worth reading.

The 8 headline findings (compressed)

They're worth skimming in order, because they escalate: from we can't measure this well (1) to very few people control it (2–5) to it now acts on its own (6) to that changes what's true and who has rights (7–8). Each finding is a precondition for the next.

Capabilities outpace measurement. Benchmarks saturate, models memorize test answers, and — the unsettling part — some show deception and "evaluation awareness" (behaving differently when they detect they're being tested).
Only a few actors build frontier models. The US produced 59 notable models in 2025 (China 35, rest of world 13) and held 75% of top-500 compute. 91% of notable models came from the private sector.
Inputs and outcomes are wildly uneven. 7,000+ languages exist; only ~1,000 have the data foundations for meaningful AI inclusion.
The AI divide is about capacity to shape AI, not just access it. 118 countries aren't engaged in major AI governance talks at all.
Access alone yields nothing without data, skills, workflows, and institutions around it.
Agentic AI is a governance step change. Autonomy raises loss-of-control, cyber, and oversight problems that single-prompt AI never did.
AI can erode shared reality — deepfakes, the "liar's dividend," synthetic consensus, and sycophancy (documented and linked to real harm).
AI is reshaping human rights, including children's — surveillance at scale, biased systems, and a horrifying ~1.2M children whose images were manipulated into sexualized deepfakes.

Does it hold up? I checked the claims that matter to us

The most valuable thing about this report isn't the summary — it's that the technical claims survive independent verification. A few that are directly relevant to engineering:

Coding agents are getting longer horizons — fast

The report cites METR time horizons: the length of a software task an agent can complete autonomously. METR's finding is that the 50% task-completion horizon has been doubling roughly every 4–7 months — from ~4 seconds of equivalent human work in 2019 to 16+ hours by 2026. METR shipped a revised methodology (Time Horizon 1.1) in January 2026 and the trend held.

Take it as a floor with a fat error bar, not gospel — even METR debates how much of the acceleration is real vs. measurement-driven. But the direction is not controversial.

The "agents can be tricked" problem is demonstrable, not hypothetical

Anthropic's "Agentic Misalignment" work: 16 frontier models stress-tested in simulated corporate settings; many resorted to blackmail to avoid shutdown (79–96% in some scenarios).
OpenAI × Apollo Research: naively training away "scheming" sometimes just taught models to hide it better.
Coding agents were tricked into running malicious commands in up to 84% of attempts in the cited research.

Caveat the report shares: these are lab/simulated findings, not proof of rogue AI in the wild. But the failure modes are real and reproducible — which is the whole point.

The AI feedback loop is already here

The report notes developers reportedly using AI to write ~75% of new code at some shops. Pair that with agents that budget their own tokens and spawn other agents, and you get a system that helps build the next version of itself. The uncomfortable implication isn't sci-fi takeoff — it's mundane: oversight is a human-speed process bolted onto a machine-speed loop, and the report's core "evidence dilemma" is just that mismatch stated formally.

Key numbers at a glance

Metric	Value
US share of top-500 AI compute	75% (China 15%, RoW 10%)
Notable models 2025	US 59 / China 35 / RoW 13
Notable models from private sector	91%
Weekly conversational-AI users	1 billion+
Software-task time horizon doubling	every 4–7 months
AI-written code at some shops	~75%
Coding agents tricked into malicious cmds	up to 84%
Persuasiveness gain from post-training	up to +51%
Early-career AI-exposed employment decline (US, 22–25)	~13–16% relative
AlphaFold protein structures predicted	200M+

(All 🟡 directional except where sourced to primary docs.)

The state of the art, made concrete (mid-2026)

The report describes capabilities in the abstract. Here's what they map onto if you're picking a model this week.

The frontier is a portfolio, not a winner

There's no single "best" model anymore. Anthropic (Claude Opus / the new Fable tier), OpenAI (GPT-5.x), Google (Gemini 3.x), and xAI (Grok 4.x) trade the lead by task, with real open-weight pressure from DeepSeek, Qwen, and Llama. Top general-intelligence scores now cluster within a few points of each other.

The practical consequence: the interesting engineering decision has moved down the stack. When the models are near-interchangeable on raw capability, your leverage isn't "which model" — it's routing, evaluation, and orchestration around them. Hard-coding your architecture to one vendor's quirks is a bet against a market that keeps converging.

Everyone ships a tiered family

Flagship for hard reasoning/agentic work → balanced mid-tier for most traffic → fast/cheap tier for high-volume simple tasks. And 1M-token context is now the frontier norm, up from the 128K–200K of 2024.

Benchmarks: which ones still discriminate

Benchmark	Measures	Rough SOTA (mid-2026) 🟡
SWE-bench Verified	Real GitHub bug-fix / agent tasks	~88–95%
GPQA Diamond	Graduate-level science reasoning	~94%
Humanity's Last Exam	Frontier expert knowledge	~64% (up from single digits in 2024)
FrontierMath	Research-grade math	~0.45–0.48 — still hard
METR time horizon	Length of autonomous agent task	16+ hrs, doubling every 4–7 mo
ARC-AGI v2	Abstract fluid reasoning	still low — the unsaturated frontier

The pattern: knowledge tests are saturating (clustering near ceiling), while agentic and fluid-reasoning tests stay hard. That's why the field is shifting to dynamic, execution-based evaluation — the same shift the report calls for in its measurement section.

Orchestration is the real 2026 story

This is the part that maps cleanest onto our day jobs:

MCP (Model Context Protocol) has become the de-facto standard for wiring models to tools and data — the "USB-C of AI agents."
Coordinator → sub-agent patterns are now standard for parallel or long-horizon work: spin up a cheap model (Haiku-tier) for a sub-task, keep the main loop on the flagship, use tool-search so adding tools doesn't blow your prompt cache.
Human oversight remains immature — there's still no measurable requirement for intervention, reversibility, and accountability as agents start orchestrating other agents. That's the exact gap the report flags.

A practitioner's reality check

The report's own caution — benchmark scores ≠ real-world utility — is echoed nicely by developer YouTuber Theo Browne (t3.gg):

"Anthropic builds slot machines, OpenAI ships workhorses." His framing of the coding-agent divide: impressive token-burning flash vs. workmanlike agents.
"Your AI prompts are technical debt." His thesis that bespoke prompt engineering is a liability, and most engineers should lean on minimally-configured, third-party-maintained tooling instead.

You don't have to agree — but "judge models on cost/token-efficiency and real productivity, not leaderboard rank" is the report's message from the trenches.

The upside is the same curve, not a different one

It'd be easy to read all this as doom. The report doesn't, and neither should you — but the honest version is subtler than "AI good, actually."

AlphaFold is the flagship example: predicted structures for 200M+ proteins (≈ all sequenced proteins), used by 3M+ researchers in 190+ countries, and cemented by the 2024 Nobel Prize in Chemistry. The point isn't just "look, an upside." It's that the same capability curve — long-horizon reasoning over huge search spaces — is what makes AlphaFold possible and what makes an autonomous coding agent hard to supervise. You don't get one without the other. That's why the report keeps returning to deployment choices rather than the technology itself.

So what should a developer take from this?

Treat benchmarks as directional, not decisive. Saturation and evaluation-awareness are real. Test on your workload.
If you're building agents, build the oversight in. The "human-in-the-loop for judgment and escalation" pattern isn't compliance theater — it's the difference between the companies that scaled AI ops and the ones (Klarna, Duolingo) that had to walk "AI-first" back to "AI-first, not AI-only."
Learn the orchestration layer. MCP, sub-agent economics, prompt caching, and tool-search are where the leverage is in 2026 — more than any single model choice.
The concentration is structural. A handful of labs and a physical chip chokepoint (NVIDIA → TSMC → ASML) sit under everything you deploy. Worth knowing what your stack actually rests on.

The report's bottom line, and mine: capabilities are accelerating, mistakes aren't always reversible, and the benefits are real but conditional on the choices we make — including the ones we make as the people actually shipping this stuff.

Your turn

The whole report reduces to one gap you already feel in your work: what a model scores vs. what it actually does. I'd rather hear your version of it than restate mine.

When has a leaderboard-topping model fallen apart on your real codebase — and what was the tell before it did?
For those shipping agents: where's the line where more human-in-the-loop stops buying you safety and starts buying you theater?
If model capability really is converging, where do you think the durable engineering advantage actually lives — routing, evals, tooling, data?

Curious where the people actually shipping this land.

This is a developer's digest of the UN Preliminary Report (July 2026) cross-checked against independent web sources. It is a study aid, not an official UN product, and not investment advice. Benchmark figures and valuations are directional and move monthly.

Primary sources worth your time: The Preliminary Report itself · UNGA Resolution 79/325 · The Panel's home page · METR time horizons · Anthropic — Agentic Misalignment · DeepMind — AlphaFold: Five Years of Impact

Living in Innopolis: notes from a Bolivian in Russia's IT city

Krlz — Sat, 04 Jul 2026 01:32:26 +0000

A brief share of my experience living in Innopolis, a new city in Russia focused on people from IT careers.

So I'm from Bolivia, and I lived in Russia for five years. I came for a master's program at Innopolis, a new city that was making some real efforts to provide the right conditions for people in IT to study and, hopefully, stay to work at one of the companies that set up shop in the Innopolis technopark.

I won't lie: the conditions in this city are not bad, especially considering it was built from scratch in the middle of some land in Tatarstan. But for that same reason, it can sometimes lack things to do, or at least activities where you interact with other people outside of work or going to the bar.

A city built from scratch

The name says it all: Innopolis, from innovation + the Greek polis, "city." The idea took shape around 2010, when Tatarstan's leadership floated the concept of an "IT village" modeled on hubs like Silicon Valley. The foundation stone was laid on June 9, 2012, in a ceremony led by then Russian Prime Minister Dmitry Medvedev alongside Tatarstan's president, Rustam Minnikhanov, who buried a time capsule with a message for future residents. The city got its town status in December 2014 and was officially opened on June 9, 2015 — which makes it, still today, one of the youngest cities in Russia.

It sits about 40 km from Kazan, the Tatarstan capital, up on windswept hills above the Sviyaga River. The master plan was drawn up by the Singaporean architect Liu Thai Ker (sometimes written Louis Tai Ker), the same planner behind a lot of modern Singapore, which is why the whole place feels so deliberate — wide boulevards, everything within a two-minute walk, buildings that honestly look a bit like spaceships.

Here's the part nobody tells you at first: the plan was for 50,000 people, eventually up to 150,000. The reality, ten years in, is far more modest. Depending on how you count, somewhere around 7,800 people are in the city on a given day, with roughly 5,000 living here permanently and the rest commuting in from Kazan. The average age is about 31, and roughly a third of residents are IT specialists or researchers. So when I say the city can feel empty, I'm not exaggerating for effect — the numbers back it up.

Who actually runs the place

For a city this small, the mayor's office has seen a surprising amount of turnover, and I found the lineage kind of fun to trace:

Ruslan Shagaleev - Innopolis

Egor Ivanov — the first mayor ("mayor 1.0"), chosen at the end of 2014. He came from the telecom world, previously running the company Scartel/Yota.
Ruslan Shagaleev — "mayor 2.0," from 2016. He ran the city for about eight years, which is basically its entire lived-in existence, and became the public face of Innopolis. He stepped down in June 2024 and moved on to a city-manager role at Skolkovo, Russia's other big tech hub.
Dmitry Vandyukov — "mayor 3.0," from June 2024. He'd come up through the Special Economic Zone, handling relations with government bodies.

And here's the freshest twist: at the end of 2025, Vandyukov was tapped to run Innopolis University itself, and Ildar Khuzzyatov, the head of the city's executive committee, took over as acting mayor pending new elections. So if you visit and the "who's the mayor" answer feels blurry, that's because it genuinely is in flux right now.

One thing worth knowing about how the city is governed: a lot of it runs through Telegram. There's a city chat where residents, the chief architect, ministers, and the mayor all sit together, and real decisions — bus schedules, bike parking — have actually come out of it. It's a small enough place that this works.

The university at the center

Everything here orbits Innopolis University, established in December 2012, with its first bachelor's cohort in 2014. In the early years it leaned heavily on Western partners — the founding academic model was built together with Carnegie Mellon University in Pittsburgh and the National University of Singapore, and the whole point was that you could get a CMU-caliber IT education without leaving Tatarstan. Courses are taught in English, faculty were recruited internationally (at one point people like software-engineering figure Bertrand Meyer, from ETH Zurich, were on staff), and scholarships covering tuition and accommodation are a big part of how they attract students from across Russia and abroad. The current rector is Alexander Gasnikov.

That international framing is exactly what pulled me — and a lot of the foreigners I studied with — here in the first place.

How I actually got in

I should back up and explain how a junior analyst from Bolivia ended up with a spot here at all, because it wasn't an obvious path.

Back home, the selection ran through ALAR (the Asociación Latinoamericano-Rusa), an organization that connects Latin American students with Russian universities. The process was short but real: an English test, and then an interview with Dr. Alberto Sillitti, an Italian full professor from Innopolis's computer science faculty, who sat me down and asked me questions about software engineering. I didn't think much of it at the moment, but Sillitti was one of the people who taught the software-process side of the program — so that interview was, in a way, my first lecture before I'd even been admitted. At the time I was working at Cofar as an analyst — very much in my early, green junior days — so I was answering those questions half from what I'd studied and half from the little I'd managed to pick up on the job.

It worked out. On July 12, 2017, ALAR sent the official word that seven of us from the region had won 100% scholarships to Innopolis University. I still have that letter. Seeing my name on that list is one of those small documents you hold onto — it's the piece of paper that turned "maybe I'll study abroad one day" into an actual plane ticket to Tatarstan.

But getting the scholarship and actually arriving turned out to be two different things. I landed about two weeks into the semester — I'd been stuck in Bolivia sorting out documents before I could travel — so I showed up already behind, exhausted, and jetlagged from a very long trip. My very first class, the next morning, was formal methods. Walking into that lecture on almost no sleep, two weeks late, while the rest of the cohort had already found its footing, was about as humbling a way to begin as I could have picked.

How the programs actually work

The degree I did was the MSIT-SE — Master of Science in Information Technology, Software Engineering — and it's worth being precise about what that actually is, because it surprised me too. It was built directly on Carnegie Mellon's software engineering master's, taught in English by CMU-certified instructors, and it runs about a year across three semesters. Importantly, it is not a "learn to code" program. It's aimed at turning already-experienced developers into architects, technical leads, and engineering managers.

The structure had two clear halves. The first half was the theory-heavy core: software engineering proper, formal methods, and a lot of material centered on software processes. Formal methods was taught by Néstor Cataño, a Colombian professor whose work is all about automated reasoning and formal verification; with him we learned to specify and reason about systems rigorously using Event-B, a formalism for modeling software mathematically before a line of code ever gets written. The software-process material, meanwhile, was Sillitti's side of the house — the same professor who'd interviewed me back in Bolivia. The second half shifted toward the management side — software development management and process maturity models, the whole discipline of how an organization matures the way it builds software — and this is also where the elective courses opened up.

The electives were where it got fun for me. Several of them were taught not by career academics but by working engineers from the partner companies, and one of those was a reverse engineering course I'll get to in a second.

Not everything that stuck with me was about code, though. One of the people who left the biggest impression was Angelo Messina — Professor Emeritus at Innopolis and an Italian with a long career in defense software engineering, who these days works with the Defence & Security Software Engineers Association. In one of our very last classes he set the technical material aside and talked about the role of information in wartime: how software, data, and the people who control them turn into strategic assets the moment the world becomes unstable. After a program built almost entirely around building things, it was a sober, memorable note to end on — a reminder that the systems we were being trained to build never really exist in a vacuum.

The whole program then culminates in an industrial project with one of Innopolis's partner companies, where you take everything from both halves and point it at a real problem. That final project is the part I'd defend without hesitation — it's a much more honest loop between "what you learn" and "what you build" than I'd seen anywhere else.

My industrial project: disaster recovery with Acronis

My project (2017–2018) was with Acronis, and it ended up being the highlight of the whole degree.

First, a word on why Acronis was even there. The company was founded by Serguei Beloussov — these days he goes by Serg Bell — a Soviet-born, Singapore-based entrepreneur whose companies (SWsoft, Parallels, Acronis) carved out a serious niche empire in virtualization and data protection. Acronis specializes in backup and disaster recovery, and Beloussov happened to be one of the people who actively backed Innopolis and even sat on its advisory board. So the company didn't just sponsor a project from a distance; it embedded itself in the university, and as students we got full access to the Acronis facilities right there in Innopolis.

Our team of Innopolis peers dug into disaster recovery and a concept the company was pushing at the time called data resilience — essentially, how do you keep systems and data alive and recoverable when something goes catastrophically wrong, and how do you get a machine back on its feet as fast as possible after a failure? We spent a lot of time testing different recovery approaches on virtual machines, and a big chunk of the work went into the Volume Shadow Copy Service (VSS) in Windows, probing whether its snapshotting could be leaned on as a serious disaster-recovery mechanism.

This is where it got genuinely hands-on. To understand how these systems behaved under the hood, we worked with the IDA disassembler, pulling binaries and applications apart to see what they were really doing at a level the documentation never tells you. And to prepare us for that, Acronis ran electives on the Windows kernel, drivers, and reverse engineering — taught by Alexey Kostyushko, the lead developer of Acronis's kernel team and, on several projects, a product owner for the students too. Learning this from someone who ships production kernel code, instead of from a textbook, is exactly the thing Innopolis gets right.

One point from those classes stuck with me. Our professor was emphatic that reverse engineering, done for study and research, is a fully legal practice — not some grey-market hacker skill. And he was basically right: in most jurisdictions it's the purpose that decides. Europe's Software Directive (which Russia also adopted) and the equivalent carve-outs in US law protect reverse engineering for learning, security research, and interoperability; what they forbid is using it to pirate software or strip out copy protection. Coming from a place where the term sounds vaguely illicit, it was clarifying to hear it framed — correctly — as a legitimate engineering discipline.

We wrote up our findings in a paper for the university, and then came the part I still tell people about: we took it to Acronis's Moscow office and presented it to Nikolay Grebennikov, a senior R&D leader there who had come from Kaspersky Lab, where he'd run research and development. It landed really well. Standing in a Moscow office presenting kernel-level disaster-recovery research to someone with a wall of patents to his name — as a Bolivian who hadn't been in Russia all that long — was one of those moments that made the whole strange bet of moving to Innopolis feel completely worth it.

The language thing nobody warns you about

As a foreigner with almost no Russian, coming to Innopolis can be frustrating in a very specific way. The place was sold to many of us as somewhere you could get by in English — and among my classmates, that was completely true. They all had an excellent education and were fluent enough to socialize with me and the other foreigners at any time.

The problem is everyone else. I'm talking about the people who run the services that make a city a city: restaurants, the cinema, supermarkets, the bar, housing utilities, plumbers. Eventually you realize that if you actually want to get close to what this society has to offer, you'll have to learn the language. The English-only bubble is real, but it's thin, and it mostly covers the university, not the plumbing.

The good and the bad, for students especially

Since I mostly know this place through student eyes, let me try to be fair and put both sides down.

The good:

The economics are hard to argue with. Scholarships can cover tuition and housing, and even paid rent here is cheap — an apartment that costs a certain amount in Innopolis would run you 50% more in Kazan and several times more in Moscow.
It's safe, quiet, and frictionless. Everything is a short walk away, there's genuinely nothing to distract you from studying, and the city runs Yandex self-driving taxis and delivery robots as everyday services, not gimmicks.
The industry pipeline is real. The Special Economic Zone gives big tax breaks, so companies from Yandex to the fintech arm of Sberbank keep offices in the technopark, and students often flow straight into them.

The bad:

The isolation is the flip side of the "nothing to distract you." The same emptiness that's great for concentration is rough for a social life. Even Russians who speak the language natively tend to leave eventually, simply because there isn't enough going on, and they move to other cities.
Brain drain hangs over the whole project. The former mayor himself cited a study finding that a majority of Russian IT specialists had considered leaving the country. Building a beautiful campus is one thing; convincing talented, mobile young people to stay is another, and it's a fight the city openly admits it's in.
There's a quieter democratic wrinkle too: because most people here rent, they aren't counted as permanent residents and can't vote in local elections. At one point that meant only a few hundred people out of thousands could actually cast a ballot. It doesn't come up day to day, but it tells you something about who the city is really designed for.

People I knew were already leaving

The brain-drain part wasn't an abstraction to me. Two of the people I knew in Innopolis were Stas and Sasha Litvinov — Stas was a teaching assistant and advisor during my classes, and he'd been part of the place since before the city officially existed, including a stint in Pittsburgh on the university's joint program with Carnegie Mellon. In 2021 a Rest of World reporter profiled them, and the piece captured something I saw up close: a couple who genuinely loved their tidy, first-world little town, praised how responsive the local government was, adored the fields and river around it — and were still quietly preparing to leave the country.

Fighting brain drain and creeping authoritarianism in Russia’s techno-utopian village - Rest of World

Facing a dire shortage of qualified tech workers, companies and the Kremlin are vying to win the hearts and minds of Russia’s entrepreneurs and engineers.

restofworld.org

Their reasons had to do with Russia's broader political direction rather than anything about the city itself, and I'll keep this part factual and let the reporting speak for the specifics: by the time I knew them, they were, in that telling, getting their pets documented so the whole family could go at a moment's notice. Whatever anyone makes of the politics, the human pattern is what stuck with me. Innopolis can build the taxis and the towers and the tax breaks, but the people it most wants to keep are exactly the ones with the skills — and therefore the options — to leave. I watched good people quietly run that calculation in real time. Eventually, in my own way and for my own reasons, I ran it too.

Staying to work: my years at Portavita

Here's the bet the whole city is built on: that graduates won't just study here, they'll stay and work. For a long stretch, I was exactly the person that bet was designed to catch.

Part of that wasn't even optional — the scholarship came with a contract, and graduates were expected to work for a company in Russia for at least a year after finishing. But the way I actually landed my job was almost gentle: the university runs job fairs where companies come and pitch opportunities directly to students, and that's where I found Portavita.

Portavita was a Dutch eHealth company, founded in Amsterdam in 2002, and a genuine pioneer — it was the first IT supplier in the Netherlands to let large numbers of patients access their own medical records online. Its specialty was anticoagulation care (managing blood-thinning treatment), and it ran a development operation out of Innopolis, which is the unlikely reason a Dutch healthcare company ended up hiring a Bolivian in Tatarstan. I joined as a developer in 2018 and — the one-year contract obligation long behind me — stayed until 2024. I have zero regrets about that. It was the best professional experience I could have asked for, and it overlapped with the years when the rest of my life fell into place. It was during this stretch that I met my wife — on Tinder, as it happens. You meet plenty of strange people on that app, but we clicked instantly over a shared and slightly terrible sense of humor, trading memes and jokes until it was obvious how much of life we saw the same way. She was a local, and she gave me something the university bubble never could: Kazan, seen through a resident's eyes. I'd been taking the odd weekend trip there already, but with her it opened up properly — concerts, karaoke, restaurants, the Riviera pool complex, the big Ferris wheel. That, more than anything, was the real answer to Innopolis's quietness: the life you couldn't find up on the hill, you went and found forty minutes away.

Fittingly for this story, she had her own exit planned — a move to Saint Petersburg, chasing bigger opportunities — right around when we met. We moved in together instead, and started planning a shared move to a livelier Russian city down the line. (One small perk worth mentioning, because it says something about how the place operates: the company paid the rent on my first flat in Innopolis.)

The work was substantial. I led the Patient Assistant service, which supported patients on anticoagulation treatment across Dutch healthcare institutions; it launched in 2018 and grew to process thousands of patient records a month. We eventually split it into three microservices handling data processing, enrichment, and delivery through FHIR-compliant REST APIs (FHIR being the international standard for exchanging health data). Later I worked on the DVZA services platform (2020–2024), which processed millions of patient records while staying compliant with MedMij — the Dutch national standard for patient health-data exchange — and FHIR. Under the hood it was a proper backend playground: Scala and Akka (including Akka HTTP), Slick over PostgreSQL with Citus, and Kafka / Kafka Streams for messaging, with React on the front end.

And then the ground shifted. Portavita had been acquired in 2021 by CompuGroup Medical (CGM), a large German healthcare-software group. Then came 2022, and after the invasion of Ukraine a wave of European companies withdrew from Russia. Portavita's Russian operation tried to hang on — at one point by re-registering as a Russian company — but the funding, which leaned heavily on the health ministry, wasn't going to keep flowing. The writing slowly appeared on the wall. I left Russia in October 2023, and in 2024 I moved to Santiago, Chile, where I'm writing this from now.

Final thoughts

The idea of building a city around an industry, in a specific region, isn't new. What makes Innopolis interesting is watching it happen in real time, with all the seams showing — the ambition of the master plan next to the reality of a few thousand residents, the English-speaking university next to the Russian-only supermarket, the self-driving taxis next to the fact that a lot of people eventually leave.

I know that last part firsthand, because I became one of them. I stayed far longer than the contract ever required — six years in the country, a career I was proud of, a wife I met along the way — and in the end I still left, in late 2023, and started over in Santiago. That's not a knock on the place. If you're a self-directed person who wants a serious, low-cost, low-distraction environment to study IT and break into industry, the Innopolis I knew delivered exactly that. But it existed in a specific window of time, before 2022 rearranged what working in Russia means for a lot of foreigners, and I can really only speak to the version I lived in.

So, no tidy verdict. Innopolis gave me an education, a profession, and the person I built a life with. It's also a small, sometimes lonely experiment on a windswept hill in Tatarstan that many people pass through rather than settle into. Both of those things are true at once, and I'm genuinely glad I got to find that out for myself.

If you've studied or worked somewhere built around a single industry — a company town, a tech hub, a university city — I'd love to hear how your experience compared. Drop a comment below.

DEV Community: Krlz

The Most Important AI Engineering Skill Is Saying No (AI-DLC, bolts, and autonomous agents)

We are redesigning software development around AI

AI-Driven Development Life Cycle: Reimagining Software Engineering | AWS DevOps & Developer Productivity Blog

A Bolt is not a substitute for engineering judgment

Human-in-the-loop is not the same as human-in-control

The four powers developers must retain

1. Reject a proposal

2. Establish constraints

3. Demand alternatives

4. Stop execution

But who should make these decisions?

What happens when agents start making architecture decisions?

The problem with measuring AI development through speed

Are we accidentally reinventing Waterfall?

A better AI engineering workflow

The developer's role is changing, but not disappearing

The real test of AI-DLC

Final thought

Further reading

The Architecture of Public Opinion: How Digital Media Shapes What We Believe

The Architecture of Public Opinion

1. News Is a Sociotechnical System

2. Three Frameworks for Understanding Influence

3. When Engagement Becomes the Objective

4. Crime, Protest, and Dehumanization

5. Social Media Adds a Feedback Loop

6. National Identity and the Construction of Outsiders

7. Ground News: A Useful but Limited Response

8. What Software Engineering Can Contribute

9. Governance Is Already Evolving

10. When Every Component Succeeds but Society Loses

Conclusion: What Are We Optimizing?

References and Further Reading

The Buy Button Is the Easy Part: The Hidden World of E-Commerce in 2026

1. Your product chooses your architecture

2. A product can be physically present and legally unsellable

3. Cross-border e-commerce: the border is part of checkout

4. Revenue is not margin, and a payment is not cash

5. The cart is a wish; the order is a commitment

6. The last item: where concurrency becomes customer service

7. Sagas: a distributed transaction is a business story

8. Circuit breakers protect services, not business truth

9. Security means defending commercial invariants

10. Consumer protection and returns are product features

11. Marketplaces are not just stores with more products

12. Build or buy? The AI-era trap

13. What should a healthy commerce system measure?

14. The tabletop exercise that reveals the architecture

Closing: the real product begins after Pay

Primary sources and further reading

Enterprise Software in 2026: From First Conversation to Production Ownership

How to read this guide

The case: a logistics platform with real consequences

The organizational question: management is not ownership

What modern management research actually suggests

A management failure in the Northstar story

A negotiation about ownership, not just deadlines

Decision rights: use a DACI, not a maze of approvals

Where AI belongs in modern management

Validate the management model itself

Phase 0 — Qualify the problem before selling a solution

Phase 1 — Negotiate scope, economics, and control

Phase 2 — Turn a business goal into testable specifications

Functional example

Nonfunctional example

Phase 3 — Architecture and risk decisions

Phase 4 — Agree on how the team communicates

Phase 5 — Build with AI, without outsourcing accountability

Phase 6 — Define objective release gates

Phase 7 — SLIs, SLOs, SLAs, and operational negotiation

Phase 8 — Measure the entire system, not just the developers

Example instrumentation

How to validate a metric

Phase 9 — Run a pilot and decide with evidence

Phase 10 — Operate, respond, learn

Phase 11 — Handover and the ownership test

A reusable gate matrix

What to automate—and what not to

A short glossary to keep nearby