Skip to content

    Forward Deployed Engineer

    90-Day Practice Plan for Enterprise AI Design

    A 90-day plan to deepen enterprise AI design skills with three projects of rising difficulty, a weekly design review, incident study and primary-source reading.

    By Published 6 min read

    • fde
    • solution-architect
    • practice-plan
    • design-review
    • incident-study
    • mastery
    Share

    This lesson is part of AI Solution Architect: Estimate, Propose and Defend. Enroll for free, then sign in, to read it in full.

    What you'll learn: a 90-day plan that follows this card: three projects of rising difficulty, a weekly design review, an incident-study habit, a short list of primary sources, and the evidence you keep.

    At a glance

    Figure 1. The weekly practice loop

    flowchart LR accTitle: The weekly practice loop accDescr: Work on the current project, hold a design review on the week's design, study one public incident review, read one primary source, record the evidence in a log, and return to the project with a changed checklist. A["Build the current project"] --> B["Design review: seven steps, 60 minutes"] B --> C["Study one incident review"] C --> D["Read one primary source"] D --> E["Record evidence and checklist changes"] E --> A

    How to read this: the loop repeats weekly; each pass leaves one written checklist change.

    • Three projects in about 13 weeks, each harder than the last.
    • One design review and one incident review a week.
    • Expertise comes from repeated delivery; this plan starts the repetition.

    Scenario

    Composite scenario, not a real company. A typical reader, a backend engineer at a mid-sized firm, finishes the card and scores 11 of 14 on the blank-page defense. There is no AI project at work yet, and about five free hours a week (illustrative).

    What you will be able to do

    • Choose a project that targets your weakest criterion.
    • Run a 60-minute design review on any design, yours or public.
    • Turn a public incident review into a checklist line.

    Prerequisites

    Core ideas

    The 90 days

    Weeks Activity Evidence you keep
    1 to 2 Repeat your lowest rubric criterion on two new briefs (the optional labs) Two scored sheets
    3 to 5 Project 1 Repository, golden set, evaluation report
    6 to 9 Project 2 Failure tests, approval demo, decision records
    10 to 13 Project 3 Threat model, trace sample, one-page briefing
    Every week Design review, incident study, one reading Review notes

    Three projects of rising difficulty

    Project What it proves Done when
    1. A read-only assistant over documents you may use, with citations and refusal You can ground answers and measure them 30 or more golden questions, some unanswerable, with before and after scores
    2. A workflow that calls an API you control, with human approval and a log You can make actions safe and test failures Timeout, duplicate and bad-input tests pass; no write runs unapproved
    3. A multi-user system with access control, tracing, a budget and a small real pilot You can operate what you design A few real users for two weeks, a threat model, a tested rollback

    Keep projects small. Project 2 draws on reliability and scaling, project 3 on LLMOps and governance.

    The weekly design review (60 minutes)

    1. Pick a design: a lab brief, your own project or a published architecture write-up.
    2. Run the seven steps for 30 minutes, with the threat-modeling lesson beside you.
    3. Defend it aloud for 15 minutes, score it, and write three lines: what was weak, what to check, what to read.

    The incident-study habit

    Once a week, read one public post-incident review of a real service. Read the review itself, not a summary.

    Figure 2. From an incident review to a checklist line

    flowchart LR accTitle: Incident study routine accDescr: Read a published incident review, list the contributing causes, find how it was detected, ask which control would have limited it, check whether your own design has that control, and add a line to your checklist. A["Read the review itself"] --> B["List contributing causes"] B --> C["How was it detected?"] C --> D["Which control would have limited it?"] D --> E["Does my design have it?"] E --> F["Add one checklist line"]

    How to read this: you end with a change to your own checklist, not an opinion.

    Read blamelessly. The Google site reliability engineering (SRE) book says a truly blameless postmortem focuses on contributing causes "without indicting any individual or team".

    Reading list: primary sources

    Source Read it for
    Anthropic, Building effective agents Workflows versus agents; start simple
    Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks The paper that proposed retrieval-augmented generation (RAG)
    NIST, AI Risk Management Framework A voluntary framework for managing AI risk
    OWASP, Top 10 for LLM Applications A risk list for large language model (LLM) applications
    Google, Postmortem Culture Reading and writing incident reviews

    What this plan does and does not give you

    Expertise comes from repeated delivery: designing, shipping, watching it fail and fixing it. A course, score or plan cannot replace that, and completing this card does not make anyone an expert or guarantee a job.

    The card aims at practitioner-level ability to design, build and defend an enterprise AI solution from a blank page. The 90 days deepen it through real projects.

    Worked example

    Predict first. A reader scored 1 on evaluation plan and 2 on everything else. Which project should weeks 3 to 5 use?

    Answer

    Project 1. Its done-when condition, a golden set with before and after scores, targets the weak criterion; a reader weak on measurement gains most from the project that forces it.

    Assumptions: five hours a week and a 13-week calendar are illustrative.

    Practice task

    Write your own 90-day plan, the last artifact of your design pack.

    1. Take your seven scores from the blank-page defense and mark the lowest.
    2. Fill the table, choose a project 1 domain and date weeks 1 to 13.
    Field Your entry
    Lowest criterion
    Project 1 domain and start date
    Weekly slots (project, review, reading)
    Evidence folder and first reviewer

    In the interview: "How do you keep your skills current?" Strong: a routine and its evidence, not a list of courses.

    Plan your 90 days (interactive when JavaScript is on)

    A design had no failure path. Which project for weeks 6 to 9?

    • Project 1, read-only assistant
    • Project 2, workflow with failure tests
    • Project 3, multi-user system
    Answer

    Project 2, workflow with failure tests. Project 2 passes timeout, duplicate and bad-input tests.

    You read an incident review and write: the team was careless.

    • Read blamelessly; list causes; add one checklist line
    • Blame shows the lesson
    • Read a summary instead
    Answer

    Read blamelessly; list causes; add one checklist line. The output is a checklist line, not an opinion.

    A friend plans one large project to finish in week 13.

    • Good, it shows more
    • Add a fourth project
    • Split into three small projects
    Answer

    Split into three small projects. Large projects often stall.

    Exercise

    Explain it back. In three sentences, tell a manager why you chose three small projects and a weekly review over another course: the gap, the evidence and the time.

    Done when your explanation names one deliverable per project.

    Hint 1: start from the gap

    Projects test designs against failure.

    Hint 2: be concrete

    Name three deliverables, such as an evaluation report, a failure-test suite and a threat model.

    Common mistakes

    • Starting one large project that is never finished.
    • Reading incident reviews for blame, not causes and controls.

    Knowledge check

    1. Why must project 1 include unanswerable questions in its golden set?

    Without unanswerable questions you cannot measure whether the assistant invents answers instead of refusing, a failure customers notice quickly.

    2. Why does project 3 need real users, however few?

    Real users bring unplanned inputs, access mistakes and changing requests. A system tested only by its author has not met them.

    3. What do you do with an incident review beyond reading it?

    List its contributing causes, check how it was detected, and ask whether your design has the control that would have limited it. The output is one checklist line.

    4. Why keep a log of evidence for each project?

    Evidence lets a colleague check progress; a claim without a golden set, test results or a threat model is an opinion.

    5. Does finishing the card make you an expert?

    No. It aims at practitioner-level ability to design, build and defend a solution from a blank page; expertise comes from repeated delivery.

    You can now

    • Add a 90-day practice plan to your design pack.
    • Run a 60-minute design review on any design.
    • Turn an incident review into a checklist line.

    Further reading

    Last verified: 2026-11-03

    Next

    This is the last core lesson of the AI Solution Architect card. Test yourself with the quiz and practice exam, then try the first optional lab, Lab: support-ticket triage assistant.

    Enroll to keep reading

    Lesson 10 of 15 · AI Solution Architect: Estimate, Propose and Defend

    A 90-day plan to deepen enterprise AI design skills with three projects of rising difficulty, a weekly design review, incident study and primary-source reading.

    In the rest of this lesson

    • Worked example
    • Practice task
    • Exercise
    • Common mistakes
    • Knowledge check
    • You can now

    Enrolling is free. It unlocks every lesson in AI Solution Architect: Estimate, Propose and Defend, tracks your progress across devices and keeps your quiz scores. The newsletter is optional.

    Ask about this article

    Get answers grounded in this post. AI-generated — based on this article, and may be imperfect.

    Scaled AI Weekly

    Enjoyed this? Get more like it every Monday.

    Real architecture decisions, LLMOps patterns that survive production, and engineering leadership advice — from 12+ years of building at enterprise scale. Free. No spam. Unsubscribe anytime.

    Get new articles by email

    Free. We email a confirmation link first, and you can unsubscribe from any email.

    Join engineers building production AI systems

    Comments