The Top 5 AI Changes Hitting Software Development for the Week of April 27, 2026
This week was not about autocomplete. It was about AI moving deeper into the real work of software delivery. Or was it?
From April 22 to April 29, 2026, the biggest announcements and research all pointed in the same direction: AI coding tools are becoming agents that plan, change code, test, review, open pull requests, and fit into enterprise workflows.
Here are the five changes Scrum and Agile teams should pay attention to.
- AI coding agents are getting better at long, messy engineering work
OpenAI released GPT-5.5 on April 23. OpenAI says it is their strongest agentic coding model so far. It scored 82.7% on Terminal-Bench 2.0 and 58.6% on SWE-Bench Pro. OpenAI also says GPT-5.5 is stronger at holding context across large systems, checking assumptions with tools, debugging, testing, and carrying changes through a codebase.
That matters because real software work is rarely one clean prompt. Most useful work includes unclear bugs, old code, hidden dependencies, half-written tests, and tradeoffs.
For Scrum teams, this changes refinement. A Product Backlog Item can no longer stop at “build the feature.” Teams need clearer acceptance examples, constraints, test expectations, and review rules. The AI can write more code, but the team still owns the intent.
- AI agents are moving into enterprise infrastructure
On April 28, OpenAI announced that OpenAI models, Codex, and Managed Agents are coming to AWS in limited preview. The announcement says AWS customers can use OpenAI models, including GPT-5.5, through Amazon Bedrock, and can configure Codex to use Bedrock as the provider. OpenAI also says Codex now has more than 4 million weekly users.
This is a major shift. AI coding is no longer just a developer tool running in an editor. It is becoming part of the company’s approved cloud, security, billing, identity, and compliance path.
For Agile leaders, this means AI adoption will move from local experiments to platform decisions. Teams will need working agreements for when agents can touch code, which repos they can access, what data they can see, and what must be reviewed by a human.
- The IDE is becoming a control room for remote agents
Microsoft’s April 28 Visual Studio update brings cloud agent integration into the IDE. Developers can start a remote coding session from Visual Studio. The cloud agent can ask permission to open an issue, work remotely, and create a pull request while the developer keeps working. The update also adds user-level custom agents, generally available C++ code editing tools for agent mode, and a Debugger Agent that validates fixes against runtime behavior.
This changes the daily flow of development. A developer may not spend the day typing every line. They may spend more time splitting work, giving agents bounded tasks, reviewing pull requests, running tests, and deciding whether the result matches the product goal.
For Scrum teams, this affects the Daily Scrum. “What did I do yesterday?” becomes less useful than “What work did I delegate, what came back, what is blocked, and what needs review?”
- AI coding cost is becoming a planning constraint
GitHub announced on April 27 that all GitHub Copilot plans will move to usage-based billing on June 1, 2026. Instead of premium request counts, plans will include monthly GitHub AI Credits. Usage will be based on token consumption, including input, output, and cached tokens.
GitHub also announced that GPT-5.5 is becoming generally available in GitHub Copilot for Pro+, Business, and Enterprise users across tools including VS Code, Visual Studio, Copilot CLI, GitHub Copilot cloud agent, JetBrains, Xcode, Eclipse, GitHub Mobile, and github.com.
This means teams will need to treat agent use like cloud use. Long prompts, large context windows, repeated retries, and broad agent runs may have real cost.
For Agile teams, this adds a new planning question: what work is worth agent spend? A good Definition of Ready may include enough context to avoid waste. A good Definition of Done may include proof that the agent’s output was tested, reviewed, and not just accepted because it compiled.
- New research shows agents are useful, but still wasteful and risky
A Stanford paper released on April 22 introduced SWE-chat, a large dataset of real coding-agent sessions from public repositories. The dataset includes 6,000 sessions, more than 63,000 user prompts, and 355,000 tool calls. The authors found that in 41% of sessions, agents wrote almost all committed code, while in 23%, humans wrote all the code themselves.
The same paper found that only 44% of agent-produced code survived into user commits, and that users pushed back against agent outputs in 44% of turns. It also found that agent-written code introduced more security vulnerabilities than human-written code in their dataset.
That is the most important warning from this week.
AI coding agents are not magic teammates. They are powerful, fast, uneven workers. They can save time, but they can also create waste. They can generate code, but they do not replace engineering judgment.
For Scrum teams, the practical lesson is simple: keep the feedback loops tight.
Use small slices.
Ask for tests.
Review the diff.
Run the build.
Check the security impact.
Make the acceptance criteria visible.
Do not let the agent become a hidden developer on the team. Make its work inspectable.
The big picture
The center of software development is shifting.
The old model was: developer writes code, tool helps.
The new model is: team defines intent, agent proposes changes, humans inspect, test, and decide.
That puts more pressure on product clarity, technical discipline, and team agreements. It also makes Scrum more important, not less. Scrum is built around transparency, inspection, and adaptation. Those are exactly the habits teams need when AI starts producing more of the code.
The teams that win will not be the ones that blindly “use AI more.”
They will be the teams that learn how to steer it.