How AI Is Reshaping Team Structure
A session "Impact of Leaning Into AI on Team Structure" (Day 1, Session 4) was one of the most extensively discussed. A participant described an experiment his EdTech company was preparing: replace the traditional discovery phase (months of UX research, Figma mockups, stakeholder interviews) with 2-person engineering teams that rapidly build 5–6 versions of a feature using AI, put them in front of customers, get feedback, iterate, and only then write formal specs.
The reactions in the room revealed deep tensions:
Only seniors benefit from AI (so far)
A participant cited studies showing that the only developers truly profiting from AI tools are senior developers already proficient with both their domain and the tooling. "The assumption that every developer in any tier gets faster is simply not empirically true."
Teams risk becoming two individuals
"If you have a team of two people and give them AI, it might not be a team anymore. It might be two individuals trying to do their thing and somehow interact with each other."
The Day 2 "Hiring in Age of AI" whiteboard captured this bluntly: "Engineers start to drift into lone units after the gains from AI-based pair programming."
The junior developer problem is acute
Multiple sessions flagged this as one of the most serious long-term risks. Middle management's logic: "Speed is everything, juniors are slow, we can skip them." But the pushback was strong:
"One key thing junior developers bring to the table is a fresh view. They are not tainted by bad biases. They will challenge stuff which you never thought about."
The SWE Manifesto/Union session reported that a 2–3 year hiring gap for junior and mid-level engineers already exists. The industry will pay for this in 5–10 years.
AI exposes existing dysfunction, it does not create it
Several participants argued that AI is not creating new organizational problems but making existing ones visible. The fundamental issue — trusting engineers, giving them autonomy, training them to understand the product — existed long before AI.
Why Businesses Don't Trust Engineers (And Vice Versa)
The Day 2 session on business trust produced one of the most candid conversations of the unconference.
The self-reinforcing cycle
"If you don't trust your engineers, you end up with engineers that cannot be trusted, which just gives you more reason to not trust the engineers."
The "engineering vs. business" red flag
A business-side participant: "The very first sign for me that I know I can't trust an engineer is when they talk about engineering versus business. As soon as this differentiation comes up, I know they are not in here for the company."
Engineers bear responsibility too
Multiple participants acknowledged that many engineers explicitly do not want to learn the business domain. "Most of the developers I work with don't know anything about the business and they don't want to know... 'This is not my job. Your job is to tell me what to do.'" This was identified as one of the strongest trust-destroyers.
What builds trust: Understand your users. Close the gap with product/business. Use Domain-Driven Design to create shared language. Hire engineers who care about solving problems, not just writing code.
Hiring and Training in the AI Era
The "How to Train Engineers in AI-Assisted Dev" session produced a whiteboard with clear conclusions:
- Hiring should focus on meta-skills (problem decomposition, critical reasoning, domain understanding) in addition to hard and soft skills
- AI proficiency is tool-training post hiring — it should not be a prerequisite, just as we do not require proficiency in specific IDEs
- Allow AI in interviews — "If you're looking for developers who will use AI, why would you forbid them?" Meta was cited as already testing candidates on their AI workflow
- Pair high-skill with low-skill during training to counteract the drift toward isolated, AI-dependent work
From the "Let's Put Dave to the Test" workshop, participants also shared ways to detect AI-generated code in take-home assignments: "When I see a very generic Java Spring Boot application, it's very easy to know when someone uses AI. It looks soulless." Inconsistent patterns across files are another tell.
Advice for Junior Developers
The round-table "What Advice to Give to New Coders in AI Times?" produced a three-phase learning framework: