Key Takeaways

  • AI adoption demands maturity frameworks that assess risk and context, and organizations must be honest about what they are actually trying to achieve with AI in their specific circumstances.
  • Collaboration patterns are changing fundamentally: Teams are shrinking, roles are blurring, and the question is no longer how to structure teams but how to make collaboration more effective in whatever form it takes.
  • The explosion of AI-generated code demands entirely new processes for quality, cognitive load management, and accountability.
  • Organizations that failed to embed agile fundamentals face catastrophic risk with AI adoption; fast feedback loops, reflective learning, observability, and shipping the right value to the right users remain as critical as ever.
  • Engineers are shifting from contributors to custodians: The defining future skill is not writing code but effectively directing, validating, and building guardrails around AI agents.
  • The industry must confront the environmental costs of AI usage, the erosion of diversity of thought from homogenized agent outputs, and the accountability gap when no individual fully owns AI-generated systems.

The Editorial Panel and the Discussion

In the annual Culture & Methods Trends Report podcast, a panel of QCon speakers and InfoQ contributors discussed AI adoption maturity and risk, the transformation of engineering team structures and roles, and the human dimensions of software development that must not be lost in 2026. The discussion was hosted by Shane Hastie (Lead Editor, Culture & Methods) and included Ben Linders, Rafiq Gemmail, Craig Smith, Vanessa Formicola, Shawna Martell, Phillip Mortimer, and Yinka Omole.

You can also listen to the entire Culture & Methods Trends Report discussion as a podcast with a supporting transcript. (Last year's discussion is available as the 2025 Trends Report podcast.)

To help navigate current and future trends at InfoQ and across our QCon and DevSummit international software development conferences, we make use of the "crossing the chasm" mental model for technology success pioneered by Geoffrey Moore in his book of the same name. We try to identify ideas that fit what Moore referred to as the early market, where "the customer base is made up of technology enthusiasts and visionaries who are looking to get ahead of either an opportunity or a looming problem".

As we have done for the 2025, 2024, 2023, 2022, 2021, 2020, 2019, 2018, and 2017 Culture and Methods trend reports, we present the topic graph for 2026:

For context, this was our topic graph for 2025:

AI Adoption Maturity and Risk

The discussion opened where every conversation about software teams now begins: AI. But the panel's framing was notably more sober than the industry's default enthusiasm. The concern raised was that AI adoption has become "everything or nothing", with organizations either jumping on the wagon wholesale or holding back entirely. What is needed instead, is the same risk-based reasoning the industry has always applied to technology decisions: What is the risk, what is the impact, what are the specific circumstances of this software, this company, and this group of people?

The panel argued for maturity frameworks for AI adoption: recognizing that a low-risk internal tool and a business-critical system warrant entirely different degrees of automation and different numbers of humans in the loop. The call was for honesty. Organizations should understand how much AI would genuinely be a catalyst for improvement in their context and how much it would not, rather than applying it everywhere in everything.

The Haves and the Have-Nots: Agility as the Foundation

A theme carried forward from the 2025 report is the widening gap between organizations that have embraced new practices and those that never built the foundations. The panel invoked Jim Highsmith's warning, quoted during the discussion: "If you failed at agile, you will fail catastrophically at AI". Many organizations still have not embedded the fundamental principles of agile development in their ways of working and they are now layering AI-generated speed on top of that missing foundation.

"It's the gap between the good and the not so good and the haves and the have-nots. Some organizations have embraced this and ran with it, but there are many organizations... they never really made the leap to agility practices in the twenty-five year span that we had in order to do that. And now they're trying to adapt to these new practices and still building it on organizations that are still tending software's being built in 1995". Craig Smith

The practices that matter have not changed: fast feedback loops, observability, confidence in what is shipped, and delivering the right value to the right users. The panel noted that many of the "new" AI-era disciplines, such as harness engineering, guardrails, and spec-driven development, are in many respects rebrandings of practices the industry has spent decades refining. Studying what came before is a good grounding for enabling teams going forward. If anything, those fundamentals are more important than they have ever been, because the risk is greater and the chunk sizes are bigger.

Cognitive Load and Hypervelocity Engineering

If the 2025 report worried about AI-generated chunk sizes, 2026 confirms the trajectory. The panel cited GitHub's expected growth from roughly one billion pull requests last year to a predicted fourteen billion in 2026, a fourteen-fold increase in the volume of change flowing through the industry's development systems, alongside the figure discussed on the podcast previously of three hundred percent more code being released producing four hundred percent more bugs.

"I'm interested in how we handle the cognitive load of ultra-fast development. We're all being pushed, perhaps many of us are being pushed to adopt hyper velocity engineering, compound engineering. We're working on multiple work streams at once. We may have multiple agents running at once. And it becomes really hard for us humans to keep up with that, manage that, manage the constant context switching... For example, the pull request process. Can you really read all the code that AI generates?" Phillip Mortimer

This is not just a process problem but a human one. Panelists described the pull of running multiple agent sessions simultaneously – not wanting to "sit on your thumbs" while an agent works – and being stretched across abstract concepts, context-switching in exactly the way humans have always been bad at. The open question raised: what is the longer-term cost to people's capability and what happens when some engineers know what to look for in agent output while others trust it uncritically? Development processes designed for human-scale output, like the pull request review, may simply not work anymore; The industry needs to build the systems that let us manage and understand what we are building at this new velocity.

Defining Value When Code Is Abundant

With code generation nearly free, the panel returned repeatedly to a question that predates AI but is now urgent at scale: are we building the right things?

"The code is really easy now, much easier than it has been before. Are we doing what we need to do to understand if we're actually solving the problems that we're setting out to solve for whoever our customers are? Are we doing the measurements we need to do to say that these experiments are working?" Shawna Martell

Organizations struggled to close this loop long before AI, shipping things and never verifying whether they solved the problem. The risk now is doing that at scale. The discussion referenced "workslop" (Harvard Business Review's word of the year for AI-generated output that makes work harder for people further down the value stream) and asked how much code slop the industry is now producing.

The economics compound the question. Token spend is significant, making FinOps as important as ever. The panel sounded a caution rarely heard in the hype cycle: today's models and capabilities are heavily subsidized by upstream providers. Organizations coupling themselves to that subsidized capability should be asking what the plan is when the economics change, and whether the return on investment is actually materializing.

The Engineer as Custodian

Perhaps the clearest articulation of the year's role shift came in the framing of engineers as custodians rather than contributors.

"It feels like … engineers are becoming a lot more custodians rather than just contributors. And we're seeing that evolution in real time... A lot more people are adopting AI usage, but fewer people are trusting the outputs, which [is] a really interesting contradiction. And I think as engineers, our role would evolve a bit more into driving that trust factor up by building more systems, building more guardrails, building more things that make it all work together and drive proper business outputs." Yinka Omole

Custodianship also extends to preserving shared understanding and enabling effective knowledge transfer. In a recent essay featured on Hacker News, Why Software Factories Fail, HumanLayer founder Dex Horthy argues that coding models "can’t maintain and improve codebase quality over time, without a decent amount of human steering". The related discussion reflects similar concerns among practitioners. In a recent InfoQ article, Building a Context Store for Evolutionary Architecture, Stella Berhe, Stephan Bragner, Vikram Maran, and Anand Jayaraman propose making that steering durable by maintaining a versioned context store, including a machine-readable knowledge graph that engineers and AI agents can query for domain knowledge, design intent, and architectural constraints.

The adoption-trust contradiction the panel identified is borne out in the industry data: Sonar's 2026 State of Code Developer Survey found AI now accounts for forty-two percent of committed code, yet ninety-six percent of developers don't fully trust it and only forty-eight percent always verify it before committing. The panel observed engineers moving toward platform work, developing the golden paths and golden bricks, the platforms on which agents write code, making review more effective. Furthermore, engineers are enabling colleagues outside engineering to contribute. Members of product and design teams are now committing code (everyone is a builder now) as freely as engineers, with engineers providing the underlying primitives, architectural designs, and APIs that make it a safe approach.

The Evolution of Teams From Two-Pizza to One-Pizza

The most animated stretch of the discussion concerned what is happening to teams themselves.

"We used to talk about t-shaped skills, cross-functional teams, [and] the two-pizza team. What I'm seeing is that two-pizza teams [are] becoming a one-pizza team: two people and an AI tool or a swarm of agents". Shane Hastie

The panel's analysis was that team design now depends on how the system is expected to evolve: Business-critical software may retain something recognizable as a team, superpowered by agents, while lower-risk products may genuinely be a product manager and one developer. Agents as team members within a group of humans and teams of agents are both plausible configurations depending on risk. The provocative reframing offered was that "teams" may no longer be the unit of analysis. The real question becomes not how to structure teams, but how to make collaboration effective in whatever form it takes, whether that is one person working with an agent or a whole organization.

Roles are blurring in every direction. The panel described the engineer-manager pendulum swinging back as managers return to writing code, front-end/back-end/platform distinctions dissolve, and individuals become leads very quickly because leading a swarm of agents is lead-like work. One panelist went as far as declaring that the old categories, engineering manager, principal engineer, backend, and frontend, are "definitely dead now", with maturity redefined as breadth of skills and proficiency across that breadth.

Smaller teams are also creating larger expectations. A one-pizza team may be expected to deliver the output of a much larger group while retaining the full burden of coordination, verification, support, and accountability. AI accelerates production, but it does not remove the human work surrounding it. Instead, it shifts effort towards orchestration, review, and decision-making. As Justin Reock, Deputy CTO at DX, argued in his QCon AI New York talk, Leadership in AI-Assisted Engineering, developer experience is fundamentally a systems problem. Organizations need to design environments that reduce friction, toil, cognitive fatigue, and burnout rather than simply raising expectations as individual output increases.

But the panel was equally clear-eyed about what one-person teams put at risk. Part of the joy of work is working with people. It is hard to imagine feeling that way about an agent. There were descriptions of organizations where the small teams have dissolved into large groups of individuals, each quietly working with an agent, turning up to standups to talk past each other and about AI being used to summarize the forty-seven-page documents that AI generated, which explain that "AI is helping us with the AI". The magic of teams with different viewpoints and different expertise, where ideas are bounced around and challenged, degenerates when teams become collections of one-person projects. The concern extends to diversity of thought itself: When every individual works with an agent trained on the same corpus as everyone else's agent, the personal diversity that made teams creative is quietly lost.

Psychological Safety in the AI Era

Psychological safety has appeared in these reports for years. The panel was asked directly: Haven’t we been tackling this since at least 2014?

"Collaboration patterns are changing in teams, between teams, between organizations. And one key aspect that enables this kind of collaboration is psychological safety combined with transparency. So how are people communicating with each other? Do they feel safe enough to raise any issues that are there?" Ben Linders

The panel's answer to the "haven't we solved this" challenge was that there have been many positive developments, but psychological safety took a dip with COVID as people retreated to personal security and recent global developments are challenging it again. It remains tied to AI capability. Are people capable enough to work with AI while still feeling safe enough to raise issues? It is definitely not a solved problem. Later in the discussion the wellbeing dimension sharpened this point: A Harvard study cited by the panel found AI intensifies work rather than reducing it. With surveys suggesting seventy to eighty percent of people believe their role is at risk from AI, anxiety and overwork are compounding. If people are more anxious and more overworked while the industry goes full speed ahead, the "we can, but should we?" question applies to ways of working too, not just to products.

Junior Engineers, Career Paths, and the New Meaning of Seniority

The panel pushed back firmly on the notion that AI removes the need for junior engineers, while acknowledging the path is genuinely changing. A cautionary tale was shared. A company attempted to vibe-code a rebuild of a tax system with inexperienced staff, building from zero; the attempt failed. Being able to "cast your wand and have something working" does not confer the judgment to know whether a system will scale or be maintainable in two years comes from a journey of initiation, learning, failure, and success.

A striking observation concerning learning plasticity was made. Senior engineers are pouring effort into coaching machines, such as building guardrails and harnesses and correcting agents that repeat mistakes, when juniors have exactly the plasticity that agents lack. They learn from a mistake once and generalize the lesson, considering whether a library choice is consistent with the platform rather than just obeying a rule. One emerging model discussed positions juniors as gatekeepers, validating work arriving from product and design contributors, which is itself a level above where juniors traditionally started, raising real questions about how anyone reaches that entry bar. At the same time, junior engineers have been reduced in skill mastery as a result of using AI tools.

On seniority, the panel noted that today a senior with good judgment finds AI a massive force multiplier, while for a junior it multiplies in ways they may not want. There was disagreement about the future. One view held that within a year the defining skill will be how well you corral agents and that the younger generation's plasticity will let them "run rings around" veterans. The counterview was that tool fluency was never the hard part, the hard-won skill is asking the right questions about the product and the problem. That journey of micro-realizations has no shortcut. A deliberately controversial take argued that career paths may change less than expected, because leaders were never selected for writing the best code but for vision, judgment, and fostering others. These are qualities that AI does not change.

"What we need to understand is the new metric of how much can I be accountable for? Not [how] much I can ship, but how much can I be accountable [for] using all the tools that I have at my disposal. Those to me are the new criteria of responsibility of skillsets of engineers in a broader term." Vanessa Formicola

Creativity and Core Domain Skills

Can AI find creative solutions to problems? The panel's experience is that it often cannot. It writes syntactically correct, even excellent code, but creative problem-solving remains human. The optimistic historical analogy offered photography, which removed the labour of drawing every line by hand and unleashed impressionism and abstract art, as well as parametric design, which freed architects from specifying every bolt and produced an explosion of architectural creativity. By that analogy, when anyone can build, creativity becomes more important and more abundant, not less. A complementary view held that constraints improve creativity. When agents remove the endless language-and-library debates, attention is freed for the actual problem.

The counterweight was a defence of core domain skills. Just because anyone can open an agent and write code does not mean they should build the bank's transaction processing. Critical thinking has been embedded in professional bodies of knowledge, including software engineering, project management, business analysis, and testing, for decades. Losing the art of business analysis, architecture, and software engineering would mean losing the humans in the loop who can say "yes, we can do that, but here's why we need to rein it in". Domain knowledge is also crucial. Understanding your customers and your business is needed in order to ask AI the right questions and to validate its output. Talking to your customers is the easiest way to know what they need..

Ethics and the Accountability Gap

Asked directly what ethical engineering looks like in 2026, the panel centered on accountability. The core concern is that the moment we lose full control of what we are building, we no longer know how to be accountable for our actions. The industry used to have tight contact with its code and still missed things. Now "the more we can build, the less we can understand". The panel's position was that professionals must either feel accountable for the code they deliver whether or not it was written by AI or be so confident in the harnesses around the system that they are accountable for those code deliveries as well. The assertion that "It was AI, how could I know? It was one billion lines of code" must not become an acceptable answer. Building the controls that make genuine accountability possible is part of the custodian's job.

The Environmental Impact of AI

The discussion confronted the environmental cost of the AI build-out directly: the electricity, the water, and the uncomfortable fact that the industry is accelerating consumption during a critical window for carbon reduction targets. The panel referred to Jutta Eckstein's earlier call on this podcast to treat the environmental footprint of services as a measured metric and observed that tokens now put a proxy for that impact right in front of every engineer, though most people only notice it when they hit a quota.

"Now we're burning tokens. We have a metric right in front of us that's a proxy for the impact of the work we're doing... There's a project I mentioned earlier that I saw called Neuralwatt and I really love their model... their pricing model is based on power consumption... essentially we're exposing your environmental impact to you and I really love that." Rafiq Gemmail

Neuralwatt prices open-source model inference by power consumption rather than token count which is a small signal that the industry may begin making the energy cost of AI legible in the pricing itself. The panel also noted the habit of reaching for premium models when a task doesn't warrant them (the big hammer for every nail) and called for intentionality. Against the costs, the potential upside was also acknowledged. AI applied to fusion, healthcare, and other civilization-scale problems could be targeted deliberately. The panel held both truths: This is a genuinely consequential technology and using it mindfully is an engineering responsibility.

Wishes for the Year Ahead

The discussion closed with each panelist's wish for the industry:

  • More mindfulness in how we wield the technology, in respect of people, the environment, and business growth
  • Keeping an eye out for each other and checking whether colleagues are still on board
  • A greater focus on quality and testing, building quickly is easy, building something robust and valuable is the point
  • Compassion and humanism through a transformation being compared to the industrial revolution
  • Not losing sight of what stays the same, fostering the people coming after us and building products that solve problems; shifting focus from outputs and metrics to collaboration, creativity, and the human element
  • Continuing to embrace both humanity and innovation, because the real innovations come from people collaborating

Conclusion: It's Still All About the People

The through-line of the 2026 discussion is that the technology questions are increasingly settled and the human questions are increasingly urgent. When code is abundant, the scarce work is judgment. Deciding how much AI is appropriate for this system and this risk profile, verifying and being accountable for what ships, preserving the collaboration and diversity of thought that make teams creative, growing the juniors who will be the seniors, and wielding an environmentally expensive tool with intentionality.

For teams looking to thrive in this landscape, the key lessons from the panel include:

  • Apply risk-and-context reasoning to AI adoption, reject "everything or nothing" and be honest about what you are trying to achieve.
  • Shore up the fundamentals first: fast feedback loops, observability, and value measurement. AI amplifies whatever foundation it lands on.
  • Redesign quality and review processes for AI-scale output. The pull request as we knew it does not survive a fourteen times increase in volume.
  • Measure whether shipping is actually improving customers' lives and watch token spend and ROI with FinOps discipline.
  • Grow engineers as custodians of guardrail-building, validation, and enabling safe contribution from across the organization.
  • Protect collaboration deliberately as teams shrink. One-person teams trade away the diverse viewpoints and the joy that make the work sustainable.
  • Keep investing in junior engineers. Their learning plasticity is precisely what agents lack.
  • Own what you ship. Accountability for AI-generated systems is an engineering discipline, not an excuse ("it was AI") waiting to happen.
  • Treat the environmental cost of AI as a first-class engineering metric and choose models intentionally rather than defaulting to the big hammer.

The host closed the conversation with a Māori proverb:

"He aha te mea nui o te ao? He tāngata, he tāngata, he tāngata."

"What is the most important thing in the world? It is the people, it is the people, it is the people"