Guardrails keep the scope under control

Level expectations define not the prestige of the technology, but the required depth of engineering evidence. Before implementation, check one main scenario, its fit with the chosen level, and the list of exclusions.

Every additional feature increases the number of unknowns, tests, and demonstration risks. A production-ready promise is inappropriate when the actual deliverable is a learning prototype.

Before startingGuardrail question
FormatDoes it match the goal and the chosen level?
Core flowIs there one end-to-end scenario?
Non-goalsWhat will deliberately not be built?
VerificationWhich concrete checks will demonstrate readiness?
RiskWhich data, integrations, or production actions are excluded?

Junior: prove one working scenario

  • choose one understandable user flow;
  • record the boundaries in SPEC.md;
  • add a basic README;
  • run a simple smoke check;
  • explain Claude Code's contribution and your own manual checks.

Middle: show a controlled cycle

Claude Code can help with discovery, drafts, review, and hypothesis checking, but it does not replace the engineering decision about scope or readiness.

  1. Record requirements and acceptance criteria.
  2. Create a short plan.
  3. Make small changes and create logical commits.
  4. Run smoke or regression checks.
  5. Review the actual diff.
  6. Update the README and prepare a reproducible demo scenario.

Senior: complexity must be justified

Senior level does not mean adding every available mechanism. It means explaining trade-offs, limiting risk, and showing why this exact complexity is needed.

FormatAdditional evidence
Legacy modernizationAnalysis of current behavior and RISK_MAP.md
Migration sliceCompatibility checks, validation, and a rollback plan
DevOps automationA reproducible run and clear responsibility
Team workflow designOwner, README, changelog, and usage rules

Freeze the scope before the demo

  • do not add integrations merely because they appear small;
  • do not expand the MVP with migration or business features without a new need;
  • do not add a new pipeline, hook, or agent without evidence of its benefit;
  • if the core flow does not work midway through the work, shorten the plan;
  • before the defense, focus on reliability, the README, and the demo.

Canonical lesson source · JavaRush

Open JavaRush material