Sheet cake. Every long modernization program I have worked near eventually buys one, and it is always for the same kind of occasion: after two or three years of dragging a platform older than half the team toward something that will still be supported in 2030, one thing finally works on the first try. This time the thing was the automation. A change request came in, and instead of an analyst spending Tuesday hunting through four tools to find out which requirements it touched, a pipeline traced them, checked test coverage, drafted the work items and produced a summary for review. Minutes.
Then twelve weeks pass. A requirement comes back, the same shape as the one that quietly wrecked the previous attempt at this migration, and nobody in the room recognises it, because it does not arrive wearing a warning label. It arrives well formed. Structured description, testable acceptance criteria, a traceability link back to the change request that spawned it, an audit record showing exactly who touched it and when, and it clears the pipeline in a fraction of the time the old process would have taken. Faster. That is the sentence worth sitting with, and none of it is a complaint about the automation.
What does enterprise-scale agentic requirements automation actually solve?
The coordination tax. That prize is larger than it sounds. On 18 June 2026, IBM published the release notes for Engineering AI Hub 1.3, describing it in its own words as a unified, extensible agentic automation platform for IBM Engineering Lifecycle Management, and the feature list reads like a precise inventory of where large engineering organizations lose their weeks. A managed Model Context Protocol endpoint provides lifecycle-aware access to lifecycle-management data. Support for A2A-compliant agents lets IBM's own agents join custom multi-agent workflows built on open standards. Amazon Bedrock joins watsonx.ai on the approved-provider list, and the platform now deploys on CNCF Kubernetes and into air-gapped installations, which sounds like a footnote until your modernization program happens to live inside aerospace, defence or medical devices.
The worked example IBM gives is worth quoting, because it is exactly the labour that eats analysts alive. A multi-agent workflow can "assess a change request, identify related requirements, review impacted work items, check test coverage and prepare a summary for engineering review, all in one go." Anyone who has assembled that by hand, across four systems and a Confluence page last edited in 2019, knows what it is worth. A great deal. The Work Item compose agent underneath it arrived earlier, announced on 19 February 2026 with general availability planned for 26 March, drafting epics, features and user stories directly inside the Engineering Workflow Management interface, and 1.3 extends it so a team can customize the prompts and get first drafts in its own house style instead of a generic one.
Let me be unambiguous, because the rest of this article is going to complicate it. This is good infrastructure, built by people who obviously understand regulated engineering, and IBM is careful about the claim it makes for it: "Engineers remain in control, while agents reduce the manual effort required to gather, connect and interpret lifecycle information." Gather, connect, interpret. Read the verbs. Not one of them is decide, and IBM is not pretending otherwise, which is more discipline than most of this market shows.
Over 65%
of engineering teams using agentic coding will treat integrated development environments as optional by 2027, "shifting control, governance and validation to automated platforms," according to Gartner. Note that this is a forward-looking prediction rather than a measurement, and note where validation is predicted to go. Onto the platform. The platform can validate a great many things, and the truth of a requirement is not one of them.
Source: Gartner press release, Gartner Says the Market for Enterprise AI Coding Agents Is Entering a New Phase of Expansion and Competitive Realignment, Stamford, 20 May 2026, quoting Sr Director Analyst Philip Walsh. Prediction, not survey data.
Why do legacy-modernization programs keep failing even as automation matures?
Because throughput was never the binding constraint. Modernization programs have been handed better tooling every single year for two decades, better version control and better pipelines and better test frameworks and better traceability and better everything, and the outcome distribution has been remarkably indifferent to the whole parade. Something else kills them. It is usually a decision nobody could state precisely, made by people who could not get thirty minutes with the one person who knew why the old system behaved the way it did, and then executed with real competence.
We made an early version of this argument in July: the agentic software development lifecycle arrived considerably faster than the requirements feeding it got any better. Legacy modernization is the extreme case of that gap, because a legacy system is twenty years of sediment, and the reasons for most of it walked out of the building with the people who made the calls. The code is not the requirement. The code is what somebody did about a requirement in 2004, shaped by the constraints of 2004, patched in 2011 by a contractor nobody can name, and there is no dependable way to read intent back out of it. You can read behaviour. Intent is a different substance, and it lives in conversations.
From the field
Quebec spent a year and a half examining one of these programs in public, under oath, and the transcript is instructive for anyone about to industrialize a modernization pipeline. The Commission d'enquête sur la gestion de la modernisation des systèmes informatiques de la Société de l'assurance automobile du Québec, chaired by Judge Denis Gallant, was created on 24 March 2025 with a mandate to identify the causes and circumstances of the management and delivery problems in the CASA program, the modernization effort behind the SAAQclic platform, as those problems had been found by Quebec's Auditor General. It sat for 75 hearing days between 24 April and 24 October 2025 and heard 129 witnesses. One program. The report was published on 16 February 2026. Reporting on it in Le Devoir, the digital shift was judged "trop vaste, trop ambitieux", and the commission's structural remedy is the part worth copying: among 26 recommendations, it proposes a centralized state body for digital transformation whose opinion public bodies must obtain before any large project, and it recommends favouring smaller projects with costs capped below 50 million dollars. Read that as an engineering recommendation rather than a political one. The commission's answer to a program too large to be understood is not better tooling. It is smaller units of work that a human being can still hold in their head long enough to check.
Sources: Commission d'enquête sur la gestion de la modernisation des systèmes informatiques de la SAAQ (mandate, hearing dates, 129 witnesses, 75 hearing days; report published 16 February 2026), and Le Devoir's coverage of the 26 recommendations, 16 February 2026. Public sector, Quebec.
I used to read cases like that as governance failures, full stop, and I was partly wrong about that. Governance was certainly involved. But governance is a system for making sure decisions get recorded and escalated, and it says nothing at all about whether the decision was right when somebody made it, which means a program can be impeccably governed and still be building the wrong thing at speed. Adding agents to that program does not change the direction. It changes the velocity, and the audit trail gets much better at documenting exactly how you got there.
What is the one question automation cannot answer for you?
Should this be true? That is the whole question, and it looks so plain written down that it is easy to miss the weight it carries: not whether the requirement is well formed, not whether it is traceable, not whether it is testable, but whether the claim inside it accurately describes what this business needs, and who in the building would object if you put it in front of them.
An agent can do a great deal with that requirement once it exists. It can surface the related ones, flag conflicts against everything already in the repository, spot the missing acceptance criterion, check whether a test covers it, and it will do all of that more consistently at 4pm on a Friday than any tired human. Genuinely useful work. What it cannot do is walk down two floors and discover that the rule everyone cites as a regulatory obligation is actually a workaround somebody invented in 2009 for a system that was decommissioned in 2014, kept alive since then because questioning it was never anybody's job. That fact exists in exactly one place, which is a person's head, and a governed pipe to your requirements repository will retrieve everything except the thing nobody wrote down.
40% vs 23%
Practitioners are already drawing this line themselves. In BMC's 2026 Mainframe Survey, 40% are willing to have artificial intelligence recommend code-management actions while just 23% are willing to let it complete them, and the same shape appears for database reorganizations, where 43% want a recommendation and 21% are comfortable letting the system carry it out. That is not technophobia. It is a working distinction between analysis and judgement, held by people who run these systems for a living.
Source: BMC Software, Trust Powers AI on the Mainframe, 1 September 2026, reporting the annual BMC Mainframe Survey: more than 1,300 mainframe practitioners and decision makers globally, fielded 24 March to 20 April 2026. Vendor-run survey; BMC sells mainframe automation software.
How does requirements validation have to sit upstream of an agentic pipeline?
Structurally, and before the first work item exists. Most programs treat validation as a review step, which puts it after the requirement has already been written, socialised, estimated and half-committed to, and by then the honest question has become socially expensive to ask. Too late. Validation belongs at the point where the claim is still cheap to lose, and the practical test for whether you have it is simple enough to run this week. Pick five requirements from your current backlog. For each one, answer three questions:
- Which named person confirmed this requirement?
- What, specifically, were they invited to disagree with?
- If they had said no, would anything downstream have changed?
Count the answers. If you cannot answer all three for at least four of those five, the validation stage does not exist yet in your process, whatever the diagram on the wall happens to show.
The mechanics of doing this well are less obvious than the principle. One analyst interviewing one stakeholder produces one framing, filtered through whatever that analyst already believed on the way into the room, which is exactly how a workaround gets recorded as a business rule and a hard regulatory constraint gets recorded as a preference. One pass, one bias. Several specialists interrogating the same interviews, tickets and policies from deliberately different expert positions produce something sturdier, because their questions collide, and the collisions are where an unstated assumption finally surfaces. Specira runs five agents on that material: four analysts working it from distinct angles, plus a Red Team Critic whose only job is to attack what the other four produced. That is the product I am building, so weigh the pitch accordingly and judge the mechanism rather than the brand. The critic is the piece that matters to this argument, because it is the one that asks why a rule exists rather than whether the rule is phrased clearly.
Then automate everything downstream of it, hard, with whatever platform your organization has standardised on. This is not an argument for keeping humans in the loop out of sentiment, and it is not the argument that the business analyst is safe because machines cannot do the work. Machines can do a great deal of that work. They should. The part that does not automate is smaller than most people think and more important than most budgets reflect: deciding, with a real stakeholder in the room, whether the thing you are about to build at machine speed is the thing worth building at all.
Key takeaway
Agentic requirements automation is real infrastructure and large modernization programs should adopt it, because the coordination tax it removes is enormous and entirely wasteful. Notice what it moves. And what it does not. It industrializes everything that happens to a requirement after somebody asserts it, and asserts nothing about whether the assertion was ever checked, which means an unvalidated requirement in a well-governed agentic pipeline does not become safer. It becomes faster, better documented, and considerably harder to question.
What has to happen to a requirement before it enters an automated pipeline?
Validation, first. The planner is the cheapest place to find out, returning the charter sections that have no objective and no constraint in them, which is a list an automation platform will never generate because it only sees what you already fed it. Discovery closes those gaps with five agents on the same conversation. Then the integrations push the validated version downstream and the export package carries the deliverables, grouped by the agent that owns each one, into whatever the pipeline does next.
What you are looking at. The planner is the check that happens before the pipeline, the integrations are where the validated requirement enters it, and the export package is the deliverable set that comes out.
Bring one requirement from the modernization backlog you are about to automate. We will show you what the pipeline would have assumed.
Book a DemoScreens are from a seeded Specira demo workspace; counts and scores are sample data.
What are the most common questions about agentic automation in legacy modernization?
