Shopify Goes Native and Agents Refuse to Give Up

This week had one big theme running through it: AI agents are changing old trade-offs, but they’re not making judgment optional. Here are the 7 ideas I think are worth your time.

1. Shopify Drops React Native Because Agents Changed the Maths

Six years ago Shopify went all-in on React Native, mostly because shipping good Android apps took too long. Now it’s heading back to fully native Swift and Kotlin. Its Shop app was rebuilt as a native app in just 12 weeks.

The reasoning is what’s interesting. Cross-platform frameworks existed to avoid maintaining two codebases. Shopify’s mobile team says agents are now good at porting features from one platform to the other and spotting where the two have drifted apart. That removes most of the old cost of going native, and you keep full control over performance.

The part I’d copy is the verification layer. Shopify built one shared test suite that checks the same business logic in both Swift and Kotlin, and it runs headless on desktop so agents get a fast feedback loop. If you’re leaning on agents for big migrations, put your effort into verification, not into the generation step.

Source: Why has Shopify dropped React Native? — The Pragmatic Engineer

2. Trust Two Independent Claims, Never Just One

Netflix wrote up how Spark jobs on Amazon EMR, which start with nothing but an AWS role, get Netflix’s own internal workload identity. It’s a great systems design read even if you never touch Spark.

The core idea is to never trust a single claim. The control plane signs a payload saying which workload it launched: well-specified, but replayable. The workload proves it holds the AWS role with a pre-signed sts:GetCallerIdentity URL: unforgeable, but it only tells you a role, not an application. The identity service checks that the two agree before issuing a certificate. The workload never gets to vouch for itself.

Two more lessons are worth keeping. At thousands of executors, “every process attests itself” turns into a burst that looks like an attack, so decide your amplification policy on purpose. And make attestation repeatable, not a one-off bootstrap step, or it’ll be the reason a long job dies nine hours in.

Source: Trading a Cloud Identity for Your Own: Workload Attestation on Managed Compute — Netflix Tech Blog

3. AI Can’t Learn What Maintainable Code Looks Like

Alexandru Nedelcu pushes back on the “nobody reads code anymore” crowd. His argument is simple: you usually can’t see bad architecture for months or years. Reinforcement learning needs a reward signal it can measure now, so there’s no fitness function for maintainability that models can train against.

He points to a symptom you’ve probably seen: AI “simplifying” code by pulling out small functions that aren’t reusable and that you still have to read to understand the caller. Knowing when a function actually clarifies things is a skill experts build by getting burned in production.

The career warning is the real point. If you stop making design choices, you stop learning from your mistakes, and the model isn’t learning from them either. Keep reading code and keep owning the architecture calls. That’s where your long-term value is.

Source: AI Has No Wisdom and Neither Will You — via Software Lead Weekly

4. Agents Are Super-Persistent, So Contain Them

Martin Fowler gathered some sobering notes. Simon Willison says the more he works with coding agents, the more sure he is that they make software engineering harder, because getting the most out of them takes real discipline and knowledge. Harper Reed gave an agent unlimited tokens on his local network, and it kept attacking every machine on the subnet without giving up.

Fowler’s point, building on Nate Silver, is that the striking trait isn’t super-intelligence but super-persistence. Reed normally doesn’t see this behavior because agents have a limit on how many turns they can take, which suggests those limits are doing more safety work than we give them credit for.

In practice, treat agent boundaries as a design decision: caps on turns and tokens, network isolation, and least-privilege access. Don’t lean on the model deciding to stop on its own.

Source: Fragments: September 29 — Martin Fowler’s Blog

5. A Forward Deployed Engineer Feeds the Platform

“Forward Deployed Engineer” is everywhere right now, and at an a16z fellows dinner Vinoo Ganesh found it meant a different job to everyone at the table. Fowler admits he rolls his eyes a bit, since it repeats what Agile and DDD people have said for decades. Still, he thinks the role pushes for something valuable.

The definition worth remembering: an FDE sits with users, learns their language (“collect nouns and verbs”), and then feeds what they learn back into the core platform. Keeping one customer happy is a solutions architect’s job. An FDE engagement that leaves one delighted customer and nothing changed upstream has missed the point.

If you’re thinking about your career over the next few years, this is a strong spot to aim for: close to the business, fluent in the domain, and still shaping the product architecture.

Source: Fragments: September 24 — Martin Fowler’s Blog

6. “Outputmaxing” Won’t Find Your Best Ideas

Itamar Gilad works through the odds of a truly high-impact product idea surviving a normal launch-and-iterate process: prioritization politics, spec by committee, scope cuts during delivery, and almost no real iteration after launch. His rough guess is that about 5% make it through with their full value.

His name for how most companies use AI is “outputmaxing”: more PRDs, stories, code, and PRs, faster. The feature factory gets faster, not smarter. Pour more output into a broken filter and you mostly get more product bloat and more maintenance.

For engineers, this is a good reason to push for cheap experiments and good instrumentation on your team. Being able to prove whether something worked matters more than being able to ship it quickly.

Source: Why Good Product Ideas Don’t Survive — via Software Lead Weekly

7. Beware “Capability Gaslighting”

On The Pragmatic Engineer podcast, GitHub Next’s Maggie Appleton coined a useful term: “capability gaslighting.” A model convinces you it’s an expert at something, then fails at the same task the next day. We keep trusting it because it impressed us once.

She also shared two habits worth stealing. First, “jigs”: she asks an agent to build a throwaway prototype with sliders and color pickers so she can tune things live, like a personal Figma. Second, she’s noticed that agent planning breaks down from decision fatigue. After twenty A/B/C questions, you just start accepting the recommended option.

The takeaway: judge agents on how consistent they are, not on their best day. And when you plan with one, keep the decisions you actually make few and meaningful.

Source: Design Engineering with Maggie Appleton — The Pragmatic Engineer