DEV Community: Krlz

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.

AI Made Code Free. So Why Are the Giants Still Winning? (And where solo devs actually beat them)

Krlz — Wed, 01 Jul 2026 21:51:10 +0000

Everyone keeps saying AI will let a solo developer take down the giants. And everyone keeps saying the giants will just absorb everything. Both takes are wrong, and I spent a while reading the actual 2025 data to figure out why.

I pulled from four of the biggest developer datasets of the year:

DORA 2025 State of AI-Assisted Software Development (Google Cloud, ~4,867 respondents)
Stack Overflow 2025 Developer Survey (49,009 respondents)
GitHub Octoverse 2025 (behavioral data across 180M+ developers)
JetBrains State of the Developer Ecosystem 2025 (24,534 developers)

Here's the honest synthesis. It's more useful than either hype narrative.

The one-sentence thesis

AI collapsed the cost of writing software to near zero. It did not collapse the cost of distribution, trust, support, or being liable when it breaks — and those are ~80% of what a software business actually is.

So the effect isn't "solos beat giants." The effect is that the middle got hollowed out. The 10-person, VC-funded, me-too startup building a feature is the loser of this era — squeezed from below by a solo who ships the same thing for free, and from above by a giant who bundles it. Solos and giants both survive. The undifferentiated middle doesn't.

"AI is an amplifier, not an equalizer"

This is the single most important finding of 2025, and it comes straight from DORA:

"AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones."

Read quickly, that kills the "AI levels the playing field" fantasy. AI rewards whoever already has good practices — not whoever is scrappiest.

But read one layer deeper and it becomes the best available argument for the small team. DORA found the key enabler is independence of action — "the ability to develop, test, and deploy value independently, with little or no coordination cost." In an Adidas pilot they cite, teams in loosely-coupled architectures saw 20–30% productivity gains; teams tightly coupled to legacy ERP saw little or no AI benefit at all.

Who has maximum independence and zero coordination cost? A solo founder, by definition. Who drowns in coordination overhead? A giant. So the amplifier finding, taken seriously, says: AI most benefits whoever has the least organizational drag. The giant still wins on distribution, capital, and enterprise trust — but not on per-engineer AI leverage. Their own bureaucracy taxes it.

Everyone uses AI. Fewer and fewer trust it.

Adoption is settled. Four sources, one tight band:

Source	AI adoption
DORA	90% use AI at work
JetBrains	85% regularly use AI
Stack Overflow	84% use or plan to (up from 76%)
GitHub (behavioral)	~80% of new devs use Copilot in week one

But here's the twist the hype cycle skips. Trust is going the opposite direction. Stack Overflow 2025:

Favorability toward AI fell 72% → 60% year over year.
46% now distrust AI accuracy vs. only ~33% who trust it (distrust was 31% a year ago).
66% cite "AI solutions that are almost right, but not quite" as a top frustration.
~45% say debugging AI-generated code takes more time.

Stack Overflow's own three-word summary — "willing but reluctant" — is the truest description of the 2025 developer relationship with AI. Everyone uses it. Fewer believe it.

Agentic coding is a frontier, not the norm (yet)

If you live on Twitter you'd think everyone is running autonomous agents. The data says otherwise:

DORA: 61% "never" use agent mode — the least-adopted way to use AI.
Stack Overflow: only ~31% currently use AI agents; 38% don't plan to.
JetBrains: 85% use AI, but only 44% have integrated it into their workflow — "AI use isn't systematized. Developers are just using it ad hoc."

And yet the frontier is exploding: GitHub logged 1M+ pull requests from its Copilot coding agent in just May–September 2025.

So the "solo operating at team scale via agents" story is real but leading-edge, not median. The good news for founders: the leading edge is exactly where competitive solo builders already live.

The unifying insight: usage ≠ results

Put all four datasets together and one theme dominates:

AI adoption is universal. Converting it into results is not. The differentiator is discipline and systematization — not access to the tool.

DORA says it as "amplifier, not equalizer." JetBrains says it as "85% use it, 44% have integrated it." Stack Overflow says it as "66% fight almost-right output." Since everyone now has the tool, the tool is not the edge. The practices around it are — taste, review discipline, distribution, trust. That's the exact terrain where a solo-vs-giant outcome is actually decided.

The counter-hype stat you should tattoo somewhere

DORA cites the now-famous METR study: experienced open-source developers were measured 19% slower with AI tools — while believing they were 20% faster.

If you're a solo founder, you are the least-checked person in your own loop. Nobody's there to catch you shipping fast-feeling, actually-slower work. Which is why, for a solo, tests and small batches aren't bureaucracy — they're the substitute for the code review you no longer have.

Clean architecture is now a business decision

Here's the part that surprised me most. AI makes architecture matter more, not less:

AI generates plausible code fast, so you accumulate unmaintainable "slop" faster. DORA found friction doesn't vanish — it moves, "from manual grind to deciding and verifying... assessing code that looks remarkably similar to correct code."
The single biggest risk to a solo AI business isn't competition — it's platform risk. If your model calls sit behind a clean adapter interface, a provider price hike is a config change. If they're smeared through your codebase, it's an existential rewrite.
DORA found frequent commits + easy rollback act as a "psychological safety net" that makes high-velocity AI work safe.

For a solo in 2026, boring, provider-agnostic, modular-monolith architecture is a survival tool. Running microservices as a one-person team is cosplaying as Google and paying the ops tax for nothing.

The map is shifting to the Global South

The competitive geography is changing fast (GitHub Octoverse 2025):

GitHub crossed 180M+ developers, adding ~36M in 2025 — "a new developer every second."
Net-new devs by region: APAC +13M, Europe +6.3M, Africa & Middle East +3.4M, LATAM +3.2M.
India added 5.2M devs (14% of all new accounts), and already has the largest open-source contributor base in the world — projected to pass the US in total developers around 2030.
Brazil is #4 globally (6.89M). India, Brazil, and Indonesia more than quadrupled their dev counts in five years.

The next decade's solo founders are disproportionately Indian, Brazilian, Indonesian, and African — not Californian. And that matters, because the strongest wedge against a US giant is "not-American, self-hostable, cheaper, localized, compliant with our law."

If you're building from Latin America (I am), the playbook writes itself:

Cost base local, revenue base global. Own the one thing US giants refuse to build — deep local compliance, payments, and language integration (electronic invoicing, local payment rails like Webpay/Flow/MercadoPago, real Spanish/Portuguese product sense). On a purchasing-power basis, a competent LATAM solo dev in 2026 is in a better risk-adjusted position than a mid-level engineer at an SF startup.

Open source is bigger than ever — and more fragile than ever

Both things are true at once (GitHub Octoverse):

255,000 new open-source contributors in March 2025 — the largest single month on record. 1.128B contributions (+13% YoY).
4.3M AI-related repos; generative-AI monthly contributions peaked at 6.28M in June 2025 (+188% YoY).
But only ~63% of public repos even have a README. The maintenance layer is thinner than ever.

And the licensing war (Elastic→OpenSearch, HashiCorp→OpenTofu, Redis→Valkey) settled on one pragmatic lesson: open source is a distribution and trust tactic, not a business model. Every solo OSS success — Plausible, Sidekiq, Ghost, PostHog, Supabase — monetizes hosting, a commercial tier, or a foundation. None sells the source. Source-available/commercial licensing is respected now. You don't owe AWS a free gift.

The solo playbook for 2026

Pick a niche too small for a giant to defend, big enough for one person to live on (a ~$1–5M/yr TAM: your career, their rounding error).
Decide monetization before you open the source. "Figure it out later" kills companies.
Build in the open for trust; license to stay alive.
Keep architecture provider-agnostic and boring. It's a business decision.
Localize where giants won't — language, payments, compliance.
Assume you'll be Sherlocked. If your only moat is the feature, the giant ships it next quarter. Build a relationship moat they can't clone.
Believe the measured results, not the feeling. (Remember the METR 19%.)

TL;DR

AI made building nearly free; distribution, trust, and support are still expensive — and that's where the contest actually happens.
AI is an amplifier, not an equalizer. Its benefit is gated by independence of action — the axis where solos structurally beat giants.
Adoption is universal; trust is falling. "Willing but reluctant."
Agentic coding is frontier, not median — but the frontier is where founders win.
Clean architecture is a survival tool, because platform risk is the real killer.
The builder base is going global — and localization is the wedge giants won't touch.

The giants own the pipes. But the pipes were never the interesting part. Taste, trust, community, and focus were — and those still don't come in an API.

Sources: DORA 2025 State of AI-Assisted Software Development; Stack Overflow 2025 Developer Survey; GitHub Octoverse 2025; JetBrains State of the Developer Ecosystem 2025; METR "Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." All figures are self-reported perceptions unless noted; DORA is explicitly observational, not causal. What's your read — is the middle really getting hollowed out? I'd love pushback in the comments.

Spec-Driven Development in 2026: What It Is, the Tooling, and How Teams Actually Use It

Krlz — Fri, 19 Jun 2026 15:20:48 +0000

A field guide to the practice that's reshaping how software gets built with AI agents.

TL;DR — Spec-Driven Development (SDD) makes a precise, executable specification the source of truth and treats code as a generated, verifiable artifact. The spec declares intent; the code realizes it. In 2026 it went mainstream because AI agents are great at writing code and terrible at guessing what you meant.

Jump to: Why now · Specs vs. executable specs · Maturity model · Workflow · Tooling · EARS · Worked example · Caveats · Bottom line

Why now? The "vibe coding" backlash

The movement defines itself against "vibe coding" — the term Andrej Karpathy popularized in early 2025 for loosely prompting an AI and shipping whatever comes back. Vibe coding is great for throwaway prototypes and miserable for anything that has to be maintained.

SDD is the disciplined counterweight: if AI writes most of the code, then the specification becomes the highest-leverage artifact a human produces. The skill that matters shifts from typing the implementation to defining the intent precisely enough that a machine can't get it wrong.

Raw specs vs. executable specs

This is the single most important distinction in the whole topic — and the one most "SDD explainers" skip.

	Traditional design docs	SDD specs
Read by	Humans	Humans and agents
Enforcement	Advisory — devs may diverge	Executable — tests fail on drift
Lifecycle	Goes stale, becomes archaeology	Living, continuously validated
Lives in	A wiki nobody opens	The repo + CI/CD

"Traditional specs are read by humans, while SDD specs are executed as BDD scenarios, API contract tests, or model simulations."
— Deepak Babu Piskala, Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants (arXiv, Jan 2026)

[2602.00180] Spec-Driven Development:From Code to Contract in the Age of AI Coding Assistants

The rise of AI coding assistants has reignited interest in an old idea: what if specifications-not code-were the primary artifact of software development? Spec-driven development (SDD) inverts the traditional workflow by treating specifications as the source of truth and code as a generated or verified secondary artifact. This paper provides practitioners with a comprehensive guide to SDD, covering its principles, workflow patterns, and supporting tools. We present three levels of specification rigor-spec-first, spec-anchored, and spec-as-source-with clear guidance on when each applies. Through analysis of tools ranging from Behavior-Driven Development frameworks to modern AI-assisted toolkits like GitHub Spec Kit, we demonstrate how the spec-first philosophy maps to real implementations. We present case studies from API development, enterprise systems, and embedded software, illustrating how different domains apply SDD. We conclude with a decision framework helping practitioners determine when SDD provides value and when simpler approaches suffice.

arxiv.org

The maturity model: three levels

Almost every serious 2026 source converges on the same ladder. Pick the rung you actually need — not the most aggressive one.

Spec-First — Specs seed the initial generation, then code is allowed to drift. Good for AI-assisted features and prototypes. Low overhead, no long-term guarantees.
Spec-Anchored — Specs and code evolve together as living documentation; automated tests enforce alignment. Piskala's paper calls this "the sweet spot for most production systems."
Spec-as-Source — Humans edit only the spec; code is fully generated and never hand-edited. Eliminates drift by design — but demands mature, trusted generation tooling. Still aspirational for most teams.

flowchart TD
  A["<b>Spec-First</b><br/>specs seed generation,<br/>code is allowed to drift"]
  B["<b>Spec-Anchored</b> 🎯<br/>specs + code evolve together,<br/>tests enforce alignment"]
  C["<b>Spec-as-Source</b><br/>humans edit only specs,<br/>code is fully generated"]
  A -->|"add living tests<br/>+ CI enforcement"| B
  B -->|"trust generation,<br/>stop hand-editing code"| C
  style B fill:#dff3e4,stroke:#2ea44f,stroke-width:2px

🎯 Recommendation: aim for spec-anchored. Spec-as-source is where the hype lives; spec-anchored is where the value is today.

The canonical workflow

Every major tool implements roughly the same pipeline, with a human review gate at each phase boundary to stop drift before it compounds:

flowchart LR
  C[constitution] --> S[specify] --> CL[clarify] --> P[plan] --> T[tasks] --> I[implement] --> A[analyze]

Phase	What happens
Constitution	Project-wide rules the agent must always obey (language, frameworks, testing, deps)
Specify	What and why: user stories + acceptance criteria. No tech choices yet
Clarify	The agent surfaces ambiguities before any planning
Plan	How: architecture, data models, technical decisions
Tasks	Decompose the plan into atomic, independently-shippable items
Implement	Execute tasks, verifying each against its acceptance criteria
Analyze	Cross-check spec ↔ plan ↔ tasks for consistency

⚠️ Golden rule: never skip from spec straight to code. Review the plan before task decomposition; review the tasks before implementation.

The tooling landscape (2026)

Tool	Strengths	Best for
GitHub Spec Kit	Open-source, model-agnostic, the reference implementation	Teams avoiding vendor lock-in
AWS Kiro	Agentic IDE with automated guardrails ("hooks"), deep AWS integration	AWS-native / serverless shops
Claude Code (cc-sdd)	Native `/sdd:specify`, `/sdd:plan` slash commands, terminal-first	Solo devs, CLI workflows
Cursor (Plan Mode)	IDE-first, inline diff review, MCP support for Spec Kit	Teams prioritizing UX
OpenSpec	Lightweight, framework-agnostic, Markdown + YAML	Indie devs, minimal tooling
BMAD-METHOD	Community methodology, constitution + multi-agent role-play	Teams wanting a flexible framework
Tessl	Compliance-focused, audit trails, regulated templates	Fintech, healthtech
Google Antigravity	"Agent-first," specification-constrained autonomy	Teams exploring deep agent autonomy

The open-source reference everyone benchmarks against:

github / spec-kit

💫 Toolkit to help you get started with SDD or any other process!

🌱 Spec Kit

Build with a spec, fix a bug, or assess an idea — with your coding agent.

English · 简体中文 · 日本語

Spec Kit is an open source toolkit that gives AI coding agents structured processes, reusable templates, and documented outcomes. Start with one of the three processes below, customize it, or bring your own.

Choose your process

What you need	Process	Outcome
Build a feature or application	Spec-Driven Development	A specification carried through planning, implementation, and convergence
Diagnose and repair broken behavior	Bug fixing	An assessed cause, scoped fix, and recorded verification
Decide whether an idea deserves investment	Idea assessment	An evidence-backed go, clarify, or stop decision

These are independent entry points, not three mandatory phases. SDD ships in core; bug fixing and assessment are bundled extensions you install when needed.

Get started

You need Python 3.11+, uv and a supported AI coding agent…

View on GitHub

Supporting standards & frameworks that predate the AI wave but power SDD

BDD: Cucumber, SpecFlow, Behave (Gherkin / Given-When-Then)
API contracts: OpenAPI/Swagger, GraphQL SDL, Protocol Buffers, AsyncAPI
Contract testing: Pact, Specmatic
Model-based design: Simulink, SCADE

None of these are new. SDD's contribution is wiring them together as the primary artifact an AI agent generates from — not the documentation you write afterward.

30-second tool-selection rubric

Already in Claude Code? → Spec Kit + cc-sdd skills
In Cursor? → Plan Mode + AGENTS.md + Spec Kit via MCP
AWS shop? → Kiro
Regulated industry? → Tessl
Want minimal ceremony? → OpenSpec

EARS: how to write specs an LLM can't misread

EARS (Easy Approach to Requirements Syntax) is the de facto standard for acceptance criteria that are unambiguous to humans and models. Five patterns cover almost everything:

Pattern	Template	Example
Ubiquitous	The system shall …	The system shall log every auth attempt.
Event-driven	WHEN … THE system SHALL …	WHEN a user submits the login form THE system SHALL validate credentials.
State-driven	WHILE … THE system SHALL …	WHILE a sync is running THE system SHALL show a progress indicator.
Unwanted behavior	IF … THEN …	IF validation fails 3× THEN lock the account for 15 min.
Optional	WHERE … THE system SHALL …	WHERE MFA is enabled THE system SHALL require TOTP.

The payoff: criteria written this way map almost 1:1 onto test cases — which is exactly what makes the spec executable rather than advisory.

A worked example: "magic-link login"

Talk is cheap; here's a (trimmed) end-to-end slice so the artifacts are concrete.

📄 spec.md (excerpt)

## Feature: Passwordless magic-link login

### Acceptance criteria (EARS)
- WHEN a user submits a valid email
  THE system SHALL send a one-time login link valid for 15 minutes.
- IF a login link is used more than once
  THEN the system SHALL reject it with HTTP 410 Gone.
- WHERE the email is not associated with an account
  THE system SHALL still return HTTP 202 (no account enumeration).
- THE system SHALL store link tokens hashed, never in plaintext.

### Out of scope
- Social login, SSO, password fallback.

🏗️ plan.md (excerpt)

## Stack
- Node 22 + Fastify, Postgres 16, Redis for token TTL.

## Data model
- magic_tokens(id, user_id, token_hash, expires_at, consumed_at)

## Decisions
- Tokens = 32 bytes CSPRNG, stored as SHA-256 hash.
- 202-for-unknown-email enforced at the controller layer.

✅ tasks.md (excerpt)

- [ ] T1  migration: magic_tokens table
- [ ] T2  POST /auth/magic-link  (issue + email)   refs spec §1, §3
- [ ] T3  GET  /auth/verify      (consume + session) refs spec §2
- [ ] T4  contract tests for 202 / 410 paths
- [ ] T5  rate-limit issue endpoint (5/min/IP)

Notice the thread: each task cites the spec clause it satisfies. That traceability is the whole point — when a test fails, you know which intent broke.

Recommendations & best practices

Constitutional foundations

Commit AGENTS.md or .specify/memory/constitution.md before the first spec.
Codify project-wide decisions as ubiquitous EARS statements: "The system shall use TypeScript strict mode."

Specification discipline

One feature = one spec directory (specs/NNN-feature-name/).
Keep specs to 1–3 pages; split if larger.
Use explicit "out of scope" sections to bound the agent's exploration.
Write in domain language (business intent), not implementation detail.

Phase boundaries

Never jump spec → code. Review the plan, then review the tasks.

Documentation & traceability

Cite specs in commits: feat(auth): magic link, refs specs/004-magic-link/spec.md.
Treat specs as durable — they outlive the generated code.
Run pre-flight /checklist passes for security, accessibility, observability.

The honest caveats

SDD has real skeptics, and they're worth more than the hype:

It can be old wine in new bottles. Brandon Kindred's "Same Patterns, New Hype" (2026) argues SDD is largely waterfall/contract-design rebranded — and that "the value is the thinking you do while writing the spec, not the tooling around it."
Drift and hallucination don't disappear. Thoughtworks stresses that executable code remains the source of truth requiring maintenance, explicitly rejecting the "specs alone suffice" view. They place SDD in the "Assess" ring of their Technology Radar — not "Adopt."
Over-specification defeats the purpose. When a spec becomes pseudo-code, you've written the program twice.
False confidence. Matching a wrong spec satisfies no real requirement.
Tooling complexity can add ceremony without proportional value.

✅ When SDD is worth it / ❌ when to skip it
Worth it: using AI coding assistants · complex requirements · multiple maintainers · integration-heavy or regulated systems.

Skip it: throwaway prototypes · solo, short-lived projects · exploratory work where requirements are still unknown.

What the data says (read with a skeptic's eye)

Vendor-reported numbers should be treated as directional, not proven. With that caveat: early adopters (GitHub, AWS) report meaningfully higher first-pass success from agents working off a good spec, and Piskala's paper cites error reductions on the order of tens of percent when LLMs work from refined specs versus loose prompts. The consistent, less-disputable finding is a shift in where humans spend time — away from typing implementation, toward review and clarification.

If you take one number away, make it this one: the spec is now where the thinking happens.

The bottom line

In 2026, SDD is best understood not as a tool but as a discipline: when agents write the code, the spec is the most leveraged thing a human can produce. The pragmatic path:

Target spec-anchored, not spec-as-source.
Write acceptance criteria in EARS.
Keep code as the source of truth and tests as the enforcer.
Use the tooling (Spec Kit, Kiro, cc-sdd) to enforce the loop — not to replace the thinking.

Building with SDD already? What's worked and what's been pure ceremony? Drop it in the comments. 👇

📚 Sources

Compiled June 2026.

The 6-Month Clock Ran Out — Are Companies Full AI Yet?

Krlz — Mon, 06 Apr 2026 15:17:51 +0000

So during this year, many changes have been introduced in software development. A big disruption is coming, and some new terminology — SDD, IDD, Cognitive Debt, DORA, the "new" XP, Agentic Programming, and others — is being promoted, sometimes used as a slogan.

I personally feel it is many times used as a strong advertising campaign, taking advantage of the panic of people feeling they might be about to lose a train, with severe consequences in their professional careers if they don't catch up. This might be true to a certain level.

But let's look at the actual numbers: in early 2026, AI coding tools have reached 90% adoption among developers, yet only 1% of companies consider themselves mature in AI usage. Everyone has the tools — almost nobody has figured out the practices.

The debate between "AI enthusiasts" and "fundamentals defenders" misses the point entirely. The real question isn't whether to use AI tools, but how companies must restructure their practices, teams, and culture to use them without accumulating what Thoughtworks now calls cognitive debt.

So let's cut through the noise.

What the Data Actually Says

Google's 2025 DORA State of AI-Assisted Software Development report is probably, for now, the most rigorous report made about the current experience of AI in companies. It surveyed nearly 5,000 technology professionals worldwide and includes over 100 hours of qualitative interviews, combining both quantitative and qualitative data. Some clear conclusions can be taken from it: the real value comes from platform quality, workflow clarity, and team alignment. The organizational capability to use AI well is the differentiator — not the tools themselves.

AI is an amplifier, not a fixer. Strong teams get stronger. Struggling teams get worse faster.

The numbers tell the story:

90% of software professionals now use AI tools
80%+ say AI enhanced their productivity
30% report little or no trust in AI-generated code
Seven organizational capabilities were identified that magnify the positive impact of AI

That last point is key. It's not about which AI tool you pick. It's about what your team already looks like before AI enters the picture.

From Vibes to Discipline

So if the tools aren't the answer, what is? To understand where things are heading, it helps to see where they just came from.

In February 2025, Andrej Karpathy — co-founder of OpenAI and former AI leader at Tesla — posted on X about a new way of coding: "fully give in to the vibes, embrace exponentials, and forget that the code even exists." The post got over 4.5 million views. Within weeks, the term "vibe coding" had spread from social media to The New York Times, Ars Technica, and The Guardian. By November, Collins Dictionary named it Word of the Year 2025. By mid-2025, The Wall Street Journal reported professional engineers were adopting it for commercial use cases.

But the honeymoon didn't last. By late 2025, Thoughtworks Technology Radar observed the concept fading in favor of more disciplined approaches — concerns about code quality, security, and maintainability in production couldn't be vibed away.

What's replacing it? Three approaches are gaining traction:

Intent-Driven Development (IDD) flips the focus: the quality of your specification determines the quality of your outcome. Teams restructure around 60% product judgment, 30% engineering architecture, and 10% design precision. The specification becomes the primary artifact, not the code.

Spec-Driven Development (SDD) takes a similar angle but draws a clearer line: humans own the design, AI owns the implementation. The key discipline is writing specifications good enough that AI can execute them correctly.

Agentic Engineering, coined by Karpathy himself in early 2026 as the successor to vibe coding, is about designing systems where AI agents plan, write, test, and ship code under structured human oversight. The risk it addresses is real: an agent writing 1,000 PRs/week with a 1% vulnerability rate creates 10 new vulnerabilities weekly.

All three share a common thread: the human's job shifts from writing code to defining intent clearly and verifying outcomes rigorously.

The Return of XP

Here's something nobody expected: Extreme Programming is back.

Kent Beck describes TDD as a "superpower" when working with AI agents. The reasoning is simple — unit tests are the most reliable way to prevent AI from introducing regressions. When AI generates code, the test suite becomes your verification layer. Not code review. Not manual testing. Tests.

The Pragmatic Engineer newsletter and the Thoughtworks Deer Valley retreat both highlight this resurgence. The practices that felt "too rigorous" five years ago are now the safety net that makes AI velocity sustainable. It turns out the answer to "how do we trust AI-generated code?" was already here — we just stopped using it.

What the Industry Leaders Are Saying

In February 2026, approximately 50 tech leaders — including Kent Beck and Martin Fowler — gathered at Thoughtworks' Deer Valley retreat. It was the 25th anniversary of the Agile Manifesto, and the question on the table was direct:

"If AI handles the code, where does the engineering actually go?"

Their conclusions reshape how we think about engineering teams:

Cognitive debt is the new technical debt. When AI generates code that nobody fully understands, you accumulate cognitive debt — and it compounds just like technical debt. "Velocity without understanding is not sustainable."

Agent Topologies. Just as Team Topologies redesigned how human teams interact, organizations now need to design how AI agents fit into their workflows. Who owns what the agent produces? How do agents interact across teams?

Tiered Code Review. Not all code needs the same scrutiny. Reserve human reviews for high-risk components and rely on strong CI/CD guardrails for the rest.

Staff engineers become supervisors. The senior role shifts toward agent orchestration and governance — designing the systems within which AI operates, not writing the code it produces.

Teams Are Shrinking, Roles Are Shifting

These aren't just theoretical changes. They're already reshaping how companies hire and organize.

Teams are shrinking dramatically. One Series C startup restructured from 12 engineers to 3 using AI tools, with a 40% increase in velocity. New roles are appearing — AI Workflow Engineers, PromptOps Specialists, Agent Orchestration leads — titles that didn't exist two years ago.

The old hiring model — bring in juniors cheaply, train them up — is being replaced by hiring fewer senior people and equipping them with AI tools. AI widens the gap between strong and weaker engineers rather than leveling the playing field.

Interview practices are changing too. Organizations are replacing generative coding tests with Review Simulations — candidates audit pre-generated, flawed codebases. The skill being tested: can you catch what AI gets wrong?

And there's a quiet crisis brewing for mid-level engineers. New graduates are more productive with AI tools — they have no habits to unlearn. Senior engineers benefit from deep experience to guide AI. Mid-career professionals risk being squeezed from both sides. Addy Osmani from Google warns this is one of the most underappreciated shifts happening right now.

Measuring What Matters

With all these changes, the old metrics stop making sense. When AI can generate unlimited code, measuring output becomes meaningless.

What We Used to Measure	What Actually Matters Now
Velocity / story points	Cycle time
Lines of code	Lead time to production
PRs merged	Defect escape rate
Story completion rate	Cognitive debt indicators

The shift is from output to outcomes: how fast does value reach users, and how reliably?

The Fundamentals Debate Is Over

If there's one thing every major source — DORA, Thoughtworks, Gartner, Google — agrees on, it's this: AI makes fundamentals more important, not less.

You need to understand architecture to design scalable systems and guide AI effectively. Developers who skip algorithms, system design, or manual debugging "lose problem-solving muscle memory."

"The best software engineers won't be the fastest coders, but those who know when to distrust AI." — Addy Osmani, Google

Gartner backs this up with a stark warning: by 2028, prompt-to-app approaches by citizen developers will increase software defects by 2,500%. The quality crisis won't come from teams that invest in fundamentals — it will come from those that skip them.

As Satya Nadella put it: "Getting the fundamentals right matters a lot." This isn't a compromise between AI and fundamentals. It's the only approach that works.

Where to Start

If you're leading a team or a company, here's a practical starting point:

Read the DORA 2025 AI Report (free). Assess where your organization actually stands.
Invest in testing culture before AI tooling. TDD, integration tests, strong CI/CD — these are what make AI velocity safe.
Adopt Spec-Driven Development. Better specifications mean better AI output. It's that direct.
Tier your code review. Human review for high-risk paths, automated guardrails for the rest.
Rethink how you hire. Test for review and debugging skills. Can candidates spot what AI gets wrong?
Measure outcomes, not output. Cycle time and defect escape rate over velocity and story points.
Read the Thoughtworks Deer Valley retreat takeaways (free PDF). It's the most forward-looking strategic document on this topic.

Resources

The tools are here. The question was never "should we use AI?" — it was always "do we have the engineering culture to use it well?" The answer to that question determines everything.

DEV Community: Krlz

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

Further reading and research basis

When Code Becomes Cheap, Ownership Becomes Everything

The software factory was built around scarcity

AI changes the economics of implementation—not necessarily delivery

Outsourcing contracts are changing—but causality remains uncertain

Four regions, different market signals

🇺🇸 North America: Pressure on transactional delivery

🇨🇱 South America: Beyond cheaper nearshore developers

🇪🇺 Europe: Continuity and specialization

🇮🇳 Asia: Scale is not disappearing

A production incident reveals the ownership gap

When AI-generated output becomes a review bottleneck

What is a core engineering team?

What does research say about ownership?

AI doesn't eliminate engineering responsibility

The economics of ownership

A small core team with a large capability surface

Outsourcing is not one business model

The strongest counterargument: outsourcing can improve ownership

Three futures for the software factory

1. Commodity factories face pressure

2. Specialized providers become more valuable

3. External teams become genuine product teams

Measure ownership, not output volume

A practical test for product ownership

The question we should be asking in 2026

Reading the evidence carefully

Sources and further reading

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

A little history: why all those boxes existed

A diagram can help you think before it helps you document

Mind maps are a great place to start

A few UML diagrams still earn their place

Why I like writing diagrams as text

Meet Codiva PlantUML

A couple of things I learned rebuilding it

Keep the JVM warm

A successful response can contain an unsuccessful diagram

Give one of your ideas a diagram

References and further reading

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

Four layers that are easy to mix up

MCP and A2A: where each fits

What is actually new in 2026?

A2A now has a stable baseline and a CLI

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

Why the A2A CLI

Where `develop` still earns its place