FRAMEWORK / OPEN QUESTIONS
Questions I do not have answers to yet.
The principles describe rules I already use. These are problems I can see but have not solved. Some may lead to new rules; others may change or disappear as I learn.
QUESTION 01
What happens to deep work?
Agentic work often turns a long stretch of making into a sequence of delegation, waiting, switching and review.
The tension
Parallel execution creates momentum; constant context switching can break the concentration needed to judge what comes back.
What I currently suspect
Separate periods for delegation and review may protect more focused time than supervising every run continuously.
What I still do not know
- Can that rhythm preserve the kind of immersion I value?
- Which work should I still do directly rather than delegate?
QUESTION 02
How many agents can one person supervise well?
Ten agents may execute at once, but their results still arrive as decisions, questions and verification work for one person.
The tension
More parallel work can produce more options; it can also create a backlog of results I cannot properly understand.
What I currently suspect
My three-or-four-thread rule is a useful personal starting point, not a universal limit.
What I still do not know
- What should count as a cognitively active thread?
- How would I notice that adding one more has reduced the quality of my decisions?
QUESTION 03
What is the minimum mental model an engineer needs?
Nobody holds every detail of a modern system in their head. AI can widen the gap between implementation and the owner's understanding.
The tension
Demanding complete recall wastes the benefit of abstraction; accepting a system nobody can reason about makes ownership fragile.
What I currently suspect
I need a reliable grasp of boundaries, assumptions, failure modes and evidence, with tests and documentation supporting the details.
What I still do not know
- Which details must stay in a person's head, and which can live in durable records?
- When do contracts and observability compensate for less direct implementation knowledge?
QUESTION 04
How do junior engineers become senior engineers?
Small features, tests, debugging and mistakes have long been part of learning judgment. AI can now do much of that work.
The tension
Removing repetitive tasks may free time for better learning; removing the practice may also remove the path to experience.
What I still do not know
- Which forms of hands-on work should teams preserve deliberately?
- Can guided AI work teach the judgment needed to review AI work later?
QUESTION 05
Does programming-language expertise still matter?
AI can help a team produce code in a language its people would have needed much longer to learn or migrate to.
The tension
Translation becomes cheaper; operating, debugging and extending the resulting system still require knowledge of its semantics and ecosystem.
What I currently suspect
Syntax may matter less than concepts such as ownership, concurrency, failure behaviour and system architecture.
What I still do not know
- What level of language fluency is needed to own a production system?
- Does AI-assisted migration save effort overall once maintenance is included?
QUESTION 06
Do programming languages converge?
If models can translate code and produce familiar patterns across ecosystems, both language choice and coding style may change.
The tension
Teams might favour a few languages with strong tooling and verification; easier translation might instead make language choice less consequential.
What I still do not know
- Will model-generated conventions flatten useful language-specific idioms?
- Will verification properties outweigh the needs of the humans who maintain the code?
QUESTION 07
Does source code become less important?
If implementation is easier to regenerate, specifications, tests, constraints and domain knowledge may carry more of the system's intent.
The tension
Code could become one output of a richer description; it remains the thing that runs and often contains decisions absent from the specification.
What I still do not know
- Which artifacts must be versioned and reviewed as the source of truth?
- How do we stop a generated implementation from drifting away from its stated intent?
QUESTION 08
Is review becoming the central engineering skill?
Producing a plausible implementation is getting cheaper. Establishing that it is correct, safe and appropriate still takes judgment.
The tension
More output increases the value of careful review; it can also overwhelm the reviewers and turn approval into a rubber stamp.
What I currently suspect
Architecture, verification and the ability to explain trade-offs will become more valuable in the work I do.
What I still do not know
- What evidence makes an AI-assisted review trustworthy?
- How much review can be delegated without losing accountable human judgment?
QUESTION 09
What happens to the craft of making software?
Part of the pleasure of engineering is wrestling with a problem, learning a system and finding an elegant way through it.
The tension
Delegation may make me more capable and productive while removing some of the work that made the profession satisfying.
What I still do not know
- Which parts of making do I want to keep for myself even when an agent is faster?
- Can a different kind of craft emerge around system design, experiments and review?
QUESTION 10
How do we pass on AI-assisted understanding?
I can spend an hour exploring a question with AI and arrive at a useful insight. A colleague who only hears the conclusion has not travelled the same path.
The tension
A concise summary is easy to share; the examples, false starts and objections that made the idea click are much harder to transfer.
What I currently suspect
A short worked example and the reasoning behind a decision may travel better than either a polished conclusion or the full transcript.
What I still do not know
- What is the smallest explanation that lets another person challenge and use the idea?
- How should teams preserve the path to an insight without archiving every conversation?