Every engineering organization is under pressure to go "AI First" — fast. But the rush to show AI-driven productivity creates a dangerous incentive: measure speed and volume instead of quality and trust.
This talk draws from an ongoing transformation inside Red Hat AI, where a 500+ person engineering organization is adopting AI agents across its entire development lifecycle — while simultaneously building AI agent platforms for customers. We'll share a practical framework for adopting at three layers (organization, team, and individual), real metrics from pipelines already in production, and honest lessons about where we went too fast, where we were too cautious, and what we deliberately chose not to automate. This isn't about slowing down — it's about going fast in the right places so your AI adoption compounds into capability, not debt.
Main Takeaways
- Adopt across three layers — org, team, individual — each with its own playbook. Organization-level adoption standardizes your SDLC and turns neglected processes into real infrastructure. Team-level adoption tailors agentic context to how each team actually works. Individual-level adoption multiplies personal productivity. All three matter, and they mature at different rates.
- Measure quality, not output. When you adopt AI across your SDLC, the first instinct is to measure speed and volume. Resist it. We'll show how we pivoted our own goals when we realized the original metrics — time-to-merge, PR count — incentivized the wrong behavior. The metrics that matter are revision counts, escaped defects, and whether the humans in the loop actually trust the work.
- Guardrails are features, not friction. Our requirements pipeline flags ~30% of items for human review — that's a feature, not a failure. Our security reviewer started noisy and got precise through structured iteration. Be cautious about full AI autonomy until you've built enough validation to prove confidence and consistency — and be honest about the areas where you went too fast or too slow.
Interview:
What is the focus of your work these days?
I lead 6 engineering teams building Red Hat's AI agent platform — the infrastructure that lets enterprises run agentic workloads securely. At the same time, my broader organization of 500+ engineers is adopting AI agents across our own development lifecycle through a structured program with seven tiger teams targeting requirements, architecture, security, quality engineering, documentation, and release automation.
We're both building the product and living the transformation. That gives us a tight feedback loop between what we build for customers and what actually works for engineering teams in practice. My focus right now is on making sure this internal adoption is phased, evidence-based, and quality-centric — not just fast.
What is your session about, and why is it important for senior software developers?
This session covers how to adopt AI agents across your software development lifecycle without sacrificing the engineering quality that makes your software trustworthy. I'll share a practical framework for thinking about AI adoption at three layers: organization, team, and individual. This framework is drawn from an ongoing transformation inside a 500+ person engineering org at Red Hat.
For senior developers, this matters because AI adoption decisions are landing on your desk right now, whether you asked for them or not. You're being asked to review AI-generated code, integrate AI into your workflows, and evaluate where agents add value versus where they add risk. This talk provides a framework for making those judgments, supported by real data.
Who is your presentation for?
Engineering leaders, architects, and senior developers responsible for adopting AI-assisted development practices. Specifically:
- Leaders under executive pressure to show AI-driven productivity gains
- Architects designing guardrails and review processes for AI-generated code
- Senior engineers evaluating where AI agents add value vs. where they add risk
- Anyone navigating the tension between AI adoption speed and engineering quality
Most relevant for people in organizations of 100+ engineers, but the decomposition framework applies at any scale.
Why is it critical for software leaders to focus on this topic right now?
Because the default path is dangerous. Every engineering organization is under pressure to show AI-driven productivity, and the natural first instinct is to measure speed and volume: PRs generated, time-to-merge, lines of code, features delivered. These metrics feel productive and look great on executive dashboards, but they're the wrong scorecard. When you optimize for output instead of quality, you get AI-generated code that passes CI but fails in production, escaped defects, unmet customer needs, and maintainer fatigue from reviewing low-quality contributions.
We experienced this ourselves. Our original goals for AI-assisted contributions were speed-focused. Our engineers pushed back before it caused damage. The real measure isn't how many PRs an AI generates, it's whether maintainers trust the output and customers get value that matters to them. Leaders who don't have this conversation now will find themselves cleaning up the debt later, and customer trust erodes slowly and recovers slowly.
What are the common challenges developers and architects face in this area?
The biggest challenge is that AI adoption looks like a tooling problem but is actually a process and trust problem. You can hand every developer an AI coding assistant tomorrow. The hard part is connecting individual productivity to team standards and organizational quality gates so that the speed compounds into capability instead of debt. It's also about using AI in ways that best supplement humans, and help us in the areas where we aren't always the best.
Specifically, I see three recurring challenges. First, organizations try to adopt one-size-fits-all agentic workflows that break when they encounter how teams actually work: different repos, different tech stacks, and different tribal knowledge. Second, the metrics conversation happens too late. Teams ship the wrong scorecard and then must unwind incentives that are already embedded. Third, guardrails get treated as friction to remove rather than features to build. Our security review pipeline started with a 58% false positive rate. It took four iterations across 1,000+ real issues to get it to a 22% findings rate with zero duplicates. That's engineering discipline, not magic, and most teams underinvest in it.
What's one thing you hope attendees will implement immediately after your talk?
Map your SDLC phases and assess blast radius — one whiteboard session with your tech leads. Identify which process standards are poorly enforced and could be agent-driven. Every organization has SDLC standards that are misunderstood, inconsistently applied, or ignored. That's the unexpected opportunity: AI-driven process enforcement doesn't just speed things up, it standardizes them. But you need to know where the blast radius of an AI mistake is recoverable versus catastrophic before you start automating. That one conversation will reframe your entire adoption plan.
What makes QCon stand out as a conference for senior software professionals?
QCon consistently attracts practitioners who are building real systems at scale, not just talking about them. The signal-to-noise ratio is high, the talks are grounded in production experience, and the hallway conversations are with people solving the same hard problems you are. For a topic like AI adoption in the SDLC, that audience matters. I'm not interested in presenting to people who want hype, I want to share honest lessons with people who will actually use them.
Speaker
Catherine Weeks
Engineering Director @Red Hat AI, 20+ Years in Software
Catherine Weeks is an Engineering Director in Red Hat AI, where she leads the teams building software with the latest generative AI innovations.
With a background in software design, Catherine is a leader who excels at translating complex customer needs into practical engineering solutions. She is known for her ability to work at every level—from high-level strategy down to the hands-on work of getting it done. This approach helps her balance the fast-moving world of AI innovation with the need to build the reliable, high-quality products customers depend on, all while fostering a supportive team culture.
With over 20 years in the software industry, Catherine has a proven record of mentoring strong teams and has always been a champion for the end-user.
