When one engineer with an AI model can plan a change across the whole stack, Conway’s law loses its grip, and the system boundaries that coordination used to enforce have to be drawn on purpose by the tech lead. A recent article by Jack Franklin argues that AI has turned tech leads into something closer to architects. This piece follows one consequence of that shift: what happens to a system’s structure when the conversations that shaped it stop.
Franklin argues that the tech lead’s coordination work has moved downstream
Franklin writes as a tech lead. He describes how the job used to involve a lot of up front coordination, such as pulling in the team’s database expert, a security consultant, and a backend engineer before a design decision. Now, he says, a single engineer with a frontier model, the codebase, version control history, and the relevant documentation can produce a credible cross-stack plan with little input. The plan should still become a design document shared with stakeholders, but the need to coordinate ahead of time shrinks.
In his account the judgment moves to new places. The tech lead sets the shape of the system, keeps the team coherent, builds guardrails such as agent skills and command line tools, and treats review of AI-guided proposals as the main point of involvement. He warns that easy code invites quick additions, noting that “the lack of friction means the consequences can be skipped,” and that a team that trades its architectural bar for speed will pay for it in subtle bugs and 4am pages.
Conway’s law shows that coordination was doing architectural work
In April 1968, Melvin Conway published How Do Committees Invent? in Datamation. His thesis, stated near the end of the paper, is that organizations which design systems are constrained to produce designs which are copies of their communication structures. In a later author’s note on the same page, he restates it informally: any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
Read with Franklin’s example in mind, the mechanism is concrete. When a frontend engineer had to ask the database expert about a schema change, that conversation was where the database’s boundary entered the design. The expert knew which tables other teams depended on, which migrations were risky, and which data had retention rules. The friction of asking was the cost of carrying that knowledge into the plan. The resulting system had a database boundary partly because a person stood at it.
When the conversation disappears, the boundary it enforced loses its guard
Franklin’s observation is that many of those conversations are now optional. The model can read the schema, the commit history, and the docs, and propose a change that crosses frontend, backend, and data in one pass. A model can reproduce the structure it finds in the code. What it does not carry is the reason a boundary exists, unless that reason is written down somewhere it can read. A boundary that lived only in the database expert’s head stops being enforced the day nobody needs to ask the database expert anything.
This is how I read Franklin’s point about quick additions. Each small cross-boundary change looks reasonable in isolation, and the engineer making it no longer pays the social cost of asking another team. The erosion happens at the margins, one convenient change at a time. Felt effort is also a poor signal of what a change costs. In its randomized trial of 16 experienced open-source developers working on 246 real issues, published on 10 July 2025, METR found that tasks took 19% longer with AI tools, while the developers believed afterward that AI had sped them up by 20%. METR has since said those early-2025 results are out of date: in a February 2026 update it reported that developers are likely sped up more by current tools, that its new data gives an unreliable signal because of selection effects, and that self-reported speedups can be quite unreliable. The speed numbers have moved. The gap between how a change feels and what it costs is the part that still applies to a tech lead deciding whether a quick addition is safe.
Tech leads should write load-bearing boundaries down where agents and reviewers both read them
Conway’s own prescription in the paper was that a design effort should be organized according to the need for communication. That need still exists, and it now sits at review, which is where Franklin places the tech lead. My lens on this is AI governance, where a control that exists only as a habit fails when the reason for the habit goes away. The fix is to turn the habit into something explicit.
In practice that means three things. First, a written map of which boundaries carry load and who owns each one, so that a proposal touching the payments schema routes to the person Franklin calls the right stakeholder without anyone having to remember to ask. Second, the same boundaries expressed in the material agents read, which Franklin already points toward when he talks about skills and tooling for the team’s agents, so the model sees the reason for a boundary before it proposes crossing it. Third, checks in the build that fail when code crosses a boundary it should not, so enforcement does not depend on a reviewer noticing.
Some boundaries only copied the org chart, and letting those fade is the gain
Conway’s argument cuts both ways. If a design copies its organization, some of its boundaries exist because two teams sat apart, and the problem itself never required them. The paper says as much: the first design is almost never the best possible, and organizations need flexibility so the system concept can change. When an engineer with a model can work across a seam that only reflected team layout, simplifying it may be the right outcome.
So the tech lead’s new architectural work is a sorting job. Boundaries that protect data ownership, security and compliance controls, or the lines that decide who gets paged need to be written down and enforced. Boundaries that only mirror a past reorganization can be allowed to fade, deliberately and with a record of the decision. The risk is losing both kinds by accident, because nobody had to talk to anyone.
Why This Matters for Engineering Leadership
For decades, engineering leaders could rely on team structure to keep system structure in check, whether or not they thought of it in Conway’s terms. Franklin’s article describes the moment that assumption weakens: individual engineers now move across the stack faster than the old coordination paths can follow. Leaders who want the architecture to survive that speed have to make its boundaries explicit, owned, and checked, and they have to decide which old boundaries are worth keeping. That is a design decision, and in Franklin’s framing it now belongs to the tech lead.
FAQ
What is Conway’s law?
Melvin Conway argued in Datamation in April 1968 that organizations which design systems produce designs that copy their own communication structures.
Why does AI weaken Conway’s law for tech leads?
The law works through conversations between specialists. When one engineer with a frontier model can plan across the whole stack, many of those conversations no longer happen, and the boundaries they shaped lose their enforcement.
What does Jack Franklin say the tech lead’s new job is?
He describes it as closer to a high level architect: setting the shape of the system, keeping the team coherent, defining guardrails for AI, and making review the main point of involvement.
Which system boundaries should a tech lead write down?
The ones that carry load: data ownership, security and compliance controls, and the lines that decide who gets paged. Boundaries that only copied an old team layout can be allowed to fade.
Can developers judge AI speedups by feel?
Not reliably. METR found in early 2025 that developers believed AI had sped them up by 20% while their tasks took 19% longer, and in 2026 it said self-reported speedups remain unreliable.