AWS gives coding agents a test bench; Gemini Hydrogen opens up

AWS gives coding agents a test bench

AWS says coding agents wrote its new cloud emulator from end to end. The interesting part is how engineers gave those agents something concrete to check their work against.

Our main story today is AWS Emulator, and how a working reference can change the job we give a coding agent. AWS released it on 11 November. It lets developers test supported AWS operations locally, before deploying an application to the cloud.

An emulator stands in for another system. Your application makes a request, and the emulator responds in a way that aims to match the original. Here, that original is AWS itself. That gives the engineering work a useful starting point: an existing service whose behaviour can be observed and compared.

For a coding agent, writing something that looks plausible is a fairly loose objective. Matching the response of a working service is much more specific. You can run a test against AWS, run the corresponding test against the emulator, and examine where the results differ. The difference gives the agent a concrete problem to work on.

AWS describes engineers designing that workflow around tests checked against real AWS, automated reviews and a gate controlling which changes could be merged. Those are three different jobs. The tests examine behaviour. Reviews examine proposed changes. The merge gate controls whether a change enters the shared implementation. Generating code sits inside that process.

That leaves engineers with a substantial design job. They choose which behaviour to test and how proposed changes reach the shared code. When several agents contribute to an implementation, the merge gate gives those contributions a common acceptance point. Each contribution has to fit the software being assembled around it.

For organisations considering agent-led development, I'd look closely at work with an existing behaviour to reproduce. It gives the developer a way to turn a broad request into smaller, observable questions. The useful investment is in making those questions repeatable, so the same check can assess a proposed fix and later changes that touch the same behaviour.

The emulator's coverage also makes those boundaries visible. Support varies by service. An operation that hasn't been implemented returns HTTP 501, the response for not implemented. That tells a developer why a test can't proceed, instead of leaving them to infer whether the application or its local test environment is at fault.

There are important checks that still belong in AWS. The emulator doesn't reproduce IAM policy enforcement, which controls access to AWS resources, or behaviour across accounts and Regions. Production security therefore needs testing in the environment that enforces those rules. That's a concrete division of labour: local tests can exercise supported application behaviour; cloud tests cover the permissions and deployment boundaries the emulator leaves out.

The opportunity is a shorter feedback loop. A developer or agent can make a change and test supported behaviour without waiting for a cloud deployment each time. That could change how much experimentation is practical during development. If checking a supported operation is easy to repeat, a developer can compare alternative implementations while the task is still fresh. For coding agents, it creates room to attempt a change, inspect the result and revise it within the same local environment.

Google makes decisions a separate API

Beyond AWS's testing workflow, there's a smaller developer release from Google that changes how an application makes a choice.

On 11 November, Google introduced the Gemini Decisions API and Gemini Decision 1. It scores predefined choices: yes or no, multiple choice, or questions assessed against a rubric. Developers get probabilities that their software can use directly.

That changes the shape of the interaction. A conventional generated answer might include an explanation that another piece of software then has to interpret. Here, the developer defines the available choices in advance. The model's task is bounded by those choices, and the application can decide what to do with the resulting scores.

A single request can evaluate up to a thousand questions against shared material. That material can include text, images, audio, video or PDFs. The same input is billed once within the request, at ten US cents per million input tokens, with no output-token charge.

The shared-input arrangement is particularly interesting for content assessment. Imagine an application checking several different criteria against one document. Each question addresses a separate property of the same material. Being able to send that material once avoids repeatedly paying for the identical input within that request. The thousand-question ceiling gives developers room to combine related checks.

Google reports end-to-end latency of 150 to 250 milliseconds in tests with contexts up to sixteen thousand tokens. The API accepts inputs up to 256 thousand tokens; response times for that larger workload aren't established by those smaller tests. For a decision made in the middle of an interactive task, the amount of material being assessed remains part of the design.

Model routing and tool selection are two possible uses. An application could score which tool fits a request, or whether a task needs a more capable model. Because the result includes probabilities, the software can also send an uncertain case for further assessment. The developer chooses that threshold according to the consequences of a wrong decision.

Those scores express uncertainty; accuracy on a particular set of business decisions still needs measurement against examples from that work. That's especially relevant when a plausible choice would send the rest of a workflow down the wrong path.

My read is that this could simplify parts of agent software that currently ask a large model to write an answer just to extract one decision from it. It's available through the Gemini API in AI Studio. Google Cloud support is still listed as coming soon.

Machine-checked proofs for Signal code

There's another development worth separating from everyday code generation: checking precisely what a compiled program can do.

Google DeepMind published AlphaProof Code on 10 November, along with verification artefacts for specified security properties in a compiled version of Signal's cryptographic library. The work covers one-to-one session establishment and messaging on an AArch64 executable, the machine-code target used in this study.

The workflow has a clear allocation of responsibilities. People approved the specifications, AI agents produced proofs, and Lean checked those proofs against the specifications. A specification states the property the researchers want to establish. The proof then connects that statement to the model of the program's behaviour.

That connection reaches compiled code. It's useful because the executable is the form the machine runs. A security argument about a protocol and an implementation of that protocol are different things to examine. This research connects specified properties to a particular compiled implementation, bringing the check closer to the software's execution.

Lean supplies the mechanical check. An agent can propose a proof, and the checker determines whether its steps establish the stated result. Acceptance rests on formal proof steps that Lean can check. For security researchers, that gives AI-generated work a demanding, repeatable form of assessment.

One of the most revealing experiments involved two previously fixed bugs. The researchers reintroduced them, then produced checked proofs that the altered binaries violated the security specification. That exercises the method in the other direction: the same formal framework can establish a specified property for one target and establish a violation in an altered target.

It also gives researchers something concrete to investigate. The public artefacts let them examine how the specifications, executable model and proofs fit together, including the assumptions supporting the result. That is useful material for anyone studying whether this approach can extend to other security-sensitive software.

The scope is specific. Group messaging and key generation are outside it, and the proofs depend on stated cryptographic assumptions and the machine-execution model. They apply to the studied build; other platforms and later builds need their own work. Cost and scalability beyond this case study are still open questions.

For builders, the opportunity I see is a stronger connection between AI assistance and formal verification. An agent may help with the labour of constructing a proof, while a checker assesses the result. Expert work remains concentrated in choosing and approving the security properties. A successful proof answers the question in the specification, so deciding which question to ask is a substantial part of the engineering.

Genie takes enterprise work into the background

For people buying enterprise software, a different question is becoming more pressing: what happens after you close the chat?

Databricks announced its second-generation Genie on 11 November. The company says it can run background tasks, delegate work to subagents and bring decisions back to employees through a priority inbox and email. It's an expansion towards work that continues over time and across applications.

The business context comes from Genie Ontology, alongside connections to enterprise applications. An ontology represents business concepts and their relationships. That matters when an agent carries a task between systems, because understanding the words in a request is only part of the job. It also needs the business meaning attached to those words.

Consider a hypothetical request involving a customer account. Different applications may hold different parts of the work, while the organisation's definitions determine what counts as that account and which records belong together. An agent following the task needs those relationships to remain consistent as it moves between applications. That's the kind of problem business context is intended to address.

Delegation adds another layer. A main agent can give parts of the task to subagents, while the employee receives the decisions that need attention. A priority inbox could make that manageable by giving the person a place to pick up the work again. Its usefulness depends on whether the agent brings back the right decision with enough context to resolve it.

Databricks has announced Unity Catalog permissions and Unity Gateway controls covering approvals, budgets and auditability. Those controls address separate operational needs: which information is accessible, which actions require approval, how much work can cost, and how activity can be examined afterwards.

For an organisation already using Databricks, I'd assess those boundaries alongside the business definitions. An agent carrying a task across applications is useful when it can preserve the meaning of the task and stop at the right approval point. Those are concrete things to examine in a purchasing decision.

Access depends on a Databricks account, entitlements and shared assets. Some associated features, including artefacts and the browser extension, are marked Beta. Customers therefore need to match the workflow they're considering to the features and permissions available in their own workspace. The immediate evaluation is whether Genie can carry their particular work far enough to save an employee meaningful effort.

Apache fixes an HTTP/2 execution flaw

Let's pause on something with a more immediate operational consequence for anyone responsible for a web server.

Apache released HTTP Server 2.4.71 on 11 November to fix a critical flaw in its HTTP/2 module. A concurrency problem can corrupt memory and enable an unauthenticated attacker to execute code remotely. Red Hat reports a demonstrated exploit.

Concurrency means the server is handling work that overlaps in time. Here, that overlapping work can corrupt memory. The protocol configuration determines which installations are exposed.

The affected upstream HTTP Server releases run from 2.4.55 through 2.4.70, with HTTP/2 enabled. Servers using only HTTP/1.1 are unaffected. There is also an affected range in the separately released HTTP/2 module, so operators using that distribution need its specific advisory.

The response for an affected upstream installation is the fixed 2.4.71 release. For a distribution-managed installation, it's the applicable vendor-fixed package. That difference matters when an inventory tool flags the version number it sees on a server.

Distributions can backport a security fix into their existing package. In other words, they can apply the correction while retaining an older upstream version number. A scan that looks only at that number may continue to flag a system whose vendor package has already been fixed. Package status and the vendor advisory give the more useful answer.

Red Hat's details also change the exposure assessment. Red Hat Enterprise Linux 8 and earlier are unaffected. The package implementations in RHEL 9 and 10 make exploitation harder, and Red Hat rates those cases Important rather than Critical. That gives operators a more precise basis for prioritising work across different systems.

My takeaway for organisations is to connect the patch decision to the deployed package and whether HTTP/2 is enabled. A generic list of Apache installations doesn't tell you where this flaw applies. The configuration identifies the relevant services, and the package record identifies the appropriate fix. With remote execution demonstrated, establishing those two facts gives an operations team a specific remediation task it can complete and verify.

IBM plans a modular quantum system

IBM has a longer-range hardware announcement, with a nearer-term change for people already doing quantum development.

On 11 November, it outlined the Nighthawk r3 processor design and a plan to connect two processors into a 1,040-qubit system in 2027. Each planned processor targets 520 programmable qubits and ten thousand quantum operations. Chip-to-chip connections are central to assembling the larger system.

That modular approach makes the connection between processors part of the scaling plan. For organisations considering future workloads, it provides a specific design target and delivery year to assess. The larger system remains planned hardware, and useful application performance and fault-tolerant operation aren't established by its qubit count.

The change researchers can use now is expanded integration between IBM's Quantum Platform and classical computing resources. Quantum work also involves conventional computing, so the way those resources fit together affects how a researcher runs a workflow.

I'd give that integration close attention. It can support work on the current platform while the larger hardware is being developed. For a working researcher, the ability to organise the whole computation may become useful sooner than the extra capacity on the roadmap.

Nonprofits seek a model-development freeze

There's also a legal filing to watch, with a very broad request before the court.

AP reports that nonprofits sued Anthropic, Google, Meta, OpenAI and SpaceXSI in San Francisco Superior Court on 12 November. The complaint invokes California's unfair competition law and seeks to halt new AI model development and deployment.

The court has yet to decide the requested restrictions, and the allegations remain unproven. For organisations following AI policy, the filing puts courts alongside other venues where the terms of model development are being contested.

What Changes for You

Back at your own desk, trying these tools starts with what you can access and what it costs.

AWS Emulator works with existing AWS SDK and command-line calls, without an AWS account or an additional service fee. It runs on Linux, or through Docker on macOS and Windows. Each test suite or coding agent can have a separate local environment, reducing setup and deployment waits. Resource state disappears when the emulator stops, so it suits disposable test environments. That gives builders a useful way to keep separate pieces of development work from sharing the same test state.

For document work and coding, there's also a new model to consider. Google's Gemini 4 Hydrogen began its global rollout on 12 November, across consumer, developer and enterprise products, including the Gemini app and Search. Availability is progressive. AI Studio and the Gemini API offer free and paid access for coding, document and multimodal work, and tasks using connected tools.

Paid API pricing is one US dollar fifty per million input tokens and seven US dollars fifty per million output tokens. Access through Google Antigravity requires a paid Google AI Pro or Ultra subscription, so the route you use changes the cost of entry.

Hydrogen has a context window of just over a million tokens: 1,048,576. Input, reasoning and output share that space. For document-heavy work, that means the material you supply and the model's work on it draw on the same capacity.

There are four reasoning settings. The highest uses more tokens and adds latency, giving developers another choice to make about how much work a request warrants. For someone building an interactive application, response time and usage cost sit alongside answer quality. My view is that the useful opportunity is to match the reasoning setting to the task: a workflow benefits from extra reasoning when the improvement in its results earns the additional time and cost.