This is an independently written synthesis of public material, not an official MEGA lesson. QueueCare, its artifacts, and the proposed workflow are original examples. You will move from a product brief to a delivered change while preserving useful feedback at every step.
Learning goals
- Separate exploration from commitment without creating a long handoff chain.
- Plan around uncertain dependencies and small end-to-end changes.
- Use agents for execution while preserving engineering responsibility.
- Define delivery to include operability, evidence, and recovery.
Exploration should change a decision
Exploration answers a question that could alter the implementation. For QueueCare reminders, useful questions include whether the current scheduler can prevent duplicates, whether appointment times already have a defined zone, and whether residents can cancel without signing in. “Research reminder systems” is too broad unless it names a decision that research will support.
Give exploration a bounded output: the relevant current behavior, evidence locations, two viable options, a recommendation, and unresolved questions. The agent can inspect code and documentation without starting implementation. That creates a chance to challenge assumptions before a large diff makes one option feel inevitable.
Use competing prototypes when the uncertainty is experiential. For example, show a resident a direct cancellation link and a link to an appointment details page. Ask them to complete the same task. Observe confusion and mistakes. A prototype can teach you about interaction while omitting production storage and delivery. Do not mistake its ease of construction for evidence that the whole system is easy to operate.
Kent's public Kody introduction describes a progression from ad hoc agent-authored code to durable hosted packages that agents can reuse. It also discusses integrations and isolated secret storage as part of that environment. These are the author's descriptions of his product, not an independent security assessment. Read Introducing Kody.
The broader development lesson is to distinguish exploratory code from a capability you intend to maintain. A prototype answers a question. A durable capability needs a contract, ownership, failure behavior, and a way to change it safely.
Planning should follow uncertainty
Order work so that the earliest result eliminates the most important uncertainty. For QueueCare, checking the appointment time model comes before writing reminder copy. Otherwise every later component might embed the wrong interpretation of “24 hours before.” Verifying dispatch identity comes before scaling the worker fleet.
A plan should contain verifiable slices rather than only activities. “Implement scheduling” is an activity. “Given one confirmed booking and a controlled clock, record exactly one eligible reminder without contacting a real resident” produces evidence. The next slice can add the provider boundary; the next can verify cancellation behavior.
Plans are hypotheses about how to proceed. Revise one when new evidence changes a dependency. If inspection reveals that every booking stores a local time without a zone, the next step may be a product and data decision. Continuing with the old plan because it is already written produces a more polished version of an incorrect assumption.
Keep a short decision record alongside the plan. It should explain rejected options and their conditions for reconsideration. This helps another agent resume without redoing the entire exploration or treating an old recommendation as permanent law.
Execution needs stable boundaries
An agent's output becomes easier to assess when the change has clear boundaries. Give it the selected behavior, relevant contracts, permitted files or modules, evaluation commands, and a stopping condition. Let it choose ordinary implementation details within those constraints. Escalate changes to public contracts or product promises as decisions, rather than hiding them inside refactoring.
Protect the feedback cycle from avoidable noise. Keep unrelated cleanup out of a feature change. Use invented booking fixtures. Keep external message sending behind a test boundary. Report which code was exercised, which dependencies were simulated, and which conclusions remain unsupported.
Mocking is a deliberate tradeoff. Kent explains that substituting a service can make a test practical while removing evidence about the real integration. Read The Merits of Mocking. For QueueCare, a fake email provider avoids contacting residents during development. It cannot prove authentication, provider acceptance, delivery, or inbox rendering. Those need their own appropriate checks.
Execution also includes feedback from people. If a coordinator cannot understand why a reminder failed, adding retries may deepen the operational problem. A small readable status view might be the better next change. Keep implementation feedback and product feedback connected without treating either as sufficient by itself.
Worked example: a delivery packet
The following packet describes an illustrative reminder change. It is a proposed artifact, not a claim that code has run.
Change: Send one reminder for an eligible confirmed booking.
Slice 1: Controlled clock selects the intended booking window.
Slice 2: Dispatch records a stable reminder identity.
Slice 3: Provider adapter sends to an approved test recipient.
Slice 4: Cancellation before dispatch prevents the reminder.
Evidence:
- Eligibility fixtures cover zone, boundary time, and status.
- Retry fixture produces one committed dispatch record.
- Browser shows useful success and failure states.
- Provider test receipt is linked to the dispatch identity.
Operations:
- Feature switch disables new dispatches.
- Already accepted messages cannot be recalled.
- Owner reviews failed dispatches after each clinic.
- No raw cancellation tokens appear in diagnostic events.Work through a failure. A worker sends a message, then crashes before recording success. A retry sees no successful record and sends again. The happy-path test passes, yet a real resident may receive duplicates. A stable identity in the database helps identify repeated work, but the team must examine the provider's own behavior and the order of operations. A local “sent” flag alone does not guarantee one external effect across a crash.
A defensible design states its guarantee precisely. If the provider supports a suitable idempotency mechanism, the adapter can reuse the same identity on retry. If it does not, the product may need to accept a documented duplicate risk, reconcile ambiguous sends, or change providers. The lesson is to expose the gap rather than claim exactly-once behavior from a single local check.
Expected delivery evidence includes one ordinary path and one forced crash path. A test recipient should receive the intended message in the controlled provider check. A simulated ambiguous result should produce an explicit state requiring the chosen recovery policy. Merely seeing a green worker log is insufficient.
Delivery closes one loop and opens another
Delivery includes the deployed artifact, configuration, migration state, monitoring, and rollback instructions. A merged change can still be inactive because its switch is off. An active switch can still point at the wrong provider account. Verify the environment and connect observations to the exact version being evaluated.
Make recovery concrete. Disabling a switch can stop future dispatches; it cannot unsend email. Restoring an older application may not undo a new data shape. These limits should shape the release plan before the first resident encounters the feature.
Failure modes
- Treating a prototype as a maintained integration.
- Continuing a plan after its core assumption fails.
- Calling a mocked provider check end-to-end evidence.
- Delegating an irreversible product decision as an ordinary code detail.
- Declaring delivery complete without checking activation and recovery.
Practice
Create a delivery packet for QueueCare rescheduling. Define four slices, the first uncertain dependency, two deliberate failure injections, and a recovery action. Use a local fixture or paper simulation if you have no application.
Acceptance requires evidence for the resident journey, booking consistency, notification behavior, and operator diagnosis. State exactly which external effects recovery cannot reverse.
A strong answer tests a failure between acquiring a replacement slot and releasing the original. It explains whether the transition is atomic or compensated. It verifies what a resident sees afterward and avoids assuming a rollback repairs every data change.
Check your understanding
- What makes exploration useful? Answer: Its findings can change a specific decision.
- Does a provider stub prove delivery? Answer: No. It proves behavior at the simulated boundary.
- Why document recovery limits? Answer: Some side effects and data changes survive code rollback.