Subscriber AMA: Reading, Career, Side Projects, and AI Development

The short answer is that no perfect block of reading time exists. There is a walk with the dog, a commute, a few pages before sleep, audio during household tasks, and periods when one book temporarily gives way to another. This is not a productivity system. It is an approach to attention: several books can stay open for different states of mind, an English text can move slowly, and a pause does not have to count as failure.

A book is selected through the question currently blocking thought or work, not from an abstract lifetime backlog. Reading therefore belongs to a longer loop: encounter an idea, test it against experience, discuss it, explain it to others, and revisit it with a changed context. Re-reading Write, Cut or Taleb is useful precisely because the reader is no longer the same person.

The public answer is easiest to describe as 6D: Discovery finds a signal; Digest works through the source; Discuss exposes the idea to people and counterarguments; Describe builds a personal model; eDit compresses and verifies it; Deliver publishes the result. The full cycle turns a raw discovery into material that others can read and check. Editing before publication is as much a part of the work as finding the idea.

The technical answer is less romantic. An experimental system with ingestion, full-text, vector, and graph search exists, yet daily work more often favours a Git repository of Markdown files and explicit agent skills. It is easier to inspect, version, and move between tools. Extra infrastructure becomes justified only after a problem appears that the simple system demonstrably cannot solve.

Discovery → Digest → Discuss → Describe → eDit → Deliver

System Design Space began as a manuscript and a Google Doc. Linear prose is good at explaining a sequential model, but architectural judgment grows through choices: notice constraints, propose alternatives, request a hint at the right moment, inspect consequences, and try again. The site is therefore moving toward exercises, explanations, interactive visualisations, labs, and short checks of understanding.

The planned book with the Piter publishing house remains a linear route through the subject; the space is a non-linear practice environment. As of the episode, the next increments are more likely to remain free, and monetisation is not yet defined. The priority is to verify that exercises transfer knowledge into decisions before announcing a business model around them.

In a work system, responsibility is distributed: product defines the need, architecture chooses boundaries, a platform supplies the production path, and operations sees failures. A side project returns the whole chain to one owner. That owner must choose value, complexity cost, data model, release path, observability, and what happens after the first incident. It is not a miniature enterprise; it is a fast test bench for engineering decisions.

Agents make that test bench even more useful. They can move rapidly from an idea to a large implementation, but they also require architectural boundaries, CI/CD, self-healing, and deterministic verification. If every file still needs manual rereading, faster generation has only moved the work to the end of the loop.

Engineering work is not disappearing; its old monopoly on implementation is. Domain models, system design, constraint setting, evidence of correctness, and the ability to explain consequences gain value. A person who only translated a complete requirement into syntax is under pressure. A person who clarifies intent and owns the result gains leverage.

For a junior engineer, this means a new learning loop: state a hypothesis, direct an agent, read the change, verify behaviour, and explain the decision. For a lead, growth is not simply the next title. It needs the right place, timing, and readiness; Westrum’s culture typology helps reveal whether information flows through the system or gets punished together with bad news.

This is a personal snapshot as of August 23, 2026, not universal advice. The final working day is August 31 after almost ten years inside one large technology system. The reason is described as diverging trajectories: both company and person continue moving, but no longer necessarily in the same direction. At forty, with a family and a financial cushion, a different form of risk becomes possible than at the start of a career.

The next chapter is a set of testable hypotheses rather than a single declared destination: author projects, public work, consulting and product possibilities, and a potential move to London around November. An intention should not become a promise, and a good handover is not just a document. The detailed transition mechanics are left for the separate Last 90 Days episode.

The practical answer is to reduce both diff size and ambiguity. Specification-driven development turns intent into criteria, a plan, tasks, implementation, and verification. ADRs preserve decisions and trade-offs; one agent can implement while another searches for omissions. Changing models does not create independence if both models read the same incomplete context.

Before release, changes should be small and checked independently of the model. Types, linting, and static analysis catch code errors; tests check behaviour. A website also needs checks for accessibility, localisation, links, file sizes, and routes. These checks support the release decision, but accountability remains with the change owner.

Investigating an incident that has already happened is a different task. A root-cause analysis (RCA) agent helps while the evidence is available in logs, metrics, traces, and decision history. If the cause is known only to an expert or hidden in an implicit division of responsibilities, the agent may reason confidently from incomplete data. A person must check its explanation too.

intent → acceptance criteria → plan → tasks → implementation → verification

“Code is almost free” does not mean “change is almost free.” In a small company, an agent can remove a visible share of manual implementation and let one person assemble a product. In a mid-sized company, gains quickly hit shared context and coordination between functions. In an enterprise, legacy systems, policies, identities, risk, and the cost of proving that local acceleration did not damage the system dominate the equation.

The effect on SaaS and internal platforms is therefore mixed. If a product merely wraps a widely available model capability, customers can replace it more easily and competitors can reproduce it. Deep integration, data, trust, and process change retain value. Yet a platform that is expensive to maintain and impossible to replace turns from an asset into a liability. Cheap generation strengthens this test but does not remove organisational cost.

The Microsoft, DORA, NBER, and 3 AImigo materials below come from the preparation notes. They help test the conversational hypothesis but were not cited as evidence during the live episode.

The live answer was shorter and sharper than the preparation notes: a recommendation of Eliezer Yudkowsky and Nate Soares’s If Anyone Builds It, Everyone Dies and a discussion of alignment. It is a strong position on superhuman-intelligence risk, not a neutral forecast. MIRI remains active and describes a 2024 strategic pivot; Safe Superintelligence states safe superintelligence as its sole goal. None of these facts proves that alignment is solved or that a timeline is known.

The prepared frame is broader: AGI can be discussed across breadth and depth of capability, separately from autonomy; ASI is a hypothetical transition to systems exceeding humans across most cognitive work. The International AI Safety Report, Levels of AGI, METR, and related sources are valuable because they preserve uncertainty. A task-horizon graph is not a calendar for full automation.

For today’s software world, the direction of travel matters more than the label attached to a future system. Scarcity is already moving from typing code toward intent, verification, architecture, security, economics, and ownership of consequences. Even if AGI remains contested, that transition can be observed and designed for now.

Viewers widened the prepared route. Whom should one follow to understand AI’s future? Not a single trendsetter, but several independent channels: engineering analyses, product conversations, and primary publications. What does it mean to treat an LLM as “the defendant”? Ask for evidence: links to context, a reproducible test, and an explicit distinction between fact, inference, and speculation.

Do Java, Go, and Spring Boot still matter? Yes, when they are the language of a system one must understand and change; no, when a technology list substitutes for engineering judgment. Can a strong product manager without deep engineering build with Lovable or Replit? They can assemble and test a hypothesis, but a growing consequence radius requires architecture, security, operations, and people who can establish correctness.

The shared answer across the AMA is to build a learning loop rather than a list of approved tools. State a question, find material, build a model, make a bounded project, verify consequences, and explain the result. That loop survives changing books, languages, models, and even definitions of the developer role.