Companion article to Async by Default: Cross-Team Communication in the AI SDLC.
An async-first engineering organization can make almost every important artifact easier to find.
Architectural decisions are documented. Design discussions are captured. Pull requests explain their rationale. AI can retrieve service context, summarize earlier conversations, and point an engineer to the relevant decision record.
That is a better knowledge system.
It is not automatically a better learning system.
Information explains what the organization knows. Apprenticeship exposes how experienced people notice risk, test assumptions, change their minds, and decide when a reasonable-looking solution is still wrong.
That distinction matters more as AI enters the software development lifecycle. In The AI-Executable Ticket, I argued that vague work instructions become dangerous when the reader is an agent instead of a teammate. In Hierarchical Context, I argued that organizations need structured context, not bigger piles of documents.
This article is about the missing human side of that same system.
If AI makes knowledge easier to retrieve, engineering organizations need to become more deliberate about the thing retrieval does not automatically produce: judgment.
The Apprenticeship We Did Not Know We Had
Software engineering has always relied on apprenticeship.
We just never called it that.
A junior engineer overhears two staff engineers debating an API.
Someone walks past a whiteboard and catches half of an architecture discussion.
A senior developer mutters, “This cache makes me nervous.”
Another replies, “Me too. We tried something similar three years ago.”
None of those conversations were intended as training.
Yet they trained everyone listening.
For decades, engineering organizations accidentally created learning environments simply by putting smart people in the same place.
The famous watercooler conversations were not valuable because someone happened to discuss databases while grabbing coffee.
They were valuable because they exposed people to expert thinking.
Not expert answers.
Expert reasoning.
Educational researchers have had language for this for decades. Jean Lave and Etienne Wenger’s work on situated learning and legitimate peripheral participation described learning as participation in a community of practice, not just the transfer of facts. Brown, Collins, and Duguid made a related argument in Situated Cognition and the Culture of Learning: knowledge is shaped by the activity and culture in which it is used.
That maps uncomfortably well to software engineering.
We do not learn architecture by memorizing architecture documents. We learn architecture by watching people reason through trade-offs, constraints, incidents, deadlines, and organizational scars.
Engineering teams had a weak, informal version of that. It was imperfect, unevenly distributed, and too dependent on proximity, but it worked more often than we admitted.
Documentation Captures Decisions. Learning Comes From Reasoning.
AI-assisted workflows can make producing and retrieving documentation easier.
Design docs are more complete.
Pull requests contain richer explanations.
Architecture decisions are easier to find.
Organizational knowledge becomes searchable instead of tribal.
This is an enormous improvement.
But documentation almost always captures conclusions.
It rarely captures uncertainty.
When an experienced engineer writes:
We chose Redis over DynamoDB for latency reasons.
the reader learns the decision.
What they do not see is the hour before that sentence existed.
“I almost chose DynamoDB.”
“I was worried about operational complexity.”
“I remembered an incident from another company.”
“I changed my mind after considering failure recovery.”
“I realized latency was not actually our bottleneck.”
That journey is where expertise develops.
The destination is easy to document.
The journey is what teaches judgment.
AI Improves Knowledge Transfer. Humans Still Teach Judgment.
Large language models can explain concepts, generate examples, compare technologies, and answer questions on demand.
They can explain distributed systems.
They can generate examples.
They can compare technologies.
They can answer questions instantly.
Those capabilities improve access to explicit knowledge. But there is another category of learning that does not arrive as a clean question and answer.
Judgment.
Why did the principal engineer immediately recognize that a deployment was risky?
Why did someone reject an architecture that looked perfectly reasonable?
Why do experienced engineers sometimes ignore what appears to be the best practice?
The answer usually is not hidden in documentation.
It is hidden inside years of accumulated mental models.
That is what apprenticeship transfers.
Not knowledge.
Judgment.
Async Preserves Conclusions. Apprenticeship Exposes Reasoning.
This leads to an important distinction.
Async communication is fantastic for execution:
- status updates,
- design reviews,
- architecture proposals,
- decision tracking,
- cross-team coordination.
As I argued in the companion article, these become significantly better when they move out of meetings and into durable artifacts.
Learning has an additional requirement: access to reasoning while it is still forming.
Reading a conclusion can explain a decision. Observing an expert compare options, notice discomfort, and revise an assumption exposes the mental process behind it.
The answer is not to bring back unnecessary meetings. It is to rethink what synchronous time is for and to preserve useful reasoning without turning every conversation into permanent corporate memory.
Thinking Out Loud
A useful practice here is Thinking Out Loud.
Instead of only documenting the final answer, deliberately capture the reasoning behind it.
Not polished presentations.
Not architecture theater.
Real thinking.
Things like:
“I considered Option A because…”
“This implementation feels elegant, but I have seen similar systems become operational nightmares.”
“I am probably overthinking this, but here is what worries me…”
“My intuition says something is off. Let us figure out why.”
Notice that none of these statements are decisions.
They are windows into how experienced engineers build intuition.
That intuition is often more valuable than the final design itself.
This is not a new educational idea dressed up in AI clothing. The cognitive apprenticeship literature explicitly emphasizes making expert thinking visible through modeling, coaching, scaffolding, articulation, reflection, and exploration. Collins, Brown, and Newman framed this as teaching the craft behind expert performance, not merely handing students the final answer.
Software engineering needs the same pattern.
The useful artifact is not only:
Here is the architecture decision.
It is also:
Here is how the architecture decision became obvious.
Learning Streams
We already record demos.
Why not record engineering thinking?
Imagine experienced engineers occasionally solving real problems while narrating their thought process.
Searching through unfamiliar code.
Exploring logs.
Changing their minds.
Taking wrong turns.
Recognizing familiar patterns.
Questioning assumptions.
Not because they are teaching a class.
Because they are simply working.
Now imagine AI helping turn that recording into searchable organizational knowledge.
Speech becomes text.
Reasoning becomes indexed.
Architectural decisions become linked.
Key moments become chapters.
Future engineers can search not just for “how was this bug fixed,” but “how did Alice figure this out?”
Instead of documentation replacing conversations, conversations become documentation.
There is a governance catch here. Not every debugging session should become permanent corporate memory. Some conversations include sensitive data, security details, performance feedback, or half-formed speculation that should not be indexed forever.
So learning streams need rules:
- record by default only in spaces explicitly designed for learning,
- redact secrets, customer data, and production-sensitive details,
- let participants mark sections as private or temporary,
- summarize the reasoning pattern, not every raw sentence,
- attach the artifact to the relevant service, incident, design doc, or ticket.
The goal is not surveillance.
The goal is reusable judgment.
Where Human Time Belongs
Async systems are strongest when the work is already understood. Human time becomes most valuable before certainty exists.
| Use async for | Protect human time for |
|---|---|
| Status and coordination | Sense-making |
| Decisions already made | Decisions still forming |
| Routine review | Ambiguous trade-offs |
| Context retrieval | Context interpretation |
| Action tracking | Mentorship and relationship building |
This does not justify bringing back every meeting. It changes the purpose of the meetings that remain.
A status meeting asks what happened. A learning workshop asks what surprised us, which assumption failed, where an AI-generated answer looked plausible but unsafe, and what an experienced engineer noticed first.
Newer engineers need access to that messy middle. They also need a role in it: decision scribe, assumption tracker, risk spotter, or the person responsible for explaining the conclusion back to the group. Participation teaches more than passive attendance.
Psychological safety is a prerequisite. Edmondson’s study on psychological safety and learning behavior in work teams connected team learning with whether people felt able to ask questions, admit mistakes, and challenge assumptions. In an AI SDLC, surfacing uncertainty before it becomes implementation is part of the control system.
The operating principle is simple: make execution asynchronous, but make judgment observable.
A Practical Protocol for AI-Native Apprenticeship
If I were implementing this in an engineering organization, I would not start with a new mentorship program deck.
I would start with a small operating protocol that fits into the work teams already do.
The goal is simple:
- expose expert reasoning,
- preserve the useful parts,
- make it searchable,
- give newer engineers repeated chances to practice judgment.
1. Reasoning notes on important pull requests
For routine changes, keep pull requests lightweight.
For consequential changes, require a short reasoning note:
- what alternatives were considered,
- what made the chosen path safer or cheaper,
- what still feels uncertain,
- what future maintainer should watch.
This turns code review into judgment review.
A few lines are enough:
## Reasoning note
- What we chose, and what we rejected:
- Why this is safe enough to ship:
- What still worries me:The most valuable line is usually the last one.
If a senior engineer writes “what still worries me,” a junior engineer gets to see how risk is recognized before it becomes an incident.
2. Decision review with juniors in the room
Do not invite junior engineers only after the decision has been sanitized.
Let them see the messy middle:
- disagreement,
- uncertainty,
- changing assumptions,
- trade-offs,
- senior engineers being wrong and recovering.
That is where the training is.
Make the role explicit. A junior engineer does not need to own the decision to learn from it.
Give them one of these jobs:
- write the decision recap,
- list the rejected options,
- identify assumptions that need validation,
- ask one “naive” question the group has to answer,
- turn the discussion into an ADR or ticket update.
This prevents passive attendance. They are not spectators. They are apprentices with a concrete task.
3. AI output critique sessions
Take one AI-generated implementation and review it as a learning artifact.
Ask:
- Where was it useful?
- Where was it merely plausible?
- What context did it miss?
- What would we change in the ticket, prompt, tests, or service documentation?
This connects mentorship directly to the agentic workflow instead of treating AI as a separate tooling topic.
Half an hour is enough: show the prompt, show what the agent produced, find the plausible-but-risky parts, then fix the ticket or the context that let them through.
End with one reusable lesson. That matters more than the specific diff. Something like “our service README does not explain tenant isolation clearly enough,” or “the test suite validates success paths but not operational failure modes.”
4. Incident stories, not just incident reports
Incident reports are necessary.
Incident stories are educational.
The report says what happened.
The story explains how people figured it out.
Both should exist.
Add a short “learning story” section to postmortems:
## Learning story
- What made us suspect something was wrong:
- What we checked that was not the cause:
- What changed our understanding:
- What a newer engineer should take from this:This is where incident review becomes apprenticeship instead of compliance theater.
5. Office hours for taste
Some engineering questions are not blocked by missing facts.
They are blocked by immature taste:
- “Does this abstraction feel too clever?”
- “Is this service boundary worth it?”
- “Would you ship this migration plan?”
- “Is this a real platform primitive or just local convenience wearing a nice jacket?”
AI can help answer those questions.
But hearing how a senior engineer answers them is still different.
Make these office hours concrete, not vague. Ask people to bring one thing: an abstraction they are unsure about, an AI-generated solution that feels too easy, a migration plan whose blast radius may not be honest.
The point is not to approve work.
The point is to calibrate taste.
What Not to Do
There are easy ways to ruin this.
Do not create a meeting called “mentorship sync” and fill it with status updates.
Do not record every conversation by default and call it knowledge management.
Do not ask senior engineers to write essays for every small pull request.
Do not treat juniors as note takers without giving them reasoning tasks.
Do not make AI critique sessions about dunking on the model. The useful question is not whether the model was smart. The useful question is what the system failed to make obvious.
Most importantly, do not confuse visibility with learning.
A searchable archive of expert decisions is useful.
A searchable archive of expert reasoning is much better.
Designing for Human Growth
The AI SDLC can reduce coordination, repetitive communication, and the effort required to retrieve existing knowledge.
The mistake would be filling every reclaimed hour with more implementation work.
Some of that capacity should be invested where people create disproportionate long-term value:
- exposing expert reasoning,
- practicing judgment on real decisions,
- turning incidents into learning stories,
- critiquing plausible but unsafe AI output,
- helping newer engineers form questions they could not yet formulate alone.
The goal of async communication was never to eliminate conversation. It was to remove conversations that did not deserve scarce human attention.
Async systems make execution scalable. AI makes explicit knowledge easier to access. Apprenticeship develops the judgment required to use both responsibly.
If every reclaimed hour goes into shipping more features, the organization may become more productive without becoming more capable. If some of that time helps people think better, the organization builds expertise that survives today’’s tools and models.
The watercooler does not need to return.
Apprenticeship does.
This time, we can build it deliberately.