Thomas Dockstader

AWS re:Invent 2025 made one thing very clear: enterprise interest in AI is no longer theoretical. The conversation has moved beyond curiosity. Teams are actively experimenting, leaders are looking for production-ready use cases, and engineering organizations are trying to figure out where AI can create real leverage across software delivery, security, platform engineering, and operations.

That part is real. But after five interviews at the event, I came away with a more important takeaway: AI is not removing the need for engineering discipline. It is increasing. Many of the challenges organizations are now running into with AI are not really AI problems at all. They are governance problems, process problems, data problems, platform problems, and measurement problems. AI is just making them harder to ignore.

‍

Pattern #1: AI Is Accelerating Output, but Also Exposing Weak Systems

A lot of the market conversation still centers on speed. Faster code generation, faster documentation, faster testing support, faster issue resolution, faster delivery. And there is truth in that. Across the interviews, there was broad agreement that AI is already creating meaningful value across the software development lifecycle, especially by helping teams move faster through repetitive work.

But speed by itself is not the breakthrough. What matters is whether the system around that speed is strong enough to absorb it.

Tim Knapp, who leads Slalom's product engineering capability in Chicago, put it bluntly: you cannot layer AI on top of broken processes and expect transformation. Many enterprises are still operating from a waterfall mindset dressed up in modern tooling, and that mismatch becomes more expensive the faster AI pushes output through the pipeline. As Tim described it, every team is feeling the AI imperative right now, but the people and the processes are still trying to figure out how to adapt to a technology side that just changed drastically.

If engineering organizations already struggle with inconsistent processes, weak standards, poor documentation, siloed ownership, or unclear governance, then AI does not solve those issues. It amplifies them. The question is no longer just, "Can AI help teams move faster?" The better question is, "Can our engineering system handle what AI is about to accelerate?"

Pattern #2: The Most Practical Value Is Removing Friction, Not Replacing Engineers

One of the more grounded themes I heard was that AI's immediate value is often less glamorous than the headlines suggest. It is not that developers disappear. It is that developers spend less time on drag.

Eric Baran, who manages Amazon's global financial services developer platform business, described this clearly. The teams he works with are finding the most impact not from AI-generated features, but from offloading all the surrounding work (test creation, pipeline configuration, infrastructure templating, deployment patterns) that was eating into developers' days. As Eric put it, many developers were only writing lines of code on actual features for an hour or two out of their day before AI entered the picture. The rest was operational weight. When AI reduces that weight, developers get meaningful time back to focus on what actually differentiates the product.

This is where some of the loudest AI narratives miss the mark. The most valuable use of AI in engineering may not be autonomous software creation. It may be freeing teams from the work that keeps real innovation from happening.

Pattern #3: More Generated Code Creates a Bigger Governance Problem

It is easy to celebrate increased output. It is harder to govern it. That tension came up again and again.

Ron Miller, editor of the Fast Forward newsletter, shared a story that captured this perfectly. He overheard two developers in a Miami coffee shop. One of them was bleary-eyed, telling his friend he had been up all night reading 10,000 lines of code. His buddy suggested using AI to review it. The response: no, I have to know my code. Ron's point was sharp. Even though AI is generating code faster, someone still has to understand what is moving into production, and that responsibility does not shrink just because the volume grows.

Eric Baran echoed this from the enterprise side. His financial services clients are seeing an explosion of code coming off AI engines, but the regulatory and governance requirements have not changed. Teams that already struggled to keep up with compliance before AI are now moving even faster into territory they cannot fully audit. As Eric described it, customers keep coming back to the table saying they need to get better at actually getting this code out, and making sure their audit and governance teams can confirm it was built to spec.

This is where many organizations will get stuck. They will assume the bottleneck is still code creation, when in reality the bottleneck is shifting toward validation, governance, and operational trust. The winners in the next phase of AI adoption will not just be the teams that can generate faster. They will be the teams that can govern faster. be the teams that can govern faster.

Speed without trust is not transformation. It is just a faster risk.

Pattern #4: Platform Engineering Is Becoming Even More Strategic

If AI increases the pace of software creation, platform engineering becomes more important, not less. Someone still has to create the paved road. To make the secure path the easy path, reduce cognitive load, standardize workflows without creating more friction, and design systems where governance is built in rather than layered on after the fact.

Hasif Calp, a technology leader with over 16 years at Cisco who holds both platform engineering and security leadership roles, used a phrase that stuck with me: frictionless security. His argument is that most security friction comes not from the controls themselves, but from how they are implemented. When organizations rely on slow approval chains and human gates that overwhelm the people in them, the result is not better security. It is a clicking exercise where nobody fully understands the implications of what they are approving. Hasif advocated instead for making it easy to do the right thing through platform engineering, so that good security and fast delivery are not in conflict.

The more power AI gives teams, the more important it becomes to have strong internal platforms, clear golden paths, embedded controls, and systems that guide good behavior by default. That is the right goal. Not security by slowdown, not security by ticket queue, but security that fits naturally into how software is built and delivered.

That model was valuable before AI. It becomes essential with AI.

Pattern #5: Context and Judgment Are Becoming Premium Skills

One of the more underrated themes from these interviews was that AI does not just raise the value of technical infrastructure. It also raises the value of human clarity.

Ron Miller made a compelling case for this. As a writer, he has watched the narrative around AI and communication skills closely, and he pushed back hard on the idea that writing becomes less important in an AI-driven world. His argument is exactly the opposite. If you are building an agent or designing a prompt that will drive real automation, the quality of how you articulate intent matters enormously. You have to understand a process deeply, and then you have to be able to communicate it in a way that models can act on. That is a writing skill, and it is becoming more important, not less.

Tim Knapp built on this from the engineering side with the concept of context engineering. His framing was vivid. Every time you make a call to an LLM or invoke an agent in your IDE, you might as well be pulling somebody brand new off the street who knows nothing about what you are trying to do. If organizations do not invest in structuring and maintaining layers of context alongside their codebases, the AI will not perform. Tim described this as an emerging discipline that teams are just beginning to take seriously, and one that could become a real differentiator.

The future is not just model-driven. It is context-driven.

Pattern #6: The Old Enterprise Habits Are Getting More Expensive

AI may be new. Enterprise dysfunction is not. Another pattern that came through clearly is that many organizations are still carrying old habits that were expensive before AI and become even more expensive after it. Slow approval chains, waterfall thinking in modern clothes, measurement that creates theater instead of clarity, security models that rely too heavily on human gates, buying tools without changing operating rhythms, and mistaking experimentation for operational adoption.

Ron Miller captured the broader landscape well. Most of the CIOs and CTOs he talks to know they have to move toward AI, but many are still stuck in experimentation mode rather than production deployment. The knowing and the doing remain far apart.

Piyush Dewan, a director of software engineering at BridgeBio Medicines, offered a concrete example of how process rigidity undermines delivery. He described how over-engineered agile methodologies (the capacity planning rituals, the strict sprint predictability expectations) often cause teams to lose sight of what they actually need to deliver and how they should innovate. In his view, the emphasis on process compliance can become its own form of waste.

Tim Knapp reinforced this point by recommending that organizations remove agile project metrics from QBRs entirely. Story points and defect counts are useful internal signals for delivery teams, but they need heavy context to mean anything, and at the QBR level, they often create more theater than clarity. What matters at that altitude is whether timelines were met, how scope was managed, and what outcomes were actually delivered.

This is part of why so many leaders are now talking about centers of excellence, shared governance, and tighter collaboration between platform, security, and engineering leadership. AI does not just require new tools. It requires a more mature operating model around those tools.

Trying a model is easy. Running the business differently is the hard part.

The Bigger Takeaway: AI Is Testing the Operating Model

This is what all five interviews really pointed out. The AI era is not just about adopting new capabilities. It is about whether the organization itself is ready to operate differently. That includes better internal platforms, clearer governance, stronger delivery controls, more usable system context, tighter alignment between engineering, security, and operations, and a more disciplined way of measuring what is actually improving.

The organizations that benefit most from AI will not just be the ones that experiment the fastest. They will be the ones that modernize the system around the experimentation. That is the difference between a promising demo and durable advantage.

Where This Goes Next

If I had to summarize what I heard at AWS re:Invent in one sentence, it would be this: AI is not bypassing engineering excellence. It is making it more necessary.

Yes, the AI tools are getting better. Yes, the use cases are becoming more tangible. Yes, teams are finding real value. But none of that removes the need for strong platforms, clear governance, trustworthy delivery systems, and disciplined operating models. If anything, it raises the bar.

The next wave of competitive advantage will not come from using AI in isolated ways. It will come from building an engineering organization that can turn AI into reliable, scalable, governed outcomes. That is a much harder challenge than generating more code. And it is the one that matters.

• AI is only as effective as the connected context it can access, and fragmented systems limit its value.
• Connected platforms unify engineering data and workflows, enabling AI to reason across the full software delivery lifecycle.
• The quality of AI outcomes will depend on how well an organization designs and connects its engineering platform.

AI is quickly becoming part of the engineering workflow. Teams are experimenting with assistants and agents that can answer questions, investigate incidents, suggest changes, and automate parts of software delivery.

But there is a problem hiding underneath all of that momentum.

Most engineering environments were not built to give AI the context it needs.

In many organizations, the service catalog lives in one place. Deployment data lives in another. Incident history sits in a separate system. Ownership metadata is incomplete or outdated. Documentation is scattered. Operational signals are trapped inside the tools that generated them.

So while many teams are excited about what AI can do, the real limitation is not the model. It is the environment around it.

AI can only reason across the context it can access. And in a fragmented engineering system, context is fragmented too.

AI does not just need data. It needs connected context.

This is where I think a lot of engineering leaders are going to have to shift their thinking.

The conversation is often framed around adopting AI tools. But the bigger question is whether your engineering platform is structured in a way that makes AI useful.

If one system knows who owns a service, another knows what was deployed, another knows what failed in production, and none of them are meaningfully connected, then AI is left working with partial information. It may still generate answers, but those answers will be limited by the gaps in the system.

That is why connected platforms matter.

The next generation of AI in engineering will not be powered by isolated tools. It will be powered by systems that connect services, teams, delivery workflows, operational signals, and standards into one usable layer of context.

This is where platform engineering becomes strategic

For years, platform engineering has been framed as a developer productivity initiative. Make it easier to create services. Standardize workflows. Reduce friction. Improve the developer experience.

All of that still matters.

But the rise of AI raises the stakes.

A connected platform is not just a better way to support developers. It is the foundation for giving AI enough context to actually understand how your engineering organization works.

That is why an Internal Developer Portal matters more now than it did even a year ago.

If it is implemented correctly, the portal is not just a front door or a dashboard. It becomes the place where standards, ownership, service metadata, and workflow context come together.

That is what makes it valuable to humans.

And it is also what makes it valuable to AI.

A portal alone is not enough

Of course, none of this works if the portal is static.

A lot of organizations have a portal that shows what services exist and maybe who owns them. But if it is not connected to CI/CD and operational systems, it becomes stale quickly.

That is the difference between a directory and a platform.

CI/CD is where code becomes running software. It is where deployments happen, tests run, policies are enforced, and changes enter production. It is also where some of the most valuable engineering signals are created. Build results, security scans, deployment history, runtime events, and change records all emerge from that flow.

If that evidence stays trapped inside the delivery tooling, the broader platform never reflects reality.

And if the platform does not reflect reality, AI does not have a trustworthy system to reason across.

The real opportunity is a living knowledge layer

When the Internal Developer Portal is connected to CI/CD and fed continuously by operational data, something more important starts to happen.

The platform stops being just a developer interface and starts becoming a living knowledge layer for the engineering organization.

Every service is connected to its owner.

Every deployment is connected to the pipeline that produced it.

Every change event is connected to downstream impact.

Every incident is connected to the affected system and the responsible team.                      

Every standard and policy is embedded into the same environment where work is actually happening.

That creates a structure AI can work with.

Instead of pulling fragments from disconnected tools, AI can reason across relationships. It can understand not just isolated facts, but how those facts connect across the engineering system.

That is what will separate shallow AI adoption from meaningful AI leverage.

The next generation of AI in engineering will depend on system design

This is why I do not think the future belongs to organizations that simply layer AI on top of fragmented tooling.

It belongs to organizations that create connected platforms first.

Because once the system is connected, AI becomes much more useful. It can surface the right operational context faster. It can help investigate incidents with better awareness of ownership and recent changes. It can support governance by tracing standards and policy state across the delivery flow. It can help teams move faster because it is reasoning inside a connected system rather than guessing across silos.

In other words, the quality of AI outcomes will increasingly depend on the quality of platform design.

That is the bigger shift.

Platform engineering is no longer just about reducing developer friction. It is about building the context layer that modern engineering organizations, and their AI systems, will depend on.

What leaders should do now

The organizations that get ahead here will not start by asking which AI tool to buy.

They will start by asking whether their engineering systems are connected enough to support AI in a meaningful way.

Can you trace a service to its owner, its pipeline, its deployment history, its policy state, and its operational health?

Does your platform reflect what is actually happening in the software delivery lifecycle?

Is your Internal Developer Portal just presenting metadata, or is it becoming the system where engineering context is connected and kept current?

Those are the questions that matter.

Because the next generation of AI in engineering will not be powered by tools alone.

It will be powered by connected platforms that turn engineering activity into usable, trustworthy context.

That is the real opportunity.

Engineering organizations are waking up to something that used to be optional: measurement.

Not vanity dashboards. Not a quarterly “engineering metrics review” that no one prepares for. Real measurement that connects delivery speed, quality, and reliability to business outcomes and decision-making.

That shift is a good sign. It means engineering leaders are taking the craft seriously.

But there are two patterns I keep seeing across the industry that turn this good intention into a slow-motion failure. Both patterns look reasonable on paper. Both patterns are expensive. And both patterns lead to the same outcome: a metrics tool becomes shelfware, trust erodes, and leaders walk away thinking, “Metrics do not work here.”

Engineering metrics do work. But only when leaders use them the right way, for the right purpose, with the right operating rhythm.

Here are the two patterns, and how to address them.

Pattern #1: “We bought the tool, gave it to leaders, and expected behavior to change”

This is the silent killer.

An engineering executive buys a measurement platform and rolls it out to directors and managers with a message like: “Now you’ll have visibility. Use this to improve.”

Then the executive who sponsored the initiative rarely uses the tool themselves.

No consistent review cadence. No decisions being made with the data. No visible examples of metrics guiding priorities. No executive-level questions that force a new standard of clarity.

What happens next is predictable.

Managers and directors conclude that engineering metrics are optional. They might log in at first. They might explore the dashboards. But soon the tool becomes “another thing” competing with real work. And because leadership is not driving the behavior, the culture defaults to the old way: opinions, anecdotes, and local optimization.

If leaders are not driving direction with data, why would managers choose to?

This is not a tooling problem. It is a leadership ownership problem.

What to do instead: make metrics executive-owned, not manager-assigned

If measurement is important, the most senior leaders must model it.

That does not mean micromanaging teams through numbers. It means creating a clear expectation that engineering metrics are part of how the organization thinks, communicates, and makes decisions.

Here is what executive ownership looks like in practice:

• The executive sponsor uses the tool publicly. In staff meetings, in reviews, in planning, in post-incident discussions.
  
• Metrics show up in decision moments. Prioritization, investment tradeoffs, risk calls, capacity conversations.
  
• Leaders ask better questions because they have data. Not “Why are you slow?” but “What is slowing you down, and what would move it?”
  
• A consistent cadence exists. Not random dashboard reviews. A repeatable operating rhythm.
  

When executives do this, managers follow. Not because they are told to, but because the organization has made measurement real.

Pattern #2: “Buying a measurement tool will fix our engineering problems”

This is the other trap, and it is even more common.

There is a false belief that if an organization has DORA metrics, improvements in throughput and quality will automatically follow. Like measurement itself is the intervention.

But measurement does not create performance. It reveals performance.

A tool can tell you:

• how long changes take to reach production
  
• how often you deploy
  
• how frequently you experience failure
  
• how quickly you recover
  

Those are powerful signals. But they do not change anything on their own.

If the system that produces those numbers stays the same, the numbers stay the same.

This is why organizations buy tools, instrument everything, and still feel stuck. They measured the pain, but never built the discipline to diagnose and treat the cause.

What to do instead: treat engineering metrics as instrumentation, not transformation

If you want metrics to lead to improvement, you need two things:

1. Clear definitions and shared understanding
   
2. A metrics practice that turns numbers into decisions and experiments
   

Without definitions, metrics turn into arguments. Everyone interprets the same number differently, then stops trusting the system.

Without a practice, metrics turn into observation. You notice, you nod, then you go back to work.

The purpose of measurement is not to create pressure. It is to create clarity. Clarity about where the system is constrained, what tradeoffs you are making, and whether your interventions actually helped.

The real goal: measure change, not teams

Here is the shift that unlocks everything:

The goal is not to measure engineers.
The goal is to measure the system.

More specifically, the goal is to prove whether a change you made actually improved outcomes.

A change could be:

• a tooling change
  
• a process change
  
• a policy change
  
• a staffing or org change
  
• a reliability investment
  
• a platform improvement
  
• a CI/CD modernization effort
  

If you cannot measure movement after you make a change, you are operating on opinions and hope.

If you can measure movement, you can run engineering like a disciplined improvement engine.

This is where DORA metrics become extremely valuable, when they are used as confirmation and learning, not as a scoreboard.

Engineering metrics should confirm reality, not replace judgment

The best leaders I have worked with do not hand leadership over to dashboards. They use metrics as confirmation of what they already sense, and as a way to test assumptions.

• “We believe code reviews are a bottleneck. Do we see it in cycle time breakdowns?”
  
• “We believe flaky tests are slowing delivery. Do we see increased rework or longer lead time?”
  
• “We believe incident recovery is too manual. Do we see MTTR improve after automation?”
  
• “We believe our deployment process is too risky. Does change failure rate drop after we change release strategy?”
  

That is the role of measurement. It turns gut feel into validated understanding, then turns interventions into provable outcomes.

A practical operating model that works

If you want measurement to drive real improvement, here is a straightforward structure that scales.

1) Define what “good” means in your context

Use DORA as a baseline, but make definitions explicit:

• What counts as a deployment?
  
• What counts as a production failure?
  
• How do you define lead time?
  
• How do you define recovery?
  

This prevents endless debates and keeps the organization aligned.

2) Establish a simple cadence

You do not need a heavy process. You need consistency.

A strong starting point:

• Weekly: team-level review of flow and reliability signals, focused on removing friction
  
• Monthly: leadership review focused on trend movement, constraints, and investments
  
• Quarterly: strategic review to decide where to focus improvement efforts next
  

3) Pair every metric with a lever

A metric without a lever becomes a complaint.

Examples:

• If lead time is high, what levers do you pull?
  
  • reduce batch size, improve trunk-based practices, improve test speed, remove manual approvals
    
• If change failure rate is high, what levers do you pull?
  
  • improve testing strategy, release safety patterns, observability, rollback mechanisms
    
• If MTTR is high, what levers do you pull?
  
  • better alerting, runbooks, ownership clarity, automated remediation, incident practices
    

4) Run experiments and measure outcomes

This is the part most organizations skip.

Pick one change. Implement it. Measure before and after. Learn. Repeat.

Improvement becomes a system, not a motivational speech.

5) Make leaders the model

This brings us back to Pattern #1.

If executives use the tool and drive decisions with it, measurement becomes real. If they do not, the tool becomes optional, and optional always loses.

Where the best organizations land

The organizations that do this well eventually stop talking about “metrics adoption.” They talk about “how we run the business.”

Measurement becomes part of how engineering communicates with leadership, how priorities get set, how teams remove friction, and how investment decisions are made.

And the biggest shift is this:They stop expecting a measurement tool to fix problems.They use measurement to prove that the problems are being fixed.

That is the point. Not dashboards, not reporting, not performance theater: Clarity, decisions, experiments, and outcomes.

In the end, measurement is not the transformation. It is the instrument panel that tells you whether your transformation is working.