Shifts that have not hit you yet but will.
The EU rule on marking AI output is already live for anything you shipped after 2 August
Compliance2 Dec
Article 50(2) of the EU AI Act requires providers of systems generating synthetic audio, image, video or text content to ensure "that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated". Chapter IV, which contains it, has applied since 2 August 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, added a new Article 111(4) giving a transitional period to providers of such systems "that have been placed on the market before 2 August 2026", who must comply "by 2 December 2026". The same regulation deferred the high risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. The marking duty does not apply "to the extent the AI systems perform an assistive function for standard editing or do not substantially alter the input data provided by the deployer or the semantics thereof", or where authorised by law for criminal investigation.
So what
Read the two cohorts carefully, because most coverage collapses them. If your generative feature was on the EU market before 2 August 2026, you have until 2 December. If you launched it on or after 2 August 2026, the obligation already applies and the December date is not yours. Either way the requirement is machine-readable marking, not a visible "AI generated" label, so decide this week whether you are inside the assistive editing carve-out, and if not pick a provenance scheme and book the work.
Claude Sonnet 4.5 retires on 30 November, and which platform you are on decides whether that date is yours
Deadline30 Nov
Anthropic announced on 30 September that claude-sonnet-4-5-20250929 is deprecated, "with retirement on the Claude API scheduled for November 30, 2026", recommending claude-sonnet-5-5 as the replacement. That is roughly 60 days of notice, matching Anthropic's stated policy, and requests to a model past its retirement date fail. The deprecation page adds an important scope note: "The dates on this page apply to Anthropic-operated platforms: the Claude API, Claude Platform on AWS, and Microsoft Foundry. Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model's lifecycle status and dates can differ."
So what
Search your code and prompt configs for the pinned string, including eval harnesses and cron jobs where old model ids survive longest. The AWS wording is a genuine trap: Claude Platform on AWS is Anthropic-operated and on this clock, while Amazon Bedrock is partner-operated and is not, and both run on AWS. Check which one you actually use. Then budget time for the migration rather than a string swap, because Sonnet 5.5 rejects forced tool use, the thinking disabled setting, assistant prefill and non-default sampling parameters, each with a 400.
GitHub starts failing macOS 14 Actions jobs on Monday, and the replacements are all arm64
Breaking change5 Oct
GitHub announced on 1 October that "The macOS 14 runner image will be retired on November 2, 2026", covering the labels macos-14, macos-14-large and macos-14-xlarge. Eight brownout windows precede it, during which jobs using macOS 14 "will temporarily fail", the first running from "October 5, 14:00 UTC to October 6, 00:00 UTC". GitHub also warns it "may reduce macOS 14 runner capacity, which could result in longer queue times" before retirement. The replacements it lists are all described as "macOS arm64 labels": macos-latest, which is macos-26, plus macos-15, macos-latest-xlarge and macos-15-xlarge.
So what
The first brownout is Monday afternoon UTC, so this is a today job. Search every workflow and composite action for macos-14 and its large and xlarge variants, including matrix entries. Then treat it as more than a label swap: the replacements are arm64, so any Intel-assuming step, Homebrew path or prebuilt binary in a mac job needs a real test run rather than a rename and a hope.
Supabase stops exposing new public tables to the Data API on 30 October, and RLS alone will not save you
Breaking change30 Oct
Supabase's breaking change entry says new tables in the public schema will no longer be exposed to the Data API by default, "enforced on all projects on 2026-10-30". The dashboard control is named "Automatically expose new tables and functions". The entry is explicit that row level security is not the mechanism here: "Without an explicit GRANT, a role will not have access to the created table." It advises bundling GRANT statements alongside the ENABLE ROW LEVEL SECURITY and policy statements in the same migration if you use a custom migration framework.
So what
Open each project's Data API settings and note the current state of that toggle, then audit your migration template. A migration that creates a table and only enables RLS plus a policy will produce a table your client SDK cannot read after 30 October, which looks like a mysterious empty result rather than a permissions error. Add the grant to your boilerplate now. If you create tables programmatically at runtime, that code path needs an explicit exposure step.
Stripe's new API version removes payment_method_types from Checkout, Payment Intents and Elements
Breaking change30 Sep
Stripe released API version 2026-09-30.endive on 30 September with an unusually broad set of breaking changes. Passing payment_method_types when creating a Checkout Session "now returns a 400 error", and the parameter is removed from Payment Intents and Setup Intents too, with excluded_payment_method_types and a new allowed_payment_method_types named as replacements. In Stripe.js, setting paymentMethodTypes means "Stripe.js now throws an integration error and prevents the Elements instance from being created or updated", and elements.create for the payment request button now throws, with the Express Checkout Element as the replacement. Behaviour also changed where it still works: allowed_payment_method_types "silently filters out incompatible methods" where the old parameter returned an error. Stripe publishes no end-of-life date for older API versions.
So what
Nothing breaks on a date here, because Stripe versions are pinned, which is exactly why this is easy to sleep through and expensive later. Grep for payment_method_types across server and client code and for paymentRequestButton or PaymentRequestButtonElement, then confirm your API version is pinned explicitly rather than inherited from the dashboard default. One trap when you do upgrade: snapshot_api_version can only be set when an event destination is created, so moving webhooks to a new version means standing up a parallel endpoint and making your handler idempotent while both are live.
Apple's original Developer ID authority expires on 1 February, and .pkg installers signed by it stop installing
Deadline1 Feb
Apple posted on 1 October that "The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date." The consequence is stated plainly: "Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install." The remedy is to generate a replacement from the current authority, Developer ID Certification Authority (G2), which Apple says "is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year".
So what
This hits anyone shipping a signed Mac app, installer or CLI tool outside the App Store. List your Developer ID certificates in the developer portal and work out which came from the original authority rather than G2, then reissue, update the signing identity in your CI secrets and notarisation step, and re-sign anything you still serve for download. Set two reminders: 1 February 2027, and an annual one, because the G2 certificates expire every year.