Junior → mid-level roadmaps — Software Engineering and Applied AI

Two MAIC-aligned, gate-driven paths in one place — Software Engineering (~18 months) and Applied AI (~20 months) — with browser-persisted progress tracking.

Pick your track

Two gated paths from junior to mid-level, aligned to MAIC's public architecture: Software Engineering owns the deterministic system around the intelligence; Applied AI owns the probabilistic intelligence inside it. Check off stages and gates as you complete them — progress is saved in this browser (localStorage) and does not sync across devices.

The path at a glance

Target profile: independently design, implement, deploy, observe, secure, debug, and evolve a production feature spanning UI, API, data, and integrations — including AI-powered features when required. Progress is gated by demonstrable exit criteria, not elapsed time.

Planning horizon

~18 mo

4 stages + final graduation gate

Weekly commitment

12–15 h

~6–7.5 h of it building

Deliberate-study hours

936–1,170

estimate, not a promotion clock

Stages complete

0/4

check them off below

Gates passed

0/5

4 stage gates + graduation

The split that frames both roadmaps

Software Engineering owns the deterministic system around the intelligence; Applied AI owns the probabilistic intelligence inside the system. This path builds the product/platform engineer archetype — end-to-end ownership over narrow layer specialization.

Assumed entry baseline — expand if not yet comfortable

This roadmap starts at a junior-developer baseline: working programs, Git, basic data structures, reading docs, debugging ordinary errors, calling an HTTP API, and building a basic CRUD app. If those are not comfortable, add roughly 8–12 weeks before Month 1 for programming fundamentals, Git, basic SQL, HTTP, shell usage, and testing.

Default stack: TypeScript, React/Next.js, PostgreSQL, plus enough Python to work across AI/backend services. Use AI coding tools aggressively — without outsourcing understanding.

Timeline

1 · Foundations

2 · Product eng.

3 · Production sys.

4 · Ownership

Graduation gate

Ranges are planning estimates. Advance when you can demonstrate the exit criteria — the month ending is not the gate.

Stages and exit gates

Each stage ends with a practical assessment that must pass before moving on. Expand a stage for curriculum detail and the assessment's pass criteria; tick “Done” and “Gate passed” as you earn them.

Production-minded foundations

Months 0–3 · 12–15 h/wk Done

Go deeper than “I know JavaScript.” Write correct, tested software and understand what the runtime, the database, and the network are actually doing.

Primary outcome: Correct, tested software plus real runtime/DB/network mental models.
Assessment gate: Ledger API — transactional account/ledger service.
Exit criteria: Explain a bug from HTTP request → app logic → SQL; write a migration safely; read a query plan; distinguish retryable from permanent errors; debug without an AI guessing blindly.

Curriculum

Language and runtime: TypeScript's type system, asynchronous execution, errors, modules, package management, process/runtime behavior, basic memory and performance concepts, shell tooling, Git branching and rebase, debugging, HTTP semantics, DNS/TLS at a practical level, REST conventions, JSON/schema validation, and test design.

Database: SQL joins and aggregates, normalization vs. denormalization trade-offs, transactions, constraints, foreign keys, indexes, query plans, locking, isolation, migrations, and safe schema evolution — PostgreSQL treats indexing, concurrency, performance, reliability, monitoring, backup, and replication as core operational topics.

Testing and CI: unit, integration, and API-level tests; separate deterministic business logic from side effects; automated build/test feedback on every change.

Assessment — Ledger API

Build a transactional account/ledger service. Required evidence: PostgreSQL schema, migrations, API, tests, query-plan analysis, and CI.

Pass: zero balance/transaction invariants violated across concurrent test cases; failed operations roll back correctly; CI green; critical SQL uses justified indexes; you can explain every transaction boundary.

Gate passed

Full-stack product engineering

Months 4–7 · 12–15 h/wk Done

Own an ordinary product feature end-to-end: interface, API, database, security, and deployment.

Depends on: Stage 1 gate passed
Assessment gate: OpsCase — multi-user case-management system.
Exit criteria: Take a small feature from requirements to UI, API, migration, tests, PR, deployment, and post-deploy verification without someone designing each step.

Curriculum

Frontend: React component/state patterns, forms, validation, loading and error states, accessibility, pagination, optimistic vs. confirmed updates, caching, and frontend performance.

Backend: API boundaries, service-layer design, validation, authentication, authorization, pagination, rate limiting, structured errors, API versioning, and third-party integrations. Learn Python/FastAPI enough to operate outside a pure TypeScript monoculture.

Security: sessions/tokens, OAuth/OIDC concepts, CSRF, XSS, injection, authorization errors, secure file handling, secret management, tenant boundaries, and threat modeling — OWASP ASVS 5.0 is the verification baseline.

Assessment — OpsCase

Build a multi-user case-management system. Required evidence: React UI, API, PostgreSQL, authentication, RBAC, audit events, tests, and a real deployment.

Pass: unauthorized-access tests all fail closed; every state change is persisted and attributable; critical flows work keyboard-only; API integration tests cover success and failure; a fresh deployment succeeds from documented instructions.

Gate passed

Production systems

Months 8–12 · 12–15 h/wk Done

Study the failure modes that CRUD tutorials hide: reliable integrations, asynchronous workflows, observable services, and secure deployments.

Depends on: Stage 2 gate passed
Assessment gate: Connector Hub — synchronize two mocked external SaaS systems.
Exit criteria: When a simulated dependency times out, sends duplicate webhooks, returns 429s, or disappears, your system degrades predictably instead of corrupting data.

Curriculum

Failure modes: queues and background workers, event-driven workflows, webhooks, retry/backoff, dead-letter handling, idempotency, deduplication, concurrency, optimistic/pessimistic locking, eventual consistency, caching, rate limits, timeouts, circuit breaking, bulkheads, scheduled jobs, file processing, and integration recovery.

Containers: Dockerized services and local dependencies — multi-container stacks (frontend, API, database, proxy, supporting services) as a normal application shape.

Observability as design: structured logs, correlation IDs, spans, traces, metrics, RED/USE concepts, dashboards, alerts, error budgets, and debugging from telemetry rather than console.log. OpenTelemetry is the vendor-neutral standard.

Database operations: slow queries, connection pools, lock contention, vacuum/analyze, backups, restore testing, replication concepts, and schema/data migration under load.

Assessment — Connector Hub

Synchronize two mocked external SaaS systems. Required evidence: webhooks, a queue, retry/backoff, idempotency, a dead-letter path, OpenTelemetry traces, and dashboards.

Pass: duplicate events cause no duplicate business action; transient failure recovers automatically; permanent failure is observable and replayable; request → job → external call is traceable end-to-end.

Gate passed

Mid-level ownership

Months 13–18 · 12–15 h/wk Done

Move from implementation to engineering judgment: design and own a bounded production system with architectural, operational, and product judgment.

Depends on: Stage 3 gate passed
Assessment gate: Operational Workflow Service — approval-driven enterprise process.
Exit criteria: Given a bounded problem (not an implementation plan), propose and execute a credible architecture, anticipate its main failures, operate it after release, and defend your trade-offs.

Curriculum

Design documents: write short docs before major work — context, requirements, non-goals, data model, interfaces, alternatives, failure modes, security, rollout, observability, migration, and rollback.

System design: modular monoliths vs. services, synchronous vs. async workflows, consistency boundaries, state machines, distributed locks, queues, API gateways, multi-tenancy, permissions, data lineage, audit logs — and when not to introduce complexity.

Operations: rollout strategies, feature flags, migrations, incident response, root-cause analysis, postmortems, capacity planning, performance testing, dependency upgrades, and cost awareness.

Review and communication: review another engineer's code, identify risky assumptions, break work into deliverable increments, and explain trade-offs to product, design, and non-engineering stakeholders.

Assessment — Operational Workflow Service

Build an approval-driven enterprise process service. Required evidence: design doc, multi-tenant model, workflow state machine, approvals, audit log, CI/CD, threat model, and runbook.

Pass: no demonstrated cross-tenant access; sensitive transitions require authorization; the rollback procedure works; one injected dependency outage is detected and handled using telemetry/runbook rather than manual database edits.

Gate passed

Final graduation gate

Build a fresh system from a new specification — roughly 50–70 hours across four to five weeks — rather than polishing an earlier project.

Scenario — procurement operations

A fictional company has purchase requests flowing between a procurement app, an inventory system, and a finance system. Your application must model requests, synchronize simulated external systems, surface discrepancies, route approvals, execute permitted actions, and preserve an audit trail.

Graduation evidence requirements
Area	Required evidence
Product	Working UI for normal and exceptional workflows; clear loading/error/approval states.
API/data	Versioned API contract, schema migrations, constraints, transaction boundaries, documented data model.
Integration	At least two simulated external integrations — one webhook-based, one pull/API-based.
Reliability	Timeouts, retries, idempotency, duplicate-event handling, dead-letter/recovery path.
Security	Threat model plus ASVS-derived checklist; no unresolved known Critical/High authorization, injection, or secret-management defect.
Observability	Structured logs, metrics, distributed traces; one business operation traceable across synchronous + asynchronous work.
Performance	On a documented reference environment, ≥99.5% successful non-fault-injected requests at 25 RPS and p95 <500 ms for ordinary non-AI API reads.
Operations	Deployment instructions, backup/restore demonstration, rollback procedure, incident runbook, one fault-injection exercise.
Design	3–6 page architecture/design document covering alternatives, trade-offs, failure domains, and what you intentionally did not build.
Communication	20-minute architecture review plus a simulated PR review of another engineer's change.

Graduation rule

Every security and data-integrity gate is mandatory, and at least 8 of the remaining 9 evidence categories must pass. A flashy UI cannot compensate for unsafe authorization, data corruption, or an architecture you cannot explain.

Graduation gate passed

What actually changes from junior to mid

The deepest transition is not “knows more libraries” — it is the loop you run. Rubric synthesized from MAIC's public constraints and current frontier-startup expectations.

Junior loop

Requirement
Implementation
Tests
Ask for review

Mid-level loop

Problem → clarify constraints → design
Identify failure, security, and data boundaries
Implement → measure → deploy safely
Observe real behavior → diagnose → improve

Full competency rubric — junior vs. mid (19 dimensions)

Junior to mid-level competency matrix for software engineering
Competency	Junior	Mid-level
Problem scope	Implements well-defined tickets.	Converts ambiguous bounded problems into technical plans and increments.
Code ownership	Owns functions/components/small endpoints.	Owns a feature or bounded service end-to-end.
Frontend	Builds components from existing patterns.	Designs coherent product flows, error/loading states, accessibility and API interaction.
Backend/API	Adds endpoints with guidance.	Designs API boundaries, validation, auth, async work, compatibility and failure handling.
Data modeling	Writes ordinary SQL/ORM queries.	Designs schemas, constraints, migrations and transactional boundaries.
SQL/performance	Understands indexes and joins.	Diagnoses slow queries, locks, pool exhaustion and migration impact.
Testing	Writes unit tests after implementation.	Defines test strategy across units, integrations, contracts and failure cases.
AI evaluation	Understands basic concept.	Can verify AI integration but does not own model quality.
Retrieval/context	Consumes an existing AI API.	Integrates search/retrieval where needed.
Agents/tools	Integrates an existing agent.	Builds surrounding APIs and controls safely.
Security	Follows team patterns.	Performs basic threat modeling and catches auth/input/secret/tenant issues.
Reliability	Handles obvious exceptions.	Designs retries, timeouts, idempotency, queues, recovery and rollback.
Observability	Reads logs.	Adds useful logs, metrics and traces and debugs production incidents from them.
Performance	Fixes obvious hotspots.	Profiles and improves database/API/frontend/system bottlenecks.
Deployment	Deploys through established pipeline.	Changes CI/CD and executes safe migrations/releases/rollback.
Architecture	Works inside existing architecture.	Proposes bounded architecture and explains trade-offs.
Product judgment	Focuses on correct implementation.	Connects implementation decisions to user/business outcomes.
Independence	Requires frequent technical direction.	Operates independently for days/weeks on bounded work and escalates genuine uncertainty.
Communication	Explains implementation.	Writes design docs, reviews code and communicates trade-offs.
AI-native development	Uses coding assistants for implementation.	Uses them for acceleration while independently verifying architecture/tests/security.

Weekly rhythm

At 12–15 hours per week, roughly 6–7.5 hours should be spent building — not watching courses.

Recommended share of weekly time

Weekly time allocation
Activity	Share of weekly time
Building	50%
Docs & study	20%
Testing & eval	15%
Design & review	10%
Retro notes	5%

The rule that makes this path work

Every substantial system you build must survive failure injection. Disconnect the database. Duplicate the webhook. Make the external API return 429. Expire the auth token. Send malformed payloads. Restart a worker halfway through a job. Roll back a migration. Restore a backup. Inspect the trace. That is what converts “I can build applications” into “I can own systems.”

Resources and source priority

Primary specs and documentation define how the technology works; startup job pages only tell you what the frontier currently values. Filter by priority.

Priority

Recommended resources by priority
Priority	Resource	Use it for
P0	MAIC — About / platform	The real target environment: operational apps, connected systems, ontology/context, agents, approvals, traceability.
P0	MAIC platform Terms	Multi-tenancy, privileged security, data ownership, third-party dependencies, AI uncertainty, human approval.
P1	PostgreSQL current documentation	SQL, indexes, transactions, concurrency, query planning, security, reliability, backups, replication, monitoring.
P1	OWASP ASVS 5.0	Software-engineering security verification baseline.
P1	OpenTelemetry docs	Vendor-neutral traces, metrics, logs, and instrumentation.
P1	GitHub Actions — CI	Automated test/build/release discipline.
P1	Docker — Get Started	Containers, reproducible environments, multi-service development.
P2	Fieldguide — AI Engineer (YC)	Example of 2026 applied expectations: agents, retrieval, evals, production reliability.
P2	Retell AI — Software Engineer, New Grad (YC)	How high the junior ownership bar has become at a fast-moving AI startup.
P2	item — Product Engineer (YC)	Product engineering + PostgreSQL + React/TypeScript + agent-first systems.
P2	AirCaps — Product Engineer (YC)	End-to-end AI product work, latency/reliability, multimodality, rapid iteration.

The path at a glance

Target profile: start from a real workflow, decide whether it needs deterministic code, retrieval, a model call, a workflow, or an agent; construct an evaluation set; implement the system; measure quality, cost, and latency; expose safe tools; control permissions; instrument it; and improve it from observed failures.

Planning horizon

~20 mo

4 stages + final graduation gate

Weekly commitment

12–15 h

~6–7.5 h of it building

Deliberate-study hours

1,040–1,300

estimate, not a promotion clock

Stages complete

0/4

check them off below

Gates passed

0/5

4 stage gates + graduation

The premise to keep in view

Applied AI is not “the easier engineering path because the model writes the hard code.” It is software engineering plus another failure surface: probabilistic model behavior. This path targets production Applied AI — not frontier model research (PyTorch/RL/CUDA/training-pipeline depth is a different specialization).

Assumed entry baseline — expand if not yet comfortable

Default stack: Python as the primary language, PostgreSQL, strong HTTP/backend skills, and enough TypeScript/React to integrate AI into real products.

Timeline

1 · SW + model fdn.

2 · Reliable AI apps

3 · Agentic systems

4 · Production AI

Graduation gate

Ranges are planning estimates. Advance when you can demonstrate the exit criteria — the month ending is not the gate.

Stages and exit gates

Software + model foundations

Months 0–3.5 · 12–15 h/wk Done

Production-grade Python plus enough ML literacy to reason correctly about what models do — and disciplined, direct use of vendor APIs.

Primary outcome: Understand what models do and build disciplined model-backed APIs.
Assessment gate: Model Gateway — one API fronting two model providers (or hosted + local/open).
Exit criteria: Explain why an output failed beyond “the model hallucinated” — distinguish model failure from retrieval, prompt/context, tool, application, and evaluation failure.

Curriculum

Production Python: typing, Pydantic/data validation, async I/O, package management, testing, dependency isolation, profiling, HTTP clients, FastAPI, PostgreSQL, and structured logging.

ML literacy: train/validation/test splits, overfitting, precision/recall/F1, ranking metrics, probability and calibration intuition, embeddings, vector similarity, tokenization, transformer architecture and attention at a conceptual level, inference vs. training, decoding, temperature, and context windows. Run and inspect pretrained/open models and do one small fine-tuning exercise so model behavior is not magical — but do not make training-from-scratch the center of this stage.

Vendor APIs directly, before frameworks: structured outputs, streaming, tool/function calls, usage accounting, retry/error handling, rate limits, model selection, and versioning.

Assessment — Model Gateway

Build one API supporting two model providers or one hosted + one local/open model. Required evidence: typed request/response schemas, streaming, retries, usage/cost tracking, and tests.

Pass: ≥99% schema-valid results across a 100-case structured-output test; provider failure triggers a documented fallback; cost/token usage recorded per request.

Gate passed

Reliable AI applications

Months 4–8 · 12–15 h/wk Done

The transition from prompt experimentation to AI engineering: retrieval and context systems that are evaluated quantitatively.

Depends on: Stage 1 gate passed
Assessment gate: Evidence Assistant — grounded QA over a synthetic 100+ document corpus.
Exit criteria: No merging a meaningful behavior change because “it looked better in five prompts” — show the eval dataset, baseline, new result, regression analysis, latency impact, and cost impact.

Curriculum

Retrieval and context: structured generation, classification/extraction, embeddings, semantic search, chunking, metadata, hybrid retrieval, reranking, document ingestion, citations, retrieval evaluation, context assembly, context compression, prompt templates, response validation, fallback behavior, caching, and model routing. Context engineering — selecting and maintaining the right instructions, tools, retrieved data, memory, and state at each step — supersedes narrow prompt engineering.

Evaluation as a first-class discipline: golden datasets; answerable vs. unanswerable cases; exact/semantic correctness; retrieval recall/precision; citation/support correctness; pairwise preference tests; regression suites; human annotation; model-based judges calibrated against human labels; and latency + cost per successful task.

Assessment — Evidence Assistant

Build grounded QA over a synthetic corpus of 100+ documents. Required evidence: ingestion, retrieval, citations, a 100+ case eval set, and answerable/unanswerable labels.

Pass: ≥90% supporting-citation precision on human-labelled cases; ≥90% correct abstention on unanswerable cases; no uncited factual answer in the designated “citation-required” mode.

Gate passed

Agentic systems

Months 9–14 · 12–15 h/wk Done

Safe tool-using workflows with state, approvals, and observability — and the judgment to know when an agent is not warranted.

Depends on: Stage 2 gate passed
Assessment gate: Operations Agent — read tools + proposed actions + approval-controlled write tools.
Exit criteria: Every consequential tool can answer: who may invoke it, what input is trusted, what the model sees, what side effect occurs, whether it is reversible and idempotent, who approves it, what is logged, and what happens if the model is manipulated.

Curriculum

Workflow vs. agent: workflows are sequences code determines; agents let the model dynamically decide how to proceed and which tools to use. Start with simple composable patterns and add autonomy only where it justifies the latency, cost, and unpredictability.

Tool design: schemas, clear names/descriptions, constrained arguments, typed responses, error messages that help recovery, read-vs-write separation, idempotency, timeout behavior, permission boundaries, token-efficient outputs, and test cases.

Orchestration: routing, prompt chaining, parallelization, evaluator/optimizer loops, manager/sub-agent patterns, handoffs, checkpoints, state machines, memory, context compaction, durable execution, and long-running tasks. Learn MCP conceptually and practically, including its consent, privacy, and access-control boundaries.

Security as a central topic: the OWASP GenAI risk model and Agentic Top 10 — behavior hijacking, tool misuse, identity/privilege abuse, excessive agency. Practice prompt injection, indirect injection through retrieved content, tool misuse, data exfiltration, tenant leakage, malicious tool descriptions, privilege escalation, output validation, memory poisoning, resource exhaustion, and approval bypass.

Assessment — Operations Agent

Build an agent with read tools, proposed actions, and approval-controlled write tools. Required evidence: tool schemas, workflow/agent loop, state, approval UI/API, adversarial tests, and traces.

Pass: 100% of sensitive write actions blocked without authorization/approval; zero cross-tenant disclosure in the adversarial suite; ≥90% correct tool/workflow choice across 100 held-out scenarios.

Gate passed

Production AI ownership

Months 15–20 · 12–15 h/wk Done

Optimize the system as an engineer rather than a demo builder: quality, cost, latency, security, rollout, feedback, and iteration.

Depends on: Stage 3 gate passed
Assessment gate: AI Workflow Service — an agent completing a multi-step business process.
Exit criteria: Operate an AI capability over time: diagnose regressions, locate the fix in code/context/retrieval/tools/model/data, and prove improvement on a pre-defined metric without unacceptable security, cost, or latency regressions.

Curriculum

Production levers: model routing on quality/latency/cost, fallbacks, rate-limit management, request queues, prompt/context caching, asynchronous generation, model/provider versioning, regression testing across upgrades, shadow evaluation, canary release, feature flags, feedback loops, online vs. offline evaluation, confidence and abstention strategies, and graceful degradation when a provider fails.

When fine-tuning is justified: better requirements → better evals → better context/retrieval/tools → better model selection → only then fine-tuning where a measured gap remains.

AI observability: trace the user request, retrieval calls, model requests, tool calls, retries, tokens, latency, cost, guardrail decisions, approvals, and final outcome — one correlation ID end to end.

Humans in the architecture: treat approval workflows as part of the system design — AI output may be incomplete or wrong, and consequential actions stay behind human approval.

Assessment — AI Workflow Service

Build an agent that completes a multi-step business process. Required evidence: evaluation harness, routing, retrieval/tools, fallbacks, OpenTelemetry, cost/latency reporting, and a security test suite.

Pass: ≥85% held-out task completion; zero unauthorized side effects; all failures classifiable from traces; predefined latency and cost budgets met — without tuning the budgets after seeing results.

Gate passed

Final graduation gate

Build a fresh Enterprise Operations Agent — roughly 60–80 hours across five to six weeks — in a domain you have not previously used.

Scenario — enterprise operations agent

Pick a domain: warranty claims, aviation-maintenance records, logistics exceptions, commercial underwriting, procurement reconciliation, or equipment-service tickets. The system receives structured and unstructured records, retrieves relevant evidence, reasons over entity relationships, proposes actions, calls tools, requests approval for sensitive operations, and writes results back to mock enterprise systems.

Graduation evidence requirements
Area	Graduation evidence
Problem definition	Written workflow decomposition identifying which steps are deterministic, retrieval-based, model-based, or agentic — and why.
Data/context	Document ingestion plus structured operational entities; explicit context-selection strategy.
Retrieval	Grounded evidence retrieval with citations and offline retrieval metrics.
Tools	Minimum five tools: at least two read-only, one computational/deterministic, and two state-changing.
Permissions	Tool-level authorization; state-changing tools separated from ordinary inference.
Human control	Sensitive actions require explicit approval; rejected actions cannot be bypassed by model output.
Evaluations	≥200 test cases: happy path, edge cases, unanswerable cases, tool failures, ambiguous inputs, adversarial inputs.
Quality	≥85% end-to-end success on the held-out ordinary-task set.
Grounding	≥90% of evaluated factual claims requiring evidence are supported by the retrieved/cited source.
Security	≥30 adversarial cases covering prompt injection, malicious retrieved text, tool abuse, data leakage, excessive agency, and approval bypass; zero successful unauthorized side effects.
Reliability	Retryable tool/provider errors recover automatically; non-retryable failures end in explicit recoverable state rather than silent corruption.
Observability	Request, context/retrieval, model calls, tools, approvals, token/cost usage, and final result traceable from one correlation ID.
Economics	A latency and cost SLO written before the final run, met on ≥95% of successful evaluation cases.
Operations	Model/prompt/config versions recorded; rollback to previous behavior demonstrated.
Communication	Architecture review plus written failure analysis identifying the five largest remaining risks.

Graduation rule

Automatic fail if any test produces an unauthorized consequential side effect, a cross-tenant disclosure, or a successful approval bypass. Of the remaining categories, at least 12 must pass. Judge the system by how predictable, measurable, recoverable, and controlled it is — not by how impressive the best response looks.

Graduation gate passed

What actually changes from junior to mid

On top of the standard junior→mid engineering loop, Applied AI adds a failure-classification loop inside it. Rubric synthesized from MAIC's public constraints and current frontier-startup expectations.

Mid-level loop

Problem → clarify constraints → design
Identify failure, security, and data boundaries
Implement → measure → deploy safely
Observe real behavior → diagnose → improve

The extra AI loop inside it

AI behavior → run evaluation
Classify each failure: model? context? retrieval? tool? data? prompt/instructions? deterministic app?
Apply the targeted change
Re-run the regression evaluation

Full competency rubric — junior vs. mid (19 dimensions)

Junior to mid-level competency matrix for applied AI
Competency	Junior	Mid-level
Problem scope	Implements a defined model-backed feature.	Converts a workflow into deterministic/AI components and defines success metrics.
Code ownership	Owns prompts/model calls/retrieval component.	Owns the complete AI capability from API through evaluation and operation.
Frontend	Can integrate a model-backed feature.	Can ship/debug the entire human-AI experience even if frontend is not the primary specialty.
Backend/API	Wraps model calls in APIs.	Designs production inference/tool APIs with rate limits, retries, fallbacks, structured outputs and observability.
Data modeling	Stores conversations/documents/embeddings.	Designs provenance, metadata, eval datasets, retrieval structures, agent state and tenant-safe context.
SQL/performance	Writes working queries.	Understands DB behavior well enough to prevent the AI layer from hiding ordinary systems bottlenecks.
Testing	Tests deterministic wrapper code.	Maintains eval + regression suites alongside deterministic tests.
AI evaluation	Creates small prompt/eval examples.	Owns golden datasets, metrics, regressions, human review and quality gates.
Retrieval/context	Builds straightforward RAG.	Diagnoses ingestion, retrieval, ranking, context and answer-generation failures separately.
Agents/tools	Creates simple tool calls.	Decides workflow vs. agent; designs tools, permissions, state, recovery, HITL and agent evaluations.
Security	Avoids obvious prompt/data leakage.	Threat-models prompt injection, tool abuse, excessive agency, tenant leakage, memory/retrieval attacks and approval bypass.
Reliability	Retries failed model requests.	Handles model/tool/provider failures, version regressions, fallbacks, partial completion and safe degradation.
Observability	Logs prompts/responses during development.	Traces context, models, tools, cost, tokens, latency, approvals and outcomes end-to-end.
Performance	Notices slow model responses.	Balances model quality, context size, tool count, latency, throughput and cost.
Deployment	Deploys a model-backed service.	Owns prompt/model/config versioning, staged rollout and AI regression rollback.
Architecture	Uses a known RAG/agent pattern.	Chooses simple call vs. retrieval vs. workflow vs. agent vs. fine-tuning based on evidence.
Product judgment	Optimizes output quality.	Optimizes task success, not model cleverness; knows when AI should not be used.
Independence	Requires guidance on architecture/evaluation.	Owns a bounded AI problem independently from discovery through post-deployment improvement.
Communication	Explains prompts/models.	Explains model-system behavior, eval evidence, risks and constraints to technical and nontechnical stakeholders.
AI-native development	Uses LLMs to prototype.	Uses agents/coding systems to increase experiment velocity without confusing generated code with validated engineering.

Weekly rhythm

At 12–15 hours per week, roughly 6–7.5 hours should be spent building — not watching courses.

Recommended share of weekly time

Weekly time allocation
Activity	Share of weekly time
Building	50%
Docs & study	20%
Testing & eval	15%
Design & review	10%
Retro notes	5%

The rule that makes this path work

Every substantial AI experiment must end with a result table: experiment, baseline, dataset/eval-set version, model, prompt/context/tool version, task-success metric, failure categories, latency, cost, regressions, and the decision. That habit matters more than memorizing another orchestration framework.

Resources and source priority

Primary specs and documentation define how the technology works; startup job pages only tell you what the frontier currently values. Filter by priority.

Priority

Recommended resources by priority
Priority	Resource	Use it for
P0	MAIC — About / platform	The real target environment: operational apps, connected systems, ontology/context, agents, approvals, traceability.
P0	MAIC platform Terms	Multi-tenancy, privileged security, data ownership, third-party dependencies, AI uncertainty, human approval.
P1	Anthropic — Building Effective Agents	Workflow vs. agent distinction, simplicity, orchestration, human oversight.
P1	Anthropic — Effective Context Engineering	Context selection/state as a core AI-engineering problem.
P1	Anthropic — Writing Effective Tools for Agents	Tool interface design and eval-driven tool improvement.
P1	OpenAI Agents SDK	Agents, tools, handoffs, guardrails, sessions, HITL, tracing, sandbox execution.
P1	Hugging Face Transformers	Transformer/model fundamentals, inference and training.
P1	Hugging Face LLM Course	Structured path from transformer foundations through datasets, fine-tuning, reasoning.
P1	Hugging Face smolagents	Minimal agent patterns, tool calling, code agents, sandbox concepts.
P1	Model Context Protocol specification	Standardized model/tool/resource integration and its security boundaries.
P1	OWASP GenAI LLM Top 10 (2026)	Prompt injection, information exposure, excessive agency, resource abuse, other LLM-system risks.
P1	OWASP Agentic AI security guidance	Tool misuse, agent hijacking, privileges, autonomous-system risks.
P1	Shared baseline: PostgreSQL, OpenTelemetry, GitHub CI, Docker	The same engineering backbone as the Software Engineering path — Applied AI is software engineering plus a probabilistic failure surface.
P2	Fieldguide — AI Engineer (YC)	Example of 2026 applied expectations: agents, retrieval, evals, production reliability.
P2	SID — Research Engineer (YC)	Contrast point: when PyTorch/RL/CUDA/model-training depth becomes central — a different specialization.