|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
Microsoft says AI sovereignty is about maintaining national control while embracing the world's best AI technologies, rather than isolating countries from global innovation.
The post Microsoft’s AI Sovereignty Model Could Shape the Future of Government AI appeared first on Cloud Wars.
Earlier this month, OpenAI gave several of its AI models a task: complete a test designed to measure their cybersecurity capabilities. It put the systems in a sandboxed environment without an internet connection and set them off to work.
What happened next is almost laughably silly - but also, as Adam Gleave, cofounder and CEO of AI safety organization FAR.AI, put it, "a visceral example of how misaligned AI could cause harm." According to OpenAI, the models escaped the sandbox meant to contain them, moved through the company's internal systems, found a route to the internet, and then started looking for a way into Hugging Face. And why was …
The jump from mid-level to senior engineer is usually described as a matter of stronger technical skills.
Michelle Brenner (Senior Software Engineer) sees it differently.
Ahead of her talk at Infobip Shift, (for which you get a special discount as a ShiftMag reader) she argues that the real shift comes from understanding the business, making pragmatic decisions, and knowing when to ask for help.
You’re three weeks into a new job, the sprint is already underway, and a ticket comes in that doesn’t fully match the docs. Do you ask for help and maybe seem inexperienced, or do you guess and hope you got it right?
That choice never really goes away. Senior engineers are not people who never need help, they know when to ask before uncertainty becomes a real problem.
For self-taught engineers, that threshold can feel especially high, as Michelle describes it:
As someone who was self-taught, I sometimes found that asking questions at work could be dangerous. I could reveal an ignorance that I was expected to know, from a computer science term to a tool name.
Michelle thinks AI can make it easier to ask basic questions. Since many developers already use AI tools connected to internal docs or code, they can get help without feeling judged.
For her, that matters because most AI conversations focus on code generation. She cares more about what happens before that: helping engineers learn faster and feel less afraid to ask questions.
One of the biggest mistakes mid-level engineers make as they work toward becoming senior engineers, Michelle says, has little to do with syntax or frameworks. The real issue is not understanding how the business works:
Learn how the business makes money, and how your team affects that.
For Michelle, engineers who understand how leadership makes decisions and how a company creates value are better equipped to make technical calls that matter. So what can you do to fix that?
You should start paying more attention to business meetings and start seeing code as one part of a larger system, not the whole job.
In smaller teams, or in companies without a deep bench of specialists, that is often part of the job. Sometimes you have to take on the roles of product manager, developer, and SRE all at once, even when you are not the expert in every area.
That same pragmatism shapes how Michelle thinks about architecture and trade-offs.
There is no single “correct” solution, just as there is no dream job or perfect candidate.
“If it works, ship it,” Michelle says. It is an argument against getting stuck in the search for a perfect answer that does not exist. Senior engineers spend less time chasing theoretical purity and more time balancing constraints, risks, and deadlines.
Michelle also gave us a sneak peek of her upcoming talk at Infobip Shift, based on the senior engineering career guide she has spent the last few years writing. She says the jump from mid to senior is much bigger than the jump from junior to mid, and that it can be especially hard without a mentor to show how the role actually works.
Her talk will focus on the practical skills engineers often do not get enough time to learn on the job, from build-versus-buy decisions to interview preparation. She also spoke with engineers from organisations around the world to keep the advice broad. If you are coming to Shift, this is one talk worth catching.
Get your ticket for Shift conference with a special discount for ShiftMag readers!
The post Being a senior engineer doesn’t mean you never need help appeared first on ShiftMag.
The following article originally appeared on LinkedIn and is being republished here with the author’s permission.
We’re currently at the peak of the hype cycle. On June 7, Peter Steinberger posted that you shouldn’t be prompting coding agents anymore; you should be designing loops that prompt your agents. That same week, Boris Cherny of Anthropic said on stage that he doesn’t prompt Claude anymore: “I write loops; the loops do the work.” Addy Osmani published an essay called “Loop Engineering” on June 7, swyx published “Loopcraft: The Art of Stacking Loops” on June 12, and LangChain published “The Art of Loop Engineering” on June 16. Then came the AI Engineer World’s Fair, where the word dominated the main stage. Swyx’s keynote was about Loopcraft, an entire track was devoted to software factories, speaker after speaker reached for the same word, and the conference closed on July 2 with an hour-long debate about whether the hype behind loops has outrun what works in practice.
The problem is that the people talking about loops aren’t all discussing the same thing. I counted at least four distinct architectures hiding behind that one word. So this post is an attempt to map out what everyone means.
This is the loop most people picture when they say “agent”: call a tool, read the result, decide the next action, and repeat until there are no more tool calls to make. It’s what Addy calls the inner execution loop, the part agents can now run largely on their own, and it’s the innermost loop you can engineer. (swyx’s stack has a token loop, but nobody designs the token loop. It’s just part of the model.)
The execution loop iterates on steps within one task. It ends on environment feedback: the test output, the API response, and the file contents. Humans are usually absent mid-loop and appear at the boundaries, approving plans or reviewing results. The execution loop also ends whenever the agent decides it’s done, whether or not it actually is. The first fix the field found for that was to wrap this loop in another one that doesn’t take the agent’s word for it.
This was the first loop to get a name and it’s Geoffrey Huntley’s Ralph loop, which got name-checked from the AI Engineer World’s Fair main stage when Allie Howe of Keycard introduced the software factories track by citing Geoffrey’s article “Everything Is a Ralph Loop.” A Ralph loop restarts a coding agent against the same specification over and over, allocating a completely fresh context window every iteration and doing exactly one task per loop. The apparent waste is the point: Refeeding the full spec each time prevents the context rot and compaction events that quietly degrade long-running sessions.
What this loop iterates on is a single artifact. What ends the loop is spec compliance and passing tests. The human writes the spec and judges doneness, and in Geoffrey’s telling the human has one more job that I’ll return to later: watching the loop, spotting failure patterns, and fixing them so they never recur. In the closing debate on the conference’s final day, he compared the role to a locomotive engineer, someone whose whole job is keeping the train on the rails. Zoom out from a single spec though, and a much bigger loop comes into view: the one that runs an entire codebase.
This was the loudest version at the AI Engineer World’s Fair. Tereza Tizkova of Factory defined a software factory as “the whole loop, the whole lifecycle of developing software with autonomy,” and Zach Lloyd of Warp got specific about what that lifecycle is in an interview with Latent Space: triage, specification, implementation, review, verification, shipping, and monitoring. Zach’s claim is that software engineering becomes factory engineering, and that you’ll be building the thing that builds the product. Warp is dogfooding this: The company placed its own open-sourced repo under the control of Oz, its factory platform. Zach describes the adoption path as starting with low-risk repos and ratcheting the automatic PR merge rate upward from 20 percent toward 60. Anthropic appears to be running the same experiment internally. The company says 65% of its product team’s code is now created by its internal version of Claude Tag, and Mike Krieger described his team’s use of it at the World’s Fair as delegated and proactive: not “fix this bug” but take responsibility for this part of the codebase, monitor this feedback channel, and pick up tasks on your own.
The task loop and the execution loop have defined exit conditions. The product loop iterates on a codebase and its backlog, continuously, and its closing signals come from outside the codebase entirely: new issues, production logs, user feedback, review outcomes. The human role becomes configurable. In Zach’s framing, you pick the parts of the lifecycle to automate and the points where humans get brought in, and organizations differ on questions like whether code review stays human for high-risk changes. A factory improves a product. The next loop improves the factory itself.
Roland Gavrilescu of Introspection calls this autoresearch. Here’s how he framed the concept in a Latent Space interview: The inner loop is your primary system doing user-facing work, and the outer loop studies and maintains the primary system. It iterates on prompts, harnesses, model choices, and the evals themselves. His one-liner is that the loop is the product.
This pattern now has real existence proofs at both ends of the scale. The minimal case is Andrej Karpathy’s autoresearch from March 2026, roughly 630 lines of Python that ran 50 hypothesis-edit-evaluate experiments overnight on one GPU. The shipped case is Meta’s Brain2Qwerty v2, announced in late June, where the researchers report that agents iteratively modified the codebase to invent better decoding architectures, producing a substantial improvement in word error rate. Meta’s caveat is instructive: Final training configurations were still selected by hand. Even the flagship system loop keeps a human at the last checkpoint.
What ends this loop is the most demanding signal set of the four: evals, judges, filtered product feedback, and, in Roland’s design, an explicit ask-a-human tool through which the agent accumulates tacit knowledge the way a new employee does. And that’s the top of the stack. Put the four together and the shape of the whole system becomes visible.
One famous pattern from the same week is missing from this map on purpose. Cognition’s Devin Security Swarm fans parallel bounded agents out across a repository and aggregates their findings, a shape the company calls Agentic MapReduce, and it gets called a loop. I don’t think it is one. Dispatch, gather, validate is a pipeline: Nothing feeds back into a next cycle, and a loop without feedback is just a for statement. Fan-out is a topology you can deploy inside any of the four loops, not a loop of its own.
In swyx’s loop diagram, the outermost ring, the one above the loop that makes loops, is literally labeled “???? loop.” Its verbs are “set goals, allocate, cull.” Its exit condition is listed as none.
I think that loop has a name. I’m calling it the oversight loop: It’s where goals get set, budgets get allocated, and work gets culled, and it’s the one ring where a human should live. Addy said on the AIEWF stage: “That inner loop is capability. The outer loop is agency.” Agency is exactly what the oversight loop holds.
And the sharpest disagreements at AIEWF were all, once you translate them, arguments about who runs that top ring. Zach and Roland make the case for turning the dial up: pick your checkpoints deliberately, ratchet autonomy as trust accumulates, and, in Roland’s memorable distinction, build orchestras before factories, where an orchestra is a system that keeps a human conductor. The other camp says the dial has a stop. Geoffrey Litt of Notion called factories a depressing vision on X and argued, in a talk he has since published as an essay, that those who delegate understanding get replaced by the agent. Paul Bakaus put it as flatly as it can be put: “There is no auto, and there will be no auto.” His argument isn’t only about quality; it’s about ownership. People need purpose, and they want a role in what they create.
The closing debate, covered in Latent Space’s conference reporting, put both positions on one stage. Dex Horthy of HumanLayer took pains to say he isn’t anti-loop, pointing out that Kubernetes is built on control loops, but deterministic ones. His worry is that enthusiasm has gotten ahead of the engineering, and his advice was to step down an abstraction level rather than up. Geoffrey took the other side and called loops inevitable. And Mike offered the most honest data point of all: Even inside Anthropic, the team running Tag reports being bottlenecked on reviews and on the human ability to conceptualize what the system is doing. The checkpoint humans kept for themselves is now the constraint.
Autonomy is a dial that exists separately on every one of the four loops. You can run a fully autonomous execution loop inside a heavily supervised product loop. You can hand the system loop to agents while keeping goal-setting entirely human. The interesting engineering question isn’t “Which camp wins?”; it’s “What information do you need to set each dial correctly?”
The table above is my attempt to fill in those blanks. Every loop, including the top one, has a nameable exit condition, and the top one is you. But naming a signal isn’t the same as wiring it in. A loop without its signal doesn’t converge. It just runs until something external stops it. Knowing whether your loops are actually closing, at production scale, means sweeping traces and clustering failures continuously instead of spot-checking transcripts, which is exactly the job Arize AX was built to do.
Now the loops have names, that’s the question to ask. The word loop is doing a lot of work this month, because this field loves nothing more than jumping on the next hot thing. But real practice underlies all four loops, and it’s the same practice in each: people are dialing up their level of abstraction and pushing human judgment further up the stack. That’s the actual lesson of loops. We get more done by climbing up the stack, and now you have a map, you know where you should climb.
The next Model Context Protocol specification (2026-07-28) lands on July 28. Postman’s MCP Inspector already supports it, including the new stateless transport, so you can test and debug your servers before, during, and after you migrate.
There’s a lot in this release, but the headline is simple: MCP is now stateless.
Before, every connection meant a session: a handshake, a session ID, and sticky routing to keep a client pinned to one server instance. That was tricky to run in production. Now an MCP server behaves like any ordinary HTTP service. You can put a load balancer in front of it and scale it horizontally, the way you already scale everything else.
Alongside that come MCP Apps, tighter authorization, and a handful of deprecations. For the full spec breakdown, read the official release post. We won’t repeat it here.
If you maintain an MCP server, moving to the new spec is a breaking change when you upgrade. The good news: the upgrade path isn’t bad. The official SDKs are already updated, and most of the work is infrastructure. You enable stateless mode and drop the session machinery you no longer need.
The recommended approach is a transition period where your server speaks both transports at once: the legacy one for existing clients, and the new one for clients that have upgraded. That way nothing breaks while the ecosystem catches up.
Postman’s MCP Inspector is built for exactly this moment:
Existing servers don’t break, and nothing changes for anyone who isn’t upgrading yet. When you’re ready to move, Postman gives you a way to prove the new protocol and stateless mode work before you ship.
The MCP Inspector in Postman is ready today. Upgrade a server, point Postman at it, and see the new transport in action ahead of the July 28 release.
The post MCP goes stateless — and Postman’s ready appeared first on Postman Blog.
Log in
