The big picture: Speedrunners have been chipping away at Super Mario Bros. for decades, systematically lowering the time it takes to complete the classic 1985 side-scrolling platformer. A combination of frame-perfect maneuvers and strategies once thought to be impossible for humans to pull off has lowered the world record to 4:54.332 – or just .067 seconds off the theoretical fastest possible run. The end, it would seem, is imminent.

Two of the world’s best Mario speedrunners – LeKukie and Niftski – are publicly battling to be the first to achieve the perfect game. The competitors have been livestreaming their attempts and during a session on August 14, Niftski set a new world record with a time of 4:54.332. Just four frames now stand between humans and the perfect game of Super Mario Bros.

The finish line is in sight, and some in the speedrunning community aren’t quite sure how to react. On one hand, it is incredibly exciting to witness history in the making and watch elite players shine when the spotlight is the brightest. Conversely, a future in which there is no longer a new goal to strive for feels a bit hollow.

There’s always the possibility that someone could discover an entirely new strategy that could pave the way for an even faster time but considering how optimized the run is today, it could just be wishful thinking. It’s also entirely possibly that someone else could swoop in and pull off the first perfect game before either of these two do it.

I’ve been casually speedrunning the NES World Championship edition of SMB on my Switch Lite for about a year and a half. The two versions are a bit different in their ruleset, but it’s still fun to tinker with when I’ve got some time to kill. For comparison, my personal best is 5:12.61 – nowhere even close to what Niftski and LeKukie are capable of even on their worst days.

Found is a TechSpot feature where we share clever, funny or otherwise interesting stuff from around the web.

Bad news for those who get their updates through RSS feeds: Feedly, the largest standalone RSS reader worldwide, has experienced technical issues for over a week, and paying users are upset that the web app has been “unusably slow.” Some users have also reported that the company has ignored their support requests. Uh-oh.

Feedly, the heir to the market ceded by Google when it closed Google Reader in 2013, is today among the most successful RSS newsreaders globally with 15 million users, according to its website. That makes it larger than competitive products like the web-based Inoreader as well as various desktop apps like NetNewsWire, Reeder, and others.

And yet, the app is experiencing a number of ongoing issues that are affecting users and paying subscribers alike. The most critical problem is a significant slowdown on its web app, which has made browsing feeds quickly and efficiently very frustrating. Users on Reddit reported the app running “extremely” slow, making it “unusable.”

Further, users said that the company’s iOS app, including on iOS 27 beta, has not been working, and the classic version of Feedly’s mobile app (preferred by a small subset of customers) was shut down without warning weeks ago.

As most consumers now keep up with news through dedicated apps, like Apple News by browsing the web and sources like Google News, and through posts on social media, the market for RSS readers has always been relatively small. However, Feedly has been working to shift its focus to AI, offering businesses a way to track emerging threats and keep up with tailored intelligence through its app.

With the latest issues, it begs the question as of whether Feedly is still focused on its core RSS customers amid its pivot to AI, which is the product the company now advertises via its homepage.

TechCrunch reached out to Feedly for an update on these issues, given that multiple customers on Reddit said their requests for technical support had been ignored.

In response, Feedly CEO Edwin Khodabakchian reassured TechCrunch that RSS was still a focus.

“Despite the pivot to cyber threat intelligence, fixing the basic RSS functionality is still a priority because our CTI community uses the news-reading capability,” he said. “Our goal has been to maintain the Feedly News Reader as fast and streamlined as possible.”

In addition, the CEO said the company was aware of the issues with its web app, which were attributed to a bug, and said the front-end team had been testing a fix. Currently, the team believes the issue was related to using “Mark as Read” on accounts with a lot of folders, and a fix for that was released Friday. The company is still confirming whether this has resolved the problem for all users.

Khodabakchian also confirmed that the Feedly Classic app was “retired two weeks ago because it “no longer met some iOS and Android requirements,” though it had been removed from the App Store long before that. At the time, the app had only a few hundred active users, he noted. The team did not notify those existing users before its final shutdown.

In addition, Khodabakchian said he was not aware of the iOS app issues, which prevent the app from loading, but said Feedly would investigate. He also promised it would be fixed quickly, noting that the company still actively invests in its main iOS and Android app.

The first thing I learned at Defcon was that I apparently didn’t know what a badge was.

I already had one hanging around my neck: the press credential that got me through the door at the annual hacker convention in Las Vegas in early August. Yet everywhere I looked, people stood in long lines to buy more. When I asked what they were waiting for and heard “badges,” I glanced down at mine, confused.

I would soon learn that Defcon badges can be electronic puzzles, soldering projects, collectibles and signs of belonging to a culture I was experiencing for the first time. Those badges were my first indication of how much I had to learn.

Everyone else seemed to understand the schedule, the language and the unwritten rules. But me? I felt like I was back in high school and had somehow missed orientation.

Over the next few days, talking with professionals, hobbyists and other beginners made cybersecurity feel much more accessible. For the first time, I could see a path from playing around with hacking tools to actually understanding how they work.

I was a script kiddie before I knew what that meant

I wasn’t completely new to hacking. In college at UCLA, I spent more time than I probably should have in the library experimenting with Firesheep, a Firefox extension that demonstrated how exposed session cookies could be intercepted over shared Wi-Fi. Watching it work showed me how easily technology could be manipulated.

I didn’t build Firesheep or understand the code behind it. I knew how to install it and click around. In hacker terminology, that made me a script kiddie: someone who uses tools created by other people without fully understanding how they work.

Still, I loved testing technology’s limits and making it do things it wasn’t designed to do. I liked the feeling of opening a door everyone else assumed was locked. That curiosity stuck, even if my technical knowledge never caught up. 

Defcon was my chance to see whether it finally could.

Exploring Defcon

Defcon featured talks and scheduled events, but much of the convention was divided into villages dedicated to particular corners of hacking. There were villages for lock picking, artificial intelligence, aerospace, cars and even boats. Inside them, people were hacking devices, building things, competing in challenges or sitting around tables working on projects I couldn’t begin to identify.

Elsewhere, teams competed in capture the flag contests, or CTFs, where players solve cybersecurity puzzles to uncover hidden pieces of text known as flags. Some competitions were designed for experts. Others were specifically meant to help beginners learn. I wanted to try one, but never did. There was always another room to explore, another talk to catch or another unfamiliar object I needed someone to explain to me.

Mostly, I wandered.

That was how I ended up learning about Defcon badges. The official badge gets you into the convention, but villages, groups and independent creators also make their own. Many are small electronic devices with lights, screens, games or hidden puzzles. Some communicate with other badges. Others come as bare circuit boards that you have to assemble yourself. Collecting and hacking them is an entire subculture within Defcon.

Because I arrived late, many of the badges I heard people talking about had already sold out. But I managed to buy one from the Maritime Hacking Village, where hackers explore the technology used on boats and other maritime systems, as well as the Car Hacking Village.

I also sat down at a soldering station and made a small badge of my own.

I had always wanted to learn how to solder, but was intimidated by the idea of trying it alone. At Defcon, a young guy and a much older man — two people who seemed like complete opposites in almost every way — took turns guiding me through it.

They showed me how to heat each connection and apply just enough solder to hold the components in place. Once I got the hang of it, I was surprised by how naturally it came to me. When the badge lit up, I realized soldering had never been beyond me; I just needed someone to show me where to start.

A lot of it went over my head, obviously

The talks were a reminder of how much I don’t know. Speakers spoke through code and acronyms as if everyone in the room spoke the same language, which frustrated me at times. Sometimes I could follow the larger idea, but lost the technical details. Other times, I had almost no idea what was happening.

One project I could understand came from Billy Swearingen. He developed software that generates and tests visual patterns designed to confuse the AI systems used by surveillance cameras. His goal isn’t to make someone invisible, but rather to make it more difficult for a camera’s software to recognize a person or face.

A talk about cellular surveillance went the same way for me. I didn’t understand every detail about cellular networks, but I understood the problem. Police can use devices that pretend to be cellphone towers, and the people being monitored may never know. Rayhunter offered an inexpensive way to start looking for signs of that surveillance.

I quickly gave up on trying to understand every technical detail. I followed whatever interested me, bought a few devices to let me experiment in different areas of cybersecurity and filled my phone with terms to look up later. It was like a college curriculum I had given myself.

I found my village

Eventually, I wandered into Noob Village. For the first time all weekend, I knew immediately that I was in the right place.

Noob Village was built for people trying to enter cybersecurity without needing to understand everything. It offered beginner-focused talks, workshops, career advice and a place to ask basic questions without feeling stupid.

That was where I met Andrew Crotty, founder and president of the Ginger Hacker Initiative, a nonprofit that helps beginners, students, veterans and career changers find their way into cybersecurity through accessible education, mentorship and hands-on learning.

Crotty and I talked about my own attempt to move beyond using tools other people built and develop a more technical understanding of hacking. I told him that I grew up in a place where cybersecurity never felt accessible. Nobody around me talked about hacking as a skill you could learn or a career you could pursue. Even after I became interested in it, I didn’t know where to begin or who to ask for help.

After wandering through rooms organized around specialties I barely understood, I had finally found my village. Literally.

That didn’t mean I suddenly knew what I was doing. It meant I had found one place that catered to not knowing. I left with a better idea of where to begin, then walked back into the chaos to see what else Defcon had waiting for me.

Some of the best moments happened in line

One of the few things I had planned was getting a copy of The Cuckoo’s Egg signed by its author, Cliff Stoll. Jaron Bradley, director of Jamf Threat Labs, had recommended the book when I interviewed him at Black Hat as a good way for me to start learning about cybersecurity. I had never heard of Stoll, but at Defcon, his name carried a kind of celebrity.

Stoll was an astronomer working at Lawrence Berkeley National Laboratory in the 1980s when a 75-cent accounting discrepancy led him to discover a hacker inside the lab’s computer network. He spent the next year tracking the intruder, eventually uncovering an international espionage operation connected to the Soviet KGB. This story became The Cuckoo’s Egg, one of the foundational books of modern cybersecurity.

While I waited for Stoll, I started talking to the man in front of me. He had joined the military without a cybersecurity background, learned the technical skills and eventually turned them into a career in his 20s. We talked about where we came from, politics and the different paths that had brought us into the same line.

It wasn’t an interview. Neither of us was trying to impress the other or extract anything useful.

It was exactly the kind of unexpected conversation I had hoped to have when I came to Defcon alone: a chance to meet someone whose path into cybersecurity looked nothing like mine and to hear how he found his way in.

Then I met Stoll, who was every bit as strange, energetic and entertaining as his reputation suggested. He signed my book and shook my hand, wishing me luck on my journey in this strange new world.

The whole experience was another reminder of how wonderfully unpredictable Defcon could be.

Next year, I’m joining in

By the end of the weekend, I had learned to solder, solved a cryptography puzzle involving a Vigenère cipher and spent more money than expected on hacking tools. More importantly, the technical side of cybersecurity no longer felt as intimidating as it had when I arrived.

There was still plenty I didn’t try. I never attempted a CTF, even though several were designed for beginners. I had my laptop with me, but I mostly used it to take notes while watching other people hack. This year, I wanted to wander and understand what Defcon was. Next year, I want to participate.

I’ll have a better idea of which villages I want to visit, and I plan to commit to at least one beginner CTF — not because I think I’ll suddenly know what I’m doing, but because I’m no longer as afraid of not knowing.

One of my favorite things about Defcon was seeing how many parents had brought their children. They were being introduced to technology as something they could question and rebuild in their own vision. That gave me a little more courage.

I didn’t leave Defcon as a hacker, not that I was supposed to. I did leave with enough confidence to start figuring things out for myself.

At one point, I admitted to another attendee that I felt like I didn’t belong there. He told me something I kept thinking about for the rest of the weekend: “You don’t have to know what you’re doing most of the time,” he said. “You just have to want to find out.”

With more than a decade of experience, Nelson covers Apple and Google and writes about iPhone and Android features, privacy and security settings, and more.

See full bio

TikTok’s parent company signed a memorandum of understanding with The Motion Picture Association.

Startup Groq has raised $350 million as it continues to pivot from an AI chipmaker to a neocloud company that provides powerful GPUs and AI infrastructure services. 

The new capital, led by investment firm Disruptive with planned participation from Nvidia, values the company at $3.5 billion. That’s down from the $6.9 billion Groq was valued at last September, just a few months before Nvidia hired the startup’s founder and CEO, Jonathan Ross, and other top talent as part of a licensing deal. 

A spokesperson for the company told TechCrunch that despite the difference in valuation, the company doesn’t see it as a down round, but rather as establishing a new valuation for the “post-Nvidia-lincensing-deal version of Groq.” 

Groq was focused on building its own chips, dubbed LPUs (language processing units), to compete with Nvidia on inference — the type of compute needed to run AI workloads in real time. After it lost its star team, Groq shifted from being a pure AI chipmaker into a cloud and data center provider that operates Nvidia systems, making the remaining Groq company an Nvidia customer. 

In June, Groq raised a $650 million round to kick off its pivot. The company intends to scale from 54 megawatts to more than 200 megawatts by 2027.

Today, Groq operates 13 data centers across North America, Europe, the Middle East, and Asia Pacific, serving more than 6 million developers, enterprises, and AI-native companies. Groq says the fresh funds will support “those seeking usage of medium and larger sized clusters of Nvidia accelerated computing for training and inference.” 

“We are building Groq into the world’s leading AI inference cloud,” Alex Davis, Groq’s chairman and CEO of Disruptive, said in a statement. “Inference will without a doubt become the largest and most critical layer of AI infrastructure.”

While inference is in high demand as enterprises scale AI workloads, it’s an open question whether neoclouds will be a profitable enough business to provide returns on their considerable investment in the long term. CoreWeave reported strong second-quarter revenue growth and recently landed major contracts, including with Meta and Anthropic. However, investors remained concerned about the company’s high capital expenditures, heavy reliance on debt, and exposure to rapidly depreciating hardware, and its ability to turn growth into free cash flow. 

Groq’s financials are still private for now, but its pivot puts the company directly inside Nvidia’s AI infrastructure ecosystem. That’s not exactly a unique relationship among neoclouds today. Nvidia supplies the GPUs powering clouds from CoreWeave, Lambda, and Nebius, while also investing billions into some of those companies as they race to build more capacity.

TechCrunch has reached out to Groq for more information.

Presented by MongoDB

Building AI that is accurate, secure, and reliable is a major engineering feat for organizations subject to the compliance obligations that govern healthcare, financial services, and transportation. The challenge of delivering AI-driven products is compounded by the fact that technology in these industries has tended to lag behind other sectors because regulation requires organizations to move carefully — and slowly. Now, many are also confronting data infrastructure modernization projects as they try to catch up with today’s demand for AI.

Australian-founded AI Care Partner Heidi offers an example of successful modernization. Its flagship product, Heidi Scribe, now automates much of the administrative work that consumes clinicians’ days across more than 190 countries, supporting roughly 2.7 million patient interactions each week. That expansion rests on infrastructure decisions taken years before the company reached global scale, says Yu Liu, co-founder and chief technology officer at Heidi.

“In most industries, an AI feature that is wrong two percent of the time registers as an inconvenience, while in healthcare that same error rate becomes a clinical safety issue,” says Liu. “The architecture has to be built around the assumption that every output may be scrutinised, audited, and relied upon in a patient’s care.”

Why deploying production AI in healthcare is architecturally different

For Heidi, data residency is a precondition rather than a feature. A clinician in Sydney, London, Tokyo, or Denver is operating under different regulatory regimes, including the Australian Privacy Principles, GDPR, APPI, and HIPAA, and their patients’ data has to live in-region.

Heidi runs fully logically isolated production deployments across the world, so residency is enforced by architecture. Auditability also has to be built in from day one, because an organization needs to be able to answer what the model saw, what it produced, and what the clinician changed, for any session, months later, when called upon.

“The blast radius of change must be engineered down,” Liu says. “In less regulated industries you can ship fast and fix forward, but in healthcare we invest heavily in making change safe by default, with continuous integration gates on risky change classes, canary releases, and treating even database schema and index changes as code that goes through review. Our speed is a product of that safety rather than something we achieve in spite of it.”

Choosing a database to connect with AI workflows

Heidi handles a diverse set of medical data collected from multiple sources, including forms, referrals, and clinicians’ notes, all of which had to be consolidated into one consistent format and one location to connect seamlessly with AI workflows. Rigid rows and columns would have been ill-suited to that workload.

For Heidi, those requirements made a document database the natural choice.MongoDBgave the team the flexibility to accommodate rapidly changing AI data without constantly reshaping the underlying database.

“The model is maybe 20% of the system, and the data architecture is what determines whether the other 80% holds up under real clinical load,” Liu says.

An AI Scribe session isn’t a single piece of data. It’s a collection of transcripts, structured notes, templates, documents, patient context, EHR integration state, and dozens of other related artifacts that change from week to week. MongoDB lets a session’s data live together in shapes that match how clinicians actually work, and lets Heidi evolve those shapes without a migration freeze every time the product moves.

“MongoDB Atlas stood out because it combined the power of the document model, which allows seamless scale, flexibility, and high performance, with built-in AI-ready features such as MongoDB Vector Search,” Liu says. “This means that Heidi does not need another bolt-on vector database to augment its existing platform.”

With more than 130 cloud regions globally alongside on-premises and hybrid options, MongoDB Atlas is the most widely available, globally distributed database platform, and its unified query API lets developers build full-text search, real-time analytics, and event-driven experiences without complicating their architecture.

“Heidi Scribe converts large volumes of medical documents into vector embeddings via LangChain in Atlas, enabling semantic search that connects transcribed medical terms directly to corresponding external knowledge,” Liu adds. “Migrating to Atlas reduced latency on key APIs by nearly 33%.”

What a trustworthy clinical RAG system requires

“Retrieval is a data architecture problem before it is an AI problem,” Liu says. “In consumer RAG, you retrieve from the open web and hope, whereas in healthcare what you retrieve from is the compliance surface.”

Heidi Evidence retrieves from licensed clinical knowledge bases, including partners like BMJ Best Practice, NICE CKS, and MIMS, and it is jurisdiction-aware, so a U.K. clinician gets U.K. guidance and an Australian clinician gets Australian formularies, because the right answer in one country can be the wrong answer in another.

Heidi’s embeddings and vector indexes live in MongoDB Vector Search, inside the same regionally isolated deployments as the rest of its data, which means retrieval physically cannot cross a residency boundary, and they are not operating a separate vector database with its own security and compliance story. Citations are a hard contract rather than a prompt suggestion, because the model only ever sees retrieved chunks that are already bound to source records.

Regional isolation enables global compliance and scale

“Each region is a full, isolated production deployment with its own MongoDB Atlas clusters, its own compute, and its own key,” Liu says.

“That is what lets us walk into a U.S. health system, an NHS trust, or an Australian hospital group and give a clean answer on residency, because it is enforced by infrastructure rather than promised by contract,” he explains. “Running multiple isolated regions with a lean team only works because the database layer is managed and consistent. We are also multi-cloud, meaning a new region can stand up another deployment on rails we have already built.”

That architecture has been most visible in the U.S., where Beth Israel Lahey Health, one of New England’s largest health systems, rolled out Heidi’s AI scribe following a pilot finding 74% of clinicians reported reduced after-hours documentation (“pajama time”), and where non-profit system MaineGeneral Health selected Heidi as a strategic partner in its rural healthcare work.

“Entering the U.S. market meant standing up another region on rails we had already built rather than re-engineering for HIPAA after the fact,” Liu says.

Lessons learned and the roadmap ahead

“Re-partitioning a large, hot, always-on collection is a serious engineering program, whereas choosing a shard key on day one is a design meeting,” Liu says. “We are doing that work now in partnership with MongoDB, but the lesson for anyone building a data-heavy AI product is that horizontal scale for your fastest-growing data is a founding decision, just like residency.”

Heidi is now extending beyond the consult note to support the full clinical workflow, from pre-visit context to post-visit documents, referrals, and workflow automation. The company is also exploring how MongoDB, large language models, and its own tooling can power an agentic ecosystem for clinical workflows.

“In healthcare AI, reliability engineering is trust engineering,” Liu says. “A clinician’s trust is lost just as fast by downtime, latency, or a data inconsistency as by a bad note, and some of our highest-leverage work is invisible, including canary releases with automatic rollback, CI gates on database changes, and cross-region consistency checks. Clinician trust is the product, and trust is architectural.”

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

The impact of AI on software development has been both profound and ever-evolving. Last year, I wrote about AMD’s plans to use AI not just for generating new lines of code, but also for other steps in the software development lifecycle (SDLC), such as triaging problems, debugging code, and testing the software. At the time, we were hoping for a 25 percent productivity boost from AI use over the course of two or three years.

But with each new release, the capabilities of Large Language Models (LLMs) improve dramatically—accelerating software development, increasing the quality of AI-generated code, and fundamentally reshaping how software is engineered. Now, just one year later, we have surpassed our productivity target, achieving a 30 percent overall productivity boost through AI. On top of that, we are rethinking not only how we use AI within the SDLC, but the structure of the SDLC itself.

We believe that the biggest AI revolution in software engineering is still ahead. So far, we have largely been teaching AI how we perform tasks and asking it to mimic existing workflows. In many ways, this constrains AI to human patterns of thinking. The next transformation will come from collaborative swarms of AI agents capable of discovering solutions independently.

Agents of today

AMD began developing AI systems for code generation, testing automation, bug analysis, and code review in 2024. At the time, our objective was to achieve 25 percent AI-generated production code by 2027 while gradually automating larger portions of the SDLC.

Measuring productivity is inherently challenging, but from the outset we have consistently tracked one objective metric: the percentage of source code generated by AI. Importantly, we count only code that passes all reviews and testing and is ultimately included in the final product. While AI-generated code is certainly not the only contributor to productivity gains, it is one of the few metrics that can be measured objectively and consistently.

By this metric, we have crossed the 20 percent mark at the beginning of this year and are now progressing toward 50 percent across entire codebase. In some software components, more than 80 percent of the code is now generated using AI.

Agentic AI has enabled us to include AI in every step of the lifecycle: For code analysis and triage, agents are trained to analyze problem reports, identify and group similar requests, and highlight which code snippets are likely to need modification. For debugging and code generation, agents are directed to analyze a bug request and implement required code changes. For testing, the agents generate unit tests, and if those are passed, identify necessary integration and product-level tests. And finally, for the approval and release stage, agents prepare architecture summary, code change review and full test results for engineers’ review and approval and if approved, integrate the changes into the next release.

Agents of tomorrow

Today, engineers create AI agents in their own image: they teach AI what they know about the system, how they would fix an issue, and how they would implement a change. This is already a major technological advancement. Engineers can create multiple “AI versions” of themselves, allowing these agents to work in parallel, scaling their expertise far beyond the limits of individual productivity. The limitation, however, is that these AI agents are still constrained by human thinking and human-defined approaches.

AMD

We believe the next major transformation in software engineering will occur when collaborative AI agent swarms can independently identify and develop solutions, guided by humans on what to solve rather than constrained by human assumptions about how the job should be done. Instead of providing detailed instructions on how to solve a problem, engineers will define the issue, the desired outcome and the quality, performance, and system constraints allowing AI agents to determine the optimal path to a solution.

A swarm of AI agents will then work in parallel to generate, evaluate, and refine multiple solution approaches. These agents will automatically validate correctness, measure performance, test trade-offs, and compare alternative implementations against defined success criteria. Finally, AI agents will prepare ranked solution options, along with validation results and performance metrics, for engineer review and approval. The agents won’t be enhancing each step of the SDLC—they will be rewriting the SLDC themselves.

To get to this point, we need to change how agents are trained. Today, improvement occurs one engineer and one agent at a time: an engineer reviews the output, refines the prompt, and repeats the process. To scale beyond this model, agents must continuously learn from one another, reuse successful strategies, and improve collaboratively across projects and teams.

We are already moving in this direction by using multi-agent workflows extensively through agentic harnesses, such as Codex and Claude Code, while simultaneously developing our own internal multi-agent systems to support the next generation of AI-driven software engineering.

A good example is our AI-driven effort to resolve issues in our Radeon Software eXperience (RSX). RSX is a user interface component that allows users to configure and monitor graphics driver behavior. In October 2025, we began using AI agents to automatically debug and fix reported RSX issues. Out-of-the-box AI tools delivered limited results, resolving only 6% of issues.

The percentage of software issues fixed automatically by AI agents in AMD’s Radeon Software eXperience (RSX) has been growing steadily, reaching 75 percent in June 2026.

As we analyzed failures and identified ways to improve, we built a learning loop—initially a largely manual process—to understand where the agents were falling short and how to improve them. Rather than retraining the underlying models, we refined the objectives given to the agents, allowing them to iteratively explore multiple approaches, evaluate the results against defined success criteria, and converge on better solutions. At the same time, advances in models and agent runtimes further increased effectiveness. Together, these improvements significantly increased our resolution rate from 6 percent to more than 75 percent of RSX issues resolved by agentic loop.

To make agents and agent swarms truly productive, we need a continuous learning loop that feeds errors and human interventions back into future agent workflows. The opportunity is to engineer this loop around clear, measurable goals. Each cycle captures new insights, making the entire AI engineering workflow smarter and more effective. Over time, this self-reinforcing loop—not just the underlying model—will become a key driver of AI progress.

The evolving role of human engineers

At AMD, we view AI as a means of increasing productivity, improving quality, and enabling employees to focus on higher-value work. Our goal is to empower our workforce with AI, not to reduce headcount.

To support this transformation, we are investing heavily in AI education and training across the company. The way we work is evolving rapidly, and we want every AMD employee to be prepared to leverage AI confidently, responsibly, and effectively.

As AI agents continue to improve, engineers will spend less time manually implementing solutions, focusing more on defining specifications, validating outcomes, and making the strategic decisions that drive innovation.

The first Zipline drone deliveries for Uber Eats orders will start later this year.