Plan & design
BEFOREA broad “clean up the code” request and assumptions about existing behavior.
AFTERA bounded change hypothesis, dependency map, characterization tests, and maintainer-approved contracts.
NEW COURSE · INTEREST LIST OPENEnterprise FDE Lab
Enterprise FDE Lab
with Claude.
Keep your engineering depth.
Expand the outcomes you can own.
Learn to discover a business problem, direct Claude’s work, and deliver an evaluated enterprise change through your organization’s software development lifecycle. Choose software refactoring, Salesforce, SAP, or Workday as your focus.
For experienced developers. Cohort dates, format, and pricing discussed before commitment.
FOUR VARIATIONS · ONE SHARED STANDARDYour platform. Your problem.
Your platform. Your problem.
A more capable engineer.
Choose one specialization. Explore the work you will do, the evidence you will produce, and what changes in your delivery lifecycle.
40hShared methods
Weeks 1, 2, 6 & 7
Weeks 1, 2, 6 & 7
40hYour specialization
Weeks 3, 4, 5 & 8
Weeks 3, 4, 5 & 8
80hTotal commitment
8 weeks · 10h per week
8 weeks · 10h per week
The same project runs through all eight weeks. Specialized exercises replace the general lab work in the four indicated weeks; they are included in the 80 hours. Completing all four specializations is outside this commitment. Thinkerland designed the capstones, effort allocation, and learning gates below; they are planned learning targets, not vendor curricula or measured participant outcomes.
Software refactoring
Choose this track Preserve behavior. Improve the system.
Use Claude to investigate a codebase, reduce a bounded source of complexity, and prove that agreed behavior survives the change.
YOUR CAPSTONE
Refactor one legacy service without breaking its contract.
Choose a difficult change path with its maintainer. Establish characterization tests, isolate a dependency, and refactor in small reviewed increments. Preserve public interfaces, authorization rules, and business semantics. Demonstrate how to revert the change.
Measure the difference: Compare an agreed follow-up change before and after: implementation time, review and rework, regression results, and a specific maintainability target. If performance matters, use the same workload and environment. Fewer lines alone is not evidence of improvement.
SDLC before & afterWhat changes in software refactoring
Illustrative starting patterns and target practices. Your baseline is measured in week one; these are not claims about every team.
Build
BEFOREA large rewrite that mixes behavior changes with structural edits.
AFTERClaude-assisted, reviewable increments; the engineer inspects diffs and preserves agreed semantics.
Test
BEFOREThe existing suite passes and a manual smoke test looks right.
AFTERBehavioral, contract, permission, failure, and relevant performance checks compare the same baseline.
Release & maintain
BEFOREMerge the cleanup and discover downstream effects later.
AFTERA reversible release, consumer evidence, maintainer handoff, and a measured follow-up change.
Behavioral practice in this trackA 20–30 minute decision and peer-review exercise
The scenario
Claude proposes a cleaner implementation, but a prepared characterization test reveals a changed business rule. A stakeholder still wants the cleanup shipped quickly.
Your decision and practice
Question the assumption that cleaner code is a better outcome. Explain the affected contract to a peer, compare a small reversible change with a rewrite, and decide what to reject, revise, or escalate. Keep intended behavior changes separate from refactoring.
Evidence for peer review
Record the decision, the failing case, and the selected next step. A peer checks whether you used the evidence, preserved the agreed behavior, and made the tradeoff understandable to the maintainer.
Use prepared or synthetic project evidence during the existing discovery or peer-review hours. The exercise is included in the 80 hours; it does not establish proficiency by itself. Explore all eight behavioral capabilities.
Your four specialization weeks40 hours within the shared eight-week syllabus
- W3 · 10h
Map and characterize
Dependency map, critical behavior inventory, characterization tests, and a reproducible baseline.
- W4 · 10h
Refactor incrementally
Two small reviewed changes with preserved contracts and an explanation of alternatives rejected.
- W5 · 10h
Prove compatibility
Consumer/contract checks, authorization and failure tests, and migration or compatibility notes where needed.
- W8 · 10h
Defend the improvement
An unfamiliar maintenance change, before/after evidence, maintainer review, and demonstrated rollback.
Weeks 1 and 2 establish the problem and design. Weeks 6 and 7 evaluate and rehearse release and recovery. Apply those shared methods to this same capstone.
What must passTrack evidence, in addition to the common assessment rubric
- All agreed behavior, security, and consumer-contract checks pass; any intended behavior change is separately approved.
- Tests detect a deliberately introduced regression. The engineer explains why the tests are sufficient for the bounded scope.
- The maintainability target agreed in week two is demonstrated, with review and rework included in the evidence.
- The maintainer can reproduce the build, understand the new boundary, and follow the recovery procedure.
These are Thinkerland’s proposed learning gates. The common 80/100 standard, independent walkthrough, and critical-security requirements still apply. No performance gain or vendor certification is promised.
Boundaries & platform referencesOfficial documentation reviewed October 19, 2026
One bounded refactoring, not a full rewrite or migration. Claude supports engineering decisions; the maintainer owns behavior and release acceptance. Production rollout and foundational language training are outside the 80 hours.
These official references support the platform practices described here. They do not establish vendor endorsement, a training partnership, or certification of this course.
ENGINEERING EXPERIENCE IS YOUR STARTING POINTMove closer to the problem.
Move closer to the problem.
Take responsibility for the result.
A forward-deployed engineer works with the people doing the work, translates their needs into systems, and stays involved through evaluation and adoption.
A working business capability
One bounded refactoring, platform extension, or AI workflow in an approved nonproduction environment, with verified behavior and predictable failure handling.
Show: a running capstone and reviewed code.A stronger way to deliver
A repeatable approach to context, delegation, verification, integration, and release that fits the team’s existing responsibilities.
Show: your SDLC before/after and delivery evidence.A decision others can trust
Evaluation results, user feedback, operational costs, unresolved risks, and a handoff that a receiving engineer can reproduce.
Show: a defensible pilot, revise, or stop recommendation.CAREER CAPABILITY, PRACTICED THROUGH WORK
From interpreting requests to investigating outcomes. From individual implementation to bounded delegation. From reviewing code to evaluating a whole system. From handing over a feature to helping a team adopt and operate it.
The intended development is in curiosity, systems thinking, technical judgment, and communication. Progress requires observed evidence; completion does not guarantee a new role, job, or promotion.
HUMAN CAPABILITY · PRACTICED IN THE CLAUDE FDE LABBetter questions. Sounder judgment.
Better questions. Sounder judgment.
More accountable work.
Tools are one part of the work. Practice how you investigate, reason, adapt, challenge, and collaborate through eight Thinkerland practice areas. Choose one to see the exercises and the observable evidence used for feedback.
Curiosity
Investigate before you propose.
Ask questions that could overturn your first explanation. Listen to how people do the work, then check the story against code, data, or observed behavior.
FROM A HABIT TO QUESTIONPitching the first plausible solution
TO A PRACTICE TO BUILDTesting the assumptions behind the request
When you exercise it
- W01
Interview two stakeholders, or use a clearly labeled course simulation, without presenting your solution. Record one question whose answer could change the scope.
- W02
Compare your preferred approach with a credible alternative, including leaving the workflow unchanged.
- W05
Investigate an unfamiliar interface. Verify the assumptions Claude makes about its behavior and permissions.
- W08
Ask the receiving team what remains unclear, and revise or defend the handoff using their evidence.
Evidence you bring to review
An assumption ledger showing the question, source or observation, and a decision to revise or retain the assumption.
What your reviewer looks for
- At least one question seeks disconfirming evidence.
- The learner separates an observation from an interpretation and explains what changed—or why it did not.
Which answer could have changed your decision, and where did you look for it?
Supports the existing capstone rubric: Business discovery.
Practice → feedback → another attempt.
Behavioral exercises are embedded in the existing business discovery, engineering, peer-review, and reflection time. One exercise or artifact can demonstrate several capabilities; these are not additional assignments. The course remains 80 hours. Technical fluency and business acumen are broader capabilities; here we make the behaviors within them observable. Each specialization includes a concrete decision exercise.
How we review developmentObservable evidence, rather than a personality label
WEEK 1
Establish a starting point
Observe a bounded task and discuss prior evidence. Record support needed and what has not yet been observed.
WEEK 4
Review and practice again
Compare artifacts, observed actions, and reviewer notes. Choose one specific behavior to practice next.
WEEK 8
Demonstrate and explain
Use the capstone, unfamiliar change, and handoff to review current evidence and agree the next development step.
These are developmental feedback checkpoints within existing work. Formal capstone reviews remain in weeks 2, 4, 6, and 8.
1
Explain with guidance
Recognizes the behavior and explains its purpose with prompting.
2
Apply with support
Uses the behavior on a familiar task with a checklist, prompts, or coaching.
3
Apply independently
Uses it appropriately, explains the decision, and supplies evidence without prompting.
4
Transfer & coach
Uses it in an unfamiliar case and helps another person apply it.
“Not yet observed” is separate from these four levels. Missing evidence is not zero ability. Self-reflection and reviewed observations stay distinct. Feedback cites an action, a work artifact, and a reviewer note; task difficulty and support provided are part of the context.
This is Thinkerland’s proposed developmental framework, not a validated measure of personality, intelligence, or cognitive ability. It adds no extra points or examination to the capstone rubric. No individual scores are collected here. Actual before/after profiles require observed learner evidence; no upward growth is assumed. The four feedback levels are course guidance, not an Anthropic competency standard.
THE SOFTWARE DEVELOPMENT LIFECYCLEThe same responsibility.
The same responsibility.
A different way of doing the work.
Explore six stages. These are Thinkerland’s target practices and starting patterns to investigate, not a diagnosis of every engineering team.
BEFORE / A PATTERN TO EXAMINE
Plan today
A ticket describes a requested feature; its business assumptions may stay implicit.
AFTER / THE PRACTICE YOU BUILD
Plan with Claude
The engineer investigates the workflow with users and uses Claude to challenge and clarify a bounded brief.
Evidence you produceProblem brief + baseline + acceptance criteria
Accountability stays explicitBusiness owner accepts the outcome and scope.
Measure the change: Clarification loops, discovery time, and requirement changes after build starts.
Your enterprise controls stay in force. Learn to make evidence easier to produce and inspect. Changes to approval policy require the organization’s owners; the course does not authorize an agent to bypass them.
Compare similarly scoped work and include review, rework, waiting, and operating cost. Report differences in task complexity and learning effects. No percentage improvement is promised, and a classroom comparison cannot establish causation.
PROTECT TIME FOR THE WORKTen hours a week.
Ten hours a week.
Practice is part of the commitment.
The planned core format is eight weeks and 80 learner hours. The capstone, preparation, review, and discovery are included in that estimate.
2h Guided workshop
Concepts, live demonstration, and design critique.
4h Independent engineering
Build, debug, test, and improve your capstone.
2h Business discovery
Interview, map work, test with users, and investigate adoption.
1h Peer review
Inspect another engineer’s code and evidence.
1h Evidence & reflection
Record results, explain decisions, and prepare the checkpoint.
What you bring
- Experience independently writing, debugging, and shipping software.
- Working knowledge of Git, APIs, tests, CI/CD, and application security. TypeScript or Python is useful for the reference exercises.
- Approved Claude Code access, a permitted repository, and non-sensitive test data. Claude API access is needed only if your chosen project uses runtime AI. Platform-specific prerequisites are listed in each specialization.
- Willingness to interview users, accept critique, and explain your code without relying on the model.
What your organization supports
- Protected learner time; this should not quietly become an extra job.
- A named problem owner and process expert. Plan about one hour a week of their time for discovery and feedback.
- An engineering or security reviewer for four checkpoints. Plan one hour per checkpoint; this is additional staff time.
- Approved tools, sandbox access, and a usage budget. Licenses, API/cloud costs, and production rollout effort are scoped separately.
A clear finish line, with honest limits.
Confirm platform access and prerequisites before enrollment; week one verifies the setup. Missing fundamentals, access delays, or remediation may require extra time. A sanitized case can replace employer data, but does not replace required platform access. Mocked integrations must be labeled. Production approvals, deployment, and sustained business impact are outside the 80-hour core plan.
EIGHT WEEKS · TEN HOURS PER WEEKOne project.
One project.
Increasing responsibility.
Each week produces evidence that the next week uses. These are the common outcomes; your selected track supplies the specific exercises for weeks 3, 4, 5, and 8. Open a module to see the practice, output, and checkpoint.
W01Discover the work. Establish the baseline.Plan · 10h
Turn an operational problem into a bounded engineering experiment with a named business owner.
What you practice
Interview two stakeholders or use a clearly labeled case simulation. Map tasks, exceptions, data, and decisions. Reproduce the starter application and record the current delivery process before using Claude on a comparable change.
What you produce
Problem brief, current workflow, baseline record, repository setup, data permissions, and explicit non-goals.
What must be demonstrated
The problem owner agrees on a measurable outcome and permitted scope. No approved employer project? Use the course sandbox and label simulated evidence.
W02Design the solution and the delegation boundary.Design · 10h
Explain when to use a rule, a model call, or an agent—and what remains a human decision.
What you practice
Use Claude to investigate the repository and propose alternatives. Review an architecture decision, context instructions, tool permissions, and evaluation targets before implementation. Separate repository guidance from controls enforced by code.
What you produce
Reviewed design and implementation plan, CLAUDE.md, permission matrix, data-flow model, and pre-agreed quality/cost limits.
What must be demonstrated
An engineering reviewer can explain the risks, reject a weak option, and identify who owns each approval.
W03Direct Claude Code. Own the change.Build · 10h
Deliver a small, reviewable change in an existing codebase and independently establish that it works.
What you practice
Break work into bounded tasks. Supply useful context, inspect diffs, and run meaningful tests. Practice fixing a regression and rejecting a plausible but incorrect implementation. Use isolated branches for parallel work only when dependencies permit it.
What you produce
Two reviewed pull requests, a regression test that fails before the fix, review comments, and an explanation of the resulting code.
What must be demonstrated
The engineer can debug and explain the change without asking Claude to defend it. Generated tests are reviewed for adequacy.
W04Build the capability. Enforce its boundaries.Build · 10h
Implement the bounded capability in your selected track, with explicit authorization and failure behavior.
What you practice
Use the track’s refactoring or platform exercises. Define contracts, validate inputs and outputs, handle retries, and preserve approval for consequential actions. If runtime AI is justified, use the Claude API and optionally the Agent SDK with bounded tools, execution, and cost. Compare against a simpler conventional implementation.
What you produce
Running capability, reviewed contracts, authorization evidence, failure tests, and applicable operating-cost assumptions.
What must be demonstrated
The capability preserves approved behavior and handles denial and failure safely. Model output cannot grant itself authority.
W05Integrate into an enterprise boundary.Integrate · 10h
Verify an enterprise interface or dependency without weakening identity, authorization, data ownership, or existing behavior.
What you practice
Verify the selected track’s consumer contract, platform interface, or approved API adapter. Review MCP only where appropriate. Test least privilege, revoked access, failures, and log redaction. Treat external text as untrusted. Label simulations when real integrations are not authorized.
What you produce
Verified interface, access-denial and compatibility tests, threat model, and unresolved-risk register.
What must be demonstrated
No secrets in source or logs. No access beyond the approved identity. A simulated connection is never presented as a live integration.
W06Evaluate behavior, not a convincing demo.Test · 10h
Make a repeatable release recommendation from correctness, safety, cost, and latency evidence.
What you practice
Build at least 30 meaningful cases: 20 representative, five edge/failure, and five adversarial or unauthorized-access cases. Use code-based checks and human review where judgment is required. For runtime AI, also keep a held-out subset, repeat selected cases, inspect traces, and record model, prompt, and tool versions when comparing configurations.
What you produce
Versioned verification set, behavior and failure report, relevant performance/cost evidence, and limitations. Runtime-AI projects also report task success, latency distribution, and cost per successful task.
What must be demonstrated
Meet the thresholds agreed in week two and pass every safety-critical case. Thirty cases are a learning minimum, not proof of production safety.
W07Release through controls. Rehearse recovery.Deploy & maintain · 10h
Deploy to an approved nonproduction environment and demonstrate a controlled recovery.
What you practice
Integrate checks into the existing CI/CD process and rerun evaluations when model, prompt, or tool versions change. Review changes by risk, preserve required human sign-offs, redact telemetry, set operational limits, and rehearse a dependency outage and rollback. Avoid granting the coding agent production credentials.
What you produce
Pipeline evidence, staging release, dashboards or trace samples, rollback rehearsal, cost limits, and support runbook.
What must be demonstrated
A reviewer can reproduce the release and recovery. The release owner retains authority to promote, hold, or stop.
W08Defend the outcome. Transfer the capability.Prove & hand over · 10h
Demonstrate the solution, respond to an unfamiliar change, and defend a pilot, revise, or stop recommendation.
What you practice
Run an observed unfamiliar practical with approved Claude use and trace review, then a code walkthrough without AI assistance. Compare before/after delivery evidence, including review and rework. Gather user feedback, explain changed responsibilities, and teach a receiving engineer to operate the solution.
What you produce
Working capstone, assessed change, SDLC comparison, handoff acceptance or gaps, and a 30/60/90-day pilot plan.
What must be demonstrated
Explain what is observed, simulated, and still uncertain. A justified no-go decision can pass; an unverified success claim cannot.
EVIDENCE, EXPLANATION, AND JUDGMENTYou pass by demonstrating.
You pass by demonstrating.
Attendance is not the outcome.
The proposed assessment standard is published up front. Four reviews—after weeks 2, 4, 6, and 8—make the expectations visible.
Business discovery
A bounded problem, credible baseline, user evidence, and a reasoned value hypothesis.
points
Engineering judgment
Understandable implementation, sound architecture, useful tests, and independent debugging.
points
System reliability
Repeatable verification, preserved contracts, failure handling, and relevant performance/cost evidence; runtime AI also requires model evaluations.
points
Security & delivery
Enforced permissions, reviewed data flows, traceable release, and demonstrated recovery.
points
Adoption & handoff
Changed roles, receiving-team understanding, support ownership, and an honest pilot recommendation.
points
Each dimension uses a 0–4 rubric: absent, explained only, demonstrated with gaps, independently reproducible, or transferred and defended. Multiply by five for the 20-point score. These thresholds and the 30-case learning minimum are Thinkerland’s proposed course criteria, not a vendor certification standard or a statistical guarantee of production reliability.
GENERAL ENTERPRISE EXAMPLE / OPERATIONS EXCEPTION TRIAGE
From incoming exception to a reviewed next action.
Use synthetic cases to classify an operational exception, retrieve permitted context, propose a resolution, and request a human decision. Demonstrate missing data, hostile input, a denied action, an integration outage, and a recoverable failure. The workflow must leave an audit trail without leaking sensitive data.
This is an optional runtime-AI example for a general enterprise project. The four specializations above provide their own capstones within the same 80 hours. Acceptance criteria and regulatory review depend on the organization. None of these examples imply a live customer deployment.
TWO DIFFERENT USES OF CLAUDEBuild with Claude.
Build with Claude.
Choose where AI belongs.
The distinction matters: a coding agent helps create software; a runtime agent becomes part of the system you must evaluate and operate. Refactoring and platform extensions can use Claude during development without adding AI to the resulting application.
DEVELOPMENT
Claude Code
Repository investigation, implementation, debugging, and verification. Practice concise context, reusable skills, bounded permissions, and independently enforced checks.
APPLICATION BEHAVIOR
Claude API & Agent SDK
Optional runtime model and tool behavior when justified by the project and approved by the organization. Use the SDK where it fits; a conventional implementation is appropriate when that better serves the problem.
YOUR ENTERPRISE
The existing delivery stack
Your source control, CI/CD, identity, observability, and approved integrations. MCP is an integration option requiring review, not automatic permission to connect anything.
Already an enterprise developer? This course builds on that foundation. Business professionals learning engineering fundamentals can explore the Business-to-FDE Leadership Lab. The Microsoft and Google developer pathway remains available.
WHAT WE LEARNED FROM ANTHROPICCurrent practice.
Current practice.
Our own learning design.
Sources reviewed October 19, 2026. Anthropic’s public work informs the practices. The 80-hour format, assignments, rubric, and intended learning outcomes are Thinkerland’s design.
Anthropic announced Claude Frontier Academy on October 2, 2026. Its program combines an assessed enterprise simulation with a 12-week workplace residency and a further assessment. That reinforces our view that applied work and demonstrated judgment belong at the center of FDE learning.
Thinkerland’s shorter core lab ends at an evaluated nonproduction solution and pilot recommendation. It is an independent program, not Anthropic’s residency, an equivalent credential, or an endorsed or licensed course. The platform specializations are also independent Thinkerland offerings, not Salesforce, SAP, or Workday certifications or endorsements.
Official sources support the cited tool capabilities and engineering practices. The schedule, exercises, behavioral framework, case counts, and pass thresholds are Thinkerland design choices, not Anthropic standards or evidence of achieved learner outcomes.
01
Anthropic · October 2, 2026
02Claude Frontier Academy
Assessed enterprise simulation followed by a 12-week employer-project residency. This is Anthropic’s separate, nomination-based program.
Anthropic · August 21, 2026
03The AI-native SDLC playbook
Practices across planning, design, building, testing, deployment, and maintenance, with accountable human decisions.
Claude Code documentation
04Claude Code best practices
Context, exploration, planning, and ways to verify the work produced by a coding agent.
Anthropic · July 21, 2026
05Securing the AI-native SDLC
Layered safeguards and the distinction between instructions and enforceable controls.
Anthropic · January 9, 2026
06Demystifying evals for AI agents
Evaluation design, graders, transcripts, and learning from observed failures.
Claude Academy
07Build with Claude
Vendor learning resources for Claude Code and the Claude developer platform; useful preparation alongside the applied lab.
Claude Code documentation
Claude Agent SDK overview
Programmatic agent-building tools. Optional in this lab when a project justifies runtime AI; availability does not replace application authorization, testing, or operational review.
BRING YOUR EXPERIENCE. MAKE ROOM FOR THE NEXT CAPABILITY.Your next role starts
Your next role starts
with the work you can own.
Tell us about your engineering background, your team, and a workflow worth improving. We’ll discuss readiness, cohort format, scheduling, access, and pricing before you decide.
Register your interest
Interest only. No payment or seat reservation.