DEV Community: Senthil Kumar MS

How to Measure Developer Experience and Productivity: The SPACE Framework for Leaders

Senthil Kumar MS — Tue, 03 Nov 2026 16:00:08 +0000

Short answer

You cannot measure developer productivity with one number. Use the SPACE framework: pick a few metrics across its five dimensions, combine short developer surveys with system data from your delivery tools, look at trends per team, and act on what you find. Never rank individuals on these metrics.

5 - SPACE dimensions of developer productivity
1 - metric is never enough: the authors warn against single measures
2 - data sources to combine: developer surveys and system data
90 days - a natural cadence for a short developer survey

Developer productivity is best measured with a balanced set of signals, not a single score. The SPACE framework, published by researchers from GitHub, Microsoft and the University of Victoria, groups those signals into five dimensions. Using it, leaders can see whether engineers are effective, sustainable and well supported, instead of counting commits that say little about value.

This guide is for CTOs, VPs of engineering and business leaders who need an honest answer to how to measure developer productivity. It covers which developer productivity metrics to track, how SPACE compares with DORA metrics and DevEx, six use cases where measurement supports a real decision, and how to report engineering productivity to a board without damaging trust.

Why single metrics fail

Every simple productivity number breaks when used as a target. Lines of code reward verbosity. Story points get inflated. Tickets closed reward splitting work. Even good delivery metrics can be gamed if they are tied to individual performance reviews. The SPACE authors put it directly: productivity cannot be captured by a single metric or dimension.

There is a second reason. Productivity has a human side that system data cannot see: interruptions, unclear priorities, slow reviews and burnout. Surveys reveal those causes before they show up as attrition or slower delivery.

The five SPACE dimensions

DimensionWhat it coversExample metricsSatisfaction and well-beingHow fulfilled, healthy and happy developers are with their work and toolsSurvey scores, intent to stay, burnout signalsPerformanceThe outcomes of the work, such as quality and impactChange fail rate, customer-reported defects, reliabilityActivityCounts of actions and outputsDeployments, pull requests, reviews (as context only)Communication and collaborationHow people and teams work togetherReview turnaround, onboarding time, knowledge sharingEfficiency and flowAbility to make progress with minimal interruptions and delaysChange lead time, focus time, hand-off wait time

A practical starting point is three to five metrics drawn from at least three dimensions, for example a satisfaction survey score, change lead time and review turnaround. Delivery metrics from DORA cover much of performance and flow already.

The most common question after choosing dimensions is which framework to use. DORA vs SPACE is a false choice. They answer different questions, and DevEx adds a third lens, so most engineering organizations end up combining parts of all of them.

Combine surveys with system data

System data shows what happens: lead time, deployments, review times, incidents. It is objective but blind to causes.
Surveys show why: friction in tools, unclear requirements, too many meetings. They are subjective but explain the numbers.
Together they let you spot a problem in the data and understand it from the people closest to it.

Keep surveys short, perhaps ten questions, anonymous and stable over time. Ask about the friction points you can act on: build and test speed, review delays, environment setup, documentation, interruptions and clarity of goals.

The DevEx authors make the same point with two kinds of measure: perceptions, meaning how developers feel about their work, and workflows, meaning how systems and processes behave. Neither tells the whole story alone. Builds may look fast in your tools while developers still find them disruptive, because the wait always lands at the wrong moment. When the two disagree, treat that as the finding worth investigating.

For a decision maker, the useful part of that research is the direction. Protected focus time, understandable code, clear tools and quick reviews are all things leaders can change through priorities and budget. None of them needs developers to work longer hours.

How to report developer productivity to the board

Executives rarely need the full engineering dashboard. They need to know whether engineering can deliver the plan, what is getting in the way and what the next investment should be. A one-page view works well: delivery speed and stability from your DORA metrics, one developer experience score such as perceived ease of delivering software, and engagement or intent to stay.

Report the trend, not the raw number, and put a sentence next to each one explaining why it moved. Then link every movement to a decision: what you funded, what you stopped and what you expect next quarter. That turns engineering metrics from a status report into a basis for investment, and it removes the temptation to compare teams whose systems and constraints differ.

Measuring AI developer productivity

AI is now the most common reason leaders ask about developer productivity, and it is where perception and data can differ most. In a 2025 randomized controlled trial by METR, 16 experienced open-source developers took about 19 percent longer on tasks when AI tools were allowed, yet estimated afterwards that they had been about 20 percent faster. The authors caution that this describes one setting: early-2025 tools, mature projects the developers knew well. It does not show that AI tools fail to help in general.

At organization level, the 2025 DORA report, based on nearly 5,000 technology professionals, found 90 percent AI adoption and described AI mainly as an amplifier: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. It linked adoption to higher delivery throughput, with stability still a concern. The lesson for leaders is that neither licence usage nor self-reported speed is enough. Measure AI like any other investment, with a baseline first, then delivery, quality and developer experience together.

A 90-day rollout for leaders

Mistakes that destroy trust

Using the metrics in individual performance reviews. Data quality and honesty collapse immediately.
Ranking teams with different contexts against each other.
Surveying without acting. Engineers stop answering when nothing changes.
Measuring only activity because it is easy to collect.
Ignoring well-being until attrition rises.

AI coding assistants make balanced measurement more important: activity metrics can rise sharply while quality or understanding drops. Our guide to managing engineers in the age of AI coding assistants covers how to adapt reviews and policies, and our article on global engineering teams covers the collaboration side for distributed teams.

Questions to ask your engineering leaders

Do we understand our developer experience?

Which metrics do we use across the five SPACE dimensions, and why those?
What did the last developer survey say were the biggest sources of friction?
What did we change as a result, and did the next survey or the data improve?
How do we make sure the metrics are never used to judge individuals?
How is AI-assisted coding changing our activity and quality signals?

Engineering leadership

Want to measure productivity without gaming it?

We design a balanced SPACE and DORA measurement set with your teams, run the first developer survey and turn the findings into a 90-day improvement plan.

Book a free 30-minute call

Sources

The SPACE of Developer Productivity (ACM Queue, 2021)
Publication page and authors (Microsoft Research)
DORA software delivery performance metrics (dora.dev)
DevEx: What Actually Drives Productivity (ACM Queue, 2023) (ACM Queue, 2021)
DevEx in Action: A study of its tangible impacts (ACM Queue, 2023) (ACM Queue, 2021)
Measuring the impact of early-2025 AI on experienced open-source developer productivity (METR, 2025) (ACM Queue, 2021)
How are developers using AI? Inside the 2025 DORA report (Google) (ACM Queue, 2021)

Originally published at phpscientist.com.

Gemini 4 Carbon: Benchmarks, Key Differences and a Decision Guide for Leaders

Senthil Kumar MS — Mon, 02 Nov 2026 15:52:18 +0000

The short answer

Most organisations cannot adopt Gemini 4 Carbon yet. Google announced it on 28 October 2026, but access is limited to a subset of cyber defenders, with more trusted partners to follow. On Google’s published numbers it leads 15 of 17 benchmarks, so it belongs on your evaluation list. The practical decision today is how to prepare: build on a model you can buy, keep the model swappable, and budget at the $4 and $20 list price.

59 - Artificial Analysis Intelligence Index v5.0, ranked #1
15 - of 17 benchmarks led in Google’s comparison table
96.2% - long-context score (GraphWalks); next non-Gemini model 71.8%
$4 / $20 - per million input and output tokens after the introductory period

Every new frontier model arrives with a table in which it wins. The useful question for a leadership team is narrower: where is the lead big enough to change a decision, how was it measured, and can you buy the thing yet? This guide answers those questions for Gemini 4 Carbon.

**A note on sources. **All model facts and scores here come from Google: its launch announcement, its Gemini model page and its evaluation methodology document. Google published these figures and they should be read as vendor claims, including the scores it lists for competitors. Differences between scores and the recommendations are my own reading of those figures.

What Google says Gemini 4 Carbon is

Google describes Carbon as its strongest model, with state-of-the-art cybersecurity and long-horizon capabilities. It follows Gemini 4 Argon, which is the Gemini model you can use through the API today. Three claims define its positioning:

**Long-running work. **Google says its internal teams have seen Carbon run for days on complex engineering tasks, such as root-causing and patching subtle bugs across large codebases.
**Cyber defence. **Google reports leading scores for finding, exploiting and patching vulnerabilities, and more than 2x uplift over Argon in generating secure code on internal benchmarks.
**More dependable behaviour. **Google reports fewer shortcuts, fewer unsupported claims and stronger resistance to prompt injection than Argon.

Gemini 4 Carbon vs GPT-6 Astra, Claude and Argon: the full table

These are the scores on Google’s model page, as of October 2026. A dash means Google lists no score. The highest score in each row is marked in bold on Google’s page; here, the last column names the leader.

BenchmarkCarbonArgonGPT-6 AstraClaude Opus 5.5Claude Fable 5.1LeaderAA Index v5.05950575849CarbonVals Index v2.270.4%69.2%65.0%70.2%—CarbonSWE-sweep9.6%4.3%9.5%3.6%2.9%CarbonFrontierSWE 261.2%55.0%65.5%62.3%56.3%GPT-6 AstraTerminal-Bench 4.0 (AA)65.2%57.1%59.1%59.6%52.0%CarbonAgents’ Last Exam v1.177.4%69.0%73.1%71.6%—CarbonOSWorld-2.1 (offline subset)81.5%74.7%80.9%87.2%76.8%Opus 5.5AutomationBench (Zapier)53.9%51.3%41.4%42.5%31.4%CarbonVending-Bench 2 (bank balance)$16,484$13,718$15,515$9,235$5,422CarbonChartography72.5%71.6%71.0%66.3%46.2%CarbonBlueprint-Bench 258.6%54.4%49.7%51.2%41.9%CarbonGraphWalks (256k to 1M, BFS F1)96.2%84.2%71.8%66.8%65.0%CarbonRiemannBench80.0%76.0%72.0%69.6%65.6%CarbonTerminal-Bench-Science 0.1 (AA)64.8%52.9%63.3%59.0%43.3%CarbonCWE-bench71.0%68.0%68.0%67.0%58.0%CarbonExploitGym54.8%42.0%42.4%34.5%—CarbonSEC-bench Pro88.2%83.4%85.4%——Carbon

Key differences: where the lead is large, narrow or missing

Counting wins hides the most useful signal. Sorting by the gap to the best non-Gemini model on the same row gives a clearer picture.

Size of leadBenchmarkCarbon vs best non-Gemini modelWhat it means for a buyerLargeGraphWalks+24.4 points over GPT-6 AstraThe clearest gap. Relevant if you work across very large contexts.LargeExploitGym+12.4 points over GPT-6 AstraStrong offensive capability, which explains the restricted rollout.LargeAutomationBench+11.4 points over Opus 5.5Relevant to multi-step business automation.ModerateRiemannBench+8.0 points over GPT-6 AstraRelevant to mathematical research work.ModerateBlueprint-Bench 2+7.4 points over Opus 5.5Relevant to reading plans and diagrams.ModerateTerminal-Bench 4.0+5.6 points over Opus 5.5Relevant to agentic work in the terminal.NarrowAA Index, Vals Index, SWE-sweep+1 point, +0.2 and +0.1Treat as level. Do not switch vendors on these alone.BehindFrontierSWE 2−4.3 points to GPT-6 Astra; also behind Opus 5.5Carbon places third of the five listed models.BehindOSWorld-2.1−5.7 points to Opus 5.5Computer use is not a clean win: Carbon leads Agents’ Last Exam but trails here.

The pattern matters more than any single row. Carbon’s strongest case is long context, cybersecurity and sustained automation. For general capability, the top three are close enough that your own workload should decide. For agentic coding, the results are genuinely split across three benchmarks.

Carbon vs Argon: is the upgrade worth waiting for?

For most teams this is the real comparison, since Argon is the model available now and Google says the two launch at the same introductory price.

MeasureGemini 4 ArgonGemini 4 CarbonAvailabilityStable in the Gemini APISubset of cyber defenders; trusted partners nextIntroductory price per 1M tokens$2 input, $10 output$2 input, $10 outputPrice after the introductory periodSee Google’s pricing page$4 input, $20 outputAA Index v5.05059SWE-sweep4.3%9.6%Terminal-Bench 4.057.1%65.2%GraphWalks, 256k to 1M84.2%96.2%ExploitGym42.0%54.8%Gray Swan indirect prompt injection, attack success0.7%0.0%Generating secure code (internal)BaselineMore than 2x uplift in success rateUnsupported claims (internal)BaselineCut by about 2xContext window1,048,576 tokensNot stated in the announcement

Carbon scores higher than Argon on all 17 benchmarks, though some gaps are small: 0.9 points on Chartography and 1.2 on the Vals Index. If Argon already clears your quality bar, there is little reason to hold a project for Carbon. Argon’s published specifications give you a firm base to design against today.

Safety and reliability claims

Google says Carbon builds on Argon’s safety stack and reports these results:

**Cheating: **successful cheating on Terminal-Bench 4.0 fell to 0.0%, and attempts fell to 0.4%.
**Misalignment: **high-severity alerts dropped by almost 80% in live coding environments with internal teams.
**Staying in scope: **overreach fell by 26% and under-service by 29%.
**Prompt injection: **Carbon resisted every evaluated attempt on the Gray Swan indirect prompt injection benchmark, with a 0.0% attack success rate.

A 0.0% score means no evaluated attack succeeded on that benchmark. It does not mean an agent is safe to run unsupervised on your systems, so keep your own permissions, sandboxing and approval steps. Our AI governance framework covers the controls to keep in place whichever model you choose.

What the cost looks like

Google states the introductory price as $2 per million input tokens and $10 per million output tokens, with cached input at 95% off the input price. After the introductory period, $4 and $20 apply. Google has not said when that period ends for Carbon. Here is an illustration for a workload of 100 million input tokens and 20 million output tokens a month:

ScenarioIntroductoryList priceNo caching$400 a month$800 a month60% of input tokens cached$286 a month$572 a month*

*Assumes the 95% cache discount continues at list price. Google states the discount alongside the introductory price and does not confirm it beyond that. Token prices are also only part of the cost: a model that runs for days can consume far more tokens than one that answers a single prompt, so measure cost per completed task. Our guide to evaluating AI ROI shows how to build that business case.

How to read Google’s numbers

Google’s methodology document is worth reading before anyone quotes this table in a board paper. Five details affect how far you can lean on it:

**Sources differ by row. **Some scores come from third parties such as Artificial Analysis, Vals AI, Zapier, Andon Labs and Surge. Others are self-computed by Google, including SWE-sweep, Agents’ Last Exam, OSWorld, ExploitGym and SEC-bench Pro for Carbon.
**Competitor scores are often self-reported. **Unless noted, non-Gemini results come from the providers’ own numbers, using maximum reasoning settings or the best available results.
**Setups are not always identical. **Carbon’s SWE-sweep score uses a mini-swe-agent harness, while rivals’ scores come from the public leaderboard. That makes a 0.1-point lead especially weak evidence.
**Some scores are best-case. **Carbon and Argon ran on the highest thinking settings unless noted, and OSWorld scores are the maximum over three runs. Expect higher cost and latency from those settings.
**Cyber scores were run without guardrails. **Google says the external cyber benchmarks were evaluated without guardrails, and ExploitGym with mitigations off. Since Google is still iterating on guardrails, the released product may not behave identically.

Two headline claims also cannot be checked from what is published. The Chrome team’s “more than 10X better” patch result is against “another lab’s large frontier model”, which Google does not name, and the 2x secure code uplift is from internal benchmarks.

What Google has not published yet

The announcement and evaluation document leave open several items that a procurement or architecture review would normally require:

A general availability date. Google says only “as soon as possible”.
Carbon’s context window and output limits.
When the introductory price ends.
Latency, throughput and rate limits.
The final guardrails, including what security work they may block for ordinary customers.

Should you adopt Gemini 4 Carbon? A decision guide

Your situationRecommended decision nowYou run security or vulnerability workAsk your Google contact about the Fairwind Program. This is the group Google is prioritising.You have a live project on ArgonStay on Argon. Add an evaluation set so you can test Carbon on the day it opens.You are starting a new AI projectBuild on a model available today, and keep the model behind a thin interface so you can swap it.You work across very large documents or codebasesPut Carbon first on your test list. GraphWalks is its largest published lead.You rely on agentic coding or computer useRun a head-to-head trial. Google’s own table shows other models leading FrontierSWE 2 and OSWorld-2.1.You are in a regulated sectorWait for final guardrails and contractual terms before committing.

Whichever row fits, moving from a promising demo to dependable operation is usually harder than picking the model. Our guide on moving AI pilots into production covers that step.

Key takeaways

What would a benchmark win have to change in our cost, quality or risk to justify switching models?
Do we have an evaluation set built from our own tasks, ready to run when Carbon opens?
Can we swap the model behind our applications without rewriting them?
Does the business case still work at $4 and $20, measured per completed task?
If an agent runs for days, who sets its permissions and budget, and who reviews its output?
Which missing facts, such as availability date, limits and guardrails, would block our approval?

AI consulting

Choosing a model for a real workload?

We can build an evaluation set from your own tasks, compare the models you can buy today, and design your application so that you can change models later.

Book a free 30-minute call

Sources

Originally published at phpscientist.com.

Technical Debt: How CTOs Measure, Prioritise and Pay It Down

Senthil Kumar MS — Fri, 30 Oct 2026 02:59:53 +0000

Short answer

Technical debt is the future cost of shortcuts and ageing design in your software. Measure it by its interest, meaning slower delivery, incidents and risk in specific areas, not by code quality alone. Prioritise debt in code that changes often and causes pain, fund a steady share of capacity for it, and report it to the business as cost and risk.

2 - axes in the debt quadrant: reckless or prudent, deliberate or inadvertent
4 - kinds of debt, each needing a different response
3 - delivery metrics that reveal costly debt: lead time, fail rate, rework
1 - rule: pay down the debt that charges the most interest first

Technical debt is the gap between how your software is built today and how it would need to be built to change quickly and safely. Like a loan, it is sometimes worth taking on to ship sooner. The problem is the interest: every change in an indebted area costs more, fails more and carries more risk until the debt is repaid. Leaders need to manage it as a portfolio, not argue about it feature by feature.

Where the term comes from, and what it is not

Ward Cunningham coined the metaphor in a 1992 experience report: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly.” The danger, he warned, is debt that is never repaid. Three decades later the idea is the same, but the scale is not: most organisations now carry debt across dozens of services, cloud platforms, data pipelines and third-party dependencies.

It also helps to be clear about what technical debt is not. A bug is a defect in behaviour; debt is a property of the design that makes defects and changes more expensive. Legacy software is not automatically debt either: a stable system nobody needs to change charges little interest. Debt matters when the business needs to change something and the software resists.

The four kinds of technical debt

Martin Fowler’s technical debt quadrant is the most useful vocabulary for leaders, because it separates debt you chose from debt you fell into, and careful debt from careless debt.

DeliberateInadvertentPrudentTaken knowingly to hit a date, with a plan to repay itDiscovered later: the better design only became clear after buildingReckless“Quick and dirty” because the team believes it has no time for good designAccumulated without realising, often from missing skills or standards

Prudent debt is a normal part of building products and should be tracked like any other liability. Reckless debt is a management signal: it points to unrealistic deadlines, missing skills or a lack of engineering standards, and paying it down without fixing the cause only makes room for more.

Types of technical debt, with examples

The quadrant explains how debt arose. To decide what to do about it, leaders also need to know where it lives. These are the types of technical debt that show up most often in modern software estates:

TypeTypical exampleWhat it costs youCode debtDuplicated logic, very long functions, unclear namingSlower changes and more defects in that areaArchitecture debtA monolith where every change touches billing; tight coupling between servicesTeams block each other; small features need large releasesTest debtLittle automated testing, or a slow and flaky test suiteFear of change, manual regression and long release cyclesDependency and security debtUnsupported frameworks, outdated libraries, end-of-life runtimesSecurity exposure, painful upgrades, compliance findingsInfrastructure debtHand-built servers, no infrastructure as code, snowflake environmentsSlow recovery, inconsistent environments, cloud wasteData debtDuplicated customer records, undocumented schemas, brittle integrationsBad reporting, failed AI and analytics projectsKnowledge debtMissing documentation; one engineer who understands the payment systemKey-person risk and slow onboarding

Most real problems combine several types. An outdated framework (dependency debt) with no tests (test debt) in a module that every product team touches (architecture debt) is exactly the kind of hotspot that deserves to be at the top of the list.

What causes technical debt

Paying down debt without addressing its causes is like clearing a credit card while still spending on it. The common causes are organisational as much as technical:

**Deadline pressure without a repayment plan. **Shortcuts are taken to hit a date, and the follow-up work never makes it onto the roadmap.
**Changing requirements. **The product outgrows the design it started with, which is normal and should be expected.
**Skills and standards gaps. **Teams without code review, shared standards or experienced engineers create reckless debt without noticing.
**Neglected upgrades. **Frameworks, libraries and runtimes age quietly until an upgrade becomes a project in its own right.
**Team turnover. **Knowledge leaves with people, and code nobody understands becomes code nobody dares change.
**Incentives that reward only features. **If roadmaps and performance reviews count only new features, maintenance always loses.

Why “we need a rewrite” is the wrong conversation

When debt becomes painful, engineers often propose a rewrite. Rewrites are expensive, risky and frequently recreate the same problems in newer technology. A better question is which parts of the system charge the most interest, and what the cheapest way is to reduce that interest. Sometimes the answer is targeted refactoring; sometimes it is replacing one component; occasionally it is a staged rebuild. Our modernise or replace framework covers that decision in detail.

How to measure the interest you are paying

Code-quality scores alone do not tell you what debt costs. Measure the effects in each product area or service, and the debt that matters becomes visible:

Change lead time and change fail rate for that area, compared with the rest of the codebase.
Deployment rework rate: how much delivery is unplanned work triggered by incidents.
Incidents and support tickets traced to the area.
Engineer time spent on workarounds, manual steps or fragile tests, from team estimates.
Risk: unsupported frameworks, security findings, single points of knowledge.

These are the same signals DORA uses for delivery performance, so if you already track DORA metrics, you can break them down by service and see where debt slows you most.

Technical debt ratio and code-quality tools

Static analysis tools put a number on code-level debt. SonarQube, for example, reports a technical debt ratio: the estimated cost to fix maintainability issues relative to the estimated cost of developing the code. Its default maintainability rating gives an A at 5% or below, B up to 10%, C up to 20%, D up to 50% and E above that.

These numbers are useful for spotting trends and for stopping new debt at the door, for example by failing a build when new code drops below a rating. They are a poor guide to business priority on their own, because they measure how code looks, not how much it slows the company down. Use them alongside the delivery and incident signals above, not instead of them.

A simple scoring model to prioritise debt

FactorQuestionScore 1–5InterestHow much does this debt slow or break changes today?Higher = more painChange frequencyHow often do we change this area?Higher = more oftenRiskCould it cause a security incident, outage or compliance failure?Higher = more riskCost to fixHow much effort does paying it down take?Higher = more expensive

Rank items by interest × change frequency × risk, divided by cost to fix. Debt in code that changes every week and causes incidents rises to the top; old code nobody touches drops down, however ugly it looks. Review the ranking quarterly, because both the product and the debt change.

Keep a technical debt register

Debt that lives only in engineers’ heads cannot be prioritised or funded. A technical debt register, kept in the same backlog tool as the rest of the work, turns complaints into decisions. Each entry needs only a few fields:

**Area and type: **which service or module, and which type of debt from the table above.
**Evidence of interest: **lead time, incidents, workaround hours or risk findings that show what it costs today.
**Score: **the interest, change frequency, risk and cost-to-fix ratings from the scoring model.
**Owner: **the team responsible for the area.
**Proposed fix and size: **targeted refactor, component replacement or upgrade, with a rough estimate.

Review the register in quarterly planning, alongside the product roadmap. That is where the trade-offs between features and paydown should be made, openly, by the people who own both.

How to fund paydown

If you are unsure where your largest risks sit, an independent software architecture review gives you an evidence-based debt map and a phased plan.

How much time should go to technical debt?

There is no universal percentage, and any figure quoted as a rule should be treated with caution. Many teams reserve somewhere between a tenth and a fifth of their capacity for debt and maintenance, but the right share depends on how much interest you are paying. A young product with a healthy codebase needs less; a platform with rising lead times, repeat incidents and unsupported dependencies needs more, at least for a while.

A practical approach is to start with a fixed allocation, make it visible in planning, and adjust it each quarter based on the signals in the register. If lead time and incidents in the worst areas are falling, the allocation is working. If they are flat or rising, it is too small or spent on the wrong items. What matters most is that the allocation is protected: capacity that disappears whenever a deadline looms is not an allocation at all.

Technical debt in agile and Scrum teams

Agile teams do not avoid technical debt; short iterations can create it faster if every sprint is filled with features. The fix is to make debt work visible in the same backlog as everything else, size it like any other item, and let the product owner see the trade-off. Debt items written in business terms (“reduce checkout release time from two days to two hours”) compete fairly with features; items written as “clean up the order service” rarely get picked.

Retrospectives are a good early-warning system. When a team keeps naming the same module as the reason a sprint slipped, that module belongs on the register with evidence attached.

How to reduce technical debt without stopping delivery

The most effective debt reduction happens alongside feature work, not instead of it. These practices let teams reduce technical debt while still shipping:

**Refactor where you work. **When a feature touches an indebted area, leave the code better than you found it, and include the time in the estimate.
**Write tests before changing risky code. **Characterisation tests capture current behaviour, so the team can refactor without fear of breaking it.
**Replace in slices with the strangler fig pattern. **Route one capability at a time to a new component until the old one can be switched off, rather than betting on a big-bang rewrite.
**Upgrade on a schedule. **Small, regular dependency and runtime upgrades are cheap; a five-year jump is a project.
**Make quality part of “done”. **Code review, automated tests and quality gates on new code stop most reckless debt from being created at all.
**Delete what nobody uses. **Retiring unused features, endpoints and integrations is the cheapest paydown there is.

AI-generated code and the next wave of debt

AI coding assistants let teams produce code faster than ever. That speed is valuable, but it also makes it easier to add code that nobody fully understands, duplicates existing logic or skips the team’s conventions. Without review standards, more output can simply mean debt accumulating faster.

The answer is not to ban the tools; it is to apply the same discipline to AI-written code as to any other: code review by someone who understands it, tests that prove its behaviour, and quality gates that catch duplication and complexity before merge. Track the debt signals above by area, and you will see quickly whether faster delivery is turning into slower change.

How to talk about technical debt with the board

Boards do not need code detail. They need to know which products are slower or riskier to change, what that costs, and what it will take to fix. Frame debt as a business liability with a cost of carry: “Changes to billing take three times longer than elsewhere and caused four incidents last quarter; a two-quarter investment reduces both.” The hidden cost of legacy systems makes the same case at the level of the whole economy.

Questions to ask your engineering leaders

Is our technical debt under control?

Which three areas of our software charge the most interest, and how do we know?
How do lead time and failure rates in those areas compare with the rest of the system?
What share of capacity goes to debt today, and is it enough to reduce it?
Which debt was reckless, and what are we changing so it does not recur?
What will be measurably better in two quarters if we fund the top items?

Engineering leadership

Need a debt map the business can fund?

We measure where technical debt costs you most, rank it with your teams and turn it into a phased, costed plan your board can approve.

Book a free 30-minute call

Sources

Technical Debt Quadrant (Martin Fowler)
DORA software delivery performance metrics (dora.dev)
The WyCash Portfolio Management System (Ward Cunningham, OOPSLA 1992)
Strangler Fig Application (Martin Fowler)
SonarQube metrics: technical debt ratio and maintainability rating (Sonar documentation)

Originally published at phpscientist.com.

Platform Engineering vs DevOps: What CTOs Need to Know in 2026

Senthil Kumar MS — Thu, 29 Oct 2026 11:51:28 +0000

Short answer

Platform engineering does not replace DevOps. DevOps is the culture of teams building and running their own software; platform engineering builds an internal, self-service platform so those teams can do it without each becoming infrastructure experts. Invest when several teams repeat the same infrastructure work, run the platform as a product, and measure it by adoption.

5 - attributes of a good platform in the CNCF white paper
1 - goal above all: lower cognitive load on product teams
0 - tickets needed for a routine capability on a mature platform
90 days - a realistic window for a first golden path

Platform engineering is the practice of building an internal developer platform: self-service tools and paved paths that let product teams create, deploy and run software safely without waiting on another team. DevOps is the culture that made teams responsible for running what they build. Platform engineering makes that responsibility manageable at scale, so the two work together rather than compete.

Why DevOps alone stops scaling

“You build it, you run it” works well for a handful of teams. As the organisation grows, every team ends up owning its own pipelines, infrastructure code, monitoring, secrets and compliance evidence. Effort is duplicated, standards drift and engineers spend more time on plumbing than on customers. Some companies respond by recreating a central operations team, which brings back the ticket queues DevOps was meant to remove.

Platform engineering takes a third route: a small team builds the common capabilities once, as a product, and product teams consume them on their own. This is part of the broader shift from cloud migration to cloud maturity.

Signs you have outgrown team-by-team DevOps

There is rarely a single moment when DevOps stops working. It erodes quietly, and the symptoms show up in delivery reviews, security audits and exit interviews long before anyone names the cause. If several of these sound familiar, the problem is no longer culture; it is the absence of shared, self-service foundations.

**Onboarding takes weeks. **New engineers spend their first month learning how this team deploys, rather than learning the product.
**Every service is a snowflake. **Ten teams have built ten slightly different pipelines, logging set-ups and Terraform layouts, and nobody can support all of them.
**Security findings repeat. **The same misconfiguration, outdated base image or missing secret rotation appears in audit after audit, service after service.
**Senior engineers become a bottleneck. **A few people who “know the infrastructure” are pulled into every incident and every new project.
**Environments are requested, not created. **Teams wait days for a database, a test environment or access to a cloud account.
**Cloud costs cannot be attributed. **Finance asks which product a bill belongs to and engineering cannot answer quickly.

Platform engineering vs DevOps at a glance

DevOpsPlatform engineeringWhat it isA culture and set of practicesA team and an internal productMain goalShared ownership of building and running softwareMake that ownership easy through self-serviceWho does the workEvery product teamA platform team, for product teamsTypical outputPipelines, automation, on-call practices per teamGolden paths, templates, self-service portals and APIsSuccess measureDelivery speed and stabilityAdoption, developer experience and delivery metrics

What a good platform looks like

The Cloud Native Computing Foundation’s platforms white paper lists the attributes that separate a useful platform from a pile of tools:

Platform as a product: it exists to serve its users, with a roadmap shaped by their needs.
Self-service: teams request and receive capabilities automatically, without tickets.
Reduced cognitive load: product teams think about their domain, not infrastructure internals.
Optional and composable: teams can use the parts they need rather than all or nothing.
Secure by default: the easy path is also the compliant path.

The most common failure

Mandating the platform from the top. The CNCF warns that teams relying on mandates for adoption meet resistance. If engineers are not choosing the golden path voluntarily, it is not yet better than the alternatives.

What goes inside an internal developer platform

“Platform” is a word that can mean anything, which is why so many initiatives stall. It helps to describe it as a set of capabilities that product teams consume, each with a clear interface. Not every organisation needs all of them on day one; most start with two or three and grow from there.

CapabilityWhat product teams getTypical building blocksService templatesA new, production-ready service in minutes, with sensible defaultsRepository templates, scaffolding toolsBuild and deployA standard pipeline they do not have to write or maintainExisting CI/CD system, deployment automation, GitOpsInfrastructure and environmentsDatabases, queues and test environments on requestInfrastructure as code modules, managed cloud servicesObservabilityLogs, metrics, traces and alerts wired in from the startManaged monitoring, shared dashboardsSecurity and complianceSecrets, identity, scanning and audit evidence by defaultSecret managers, policy as code, image scanningDiscoverabilityOne place to find services, owners, docs and the paths aboveA developer portal or service catalogue

Notice that the developer portal is the last row, not the first. A portal is the front door to a platform; without working capabilities behind it, it is a catalogue of things teams still have to do by hand.

Build, buy or assemble

Very few organisations should build a platform from scratch. The practical choice is between three approaches, and most mature platforms end up mixing them.

Assemble managed cloud services, your existing CI/CD tooling and a library of templates. This is the fastest route to value and the right starting point for most companies, because it reuses what teams already know.

Adopt an open-source framework such as Backstage, the developer portal framework created at Spotify and now a CNCF project. It gives you a service catalogue, templates and a plugin ecosystem, but it is a framework rather than a finished product: expect to dedicate engineers to running and extending it.

Buy a commercial platform or portal when you want a faster start and are comfortable with a vendor shaping part of your developer experience. Check how easily you could leave, and whether it works with the cloud services and tools you already run.

Whichever route you take, the expensive part is not the software. It is the product work: understanding users, designing golden paths, writing documentation and supporting adoption.

When it pays off, and when it does not

Platform engineering pays off when the same problems appear across many teams: slow onboarding, inconsistent deployments, security findings repeated in every service, or engineers waiting days for environments. It rarely pays off for a single product team or a small company, where a well-chosen managed cloud service and a few shared templates achieve most of the benefit.

Cost matters too. A platform should make cloud spend more visible and controlled, for example by building tagging and right-sizing into every template. Our FinOps playbook covers the cost practices worth baking in.

What a golden path looks like in practice

Take the most common journey in most engineering organisations: a team needs a new web service in production. Without a platform, that journey usually involves copying an old repository, asking another team for a cloud account, writing a pipeline, requesting a database, opening a firewall ticket, setting up dashboards and filling in a security questionnaire. Each step is reasonable on its own. Together, they can take weeks and produce a service that differs slightly from every other one.

With a golden path, the same team picks a template, gives the service a name and an owner, and gets a repository with a working pipeline, a staging environment, standard logging and alerts, secrets handled properly and the service listed in the catalogue. The first deployment can happen the same day. The security and cost rules are not a checklist at the end; they are already built into what the template creates.

Two details make the difference between a golden path and a golden cage. First, it is documented and explained, so engineers understand what they are getting and why. Second, it can be extended or left: a team with a genuinely unusual need can swap a component or step off the path, as long as it then takes responsibility for what it changed. That freedom is what makes voluntary adoption possible, and voluntary adoption is the clearest sign that the platform is working.

For decision makers, the golden path is also the easiest thing to demonstrate. Timing how long a new service takes to reach production, before and after, is a measure anyone in the business can understand.

Who builds the platform

Team Topologies, the most widely used model for organising around platforms, describes a platform team as one that provides internal services to reduce the cognitive load of stream-aligned teams, the teams that deliver product value. The relationship works best as “X-as-a-Service”: product teams consume the platform through clear interfaces, with as little hand-holding as possible.

In practice, a first platform team is small: a handful of experienced engineers who understand infrastructure, delivery and security, plus someone who acts as product manager. That product role is the one most often skipped and most often missed. Someone has to talk to users, decide what not to build and say no to requests that serve one team at the expense of all the others.

Staff the team from people product engineers already trust. A platform built by respected colleagues gets a fair trial; one handed down by a distant infrastructure group gets worked around.

How to start in 90 days

How to measure whether it is working

A platform is an investment, and boards will ask what it returns. Measure three things: whether teams use it, whether it makes delivery better, and whether engineers find it helpful. Take a baseline before you start, or you will have nothing to compare against.

What you measureExample metricsWhat it tells youAdoptionShare of services on the golden path; teams using each capabilityWhether the platform is genuinely better than the alternativesDelivery performanceDORA metrics: change lead time, deployment frequency, change fail rate, failed deployment recovery timeWhether teams ship faster and more safelyDeveloper experienceTime to first deploy for a new engineer or service; regular developer surveysWhether cognitive load is actually going downCost and riskShare of resources correctly tagged; repeat security findingsWhether governance is becoming automatic

Treat adoption as the leading indicator. If usage is low, delivery metrics will not move, and no dashboard will fix that. Go back to your users and find out what the golden path is missing.

Report these numbers to leadership in the same rhythm as any other product: a short quarterly review covering what was shipped, how many teams adopted it, what changed in delivery and onboarding, and what users are asking for next. It keeps the platform accountable and makes the case for continued funding with evidence rather than enthusiasm.

Pitfalls that sink platform initiatives

**Building before listening. **Platform teams that start with tools they find interesting, rather than the problems users report, build things nobody adopts.
**Renaming the operations team. **If the platform is still delivered through tickets, nothing has changed except the job titles.
**Portal first, capabilities later. **A polished portal over manual processes raises expectations and then disappoints them.
**Trying to cover every case. **One excellent golden path beats five mediocre ones. Leave room for teams with unusual needs to step off the path.
**No ownership of the long tail. **Templates and modules age. Without versioning, upgrades and deprecation, today’s golden path becomes tomorrow’s legacy.
**Funding it as a project. **A platform is a product with ongoing users. Budgeting it as a one-off build guarantees it decays once the project ends.

Questions to ask before you fund a platform team

Is a platform the right investment?

Which infrastructure and deployment problems are repeated across at least three teams?
How long does it take a new engineer, or a new service, to reach production today?
Who will own the platform as a product, and how will they hear from users?
Which managed services can we assemble instead of building?
How will we know in six months whether teams choose the platform voluntarily?

Cloud & DevOps

Deciding whether to build an internal platform?

We assess where your teams lose time, design a thin first golden path on managed services, and set the adoption and delivery metrics that show whether it works.

Book a free 30-minute call

Sources

CNCF Platforms White Paper (CNCF TAG App Delivery)
Team Topologies key concepts (teamtopologies.com)
DORA’s software delivery performance metrics (dora.dev)
Backstage (backstage.io)

Originally published at phpscientist.com.

PolyShell (CVE-2026-48356): The Actively Exploited Magento Flaw Every Store Owner Must Act On

Senthil Kumar MS — Wed, 28 Oct 2026 14:37:54 +0000

Decision needed this week

CVE-2026-48356, nicknamed PolyShell, lets anyone on the internet upload a file to a Magento or Adobe Commerce store through its public shopping-cart API, with no login. On many servers that file becomes a backdoor that criminals use to plant card skimmers. Attacks have been running since March 2026, and on 27 October CISA added it to its list of actively exploited flaws, with a 10 November deadline for US federal agencies. If your store has not installed Adobe’s July 2026 security update (APSB26-73), treat it as urgent, and check for signs of compromise even if you have.

9.3 - CVSS 3.1 score, rated critical by Adobe and NIST
0 - accounts or passwords the attacker needs
471 - stores infected in one hour on 30 March 2026 (Sansec)
10 Nov - CISA deadline to patch or stop using the product

Most security bulletins can wait for the next maintenance window. This one should not. It affects every supported line of Magento Open Source and Adobe Commerce, it was being exploited for four months before an official patch existed, and the people using it are organised groups who steal payment data from shoppers. This guide is for owners, directors and heads of e-commerce: what the flaw is in plain terms, what it can cost you, how to tell whether you are exposed, and what to ask your team or agency to do this week.

What PolyShell is, in plain terms

Magento lets a product carry a “custom option”, such as a file a shopper attaches to an order: a logo for printing or a photo for engraving. Those files are saved on your server. Researchers at Sansec found that the public API behind the cart, the one your storefront and apps use for guest checkouts, would accept such a file for any product, even one with no file option, and from anyone, with no login.

Magento only checked that the upload looked like an image. Attackers send a “polyglot”: a file that is a valid GIF or PNG and at the same time contains PHP code. It lands in pub/media/custom\_options/quote/ on your server. What happens next depends on how your web server is set up:

If the server runs PHP files in that folder (common with older or customised nginx and Apache set-ups), the attacker can run any code on the store. This is full control: the database, customer records, admin accounts and the checkout.
If it does not, the file is still stored and can be used to attack people who view it, for example an administrator, which is why the official description mentions user interaction.

The flaw has existed since the first release of Magento 2, so the age of your store does not protect you. Sansec named it PolyShell when it published its advisory on 17 March 2026.

Why the official description sounds milder

The NVD entry describes code execution that needs a victim to visit a crafted link, the worst case Adobe could promise for every configuration. In practice, Sansec and CISA report attackers running code directly on servers that execute PHP in the upload folder, without anyone clicking anything. CISA rates the technical impact as “total”. Plan for the worse outcome.

What it can cost the business

The groups exploiting PolyShell are not after your server; they are after your customers. Sansec traced the attacks to a long-running campaign that, once inside, does three things:

For a decision maker, that translates into concrete exposure:

Payment card theft and PCI DSS consequences. A skimmer on the checkout is a reportable cardholder-data breach, with forensic investigation costs, possible fines from your acquirer and, in some cases, loss of the ability to take cards.
Personal data breach notification. Customer names, addresses and order histories are in reach, which can trigger GDPR, UK GDPR or US state notification duties.
Revenue and reputation. Browsers and search engines flag infected sites; clean-up often means taking the store offline or into maintenance at short notice.
Hidden, lasting access. Because the injected script lives in the database and the backdoors are spread across folders, patching alone does not remove an existing infection.

How widely it is being exploited

This is not a theoretical risk. According to Sansec’s research:

Date (2026)What happened17 MarchSansec publishes the PolyShell advisory; no production patch exists yet19 MarchMass scanning begins from more than 50 IP addresses30 MarchAutomated wave: 471 stores infected with a skimmer loader in one hour14 JulyAdobe releases APSB26-73 with fixes for supported versions; CVE-2026-48356 is published7–23 OctoberThe same group moves to a new domain; Sansec counts 953 stores affected since July 202527 OctoberCISA adds CVE-2026-48356 to the Known Exploited Vulnerabilities catalog, due 10 November

Sansec also found that 60% of infected Magento 2 stores it examined had files uploaded through PolyShell or the earlier SessionReaper flaw (CVE-2025-54236), and found the loader on one store that had every core patch. That is the key message for leadership: patched does not mean clean.

Are you affected? A quick check

ProductAffected versionsFixed in (July 2026 security release)Adobe Commerce2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, 2.4.4-p18 and earlier2.4.9 / 2.4.8 / 2.4.7 / 2.4.6 / 2.4.5 / 2.4.4 “-2026-jul” releasesMagento Open Source2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15 and earlier2.4.9 / 2.4.8 / 2.4.7 / 2.4.6 “-2026-jul” releasesAdobe Commerce B2B1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17, 1.3.3-p18 and earlierMatching “-2026-jul” releasesAdobe Commerce Events1.20.0 and earlier1.21.0

If your store is on Magento 2.3 or an older 2.4 line that no longer receives patches, there is no official fix: you need an upgrade plan, and the server-level block below in the meantime. Adobe Commerce Cloud customers should confirm with Adobe or their partner that the patch is applied to every environment, including staging.

Your developer can confirm the version and look for the most common traces in a few minutes:

# 1. Which version is installed?
bin/magento --version

# 2. Any files uploaded through custom options? (expect very few, and no PHP)
find pub/media/custom_options pub/media/customer_address -type f -newermt 2026-03-01 | head -50
grep -rlE "<\?php|eval\(|base64_decode" pub/media/custom_options pub/media/customer_address 2>/dev/null

# 3. Known backdoor name from the attack wave
find . -name "accesson.php" -not -path "./vendor/*"

# 4. Injected loader in CMS content (MySQL)
mysql -e "SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%fpCode%' OR content LIKE '%localStorage.getItem%' OR content LIKE '%se_referrer%';" your_db

Any hit on steps 2 to 4 means you should treat the store as compromised and bring in incident response, not just apply the patch.

What to do this week

For nginx, Sansec’s advice is to deny the folder before any rule that passes .php files to PHP, otherwise the PHP rule wins:

# Place ABOVE any "location ~ \.php$" block
location ^~ /media/custom_options/ {
    deny all;
    return 403;
}

On Apache, confirm that pub/media/custom\_options/.htaccess exists and contains both php\_flag engine 0 (inside an IfModule mod\_php block) and Deny from all. These are stopgaps: files can still be written to disk, so the patch remains essential.

Questions to ask your developer or agency

Send this list today

Which Magento or Adobe Commerce version runs on production and staging, and is APSB26-73 installed on both? When was it deployed?
Is PHP execution and direct access blocked for pub/media/custom_options/ in our web server configuration?
Have we scanned for web shells, accesson.php files and injected scripts in CMS blocks, and what did we find?
Are there admin users, integrations or CMS changes since March 2026 that nobody can explain?
Does our WAF or CDN block file uploads to the guest-cart API, and are we on a supported version line?
If anything was found, who leads incident response, and do we need to notify our payment provider or customers?

If you also run other PHP applications on the same servers, check this month’s other critical fixes too: our PHP2Shell guide covers the October PHP runtime release.

Magento security

Need your store checked and patched?

We can confirm whether your Magento or Adobe Commerce store is exposed, apply APSB26-73 and the server-level block, check for web shells and skimmers, and plan an upgrade off unsupported versions.

Book a free 30-minute call

Sources

NVD: CVE-2026-48356 (description, CVSS 3.1 vector, CWE-434, affected versions)
Adobe security bulletin APSB26-73 (Adobe Commerce and Magento Open Source, 14 July 2026)
CISA Known Exploited Vulnerabilities catalog: CVE-2026-48356 (added 27 October 2026, due 10 November 2026)
Sansec: PolyShell, unrestricted file upload in Magento and Adobe Commerce (technical analysis and server mitigations)
Sansec: PolyShell mass attack wave (471 stores in one hour, 30 March 2026)
Sansec: Magento CMS block loader campaign (953 stores, indicators of compromise, October 2026)

Originally published at phpscientist.com.

Cloud Migration Strategy: The 7 Rs Explained for Business Leaders

Senthil Kumar MS — Wed, 28 Oct 2026 14:23:14 +0000

Short answer

The 7 Rs are the seven ways to move each application to the cloud: retire, retain, rehost, relocate, repurchase, replatform and refactor. Do not pick one strategy for the whole estate. Decide per application based on its business value and technical condition, retire what you can, move most applications with rehost or replatform, and refactor only what differentiates the business.

7 - migration strategies to choose from for every application
1 - decision per application, not one strategy for the estate
2 - that cost the least: retire and retain
1 - that changes the most: refactor

A cloud migration strategy is a decision, made for each application, about how it will move to the cloud or whether it should move at all. AWS groups the options into seven strategies, known as the 7 Rs. Using them turns a vague “move to the cloud” programme into a portfolio of clear, costed decisions that leaders can govern.

The 7 Rs at a glance

StrategyWhat it meansEffortTypical useRetireSwitch the application offLowestDuplicate, unused or low-value systemsRetainKeep it where it is for nowLowRecently upgraded, regulated or not worth moving yetRehostLift and shift without changesLowFast data-centre exitRelocateMove at hypervisor level, for example VMware to its cloud equivalentLowLarge virtualised estates on a deadlineRepurchaseReplace with a different product, usually SaaSMediumCommodity systems such as CRM, HR or emailReplatformMove with targeted optimisation, such as a managed databaseMediumApps worth keeping that gain from managed servicesRefactorRe-architect to use cloud-native featuresHighestDifferentiating systems that need scale or speed

How to choose a strategy for each application

Score each application on two axes: how much business value it creates, and how healthy it is technically. High-value, healthy systems are candidates for replatforming or, if they differentiate you, refactoring. Low-value systems should be retired or repurchased. Fragile but important systems deserve an honest decision about whether to modernise or replace them, which we cover in our modernise or replace decision framework.

Business value: revenue, customers or critical operations that depend on it.
Technical condition: supportability, security posture and how often it changes.
Risk and compliance: data residency, regulation and integration dependencies.
Timing: contract renewals, hardware end of life and data-centre exit dates.

Common mistakes that make migrations fail

One strategy for everything. Refactoring the whole estate takes years; rehosting everything moves your problems and costs to a new bill.
Skipping retirement. Many portfolios contain systems nobody uses. Switching them off is the cheapest migration there is.
Treating migration as the finish line. Moving workloads without changing operating practices creates little advantage, as we explain in cloud maturity.
Ignoring cost after the move. Lifted-and-shifted servers sized for on-premises peaks often cost more in the cloud. Right-size within weeks.
Migrating dependencies apart. Applications that talk constantly should move in the same wave to avoid latency and data-transfer costs.

A migration plan leaders can govern

Cost control should start on day one, not after the bill arrives. Our FinOps playbook covers tagging, right-sizing and commitments for a freshly migrated estate.

Questions to ask before approving a migration

Is this migration plan ready?

Has every application been assigned one of the 7 Rs, with a written reason?
Which applications are we retiring, and how much does that save?
How are waves grouped around dependencies, and which goes first?
What is the plan to optimise cost and operations after each wave?
How will we measure success beyond “percentage migrated”?

Cloud & DevOps

Planning a cloud migration?

We inventory your portfolio, assign a strategy to every application, plan the waves and landing zone, and keep costs under control from the first move.

Book a free 30-minute call

Sources

AWS Prescriptive Guidance: migration strategies (Amazon Web Services)

Originally published at phpscientist.com.

How to Structure Engineering Teams as You Scale: A Team Topologies Guide for Leaders

Senthil Kumar MS — Tue, 27 Oct 2026 02:15:02 +0000

Short answer

Structure engineering around the flow of business value. Most engineers should sit in small, long-lived stream-aligned teams that own a product area end to end. Add a platform team when teams repeat the same infrastructure work, enabling teams to spread new skills, and a complicated-subsystem team only for deep specialist parts. Keep each team’s cognitive load manageable.

4 - team types: stream-aligned, platform, enabling, complicated subsystem
3 - ways teams interact: collaboration, X-as-a-Service, facilitation
5–9 - people per team, a common size for shared context and ownership
1 - clear owner for every service, incident and roadmap

The best way to structure engineering teams as you scale is around the flow of business value, not around technologies or job titles. The Team Topologies model gives leaders a shared vocabulary for this: four team types and three ways for teams to work together. It helps you grow from one team to dozens without every feature needing five hand-offs.

Why structure becomes the bottleneck

At ten engineers, one team can hold the whole system in its head. At fifty, the organisation chart starts to shape the software: if a feature needs the front-end team, the API team, the database team and operations, every release becomes a negotiation. Lead time grows, ownership of incidents blurs and good engineers spend their week in coordination meetings.

The fix is not more process. It is drawing team boundaries so that most work can be finished inside one team, and making the interfaces between teams deliberate. The same principle applies across borders, as we describe in scaling innovation across borders.

The four team types

Team typeWhat it doesWhen you need itStream-alignedOwns a flow of business work end to end: build, run and improveAlways: most engineers should be herePlatformProvides internal services as a product, such as deployment, observability and dataWhen several teams repeat the same infrastructure workEnablingHelps other teams adopt new skills or tools, then steps backDuring a shift, such as a cloud migration or AI adoptionComplicated subsystemOwns a part needing deep specialist expertiseFor genuinely hard domains: pricing engines, video, ML models

A common mistake is creating many component teams (“the database team”, “the front-end team”). Each looks efficient in isolation but forces every feature across several queues. Stream-aligned teams own the full slice instead.

Three ways teams should interact

Collaboration: two teams work closely for a defined period to discover something new. Valuable, but expensive, so time-box it.
X-as-a-Service: one team consumes what another provides with minimal coordination, like using an internal deployment platform. This is the default you want for mature capabilities.
Facilitation: one team coaches another to build a skill, then withdraws. Typical for enabling teams.

Writing down which mode each pair of teams uses removes a surprising amount of friction. If a team believes it is “collaborating” while the other thinks it is providing a service, expectations clash.

Cognitive load: the limit leaders forget

Every team can only handle so much complexity. If one team owns too many services, technologies or domains, it slows down, makes poorer decisions and stops improving its own systems. When a team is overloaded, split the domain or move undifferentiated work to a platform; do not simply add people to the same team.

A practical reorganisation plan

Run the change in phases, starting with one product area. An architecture review often helps, because team boundaries and service boundaries should line up.

Questions to ask your engineering leaders

Is our structure helping or hurting delivery?

How many teams are involved in shipping a typical feature, and where does work wait?
Does every service and incident have exactly one owning team?
Which teams are overloaded, and what will we move off their plate?
Which repeated work should become a self-service platform capability?
How does our team map line up with our architecture?

Engineering leadership

Planning a reorganisation or scaling fast?

We map your value streams, team boundaries and architecture, and design a phased structure that shortens lead time without disrupting delivery.

Book a free 30-minute call

Sources

Team Topologies key concepts (teamtopologies.com)

Originally published at phpscientist.com.

NCM vs LLM: What Next-Concept Modeling Changes, and What It Doesn’t

Senthil Kumar MS — Mon, 26 Oct 2026 14:22:02 +0000

Short answer

NCM (Next-Concept Modeling) is a new research method from Stanford and Together AI that writes text coarse-to-fine: it drafts the overall structure first, then fills in detail, predicting many pieces in parallel instead of one token at a time like today’s LLMs. Early results are fast and efficient, but they are measured against diffusion language models at small scale, not against ChatGPT-class LLMs. It is worth watching, not acting on yet.

10–31× - faster generation than strong diffusion language models, in the authors’ tests
~4–5× - fewer training tokens, including tokenizer training
725M - largest model tested: far smaller than frontier LLMs
0 - hosted APIs: it is a research release with code on GitHub

NCM vs LLM is a comparison between two ways of generating text. Today’s large language models are autoregressive: they write one token at a time, each depending on the ones before. Next-Concept Modeling, published by Stanford’s Hazy Research lab and Together AI in October 2026, builds the text as a hierarchy, outlining it first and then refining every part in parallel. That makes it potentially much faster, but it is still early research.

Why generation speed is a business issue, not just a technical one

It is easy to treat “faster text generation” as an engineering detail. For decision makers it is three business levers at once: cost, response time and what your products can do.

Cost: most of what you pay a model provider, or spend on your own GPUs, goes on generating output. If the same answer needs far fewer sequential steps, the same hardware can serve more requests.
Response time: people abandon slow tools. Support agents, sales teams and customers notice the difference between an answer in one second and an answer in eight.
New products: some ideas are uneconomic today because generation is too slow or expensive, such as drafting a personalised summary for every customer record overnight, or checking every contract clause in real time while someone types.

Illustrative example

A support team uses an AI assistant to draft replies of around 300 words. An autoregressive model produces those words one token at a time, so a long reply means hundreds of steps in a row. A coarse-to-fine model would produce the reply in a fixed number of levels, each computed in parallel. If that holds up at production scale, the same team could get drafts noticeably faster and the provider could serve more agents per GPU. This is a thought experiment, not a measured result.

How today’s LLMs generate text

Models such as GPT, Claude and Gemini are autoregressive: they predict the next token, a word or part of a word, append it, and repeat. This is reliable and scales extremely well, which is why it powers nearly every AI product today. Its weakness is speed: a 1,000-word answer needs well over a thousand sequential steps, and each step must wait for the one before. Much of the cost of running AI products comes from that sequential decoding.

Researchers have tried alternatives. Diffusion language models start from noise and refine the whole text over many steps in parallel. They avoid strict left-to-right writing but typically need many passes to reach good quality, which is the gap NCM targets.

How Next-Concept Modeling works

NCM borrows an idea from image generation, where models paint a rough picture and then add detail. It works in two stages:

A multiscale tokenizer learns to represent text as a hierarchy of discrete codes: a few codes for the broad structure at the top level, more codes for finer detail at each level below.
A transformer then generates the text level by level, coarse to fine. All codes within a level are predicted at once, in parallel, and each level is conditioned on the levels above it.
A decoder turns the finished hierarchy back into words.

Because each level is produced in one parallel step, the number of sequential steps depends on the number of levels, not the length of the text. That is the source of the speed-up.

NCM vs LLM at a glance

Autoregressive LLMsNext-Concept ModelingHow text is producedOne token at a time, left to rightCoarse to fine, a whole level in parallelSequential stepsGrows with the length of the outputFixed by the number of levelsMaturityProduction at massive scaleResearch release, October 2026Largest modelsHundreds of billions of parameters725 million parameters in the paperCompared against—Mainly diffusion language models; an autoregressive baseline only on SudokuHow to use itHosted APIs and open modelsResearch code and task-specific checkpoints

Where coarse-to-fine generation could fit first

The published experiments cover open-ended text generation, summarisation and puzzle-style reasoning. Based on how the method works, the most likely early uses are tasks with a clear overall structure and a predictable length:

Use caseWhy coarse-to-fine might suit itBusiness exampleSummariesThe structure is predictable and the length is boundedDaily digests of tickets, calls or incident reportsStructured documentsSections and fields can be planned before wordingDraft reports, product descriptions, form responsesConstraint puzzles and planningThe whole answer must satisfy rules at onceScheduling, configuration and rota problems (the paper’s Sudoku results point this way)Bulk generationThroughput matters more than live streamingOvernight personalisation for thousands of records

These are directions to test, not proven applications. Until there are general-purpose NCM models, each of them would need a task-specific model trained in-house.

Where today’s LLMs keep winning

Open-ended conversation and very long outputs, where the length and direction of the answer are not known in advance.
Streaming responses: chat interfaces show words as they are generated, which hides latency. A level-by-level method shows nothing until a level completes.
Tool use and agents, where the model calls tools mid-answer and reacts to the results, a pattern explained in our guide to AI agents vs AI workflows.
Breadth and maturity: frontier LLMs are trained on vast data, support many languages and tasks in one model, and come with hosting, safety tooling and support.
Ecosystem: inference servers, fine-tuning tools, evaluation frameworks and security controls are all built around autoregressive models.

A worked example: how NCM would build a summary

To make the idea concrete, imagine summarising a two-page incident report. This walk-through is a simplified illustration of the coarse-to-fine principle, not a trace of the real model, which works on learned codes rather than readable outlines.

An autoregressive LLM would write the same summary strictly left to right, deciding the first word before it has “planned” the last sentence. That works remarkably well in practice, but it is inherently sequential. NCM’s bet is that settling structure first and detail later can be both faster and, for some tasks, more coherent.

What the results actually show

The authors report that, on a single NVIDIA H100, NCM generated text 21 times faster than the strongest diffusion baseline on LM1B, 10 times faster on OpenWebText and 31 times faster on XSum summarisation while matching its ROUGE-L score. It also needed about 4 to 5 times fewer training tokens, even counting the tokenizer’s training. On Sudoku puzzles it outperformed both autoregressive and diffusion baselines across difficulty levels.

Three caveats matter for anyone reading the headlines:

The speed comparisons are against diffusion language models, not against GPT-, Claude- or Gemini-class autoregressive LLMs.
The models are small: the scaling experiments use 97M, 317M and 725M parameters, while frontier LLMs are hundreds of times larger. Whether the advantage holds at that scale is an open question the authors themselves list.
The results are new and author-reported; independent reproductions and general-purpose benchmarks have not yet appeared.

Not the “end of LLMs”

Social posts calling NCM the end of LLMs go well beyond the paper. It is a promising new way to generate text, tested at small scale against a different family of models. Treat claims of LLM replacement as speculation until NCM is shown working at frontier scale on general tasks.

How to judge AI research headlines like this one

NCM is a useful case study in reading AI news. A new paper appears, social media calls it a revolution, and leaders are asked whether to change course. Six questions separate a promising result from a reason to act:

QuestionWhat to look forNCM todayFaster than what?The baseline it was compared withMainly diffusion language modelsAt what scale?Model size compared with what you useUp to 725M parametersOn which tasks?Benchmarks that resemble your workloadGeneration, summarisation, SudokuWho measured it?Independent reproduction, not only the authorsAuthor-reported so farAt what quality?Accuracy or quality held steady while speed improvedCompetitive with or better than the diffusion baselinesCan I use it?Hosted APIs, general models, supportResearch code and task-specific checkpoints

Apply the same checklist to the next “end of transformers” or “10× cheaper AI” headline. Most results that matter take one to three years to reach products, and the ones that do usually arrive through your existing providers.

Three scenarios for the next 12–36 months

Nobody knows yet how NCM will develop. Planning around scenarios, rather than predictions, keeps the roadmap robust:

ScenarioWhat happensWhat it means for youIt stays a research ideaResults do not hold at large scaleNo change: autoregressive LLMs keep improving and getting cheaperIt becomes an ingredientProviders adopt coarse-to-fine or parallel decoding inside their modelsFaster, cheaper APIs with no work on your side, if you can switch models easilyIt becomes a new model familyGeneral-purpose NCM models match LLMs on many tasksOption to move high-volume, structured workloads to a cheaper, faster generator

In all three scenarios the winning move is the same: build AI features so that the model behind them can be replaced without rewriting the product. That is cheap to do now and expensive to retrofit later.

What it means for business leaders

For now, nothing in your AI roadmap needs to change. Every production AI system you can buy or build today runs on autoregressive models, and the practical decisions remain the same: choosing between AI agents and AI workflows, governing data and measuring value. What NCM signals is that generation cost and speed may fall sharply in the next few years if parallel approaches mature.

Avoid long lock-in to a single model architecture: keep model calls behind your own interface so a faster, cheaper generator can be swapped in.
Measure latency and cost per task now, so you can recognise when a new approach genuinely improves them.
Ask vendors how they would adopt faster decoding methods, not whether they use NCM.
Let your AI team experiment with the open code on narrow, structured tasks if speed matters, but keep it out of production.

The architectural habits that protect you here are the same ones we recommend for any LLM system in our 10 architectural rules for effective LLM use.

For your AI team, the practical priorities do not change: a clean abstraction over model providers, an evaluation set built from your own tasks, and cost and latency tracked per feature. With those in place, testing a new kind of generator becomes a week of work rather than a rebuild, and you can make the decision on your own data instead of on headlines. Teams without them tend to stay locked to whichever model they started with, even when better and cheaper options appear.

Questions to ask your AI vendors

What latency and cost per request do we get today for our main use cases, and how do you report it?
How quickly can we switch to a newer or cheaper model if one becomes available?
Are you evaluating faster decoding methods such as parallel or coarse-to-fine generation, and how would that change pricing?
If quality changes when you change models, how will we know before our customers do?

What to watch next

Signals that NCM is becoming practical

Results at billions of parameters, not only hundreds of millions.
Head-to-head comparisons with autoregressive LLMs on general tasks, not only diffusion models.
Independent reproductions of the speed and quality claims.
A general-purpose checkpoint instead of one model per task, and support in inference servers or hosted APIs.
Major model providers adopting coarse-to-fine or parallel decoding in their own products.

AI strategy

Want an AI architecture that can adopt better models as they arrive?

We review your AI systems for model lock-in, latency and cost, and design the abstraction and measurement that let you switch to faster, cheaper models without a rebuild.

Book a free 30-minute call

Sources

Next-Concept Modeling: Fast, Parallel Coarse-to-Fine Text Generation (Hazy Research blog, 12 October 2026)
Paper on arXiv (2610.14162) (Stanford University and Together AI)
NCM research code (GitHub)

NCM vs LLM: What Next-Concept Modeling Changes, and What It Doesn’t

Originally published at phpscientist.com.

DORA Metrics Explained: How CTOs Measure Engineering Performance in 2026

Senthil Kumar MS — Sun, 25 Oct 2026 13:12:42 +0000

Short answer

DORA metrics are the industry-standard way to measure software delivery: how fast changes reach production and how often they break it. DORA now defines five metrics, three for throughput and two for instability. Track them per service, review trends rather than targets, and never use them to rank teams.

5 - software delivery metrics DORA now defines (the “four keys” grew to five)
3 - throughput metrics: lead time, deployment frequency, recovery time
2 - instability metrics: change fail rate and rework rate
30 days - enough to get a first, honest baseline for one product line

DORA metrics tell a CTO whether the engineering organisation can ship change quickly and safely. They are five measures defined by Google Cloud’s DORA research programme: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Together they show speed and stability on one page, which is why boards and engineering leaders increasingly use them.

The five DORA metrics in plain English

MetricWhat it measuresQuestion it answers for leadersChange lead timeTime from a change in version control to it running in productionHow long does an idea wait before customers can use it?Deployment frequencyHow often you deploy, or the time between deploymentsCan we release small changes whenever we need to?Failed deployment recovery timeTime to recover from a deployment that needs immediate interventionWhen a release breaks something, how quickly are we back?Change fail rateShare of deployments needing a rollback, hotfix or other immediate fixHow often does shipping hurt customers?Deployment rework rateShare of deployments that are unplanned and triggered by an incidentHow much of our delivery is firefighting rather than planned work?

If your dashboards still show “mean time to restore”, they are on the older definition. DORA replaced it with failed deployment recovery time, which focuses on recovering from changes you shipped rather than every outage, and added deployment rework rate to expose hidden firefighting.

Why speed and stability belong together

The core finding behind DORA is that speed and stability are not a trade-off. Teams that deploy small changes often tend to fail less and recover faster, because each change is easier to test, review and roll back. Looking at throughput without instability rewards reckless shipping; looking at instability alone rewards shipping nothing.

For a leader, this changes the conversation. Instead of asking engineering to “move faster” or “be more careful”, you can ask which constraint is holding delivery back: long reviews, manual testing, risky big-bang releases or slow incident response. It also matters more as AI coding assistants raise the volume of code, a shift we cover in the move from software development to software orchestration.

How to start measuring in 30 days

Most teams can calculate a usable first version with a script against their CI/CD and incident APIs before buying a tool. Buy software once the definitions are stable and you know which views leaders actually use.

Mistakes that turn DORA metrics into theatre

Ranking teams against each other. Context differs: a payments team and an internal tools team should not have the same targets.
Setting targets as goals. When a measure becomes a target, people optimise the number, for example by splitting one change into many deployments.
Measuring individuals. DORA metrics describe systems and teams, not people. Using them in performance reviews destroys trust and data quality.
Ignoring outcomes. Fast, stable delivery of the wrong features is still waste. Pair the metrics with product and customer measures.
Reporting without acting. A monthly slide nobody discusses is overhead. Every review should end with one improvement to try.

For distributed teams

In teams spread across time zones, slow reviews and hand-offs usually dominate lead time. Our guide to [[building high-performance global tech teams|/blog/building-high-performance-global-tech-teams-across-time-zones/]] covers the operating model that shortens them.

What to ask your engineering leaders

Five questions for your next review

Can you show the five DORA metrics for our most important product, using DORA’s current definitions?
Which single constraint most limits our change lead time today, and what is the plan to remove it?
What share of last quarter’s deployments was rework triggered by incidents?
How quickly did we recover from our last three failed deployments, and what changed afterwards?
How are we making sure the metrics are used to improve the system, not to judge individuals?

As AI assistants change how code is written, DORA metrics become a useful guardrail: if lead time drops but change fail rate climbs, quality controls are not keeping up. Our article on managing engineers in the age of AI coding assistants covers how to adjust reviews and policies.

Engineering leadership

Want a delivery baseline your board can trust?

We set up DORA measurement on your existing tools, agree definitions with your teams, and turn the first baseline into a 90-day improvement plan.

Book a free 30-minute call

Sources

DORA’s software delivery performance metrics (dora.dev)

Originally published at phpscientist.com.

Laravel TokenGuard Auth Bypass (CVE-2026-114509): What Site Owners Must Do Now

Senthil Kumar MS — Sat, 24 Oct 2026 23:49:01 +0000

Act today if this applies to you

CVE-2026-114509 is a critical (CVSS 9.2) flaw in Laravel’s built-in token API guard. If your app authenticates API requests with the "token" driver and stores users in MySQL or MariaDB, an attacker with no account can sign in as an existing user, without that user’s token. Update laravel/framework to 12.68.0 or 13.29.0 or later. Apps that use only Sanctum, Passport or session logins are not affected by this flaw.

9.2 - CVSS v4 base score, rated critical (9.8 under CVSS 3.1)
0 - accounts, passwords or tokens the attacker needs
12.68 · 13.29 - the fixed laravel/framework releases
0 - official workarounds: updating is the fix

Laravel published the advisory on 19 October 2026. It affects a feature many teams forget they still have: the simple token guard that older Laravel apps used for their API before Sanctum existed. If your site or product was started a few years ago and has a mobile app, an integration or a partner API, it is worth five minutes to check. This guide explains, for site owners, whether you are exposed and what to ask your developer to do.

What the vulnerability does

Laravel’s TokenGuard checks an API token by looking up the user whose stored token matches the one sent with the request. Before the fix, it only checked that the value was not empty. It did not check that it was text.

An attacker can send a specially crafted value that is not text in a JSON request. On MySQL and MariaDB, the database then compares the stored tokens in a way that can match an existing user, so the request is treated as that user. The attacker does not need an account, a password or a real token, and no one has to click anything.

The result is account takeover on every route protected by that guard: reading the user’s data, changing it, or acting as them through your API. If the matched user is an administrator, the impact is the whole application.

Are you affected? A four-question check

You are exposed only if all four answers are yes:

QuestionHow to checkIf the answer is noIs laravel/framework older than 12.68.0 (or 13.x older than 13.29.0)?composer show --locked laravel/framework, or php artisan --versionYou already have the fixDoes config/auth.php define a guard with 'driver' => 'token'?Search config/auth.php for 'token'This flaw does not apply (Sanctum and Passport use their own guards)Do any routes use that guard?Look for auth:api or auth: in routes/, or run php artisan route:listThe guard is unused; still update and remove itAre users stored in MySQL or MariaDB?DB_CONNECTION in .envThe advisory names only MySQL and MariaDB; update anyway

Your developer can run these checks in a couple of minutes:

# 1. Which Laravel version is installed?
composer show --locked laravel/framework | grep versions

# 2. Is the built-in token guard configured?
grep -n "'driver' *=> *'token'" config/auth.php

# 3. Which routes use it? (usually the "api" guard)
grep -rn "auth:api" routes/ app/
php artisan route:list --middleware=auth:api

# 4. Which database holds your users?
grep -n "^DB_CONNECTION" .env

Common in older apps

Laravel 7 and earlier shipped an "api" guard with the token driver in config/auth.php by default. Many apps upgraded since then kept that guard even after moving to Sanctum, sometimes on a forgotten mobile or partner endpoint. Check it rather than assume.

Which versions are fixed

Laravel versionStatusWhat to do13.xFixed in 13.29.0Update to 13.29.0 or later12.xFixed in 12.68.0Update to 12.68.0 or later11.xNo fixed release named in the advisoryPlan the move to 12 or 13; apply the stopgap below meanwhile10.x and olderNo fix; out of security supportUpgrade; apply the stopgap below meanwhile

Some write-ups say Laravel 11.56.1 contains the same type check, citing the proof-of-concept authors. The official advisory does not list an 11.x fix, so do not rely on it: treat 11.x as unpatched until Laravel says otherwise, and check Laravel’s support policy for which versions still receive security fixes.

How to fix it

composer update laravel/framework --with-all-dependencies
composer show --locked laravel/framework | grep versions   # expect 12.68.0+ or 13.29.0+
php artisan optimize:clear
# Restart PHP-FPM, queue workers and Octane (commands depend on your server)

If you cannot update today: a temporary stopgap

The fix itself is small: TokenGuard now rejects any token that is not a non-empty string (see the current source). Until you can update, a middleware that does the same check before the guard runs closes the hole. Add it in front of your token-guarded routes and remove it after updating.

<?php
// app/Http/Middleware/RejectNonStringApiToken.php
// Temporary: blocks CVE-2026-114509 until laravel/framework is updated.
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class RejectNonStringApiToken
{
    public function handle(Request $request, Closure $next)
    {
        // Use your guard's input_key if you changed it from the default.
        $token = $request->input('api_token');

        if ($token !== null && ! is_string($token)) {
            abort(401);
        }

        return $next($request);
    }
}

Register it so it runs before auth:api on the affected routes. It is a stopgap only: the framework update is the real fix, and Laravel 10 and 11 apps still need an upgrade plan.

Is it being exploited?

As of 24 October 2026 there are no confirmed reports of attacks, and the flaw is not in CISA’s Known Exploited Vulnerabilities catalog. Security Online reports that a proof of concept has been published on GitHub, although the advisory itself links none. With a working example circulating, assume automated scanning will follow and patch exposed APIs first.

If you also run PHP 8.2 to 8.5, check that the server has this month’s PHP security release as well: our PHP2Shell guide covers the separate runtime fixes released on 21 October.

Questions to ask your developer or agency

Send this list today

Which laravel/framework version does each of our apps run, including staging and old microservices?
Does any app still have a guard with the token driver in config/auth.php, and which routes use it?
When will we be on 12.68.0 or 13.29.0, and were workers and Octane restarted after the update?
Have we rotated API tokens and reviewed API logs since 19 October?
If we are on Laravel 10 or 11, what is the upgrade plan and date?

Laravel security

Need your Laravel apps checked and patched?

We can audit every Laravel app you run for this flaw, apply the update or the stopgap without downtime, and plan the upgrade off unsupported versions.

Book a free 30-minute call

Sources

GHSA-f9x3-7vq9-cph6: Token-based API guard Auth Bypass (Laravel, 19 October 2026)
GitLab Advisory Database: CVE-2026-114509 (affected ranges, CVSS 3.1, CWE)
Illuminate\Auth\TokenGuard source (laravel/framework 13.x)
Laravel authentication bypass PoC released (Security Online)

Originally published at phpscientist.com.

REA (Reverse Engineer Anything): What AI Reverse Engineering Can and Can’t Do

Senthil Kumar MS — Sat, 24 Oct 2026 14:08:01 +0000

Short answer

REA (Reverse Engineer Anything) is an open-source, MIT-licensed MCP server that lets AI coding agents such as Claude Code, Codex, Cursor and Gemini CLI drive reverse-engineering tools. It returns pseudocode, assembly and behaviour, not original source code. It runs analysis locally, but results go to your AI model provider. It is not an Anthropic product, and the only official sources are github.com/morluto/rea and the rea-agents npm package: a fake copy distributed a trojan in October 2026.

MIT - licence: an independent open-source project, not an Anthropic or OpenAI product
1 of 3 - native engines needed for deep analysis: Hopper, Ghidra or IDA
0 - lines of original source code recovered: it returns pseudocode and assembly
172 - reported downloads of the fake rea-tools/rea “Windows exe” before the warning

REA went viral on GitHub in October 2026, and so did the claims around it. Some posts say it rebuilds any program’s source code. Others, this week, say Anthropic “quietly killed” it. Neither is accurate. This guide separates what the project’s own README and issue tracker confirm from what social posts claim, and gives security and engineering leaders a short policy for using it safely.

What REA is

REA is a Model Context Protocol (MCP) server for reverse engineering. Its README describes it as “one MCP for reverse engineering across binaries, applications, and runtime behavior.” Once registered, an AI coding agent can call its tools to inspect a target and explain what it does. The same tools also work from a terminal.

Native binaries, including Go and Rust, and GPU code objects
JavaScript and Electron apps, and .NET assemblies
Android APKs and devices, and Flutter apps
Websites, saved network captures and packet captures
Firmware, PyInstaller executables and Apple crash reports
Model files (GGUF, safetensors), SQLite databases and EVM bytecode

Deep native analysis needs one engine you install yourself: Hopper, Ghidra or IDA. Static JavaScript and .NET inspection needs none. Supported agent clients include Claude Code, Codex, Cursor, Gemini CLI and Grok Build, and any agent that supports local MCP servers can register it by hand.

What REA can and cannot do

ClaimRealityWhy it mattersIt reconstructs the original source codeFalse. It returns pseudocode, assembly and how functions relateOutput needs expert review; it is not a copy of the vendor’s codeIt replaces Ghidra or IDA ProFalse. It drives Ghidra, IDA or Hopper, which you install and licenseCommercial tools still need your own valid licenceIt works on any programPartly. Results depend on the format and the tools installedExpect gaps on packed, obfuscated or unusual targetsEverything stays on your computerAnalysis runs locally, but results go to your AI model providerTreat confidential binaries as data you are sending to that providerIt is an Anthropic productNo. It is an independent MIT project that supports several agentsAnthropic cannot “remove” it; check the repository for its status

Did Anthropic block REA?

Reddit conversations this week claimed Anthropic had “quietly killed REA” after viral demos of people analysing smart-TV firmware. We found no announcement, release note or press report of any such change, and the official repository carries no notice about it. Because REA is an independent project, Anthropic could at most change how Claude responds to particular requests, not remove the tool itself.

If an assistant declines a specific reverse-engineering request, that is a model-level decision about that request. It is worth reporting with an example, but it is not evidence that the tool was taken down.

The fake REA “Windows exe” trojan

On 13 October 2026 a user reported, in issue #2424 on the official repository, that a lookalike repository, rea-tools/rea, had copied the README and added a “Windows Standalone .exe” section. Its release served rea-x64.7z (82.6 MB) containing rea-x64.exe, reported as downloaded 172 times.

The reporter cited Microsoft Defender detections (Trojan:Win32/Wacatac.B!ml for the extracted file) and 8 of 45 engines on VirusTotal flagging it as a trojan or dropper. The maintainer closed the issue the same day with a README warning. REA has no official Windows installer: it is installed through npm.

If anyone downloaded it

Treat any machine that ran rea-x64.exe from rea-tools/rea as compromised: isolate it, run a full scan, and rotate any credentials, tokens and SSH keys used on it. Then reinstall REA from npm.

How to install REA safely

Install only from the official project. The package name is rea-agents and it needs Node.js 22, 24 or 26.

# Check the package before installing: it should point to github.com/morluto/rea
npm view rea-agents repository.url

# Register REA with your agent (Claude Code, Codex, Cursor, Gemini CLI…)
npx rea-agents setup

# Or install the CLI globally, then verify registry signatures
npm install --global rea-agents
npm audit signatures

Never download REA as an .exe, a .7z archive or from a site other than GitHub, npm and the project’s own pages. Search results and “download” repositories are where the fake copy spread.

The legal line

REA’s README limits it to lawful research, education, interoperability, software preservation and analysis of software you own or are authorised to examine. It grants no licence for commercial tools such as IDA Pro, Hopper or JEB, and says cracked copies, stolen keys and bypassing licence restrictions are not authorised. Contract terms and local law still apply to the software you analyse.

A five-point policy for engineering teams

Before anyone on the team uses REA

Install only from github.com/morluto/rea or the rea-agents npm package, and block the rea-tools/rea lookalike.
Analyse only software you own or have written permission to examine, and record that permission.
Remember analysis results go to your AI model provider: keep confidential or customer binaries out unless your contract allows it.
Run it on a non-production machine or VM, never on servers that hold production credentials.
Treat its output as a lead for an expert to verify, not as recovered source code or proof.

Application security

Want AI tooling adopted safely across your team?

We review AI coding agents, MCP servers and their data flows, and set the guardrails that let engineers use them without new supply-chain or data-exposure risk.

Book a free 30-minute call

Sources

REA official repository and README (morluto/rea, MIT licence)
Issue #2424: fake repo rea-tools/rea distributes a trojan “Windows exe” (13 October 2026)
REA, AI reverse engineering at record pace on GitHub: what is true and what is not (Pasquale Pillitteri)

Originally published at phpscientist.com.

PHP 8.2 End of Life: Upgrade Before 31 December 2026

Senthil Kumar MS — Fri, 23 Oct 2026 13:10:02 +0000

In brief

PHP 8.2 receives security fixes only until 31 December 2026. After that date, no new vulnerability in PHP 8.2 will be fixed by the PHP project. The current release, 8.2.35 from 21 October 2026, fixed two critical remote code execution flaws, a reminder of what an unsupported version would miss. Move to PHP 8.4 (security fixes until 31 December 2028) or PHP 8.5 (until 31 December 2029), and start now: a tested upgrade takes most teams several weeks.

31 Dec 2026 - last day of security support for PHP 8.2
~10 weeks - left from the October security release to end of life
8.4 or 8.5 - the versions to target, supported until 2028 and 2029
2 - critical RCE flaws fixed in 8.2.35, the kind of fix that stops after end of life

The PHP 8.2.35 announcement on 21 October 2026 carried two messages. The first was urgent: it fixed CVE-2026-109618 and CVE-2026-109619 (known as PHP2Shell), two critical flaws that can allow unauthenticated remote code execution (see our guide to the October security release). The second was a deadline: “PHP 8.2 reaches end of life on 31 December 2026 and will receive no further security fixes after that date.”

What end of life means for PHP 8.2

Each PHP version gets two years of active support (bug and security fixes) and two more years of security fixes only. When security support ends, the PHP project stops publishing fixes for that branch altogether. A vulnerability found in January 2027 will be fixed in 8.3, 8.4 and 8.5, and not in 8.2.

VersionActive support untilSecurity fixes untilStatusPHP 8.2Ended 31 Dec 202431 Dec 2026Upgrade nowPHP 8.3Ended 31 Dec 202531 Dec 2027Short-term optionPHP 8.431 Dec 202631 Dec 2028Recommended for mostPHP 8.531 Dec 202731 Dec 2029Longest support

Some Linux distributions and commercial vendors keep patching PHP 8.2 inside their own long-term releases. That buys time on those platforms, but only for what the vendor chooses to backport, and only on their packages: official Docker images and source builds stop with the PHP project.

Which version should you move to?

🪜 PHP 8.3: the smallest step

Fewest changes from 8.2, so the quickest upgrade.
But security fixes end on 31 December 2027: you would repeat the exercise in a year.

✅ PHP 8.4: the right target for most

Security fixes until 31 December 2028.
Mature and widely supported by frameworks, CMSs and hosting platforms.
Adds property hooks and asymmetric visibility.

🚀 PHP 8.5: the longest runway

Security fixes until 31 December 2029.
Adds the pipe operator and a built-in URI extension.
Check that your framework, CMS and extensions support it before you commit.

What changes between 8.2 and 8.4 or 8.5

Most applications that run cleanly on 8.2 move to 8.4 with modest work. The changes to watch, by version:

**PHP 8.3: **typed class constants, json\_validate(), the #\[\\Override\] attribute, and readonly properties that can be reinitialised during cloning.
**PHP 8.4: **property hooks, asymmetric visibility, new without parentheses in method chains, array\_find() and friends, and a deprecation that catches many older codebases: implicitly nullable parameters such as function f(Foo $x = null) must now be written ?Foo $x = null.
**PHP 8.5: **the pipe operator |>, the URI extension, clone with property overrides, the #\[\\NoDiscard\] attribute, array\_first() and array\_last(), and backtraces in fatal errors.

Deprecations are notices, not failures, but they become errors in a later major version. Fix them as part of the upgrade rather than silencing them. Our overview of PHP 8.3 and later covers the new features in more depth.

A five-step upgrade plan

Scan for compatibility problems and apply safe automatic fixes:

# Find code that breaks or is deprecated on PHP 8.4
composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs -p --standard=PHPCompatibility --runtime-set testVersion 8.4 src/

# Preview automatic upgrades (review the diff like any pull request)
composer require --dev rector/rector
vendor/bin/rector process src --dry-run

<?php
// rector.php: upgrade rules for PHP 8.4
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src'])
    ->withPhpSets(php84: true);

While you are changing runtimes, it is a good moment to review your PHP configuration too: our guide to secure PHP settings lists the production defaults worth carrying over.

If you cannot upgrade by 31 December

**Use a vendor that still patches 8.2. **Your Linux distribution’s long-term packages, or a commercial extended-support build. Confirm in writing which fixes they cover and until when.
**Reduce exposure. **Keep unsupported systems off the public internet where possible, behind a VPN or an IP allow-list, and apply the interim hardening from the October advisory.
**Set a date. **End of life does not move. Every month on an unsupported version adds risk, and the next critical flaw will not be fixed for it.

Questions for your team this week

Five questions

Which of our applications, containers and servers still run PHP 8.2 or older?
Are we already on 8.2.35, with the October security fixes?
Does every framework, CMS, plugin and extension we use support PHP 8.4?
Who owns the upgrade, and what is the target date before 31 December?
For anything that will miss the date, what is the interim plan and who signs off the risk?

PHP upgrade

Need a hand getting off PHP 8.2?

We can inventory your PHP estate, check your stack’s compatibility, and plan and run the upgrade to PHP 8.4 or 8.5 without downtime.

Book a free 30-minute call

Sources

Originally published at phpscientist.com.