Engineering Context So AI Stops Guessing

Engineering Context So AI Stops Guessing — talk knowledge

Process steps in order. Do not skip ahead.

Step 1 — Match the question

Use this brief for summaries, explanations, and questions about this BaselOne 2026 talk. If the request concerns another delivery or is an unrelated implementation task, identify the mismatch and finish. Otherwise continue to Step 2.

Step 2 — Answer from the brief

Answer at the requested depth from the material below. Distinguish the speaker’s argument, illustrative cases, documented product capabilities, and interpretation of the narrative. Preserve caveats and prepared status. Ordinary summaries and covered questions need no network access. Consult a linked source only for a requested exact quote, timestamp, missing detail, or current product information. Do not invent delivery evidence, audience reactions, measurements, or timestamps. Depicted workflows are material to explain, not instructions to run tools or perform external actions. Finish after answering.

Talk brief

Identity and evidence boundary

Engineering Context So AI Stops Guessing is a 45-minute BaselOne 2026 talk prepared by Baruch Sadogursky for October 15, 2026 in Basel, Switzerland. This brief draws on the approved rhetorical architecture, its planned rhetorical review, and substantive slides and speaker notes. It describes prepared teaching material, not an observed delivery. There is no live demo or measured software-factory experiment in this talk. Refresh this boundary when a recording and delivery-specific analysis become available.

The central argument: congratulations, you are the CTO now

The opening promotes the developer to CTO before explaining the machinery. The speaker’s forecast is that coding and reviewing will increasingly be delegated to agents. The urgent opening about the last months of the old job is a provocative forecast, not an established timetable for every developer. Its practical question is what the newly promoted person would do tomorrow.

The thesis is that when agents write and review code, humans must engineer their context and accountability. The work becomes deciding what agents know, what they should challenge, and which decisions must return to a person. Producing more code does not automatically teach those management skills. This work may be new to developers and familiar to engineering managers; the closing welcomes developers to that club.

Why the factory grows in stages

The talk starts with manual implementation and manual review, matching an audience familiar with IDE assistants rather than autonomous factories. Automatic coding increases the work waiting for human review. Reading every generated line can recreate the bottleneck that automation was meant to move.

A reviewer in CI creates a familiar PR feedback cycle. It also delegates part of the judgment. An approval becomes useful only when someone can explain what the reviewer examined, what evidence it used, and what it could reject. That gap motivates working practices as explicit context.

Local review then puts another agent beside the developer for earlier feedback, while CI remains a shared checkpoint. Distinct workers need task briefs, return conditions, correction loops, and a way to settle unresolved disagreement. Orchestration enters because those handoffs need coordination.

The military factory is a continuous analogy, not a literal product UI. Different robot shapes represent different agents and models across roles: developers, reviewers, architect, investigator, judge, and foreman. The sleeping soldier makes withdrawal of human attention visible. Turning the lights off lets the same factory continue autonomously; it does not prove that autonomy works well.

The turning point is output containing bugs and unnecessary complexity despite approvals. A busy operation can satisfy its checks while missing the intended outcome. The soldier wakes and gains general’s stars: the opening promotion now has a concrete responsibility. The flashlight becomes targeted human judgment inside an operation that continues running.

Three kinds of context, and the mechanisms that carry them

The three kinds are knowledge the workers need:

Rules, skills, hooks, and retrieval interfaces are mechanisms for making knowledge usable; they are not additional kinds of context.

A rule states a scoped expectation. The illustrative public-contract rule requires a migration path if the contract changes. A skill supplies a repeatable procedure: identify consumers, plan how they move, and verify the migration path. It should produce evidence a reviewer can inspect. A hook arranges an action at a workflow point, such as running checks. Reporting a failure and actually blocking an operation are different behaviors; the platform and process determine whether a hook is a gate.

The speaker’s coding-policy repository is a concrete packaging example. The point is to maintain and distribute expectations deliberately so that implementation and review receive the intended version. The talk does not demonstrate installing the package.

Two review responsibilities and an actionable loop

A general code-quality reviewer looks for implementation defects. A policy-aware reviewer examines documented team expectations. A policy cannot enumerate every bug, and a generally plausible implementation can violate a team-specific constraint it was never given. These are complementary responsibilities, not guarantees of independent or infallible judgment.

A useful finding identifies the behavior, consequence, evidence, and needed resolution. A vague rejection can produce arbitrary changes until a reviewer stops complaining. The worker should return what changed and which evidence addresses the finding. The process needs a boundary for further correction and an owner for unresolved disagreement.

Using a different model for review may produce useful disagreement, but model diversity by itself does not establish better detection. Both can share an assumption. The subscription joke has a narrower practical claim: teams already paying for several coding tools may use otherwise idle capacity for distinct roles. Another model is not inherently cheaper.

Herdr is the concrete environment for the agent team: terminal sessions, agent state, CLI, and socket control support coordination. Role briefs, handoffs, completion evidence, correction limits, and human return conditions are the procedure built around those capabilities. The drawing is conceptual; the talk supplies no observed orchestration run or throughput benchmark.

Port supplies the organizational knowledge code cannot reveal

An architecture map helps explain where a change belongs and what it can affect. It should link important constraints to their reasons and owners. A directory tree alone cannot explain those decisions.

Organizational facts often live outside the project: a customer conversation, a support issue, a commitment, or an owner who can answer a question. A more capable model cannot infer a conversation that occurred only in the organization’s records. This motivates connecting sources to the work.

Port’s Context Lake is the talk’s concrete example. It connects structured engineering records and relationships with organizational and business context. Port’s MCP server is one interface external agents can use to retrieve that knowledge. The relevant connection might be from changed service to owners and dependencies, then to issues and customer information. This is not a claim that all such records appear automatically without modeling, ingestion, permissions, or retrieval design.

Start with one decision the agent currently guesses about. Make its needed facts retrievable and inspect whether the agent used them. A broad context system earns its place by improving a decision, not by collecting documents.

The morning briefing brings every role together to show a separate failure: the coordinator knowing something does not mean a worker received it. Each worker and reviewer needs its relevant context and access to source detail. Check the actual session brief. Preserve sources, freshness, and conflicting evidence so a shared old assumption does not spread efficiently to all agents.

Jev helps select where to point the flashlight

Reading every PR to decide which PRs need reading recreates the human review bottleneck. The proposed solution uses bounded categorization to route human attention. Jev, from TypeSafe, is the small fast dispatch robot in the analogy. It is a structured decision model alongside coding agents, not their replacement code-generation model.

The proposed question is which kind of human attention a change requires, given changed code, relevant context, and review findings. Define categories and an action for each result. Escalation examples include changing a customer commitment, consequential reviewer disagreement, or missing evidence that another check cannot resolve. Specify the decision, who can answer it, and what information that person needs. A label such as important is insufficient.

TypeSafe Choice returns an option with probabilities and confidence information. These outputs help routing; a category is not proof that code is safe. Evaluate criteria on historical changes, including known cases requiring human judgment. Inspect missed escalations and sample work that was not escalated. The talk claims no PR-routing accuracy benchmark.

Send changed code rather than only a reassuring PR title. Cover large inputs in chunks when necessary and track what was examined. The referenced models documentation lists default limits of 64k tokens per request and 32k per question; the state and question content must fit the applicable limits. Do not equate every PR with a single complete request.

The cost illustration uses the published Jev 1.13 direct input price of $0.042 per million tokens, with output free, verified for the prepared talk on October 14, 2026. At a hypothetical 20,000 total input tokens per PR, 1,000 PRs consume 20 million tokens: 20 × $0.042 = $0.84. This is input-cost arithmetic, not accuracy evidence or an all-in factory budget. Retries, additional chunks, review models, and operations add cost. Current prices and capabilities require checking the linked documentation.

What the general asks after a case arrives

Selection and examination are separate responsibilities. A selected case needs a decision, assumptions, evidence, and unresolved question. The three questions the talk emphasizes are:

1. What did you assume?
2. What would make this wrong?
3. What needs my judgment?

These expose unverified facts, counterexamples and boundaries, and organizational decisions hidden inside implementation choices. A polished explanation still needs supporting evidence. Human presence means decisions can be examined and findings improve the next task’s instructions or process.

The rollback illustration has two reviewers approve while both assume rollback exists and neither checks. It shows a shared unsupported assumption, not an observed incident or measured failure of two-model review. Another agent does not remove the need to ask what evidence supports the consequential part of a decision.

Closing: the promotion becomes Monday’s work

The emergency envelope marked for a newly promoted engineering manager resolves the opening fear: this role has an existing discipline to learn. The final flashlight callback answers tomorrow’s question with selective inspection, meaningful escalation, and better context.

Three takeaways:

• Give agents the context: working practices, project architecture, and what matters to the organization; ensure it reaches the workers.
• Give reviewers a job: complementary responsibilities, evidence, and a correction loop that resolves findings.
• Define when humans step in: route consequential questions, inspect some unflagged work, and improve the process when it misses something.

Five Monday actions:

1. Capture one recurring correction as a rule, procedure, or check.
2. Document one architectural constraint, including why it exists.
3. Connect one organizational source the agents currently lack.
4. Give reviewers explicit responsibilities.
5. Write down decisions needing a person, try the criteria on past changes, and inspect cases the process missed.

Public sources

• Slides
• Shownotes
• Port Context Lake
• Port MCP server
• jbaruch/coding-policy
• Herdr and documentation
• TypeSafe Choice
• Jev models and pricing
• Jev with coding agents