When Developer Tools Move Faster Than Compliance Frameworks

Martin Stefanko and Jan Martiska started writing Quarkus in Action on version 2.something. They published on 3.15. That's thirteen major version jumps between first draft and final copy. This isn't just a documentation headache. It highlights a tension most policy talks miss.

When software frameworks change faster than books about them can be written, what does that mean for rules that move even slower?

The Documentation Problem Reveals the Regulation Problem

Stefanko and Martiska are both IBM engineers who've worked on Quarkus since its early days. They faced constant rewrites. Not just code samples -- those were manageable thanks to OpenRewrite, the automated upgrade tool. The harder part was updating 300 pages of explanations, screenshots, and version-specific details every time their teammates shipped changes.

"You just want your colleagues to just stop working so that you can finish it," Martiska said during a GOTO Book Club talk.

They can't stop working, of course. That's what active development means. But here's the policy angle: if technical writers on the dev team struggle to keep docs current, how can compliance officers judge whether systems meet the rules?

Think about the EU AI Act's requirements for technical docs. The Act demands detailed system descriptions, risk reviews, and data governance plans. All of these assume a fairly stable technical base. But modern frameworks like Quarkus ship changes nonstop: new security features, different build methods, updated protocols. Each change could shift the compliance picture.

Regulators expect something close to old-style versioning: big releases with clear lines between them. The reality is nonstop deployment, feature flags, and version numbers that treat breaking changes as routine.

AI Integration Makes This Worse

Stefanko noted that Quarkus is "one of the frameworks which are pushing LLM integrations in Java." The LangChain4j tie-in is so smooth that "sometimes you will even forget what is calling an LLM and what is actually calling some of your code."

For developer experience, this is great design. For compliance, it's a nightmare.

When AI calls look just like regular code, how do you audit them? The EU AI Act requires openness about when AI systems make choices. But if the framework hides the line between AI and normal code, developers must track it themselves. Many may not realize they need to.

The book covers 29 Quarkus extensions across 12 chapters. Each one is a different hookup point -- databases, messaging, security, front-end tools. Many involve third-party services with their own compliance duties. The GraphQL chapter covers API design. The messaging chapter handles both Kafka and RabbitMQ. The security chapter tackles login patterns.

Every hookup point is a potential compliance line. GDPR requires data deals with third parties. SOC 2 requires vendor risk checks. Rules like HIPAA or PCI-DSS add more limits on how data moves through systems.

Modern frameworks hide these lines on purpose to help developers work faster. That's useful. Developers shouldn't have to think about message queue setup when building a feature. But someone must think about it for compliance. And that someone often isn't the framework maker.

The Build-Time Initialization Question

One of Quarkus's key features is build-time setup. As Martiska explained: "the application gets partially initialized already during the build and when you actually start the application, it's blazing fast because most of the initialization steps have already been done before."

This moves security lines in ways current rules don't cover. Standard security audits focus on runtime -- what can an attacker do to a live app? But if much of the app's behavior is set at build time, you need to lock down the build process too.

This isn't abstract. Supply chain attacks now target build systems because they control what gets deployed. The SolarWinds breach hit build tools. The XZ Utils backdoor showed how build-time changes can sneak in flaws that code review won't catch.

Yet most compliance frameworks still treat "the application" as the security line, not the build pipeline. SOC 2 audits might check who can access production. But they often skip who can change build configs. The NIST framework talks about secure development but doesn't clearly split build-time from runtime security.

Quarkus's approach makes sense. Moving setup to build time speeds up starts and cuts dead code. But it demands new thinking about where security checks apply. The rules haven't caught up.

Dev Services and the Invisible Infrastructure

The book digs into dev services -- Quarkus's ability to auto-spin containers for databases, messaging, and other tools during development. Multiple services find and link to the same setup on their own.

"Everything magically connects together," Martiska noted.

Magic in software is just hidden convenience. Here it means developers can test complex systems without hand-building the setup. That's a big productivity win. But it also means the test setup may look nothing like production.

For testing, this creates problems. When you test against dev services, you test against container versions of production tools. These may act differently under load or when things break. Compliance audits that lean on test results need to account for this gap.

More broadly, as frameworks handle more setup on their own, app code and infrastructure code blur together. Infrastructure-as-code was meant to make this clearer by treating infra as software. Instead, app frameworks now auto-generate infra configs. They bake infra choices into defaults most developers never look at.

The Policy Implications Nobody's Discussing

Policy talks about software rules tend to focus on outcomes. Does the software discriminate? Does it protect privacy? Is it secure? Those matter. But they assume something stable enough to test.

Modern development fights that stability. Frameworks change nonstop. AI blends in at many layers. Infrastructure gets auto-built. Build-time and runtime lines shift.

This doesn't make rules impossible. But it suggests current methods may not fit how software actually gets built. A few takeaways:

First, compliance rules that assume stable system lines need a refresh. When a framework update changes security traits, does that count as a "system change" that triggers a new review? Rules like the EU Medical Device Regulation leave this unclear.

Second, it gets harder to assign blame when frameworks hide complexity. If Quarkus auto-generates Kubernetes manifests (which it does), who must make sure those manifests are secure -- the framework maker, the app developer, or the team deploying them?

Third, the speed of change suggests compliance may need ongoing checks, not one-time reviews. If Stefanko and Martiska had to update their book thirteen times between draft and print, how often should compliance reviews happen?

The authors built their sample app -- a car rental system with five microservices -- to be too complex on purpose. It shows off different protocols (REST, GraphQL, gRPC), messaging systems, and database methods. "This is CV-driven development. You do not need to use all of these things," they imagined a review board saying.

But modern apps often are that complex. Not from resume padding but from real needs to link diverse systems. Each link brings its own compliance duties. Frameworks that make linking easier don't always make compliance tracking easier.

Stefanko's goal of writing a book before turning 30 came from Heinz Kabutz's advice about regret. He made it. The book shipped, covering a framework that changed dramatically during writing and will keep changing.

The rules trying to govern such software are still figuring out how to describe what they're aiming at. The gap between how fast technology moves and how fast policy responds isn't closing. It's getting wider.