The tracks run in parallel and don't need equal time. Practice starts from the first step, and using AI to learn starts on day one; building AI into the product comes later.
State 1 of 5
Relies on AI to produce the product.
State 2 of 5
Adds the ability to understand, write, review, and debug code.
State 3 of 5
Adds system organization and technical trade-offs.
State 4 of 5
Adds user needs, business rules, priorities, time, and cost.
State 5 of 5
Adds communication, coordination, and delivery with others.
A shared trap anyone can fall into at any stage: collecting lots of knowledge without applying it. It isn't a sixth rank or a promotion.
Stage 1 · Steps 01–04
Start using AI and build a foundation that helps you understand and review, with an in-memory program that manages courses, students, and enrollments.
You run the program and explain its behavior, add a new rule, and diagnose a bug and prove the fix with a test.
Stage 1 · Beginner
Where do we apply this in the platform? Run a Java program that shows course data, and define the teacher, student, course, and enrollment as the platform's first scope.
ChatGPT or Claude basics: a clear goal, context, follow-up questions, and the limits of trust and privacy.
You use it to explain, practice, and review from day one.
You summarize a concept in your own words, try an example, and verify the answer.
The JDK, an IDE such as IntelliJ IDEA, the terminal, files, running a Java program, and tracing inputs and outputs.
You set up an environment to experiment in and understand the write-and-run cycle.
You run a program that shows course data, change the inputs, and explain the result.
The user, the problem, the goal, and the scope: teacher, student, course, and enrollment; stating your assumptions.
You connect learning to a real need and start with a small scope.
You write a short description of the platform and three questions you need the teacher to answer.
Describing the goal, what you tried, and the expected versus actual result; basic English technical vocabulary.
You get useful help and reduce misunderstanding.
You write a question someone else can understand and reproduce.
Stage 1 · Beginner
Where do we apply this in the platform? The enrollment-eligibility rule: who can enroll in a course, with written success and rejection cases that match the program's behavior.
Asking for a hint, breaking the problem down, explaining one step, then verifying and trying on your own.
You turn help into an ability you can use yourself.
You solve a similar exercise and explain the solution after the help ends.
Types, variables, conditions, loops, methods, strings, arrays, scope, and the debugger.
You express the platform's rules in code and follow how they run.
You implement a simple enrollment-eligibility rule, trace a wrong condition, and fix it.
Inputs and outputs, pseudocode, success and rejection cases, and concrete acceptance examples.
You define the required behavior before implementing it.
You write cases for an eligible and an ineligible student, and the program's results match them.
Explaining the steps of a solution, writing down assumptions, and clearly stating what you don't understand.
Others can follow your logic and help you.
You explain the enrollment rule and a counterexample in two minutes.
Stage 1 · Beginner
Where do we apply this in the platform? An in-memory model of students, courses, and enrollments that prevents duplicate enrollment and respects course capacity.
Examples, exercises, and edge cases; predicting the result before asking for an explanation.
You uncover gaps in understanding instead of just following a ready answer.
You predict the output and explain any difference between expected and actual.
OOP, encapsulation, composition, interfaces, collections, generics, and exceptions; data-structure and complexity basics.
You represent students, courses, and enrollments and choose how to work with them.
You build an in-memory model that prevents duplicate enrollment, add course capacity, and test it.
Entities, invariants, separating business rules from the user interface, and a simple design that can change.
You know where the enrollment rule lives and what is affected when it changes.
You justify where the capacity rule lives and change it without copying it to several places.
Explaining what each part is responsible for and why you chose a collection or an interface, plus a simple alternative.
The code becomes open to discussion and review.
You give a short walkthrough, and a colleague can add a new rule.
Stage 1 · Beginner
Where do we apply this in the platform? The platform's first repository: a build from a clean checkout, a test that prevents duplicate enrollment, and a reviewable PR.
Showing your attempt and asking AI about a specific flaw or alternative, then examining the diff and the suggestions.
You learn to evaluate a review and avoid accepting changes you don't understand.
You accept or reject a suggestion based on a test and an explanation.
Git, commits, branches, pull requests, Maven, and JUnit; refactoring and reading stack traces.
You keep the project's history and change code with confidence.
The project builds from a clean checkout, and a test fails before the duplicate-prevention fix and passes after it.
Breaking down the task, acceptance criteria, a definition of done, and separating behavior changes from structural improvements.
You finish a reviewable unit and know when it is done.
A small task with code, tests, and acceptance criteria that are met.
A short README, a clear commit and PR, requesting review, and responding to comments.
Someone else can run the project and understand the change.
A colleague runs it from the README, reviews the PR, and knows why the behavior changed.
Stage 2 · Steps 05–07
Turn the program into a backend with persistent data and APIs for courses, lessons, and enrollment.
You trace a request to the database, justify the model and the API contract, change a requirement and test it, and someone else can use your documentation.
Stage 2 · Junior foundations
Where do we apply this in the platform? Move students, courses, and enrollments to PostgreSQL, with an Enrollment table and constraints that prevent duplicates.
Comparing schema alternatives, raising cases that expose missing constraints, and generating test data.
You test the model's assumptions before relying on it.
You review a suggestion and prove your choice with data and an experiment.
PostgreSQL, tables, keys, constraints, joins, transactions, index basics, JDBC, then migrations.
You store students, courses, and enrollments and enforce their consistency rules.
Data persists across runs, a forbidden duplicate fails, and an incomplete operation is rolled back.
ERD, cardinality, normalization, transaction boundaries, and rules for deletion and change.
You turn the domain into a model that serves its use and stays consistent.
You justify the Enrollment table and test enrollment, deletion, and failure.
Explaining relationships and constraints, naming terms, and recording open questions.
The team interprets the data the same way.
Someone else reads the diagram and writes a correct query for a student's enrollments.
Stage 2 · Junior foundations
Where do we apply this in the platform? An API contract for listing courses, enrolling, and rejection cases, agreed before implementation.
Interpreting HTTP requests, responses, and errors, and proposing specific diagnostic experiments.
You learn to trace a request and verify hypotheses.
You explain a failed request and prove the cause instead of settling for the model's guess.
Client/server, an introduction to DNS and TCP/TLS, HTTP, REST, JSON, status codes, headers, and curl or Postman.
You understand how the platform's interface talks to the backend and how requests behave.
You write and try an enrollment request and explain the correct and incorrect responses.
Actors, scenarios, request/response, errors, pagination, and acceptance criteria.
The meaning of each operation is clear to the interface and to testing.
You define the contract for listing courses and enrolling, including rejection cases, before implementation.
Clarifying questions, example requests and results, and describing a reproducible bug.
You agree on behavior and reduce rework.
A colleague implements a client or a test from the contract without guessing.
Stage 2 · Junior foundations
Where do we apply this in the platform? A Spring Boot backend with APIs for courses, lessons, and enrollment, and documentation someone else can use.
File context, specific instructions, a small suggestion or change, reviewing the diff, and running the tests.
You speed up implementation while understanding what changed.
You implement a bounded endpoint, explain every change, and catch an unsuitable suggestion.
Dependency injection, configuration, controllers, services, DTOs, validation, error handling, and Spring Data JPA, with an understanding of SQL, migrations, and API docs.
You turn the program into a usable backend.
APIs for courses, lessons, and enrollment, and you trace a request from the controller to the database.
Separating responsibilities and simple module boundaries, domain rules, the use-case flow, and a feature's definition of done.
You control the impact of a change and keep behavior clear.
Changing an enrollment rule affects only the expected parts, and you prove it with a test.
Showing the user journey, explaining the decision, documenting the API, and taking feedback.
The team confirms the meaning and the result before expanding.
Someone uses the API from the documentation, and you absorb a change request and explain it.
Stage 3 · Steps 08–10
Add accounts, permissions, lessons, quizzes, and results, and deliver a complete student journey on a deployed environment.
You deliver a small feature from understanding the requirement through deployment and follow-up, and you know when you need help or review.
Stage 3 · Capable Junior
Where do we apply this in the platform? Accounts and roles: a student sees only their own enrollments and a teacher edits only their own courses, even with a direct request.
Using AI to suggest misuse cases and review specific settings or code, with independent verification.
You widen the set of cases you examine.
You find an unauthorized-access scenario and prove it is blocked with a test.
Spring Security, authentication, authorization, password hashing, sessions/tokens, resource ownership, secrets, and CORS/CSRF depending on the login mechanism.
You protect the platform's accounts, content, and operations.
A student can't read another student's enrollment and a teacher can't edit someone else's course, even with a direct request.
A matrix of roles, ownership, and access conditions; least privilege; and simple threats.
Permissions follow the platform's rules and cover the required records.
You turn every access rule into a success case, a rejection case, and an acceptance test.
Explaining impact, priority, and reproduction steps, and avoiding sharing sensitive data.
The team handles the problem clearly.
You write an issue report that shows who is affected and how to verify the fix.
Stage 3 · Capable Junior
Where do we apply this in the platform? Tests for the lesson, quiz, and result journey that catch any grading bug before it is fixed.
Boundary cases, negative cases, fixtures, critiquing assertions, and examining suggested tests.
You expand coverage around real risks.
A suggested test exposes a real defect, and you explain what it proves and what it doesn't.
JUnit, Mockito when needed, integration tests, Testcontainers, Spring test support, and core journey tests.
You verify business rules and the real connection to the database.
The lesson, quiz, and result journey works, and a grading defect fails the test before it is fixed.
A practical test pyramid, regression risks, acceptance tests, and release criteria.
You tie testing to behavior that matters to the user.
Every critical rule has a suitable test, and a requested change doesn't break the core journey.
Bug reports, review with QA, explaining the limits of testing, and documenting the fix decision.
Bugs become easy to reproduce and prioritize.
A colleague reproduces a defect from your report and verifies its fix.
Stage 3 · Capable Junior
Where do we apply this in the platform? A complete student journey on a deployed environment: sign in, choose a course, enroll, take a lesson and a quiz, and see the result.
A clear scope of files and tools, checkpoints, reading the diff, limited permissions, and verifying it runs.
You delegate a bounded step and keep the ability to review it.
The agent completes a task such as run setup or documentation, and you verify it from a clean environment.
Linux basics, Docker and Compose, environment configuration, CI/CD, secrets, health checks, logs, migrations, and backup/restore.
You ship the service, follow it, and have a way to recover.
It runs from a clean environment with an automatic pipeline; you deploy an update and restore a test data backup.
MVP, prioritization, a release checklist, migrations, rollback, and a simple operating plan.
You deliver a complete student journey instead of separate features.
Sign-in, choosing a course, enrolling, a lesson, a quiz, and a result on a deployed environment.
Showing a user journey, release notes, a runbook, and an update about a blocker or an incident.
Users and the team know what was done and what needs attention.
Someone runs the service and follows the diagnostic steps for a problem from your documents.
Stage 4 · Steps 11–14
Handle business rules, concurrency, performance, integrations, and failure with more independence, and build a first useful AI feature for teachers.
You own a medium-sized feature from requirements to operation, handle integrations and failure cases, and explain your trade-offs, with review matched to the risk.
Stage 4 · Mid-level
Where do we apply this in the platform? Protect the last seat in a course from concurrent enrollments, with a test that proves the result.
Change-impact analysis, design alternatives, critiquing assumptions, and providing context from specific files.
You test your idea before and during implementation.
You pick an alternative based on a constraint and an experiment, and document why you rejected another.
Streams, immutability, JVM/memory basics, threads, executors, synchronization, race conditions, virtual threads, and complexity analysis.
You understand how code behaves under concurrency and choose suitable tools.
You reproduce concurrent enrollments that break capacity, then fix them and prove the behavior.
Invariants, transaction boundaries, optimistic/pessimistic locking, and what success means under contention.
The last seat in a course is never sold to more than one student.
A concurrent test proves the result, and you explain the cost of your choice.
Breaking down a feature, identifying dependencies and risks, and updating the estimate as you learn.
The team relies on a clear commitment.
You deliver a small plan and flag early when new information changes it.
Stage 4 · Mid-level
Where do we apply this in the platform? Speed up course and progress listings with a specific measurement, and protect lesson files from unauthorized access.
Analyzing query plans and logs with sensitive data removed, with AI's help, and proposing experiments.
You speed up the investigation.
You measure before and after the change and separate the hypothesis from the proven cause.
EXPLAIN, indexes, N+1, fetch strategies, pagination, connection pools, k6, Redis when needed, object storage, and signed URLs.
Showing courses, progress, and content stays practical as data grows.
You improve a slow endpoint with a specific measurement and prove that access to an unauthorized file is blocked.
Latency, throughput, data volumes, storage cost, cache invalidation, and the content-access policy.
"Fast" and "scalable" become requirements you can check.
You define a target load and an acceptable result, and test both.
A short performance report and an explanation of the trade-offs.
Decisions are revisited based on evidence.
You show the improvement, its cost, and the limits of the test.
Stage 4 · Mid-level
Where do we apply this in the platform? Payments and notifications: a duplicate payment webhook doesn't duplicate the enrollment, and an email outage doesn't lose the job.
Project instructions, checkpoints, file and tool limits, reviewing changes, and verifying acceptance criteria.
You delegate larger work while keeping control.
You detect a deviation from the rules and correct it before delivery.
HTTP clients, timeouts, retries/backoff, idempotency, webhooks, scheduling, RabbitMQ for example, DLQs, and an introduction to the outbox pattern.
Payments and notifications tolerate delay, duplication, and failure.
A duplicate payment webhook doesn't duplicate the enrollment or the financial effect, and an email outage doesn't lose the job.
Order, payment, and enrollment states; refunds; reconciliation; and separating financial facts from success messages.
Payment success, enrollment, and notification are not one operation that is automatically guaranteed.
You map and test successful, failed, delayed, and duplicate payment paths.
Reading integration docs, asking precise questions, and documenting incidents and the limits of responsibility.
An integration depends on more than one team and system.
You file a support request with a correlation ID, steps, and the expected result.
Stage 4 · Mid-level
Where do we apply this in the platform? Draft quiz questions generated by AI and reviewed by the teacher, who can edit or reject them, with quality, cost, and latency measured.
Model APIs, prompts/templates, tokens, context limits, structured outputs, streaming, timeouts, budgets, and a small evaluation set; Spring AI is a Java option.
You add real help for teachers.
Generating a draft of questions the teacher reviews, with quality, cost, and latency measured and failures handled.
Key management, client integration, output validation, rate limiting, saving job state, and monitoring calls.
A model call stays part of a service you can operate.
A provider outage or invalid returned JSON doesn't break the teacher's journey.
Defining the user and the desired outcome, a manual baseline, the review workflow, and a success criterion.
You test whether AI saves time while keeping acceptable quality.
A comparison on fixed examples shows the feature's benefit and where it needs review.
Presenting the draft and its assumptions and asking for the user's assessment.
Users know what needs review.
The teacher can edit and reject the output and report a specific defect.
Stage 5 · Steps 15–18
Handle more ambiguity and risk, and improve both the system and the team; add a content assistant and permissions, and study SaaS, reliability, and distribution when they are needed.
You own an important part across design, implementation, and operation, reduce its risks, guide others, and work with incomplete requirements. Doing this with a real team and real users is a core part of proving it.
Stage 5 · Preparing for Senior responsibilities
Where do we apply this in the platform? An assistant that answers students only from the course content they are allowed to access, with citations and tests that prevent leaks.
Embeddings, chunking, retrieval, metadata filtering, pgvector for example, RAG, citations, and evaluating retrieval and answers separately.
Students ask about content they are allowed to see.
Known and out-of-scope questions, and tests that prevent retrieving data from an unauthorized student or course.
Ingestion jobs, parsing, indexing, updating and deleting indexes, metadata, and module boundaries.
The assistant's content stays consistent with current content and permissions.
Editing a lesson or revoking a permission is reflected in retrieval according to a documented policy.
Threat modeling, prompt injection, source and refusal policies, and authorization before retrieval and execution.
Content or the model can't change the system's permission rules.
Adversarial tests that try to leak content or execute embedded instructions are rejected.
Explaining what was measured and what wasn't, the feature's limits, and a gradual rollout plan.
A clear launch decision.
You present successes, failures, and the criteria for stopping or improving the feature.
Stage 5 · Preparing for Senior responsibilities
Where do we apply this in the platform? The platform serves centers and teachers with isolated data, plans and subscriptions, and a gradual migration plan.
Critiquing boundaries, dependencies, and migration plans, and comparing scenarios.
You widen the alternatives you examined.
An architectural decision backed by constraints and an experiment that you can defend without going back to the model's answer.
Modular monolith, practical DDD, bounded contexts, dependency boundaries, isolation strategies, tenant context, tenant-aware queries/cache/jobs, and isolation tests; Spring Modulith is a helpful option.
You serve teachers and centers with clear data and boundaries.
One center can't reach another center's data through the API, files, jobs, or cache, with tests.
Tenants, memberships and roles, plans/entitlements, quotas, onboarding, support and operations, and the shared-versus-dedicated decision.
The product model differs from a single teacher's platform.
A context map, an ADR, a gradual migration plan, and acceptance tests for every plan.
RFC/ADR, listening to objections, and facilitating a decision.
Important decisions need shared understanding.
The discussion ends with a decision, its reasons and risks, and an owner for follow-up.
Stage 5 · Preparing for Senior responsibilities
Where do we apply this in the platform? Monitor the platform with metrics, logs, and traces, and run an exercise of a failing external dependency and service recovery.
Summarizing signals and failure hypotheses from controlled context and verifying them with measurements.
You speed up diagnosis and keep a record of the evidence.
You confirm or rule out hypotheses with experiments and real indicators.
Metrics, logs, traces, OpenTelemetry, Micrometer, Prometheus/Grafana, profiling/JFR, load tests, graceful degradation, and backup/restore drills.
You know the impact of failures and restore service.
Injecting a failure into an external dependency, detecting it, reducing its impact, and restoring service to a defined target.
SLIs/SLOs, error budgets, capacity, RTO/RPO, runbooks, postmortems, and prioritizing reliability work.
You balance feature development with service stability.
A documented incident exercise with follow-up actions that have owners and dates.
Splitting the investigation, updating stakeholders, separating facts from hypotheses, and blameless guidance.
Less confusion and better team learning.
A colleague takes over part of the investigation using your explanation and the runbook.
Stage 5 · Preparing for Senior responsibilities
Where do we apply this in the platform? An assistant that reads a student's progress and suggests a plan without changing an enrollment or a grade, and splitting a service only with proven justification.
Tools with defined contracts, schema validation, permissions, bounded workflows, approval for sensitive operations, evals, and audit trails.
The assistant performs specific functions safely.
It reads a student's progress and suggests a plan, and doesn't change an enrollment or a grade outside the application's permissions and policy.
Partial failure, consistency, delivery semantics, ordering, idempotent consumers, outbox, sagas, deeper messaging, and splitting a service when clearly justified.
You understand the consequences of distributing a system.
Redelivering an event doesn't repeat its effect, and a failure in part of the journey has clear recovery and tests.
Scale estimates, a cost model, buy versus build, monolith versus services, contracts, and a migration plan.
Added complexity must pay for itself.
You prove a bottleneck or a need for independence, compare solutions, and have a rollback plan.
Negotiating scope, time, and quality; delegation; mentoring; and resolving disagreement with evidence.
A senior's impact includes enabling others.
A colleague delivers an independent part while you review the risks and the result without doing every detail.
Stage 6 · Steps 19–21
Connect technical direction to platform economics and enable multiple teams. Staff and Architect may be different paths, not necessarily consecutive ranks.
Initiatives adopted by several teams, lasting measurable results, and knowledge and ownership that continue without depending on you day to day.
Stage 6 · Staff / Architect and beyond
Where do we apply this in the platform? Reproducible environments for several teams, and measured cost per center, student, and AI session.
Versioned prompts/evals, model selection, routing/fallback, caching, budgets, monitoring, data policies, and reviewing provider changes.
Quality, cost, and behavior are tracked as usage and models change.
A model or prompt change goes through tests, gradual rollout, rollback, and a cost and quality comparison.
Cloud architecture, IAM/networking, Infrastructure as Code such as Terraform, IaC review, deployment strategies, supply-chain security, and Kubernetes when operationally justified.
Multiple teams build and operate on reliable foundations.
Creating a reproducible environment, testing its isolation and recovery, and measuring its operating cost.
Cost per tenant, student, and AI session; budgets; quotas; customer support; investment priorities; and vendor risks.
Growth stays sustainable.
A technical decision that improves a measured cost or experience, with its side effects explained.
Executive summaries and presenting options in terms of impact, cost, and risk.
You connect engineering investment to the organization's goals.
A non-technical decision maker understands the alternatives and can choose between them.
Stage 6 · Staff / Architect and beyond
Where do we apply this in the platform? API and event governance across the platform's teams, and shared migrations that don't break consumers.
Task and context templates, tool guardrails, evaluating workflows, and quality and rework metrics.
The benefit extends to the team and can be measured.
A pilot that shows delivery time, defects, and rework, then a recommendation based on the results.
API/event governance, compatibility, schema evolution, platform boundaries, migration at scale, and reliability/security standards.
One team's changes don't break the rest of the platform.
A migration shared across teams without unplanned downtime or broken consumers.
Capability maps, build versus buy, sequencing, technical debt, investment priorities, and tying the technical roadmap to the product.
You direct several teams' effort toward the organization's most important problems.
A strategy that turns into deliverable, measurable initiatives and is revised with evidence.
Stakeholder alignment, proposals, managing disagreement, and mentoring technical leaders.
The scope of the work is larger than one person's authority.
Teams adopt a decision, implement it, and keep it going after you step back from the daily details.
Stage 6 · Staff / Architect and beyond
Where do we apply this in the platform? A deep specialization that solves recurring problems in the platform, and leaders and teams who carry the direction forward independently.
Assessing where AI helps and where rules or traditional search are enough, with an exit strategy from a costly dependency.
You choose an investment that fits the problem.
You accept or reject an AI project with a reviewable comparison.
Choosing a field: JVM/performance, distributed systems, security, data, platform, or AI systems.
You build depth to solve hard, recurring problems.
A solution that affects several systems or teams, and reusable knowledge.
An ambiguous problem across teams, a target architecture, a transition roadmap, organizational consequences, and measuring long-term impact.
You expand the organization's ability to build and change.
Sustained improvement in delivery, reliability, cost, or product growth across more than one team.
Coaching, succession, communities of practice, and distributing knowledge and ownership.
The results continue without permanent dependence on you.
Leaders and teams develop the direction and make suitable decisions independently.
Feature: Preventing duplicate enrollment · A contribution matrix, not a sequence of services.
| Track | Understand | Design | Implement | Verify | Explain |
|---|---|---|---|---|---|
| 1AI | Questions that expose ambiguity | Critique the alternatives | Bounded assistance | Suggest failure cases | Review the explanation's clarity |
| 2Java Backend | Read the current behavior | A suitable data constraint | Service + SQL | A concurrent test | Show the code and the result |
| 3Business, design & delivery | Define a duplicate | The error contract | A small feature scope | Accept success and rejection | Deliver the journey |
| 4Communication & professional | Clarify the requirement | Agree with Frontend and QA | Update progress | Review with a colleague | Demo and a documented decision |
●The developer
Understanding and decisions stay with you
●The teacher
The teacher makes the final decision
Example: enrolling in a course
I explain the idea and its limits in my own words.
I explain why Enrollment is its own entity, and when a UNIQUE constraint isn't enough on its own.
I apply it to a new requirement.
I add a rule that enrollment closes one day before the course starts.
I reproduce a bug and fix it.
I reproduce a duplicate enrollment, fix it, and prove the fix with a test.
I test the behavior and explain my choice.
I write tests for success and rejection, and explain why I chose a database constraint.