When you modernize a .NET Framework application to modern .NET, you end up with a transformed, buildable codebase — but the question that immediately follows is always the same: how do I safely keep changing it from here? Once the code is modernized, your team keeps evolving it — fixing bugs, adding features, upgrading dependencies — and each change needs a way to confirm the modernized code still behaves as expected. Building that safety net has always been the developer’s job, and while AI agents now help produce the tests, getting coverage with the ability to catch regressions remains hard. That is exactly the gap the newest AWS Transform for .NET capability closes.

As of September 2026, AWS Transform for .NET can automatically generate unit tests for the code it modernizes. When you enable it, AWS Transform generates unit tests that target the testable classes in your transformed application — business logic, controllers, and the like—giving you an automated test safety net as part of the same job that performs the modernization. In this post, I’ll walk you through how the unit test agent fits into the transformation flow and how to run it after a .NET transformation in Visual Studio.

Why this matters

A previous post walked through a sizeable .NET transformation using the conversational AI assistant in Visual Studio — assessment, plan review, project-by-project transformation, a local build, and a final set of artifacts. At the end of that walkthrough, the result was a transformed solution that built cleanly. But a clean build only tells you it compiles — the modernized code has little or no test coverage to validate future changes. That is where the unit test agent comes in: the tests it generates capture the behavior of the modernized code and become the safety net that guards every future change, so the next edit someone makes can’t quietly break it.

Tests generated against the modernized code establish a behavioral baseline you can build on: every time your team fixes a bug, adds a feature, or bumps a dependency, the test suite tells you whether the change is safe or something regressed. Developers today rarely write all of that coverage by hand — they lean on AI agents to help. The hard part isn’t producing some tests; it’s producing effective ones: high line and branch coverage, ability to catch regressions, tests that run fast, and — critically — coverage generated without altering the original code under test. The unit test agent addresses this directly: it produces test coverage for the modernized code so you finish the modernization with tests already in place, rather than treating test authoring as a separate project that starts after the modernization ends.

How the unit test agent works

The unit test agent runs alongside the standard transformation rather than bolting on afterward. When enabled, AWS Transform:

1. Assesses your application for testability in parallel with the standard .NET assessment.
2. Plans which classes and methods to cover — focusing on the testable units such as business logic and controllers.
3. Generates the corresponding unit test code so the test project is populated as part of the same job that performs the modernization.

The important design choice here is that unit test generation is opt-in, and you have two moments to opt in:

• At the start of a job — so testability assessment and test generation happen together with the transformation, unattended.
• After transformation completes — so you can transform first, review the modernized code, and then ask for tests once you’re satisfied with the port.

If unit test generation is enabled as part of the transformation, the tests are generated automatically, without any additional steps from the developer — testability assessment, coverage planning, and test code generation all happen within the same job that performs the modernization.

That flexibility mirrors the rest of the AWS Transform experience: you stay in control of when the agent does work, and you can let it run unattended or drive it interactively.

Prerequisites

To generate unit tests with AWS Transform for .NET, you’ll need the following:

Unit test generation is available in all AWS Regions where AWS Transform for .NET is supported.

Walkthrough: adding the unit test agent after a transformation

Let me walk through the flow the way you’d actually experience it in Visual Studio.

Step 1: Start a transformation (with tests in mind)

In this step, before starting the transformation setup sample application using following steps using Visual Studio:

1. Clone git hub sample (https://github.com/aws-samples/bobs-used-bookstore-sample.git) by going to Git → Clone Repository, paste https://github.com/aws-samples/bobs-used-bookstore-sample.git, and choose a local path (Figure 2). Choose Clone which is .NET 10 sample.

Figure 2: Clone repository

2. Select .NET version 8 or version 6 by following one of the options:
   1. Switch to a branch (.NET 8, e.g. v2).
      1. Click the branch name in the status bar at the bottom right, or open Git → Manage Branches.
      2. Under remotes/origin, right-click v2 and choose Checkout. Visual Studio creates a local v2 branch that tracks it.
   2. Switch to a tag (.NET 6, v1.12.0). Tags are harder to reach in the Visual Studio UI, so the Developer PowerShell is the simplest way using the following steps:
      1. Open View → Terminal, which is a Developer PowerShell with Visual Studio’s bundled git.
      2. Run: git checkout -b net6 v1.12.0 This creates a local branch net6 from the .NET 6 tag. Visual Studio will reload the solution.

Open your solution in Visual Studio, sign in to AWS Transform on the Getting Started panel (Extensions > AWS Toolkit > Getting Started), and confirm your region and workspace on the AWS Transform Dashboard. To initiate the transformation, select the solution in Solution Explorer and choose Port solution with AWS Transform from the context menu, then specify the target framework.

Figure 3: Initiating a transformation job

This is the first decision point for tests. If you want to add unit test along with transformation, choose to generate unit tests at the start of the job. AWS Transform then assesses testability in parallel with the standard assessment, so by the time the transformation plan appears, the plan to cover the testable classes is already part of it. If you’d rather see the modernized code first, skip it here and enable it later — Step 4 covers that path.

Figure 4: AWS Transform dialog with Generate unit tests option

As with any AWS Transform job, you can choose interactive mode (the agent pauses for review and lets you steer) or autonomous mode (unattended, suitable for overnight jobs). Working interactively lets you see what the test agent proposes.

Step 2: Review the assessment

Once the job starts, the familiar windows open — Chat, Worklog, and Job Plan. When unit test generation is enabled at the start, the assessment shows up alongside the standard assessment summary in chat.

The agent focuses on the testable units and identifies the potential code for which unit test can be generated by analyzing the pre transformed code.

Step 3: Transform your projects

Approve the plan and let the agent transform the solution. The transformation itself proceeds exactly as it does without tests: projects are ported in dependency order, code changes are applied in Visual Studio automatically, and you can review diffs and ask the agent to explain any change. Because test generation was enabled at the start, the test project is populated as the corresponding production code is transformed, so tests arrive as part of the same job rather than as a separate follow-on effort.

Step 4: (Alternative) Enable unit test generation after transformation

If you didn’t opt in at the start — maybe to see the ported code before committing to tests — there’s no need to start over. Unit test generation is opt-in after transformation completes as well in the interactive mode. Once the transformation finishes and you’ve reviewed the modernized solution, ask the agent to generate unit tests. It runs the same testability assessment, plans coverage over the testable classes in the already-transformed code, and generates and validate the test code. This is the path to prefer when you want to eyeball the port first: transform, confirm the modernized code looks right, and then add the safety net.

Figure 5: Worklog pane showing unit test generation

You can also view the status of unit test generation from the web console view of your job. Figure 6 shows 3 test projects were generated with 42 test files.

Figure 6: Web console view of job with unit test activity

Step 5: Review, Build and run the generated tests

The AWS Transform transformation report shows unit test results. Once Generate Unit test is complete, testable methods count, Line/Branch Coverage per project can be seen by selecting “Unit Test Generation” per project (Figure 7).

Figure 7: Unit test generation results in transformation report

A summary of all the test across all projects can be seen under section “Unit Test Results” (Figure 8).

Figure 8: test results summary in transformation report

Conclusion

Modernizing a .NET Framework application has always produced a buildable codebase; what it hasn’t always produced is a way to maintain it with confidence. The generated Unit tests establish a coverage baseline on the modernized code so that every change made afterward can be checked by re-running the suite. With automatic unit test generation, AWS Transform for .NET provides that baseline as part of the modernization — assessing testability in parallel with the standard assessment, planning coverage over your testable classes, and generating the test code within the same job. Because it’s opt-in at either the start of a job or after transformation completes, you decide whether tests ride along with the modernization or get added once you’ve reviewed the port.

Try it on your next .NET modernization. Run a transformation with AWS Transform for .NET in Visual Studio, choose to generate unit tests, and finish the modernization with a maintenance safety net already in place for the changes that follow. To learn more, see Modernizing .NET in the IDE in the AWS Transform User Guide and the launch announcement.

As AI models become more capable, they uncover more security vulnerabilities and identify increasingly sophisticated paths to exploit them, raising the bar for how quickly defenders must respond. Security teams now face more potential vulnerabilities than their existing processes were designed to handle — each requiring investigation, reproduction, and a repair that must be tested to confirm it closes the vulnerability without breaking expected behavior.

AWS Continuum for code vulnerabilities accelerates this work with autonomous security at machine speed. To measure Continuum against a concrete public standard, we chose CyberGym-E2E, which asks an agent to find a vulnerability in a real codebase, demonstrate it with a working proof of concept, and repair it without breaking behavior covered by the project’s tests. Continuum passed 819 of 920 tasks within the benchmark’s 90-minute limit, achieving an 89.0% end-to-end success rate. This establishes a new standard 23.1 percentage points up from the previous public high of 65.9%.

Many security benchmarks test a single task in isolation. Detection benchmarks test whether a system can identify suspicious code, while patching benchmarks begin with a known flaw and ask for a fix. CyberGym, the predecessor to CyberGym-E2E, also begins with a known vulnerability and focuses on exploit generation. By contrast, CyberGym-E2E evaluates the full vulnerability lifecycle, requiring a system to identify and demonstrate a vulnerability before producing a tested repair. This broader scope more closely reflects the work facing security teams.

Each CyberGym-E2E task places an agent in a container with a vulnerable revision of a real open-source project and the tools needed to build and test it. An agent can inspect and modify the source, but receives no vulnerability description, proof of concept, crash log, or original patch. External network access is blocked, and protected benchmark files cannot be modified. Within 90 minutes, the agent must submit an input demonstrating a vulnerability and a source-code patch. The full benchmark contains 920 tasks based on historical OSS-Fuzz vulnerabilities across 139 open-source projects. The median project contains more than 600,000 lines of code.

The benchmark evaluates each submission in four cumulative stages:

1. S1 checks whether the agent produced an input that crashes the vulnerable program.
2. S2 checks whether the agent’s patch prevents that crash.
3. S3 checks whether the patched project still passes its functionality tests.
4. S4 checks whether the patch also fixes the specific historical vulnerability selected by the benchmark.

CyberGym-E2E defines S3 as its main measure of end-to-end success. S4 is diagnostic because a repository may contain several valid vulnerabilities: an agent can find and repair a real flaw that differs from the benchmark’s selected target.

Continuum for code vulnerabilities reached a new standard for every stage of CyberGym-E2E. The table below compares its performance with the previous best public results.

On S3, the benchmark’s main measure of end-to-end success, Continuum passed 819 of 920 tasks. Its 89.0% success rate exceeds the previous public high of 65.9% by 23.1 percentage points. The result reflects both the capability of the underlying frontier models and Continuum’s design as a multi-agent security system. The next section examines how that system adds value beyond the models alone.

The official 89.0% result applies CyberGym-E2E’s 90-minute limit. When tasks were allowed to continue beyond that limit, Continuum’s end-to-end pass rate reached 93.7%, indicating higher potential coverage when longer-running analyses can complete.

We conducted the evaluation under CyberGym-E2E’s network-isolation and submission-review requirements. External retrieval was blocked during execution, and post-run trajectory review confirmed that successful results came from vulnerability analysis rather than retrieval of public historical fixes.

Continuum for code vulnerabilities is a multi-agent system organized around the main phases of the code vulnerability lifecycle: discovery, validation, and remediation. Each phase uses specialized agents adapted to the evidence and decisions it requires. The system carries evidence forward so that each phase builds on the work completed before it.

During discovery, Continuum analyzes the repository and develops candidate vulnerability findings. Its agents identify code paths that warrant deeper investigation and record the source evidence supporting each candidate.

During validation, specialized agents attempt to turn a candidate finding into a demonstrated security issue. They construct a proof of concept, run it against the vulnerable program, and determine whether the observed behavior supports the finding. This converts a potential code-level weakness into executable evidence.

During remediation, agents trace the vulnerability to its root cause and produce a patch. Continuum then verifies that the patch prevents the demonstrated failure and that the project’s functionality tests continue to pass. The repair is therefore evaluated against the same evidence used to establish the vulnerability.

Together, these phases create a connected record from suspicious code to a demonstrated vulnerability and tested repair. The architecture allows Continuum to adapt its tools, instructions, checks, and models to each phase while maintaining a consistent standard of evidence. It also supports a multi-model approach that can leverage complementary strengths and incorporate new models as they become available.

In customer environments, Continuum can also combine code-level evidence with available deployment context, including service exposure, network paths, permissions, and configuration. This context helps distinguish vulnerabilities with limited production impact from exposures that demand immediate action. CyberGym-E2E evaluates the code-level process but does not provide deployment context, placing this broader prioritization capability outside the benchmark’s scope.

CyberGym-E2E advances security evaluation by turning a complex, multi-stage process into a large public benchmark with reproducible tasks and outcomes that can be verified by running code. The CyberGym-E2E authors’ careful work on task construction, scoring, and submission standards gives the field a concrete foundation for measuring end-to-end progress.

To keep evaluation consistent and reproducible across 920 tasks, CyberGym-E2E focuses on memory-safety vulnerabilities in C and C++ projects. Sanitizer-detected crashes provide objective evidence of a defect, while subsequent checks determine whether a repair blocks the proof of concept and preserves functionality covered by the project’s tests. This design necessarily leaves many languages and vulnerability classes outside the benchmark’s current scope, including many of the most common and impactful bug classes observed in production systems. Evaluating these areas will require different task environments and equally rigorous forms of validation.

Our view of end-to-end security also extends beyond producing a tested code-level repair. In production systems, deployment context such as service exposure, network paths, permissions, and configuration often determines whether a vulnerability presents limited risk or demands immediate action. Future evaluations should test whether autonomous systems can reason about this context and prioritize findings according to their effect on the safety of the deployed system.

CyberGym-E2E’s value extends beyond the dataset itself. It makes the case that end-to-end security is worth defining and measuring as a task in its own right. That involves hard design choices about scope, evidence, and what counts as success, and CyberGym-E2E gives the field a concrete starting point for working through those choices. This system-level view complements our work on the Deception Benchmark, which evaluates a narrower but related capability: how reliably individual frontier models distinguish real vulnerabilities from safe code. Together, they examine security performance at both the model and system levels.

To learn how AWS Continuum for code vulnerabilities helps teams discover, validate, prioritize, and remediate vulnerabilities at machine speed, visit the AWS Continuum product page.

Azure Standard founder pens new book, stays true to farm roots

Published 7:30 am Tuesday, October 6, 2026

Founder and CEO wants to encourage farmers, those with health issues

DUFUR, Ore. — This small town, population 650, holds the headquarters for an organic and natural foods distributor with 500 farm partners around the world and deliveries to 100,000 customers across the U.S. every month.

“I don’t think very many local people know how big we are,” said David Stelzer, founder and CEO of Azure Standard, which sprang from his family’s wheat farm nearly 40 years ago.

Stelzer’s new book, “Seeds of Hope: The Azure Standard Story,” will be released Oct. 13.

He started writing to encourage people with health issues and fellow farmers feeling stuck in their practices or commodity markets.

“You can win, but think outside the box,” Stelzer said.

He succeeded with direct marketing and value-added products.

The book also details challenges such as an IRS raid at the family farm, a devastating fire that destroyed a warehouse and a battle over weeds with Sherman County, which wanted to spray Azure’s organic acreage.

Stelzer wrote that a social media campaign, which flooded the county with phone calls and emails, forced officials to find a reasonable solution.

More room for growth

Stelzer said Azure stayed true to its roots as it scaled up from a single delivery van.

In the 1980s, he delivered his family’s wheat to Northwest health food stores and cooperatives.

Stelzer saw a need and refocused on distribution, but home deliveries quickly became too time-consuming so he established community drop locations.

Azure now has 5,000 sites throughout the U.S.

While most sales are online, the business still has a call center and paper catalog.

Stelzer said there’s more room for growth.

“The demand for high quality organic food is through the roof,” Stelzer said.

The pandemic boosted demand with Americans cooking more at home and wanting better options, said Crystal Stelzer, Stelzer’s daughter and Azure’s bakery manager.

An explosion of orders put Azure on solid financial footing and led to expansion.

The business more than tripled its employees to 550 in a few years.

That includes 70 in Dufur — where the business operates a bakery, grocery store, hardware store and gas station — and 150 distribution center employees in nearby Sherman County.

Azure is building a processing center for value-added products outside Dufur and the facility will include an individual quick freeze plant.

The business also has customer service, warehouse and delivery workers throughout the country.

A mission to create quality food

Azure Standard started, in a way, because Stelzer was constantly sick as a boy.

A naturopath convinced his parents to change their diet to natural foods.

Stelzer’s health returned and his father committed to organic farming in the 1970s.

From one generation to the next, the family’s health changed dramatically. Stelzer said his 11 children only had one doctor visit growing up, for a broken bone.

“I want to create hope that we can change the trajectory of the health of our families, because it changed for my family,” he said.

“My whole mission is to connect farmers who produce quality food with consumers,” Stelzer added.