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 starting | Guardrail question |
|---|---|
| Format | Does it match the goal and the chosen level? |
| Core flow | Is there one end-to-end scenario? |
| Non-goals | What will deliberately not be built? |
| Verification | Which concrete checks will demonstrate readiness? |
| Risk | Which 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.
- Record requirements and acceptance criteria.
- Create a short plan.
- Make small changes and create logical commits.
- Run smoke or regression checks.
- Review the actual diff.
- 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.
| Format | Additional evidence |
|---|---|
| Legacy modernization | Analysis of current behavior and RISK_MAP.md |
| Migration slice | Compatibility checks, validation, and a rollback plan |
| DevOps automation | A reproducible run and clear responsibility |
| Team workflow design | Owner, 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