Systems | Development | Analytics | API | Testing

Some approaches to API governance interrupt developers mid-flow, forcing them to context-switch into a separate tool and manually verify their API definition before they can ship. That approach has never really worked. Not because developers don’t care about quality, they do, but because the best time to fix an API is the moment you’re already thinking about it. That’s what has always guided how Swagger grows. Not “come to us.” But “we’ll be there.”

GitHub Copilot, Claude, and Cursor have become genuine superpowers for API development. They draft OpenAPI definitions, generate endpoints, propose schema changes, and write test cases — all from inside the IDE, in real time. Teams using these tools are generating API definitions faster than most thought possible even a few years ago. That velocity is real, and it’s reshaping how engineering teams think about their toolchain.

Autonomous testing is one of the most talked about developments in software quality right now. It shows up in analyst reports, vendor pitches, conference talks, and job descriptions – often in the same breath as automated testing. Most of those conversations treat the two as interchangeable, or worse, position autonomous testing as simply a smarter, more advanced version of what teams already do.

An automation suite that’s losing ground rarely makes it obvious. Coverage numbers look reasonable. Tests are running. The CI pipeline is green more often than not. Meanwhile, the team is quietly working around what isn’t working – rerunning tests until they pass, deferring maintenance, or accepting a regression window that’s wider than it should be. Those workarounds can feel normal. They aren’t.

Automated test suites tend to follow the same arc. The suite works well until the application changes and a block of tests fails. Someone fixes them. The application changes again. At some point, the work of keeping tests current starts consuming the time that should go toward coverage decisions, risk assessment, and the testing work that requires human judgment.

Not every test automation problem looks the same. A team maintaining complex desktop applications in a controlled financial services environment has different automation needs than a team shipping web and mobile updates every two weeks. The application, the environment, and the people creating tests all shape what “good automation” has to do.

For teams building APIs as products, the developer portal is the front door to your business. It’s where partners discover your endpoints, where customers authenticate and start integrating, and where the quality of the experience directly shapes adoption. Now that changes.

AI is accelerating how teams build and ship software, but validating quality is getting harder, not easier. More AI-generated code means more to test, more API drift to catch, and more documentation that falls behind. The work is growing faster than teams can keep up.

There is a specific kind of confidence that comes with deploying software. Not just “the tests passed” confidence, but the kind that comes from knowing the services your application depends on still behave the way you expect them to. Preserving that integrity becomes harder as systems grow, teams move faster, and AI agents become active participants in delivery workflows.

For everyone in QA inside the Atlassian ecosystem, the last few months have made one shift obvious. AI is changing how software gets built, and the quality function must change with it.