AI is moving software work from typing code toward specifying intent, reviewing results, and supervising systems.
2
Agents may become team members, peers, managers, or even the main operators of a business, but humans still need to understand the work and handle failure.
3
Patrick Debois advises people to learn how to build the systems that build the things they currently build, rather than focusing only on producing the final output.
Summary
Patrick Debois applies Conway's law to the effect of generative AI on organisations. As AI moves from copilot to contributor, team member, peer, manager, and possibly business operator, the structure of teams and companies may change with it. He describes a shift from typing code to expressing intent, writing specifications, reviewing output, and dealing with exceptions. Agents may give teams access to much more domain knowledge, shorten feedback cycles, and allow smaller or more fluid teams. Debois is careful about the limits. AI systems fail, humans still need to decide what good looks like, and someone has to clean up when automation goes wrong. He also discusses agent culture, guard rails, incentives, performance reviews, organisational digital twins, and the question of who controls whom. His practical advice is to move up a level of abstraction and learn how to build the systems that build current software and processes.
The way teams are organised shapes what they can build
Debois introduces Conway's law as the idea that an organisation's structure affects its architecture. Small, distributed teams are likely to produce modular services and architectures because their communication patterns shape the system. He turns the idea around for generative AI: organisations are already changing where AI belongs, with questions about whether it should sit in data, application, or platform teams. Earlier, he discussed using platform teams to scale AI. This talk asks the reverse question: how will AI change the way people organise themselves? The technology therefore affects both the software being built and the communication structure used to build it.
Software work is shifting from typing toward intent and review
Debois describes a move away from typing code line by line. Developers can increasingly state an intent or provide a product requirement, then have a system generate code. Work becomes more specification-centric. The human still needs to review the result and decide whether it is good or bad, but spends less time on the mechanics of typing. This changes the developer's role from creator in the narrow sense toward someone who manages the work and focuses more on why a system should exist than on exactly how every part is written. Debois connects this to the unbundling of jobs into tasks that technology can complement, add to, move elsewhere, or eventually substitute.
Automation removes tasks while leaving humans responsible for failure
Debois uses an example of automated bidding driving up a price to show why human intervention remains necessary. Systems will go wrong, and people have to understand what happened, clean up the result, and handle cases the machine cannot manage. Automation work is therefore also about preventing failure and designing for failure. He describes a paradox: more automation can reduce routine work while preserving the need to train and prepare for exceptions. Fewer people may be needed for some operations, but those who remain still need enough understanding to make decisions when the automated path breaks. The result could be little net reduction in human effort in areas dominated by failure handling.
Agents may expand team knowledge and change team size
At team level, AI moves from a personal assistant to a team member with access to the whole team's work. A human team has a limited amount of knowledge spread across its members, while an AI system may provide access to a much larger body of domain knowledge. This could reduce the need for overlapping expertise and lead to smaller teams, although Debois has seen examples where teams became both smaller and bigger, so he does not claim a fixed outcome. People still need to verify the system's answers and understand what good looks like. Roles may become more fluid, with one person moving between domains and overseeing several agent-supported projects.
Shorter feedback cycles may replace long human team cycles
Debois expects AI-supported work to compress cycles that once took one or two weeks, or sometimes three weeks, into cycles that may complete in two days. Teams may run several small feedback loops inside a larger loop. This creates a more real-time working pattern, but people cannot hold every conversation with everyone involved. Humans therefore spend more time switching between domains, making decisions, and overseeing systems rather than completing each task directly. New developers may also join teams more easily because AI can reduce the learning curve and provide more tailored help. Debois still argues that understanding remains necessary for decisions and failure handling.
Agents may become peers, managers, and organisational participants
Debois describes a progression from assistant to team member to peer. Agents could carry cultural knowledge from the models they use and imitate some patterns of human collaboration. He cites research in which multiple agents interacted in a simulated town and found that agents collaborating and talking more produced better results. The possible next step is a company made largely from agents, with agents performing roles such as software engineer, investor, or product manager. He does not trust that arrangement yet. He also asks where an agent should sit in an organisation chart, whether it could manage people, and what guard rails and human oversight would be required.
Organisations will need rules, incentives, and measures for agents
If agents occupy formal roles, organisations will need to decide how to control their behaviour and measure their output. Debois compares unwanted agent behaviour to toxic behaviour spreading between human team members. He discusses specialised and general agents, agent conduct rules, and OpenAI's model spec as an example of defining what a model is allowed to do. Agents could receive a place in an organisation chart, have performance reviews, and be assessed through individual, team, or business incentives. A digital twin of the organisation could help simulate the effect of adding an agent, including its cost and output. These ideas raise sensitive questions about who controls the agents and who watches the people or systems controlling them.
People should learn to build systems that build the work
Debois's practical advice is to stop focusing only on building the software or processes directly. People should think about how to build the systems that build those things. This move up one level puts a person in a better position to supervise the output, understand what the systems are doing, and add value through a new skill. He presents this as advice for a future that remains uncertain. The outcome depends on how capable the technology becomes and how much trust organisations place in it. The organisational effects could arrive sooner than expected, including changes to jobs, company size, outsourcing, and how people are paid.
"Don't build the software yourself, but think about how you would build the systems that build the things that you're currently building."27:10
Who should watch
You are deciding where generative AI belongs in your engineering organisation and need a way to think about team structure alongside tooling.
You lead teams that are moving from copilot use toward agents with access to shared domain knowledge, and need to plan for review, failure handling, and changing team roles.
You are worried about how your job changes when AI takes over individual tasks and want practical advice on moving toward supervision and system design.
