AI engineering resources for shipping your first feature
In short: Choose AI engineering resources by the production artifact each helps you produce: courses for practice, creators for technique, newsletters for change.
The Hugging Face Agents Course syllabus, as inspected on 30 September 2026, puts three frameworks in its second unit, a final project in its fourth, and tucks observability and evaluation into a bonus unit. That ordering is honest: a course is for practice with tools, and the bonus unit is where production actually lives. Full Stack Deep Learning's LLM Bootcamp, dated spring 2023, has the opposite shape: an LLMOps lecture and an application walkthrough, with examples old enough to need a compatibility check before you run them.
So the method for choosing AI engineering resources is not a ranking. Select each one for the production capability it helps you demonstrate. Courses are for practice on a bounded exercise. Creators' write-ups are for techniques you can lift into your own code. Newsletters are for tracking what changed since you last looked. A learning plan that uses each for its job, and attaches one observable artifact to every stage, gets a first feature shipped; a plan that ranks them produces a reading list.
Four resources, four jobs
| Resource | Job | Prerequisites | What was inspected | Access | What to build from it |
|---|---|---|---|---|---|
| Hugging Face Agents Course | hands-on practice with agent frameworks | Python, basic API calls | syllabus: three frameworks (unit 2), final project (unit 4), eval bonus unit | free course; some runs need model API or GPU access | one agent with a bounded tool set and a trace you can read |
| FSDL LLM Bootcamp (spring 2023) | the end-to-end application shape, incl. LLMOps | some ML background | lecture list incl. LLMOps and app walkthrough | free recordings; examples dated | a deployed endpoint with logging, after updating the code |
| Simon Willison's weblog | techniques and working examples, continuously | none beyond reading code | ongoing posts and tool write-ups | free | a technique borrowed into your own feature, with its source linked |
| Latent Space | change tracking and practitioner interviews | none | the publication's about page | free with paid tier | a monthly note on what changed in your stack |
Only home and syllabus pages were inspected; no course was completed and not every tutorial was executed. Treat depth and current quality as provisional until a representative lesson is checked.
Two distinctions matter more than the names. Free material is not the same as free runtime: a free course whose exercises call a paid model API or need a GPU has an access constraint, and the earlier piece on a free learning path is the checklist for it. And dated material is not dead material; the 2023 bootcamp's architecture lecture still describes the shape of an LLM application, but its code is a compatibility exercise before it is a tutorial.
The path: four stages, one artifact each
Each stage has a technical guide on this site to pair with the resource. The endpoint stage is where the course exercises belong. The eval stage follows how to evaluate an LLM feature before production, and the artifact is a report that can fail. The bounded-tools stage follows keeping multi-step agents under control: the artifact is a trace showing a tool call the host refused. The deployment stage follows what a production-ready LLM architecture needs; the artifact is a dashboard with a named operator and a rollback that has been tried once.
How to read each kind of resource
Use course chapters for practice, not for architecture: do the exercise, then rebuild it without the framework once, so you know which parts were the framework's and which were the problem's. Use creators' posts for techniques: when a write-up shows a working trick — a prompt pattern, a retrieval tweak, a tool-calling guard — port it into your feature and link the source in your code comment, because that link is how you will find the follow-up post when it breaks. Use newsletters for change tracking only: a weekly issue tells you what moved, and the right response is a note in your stack's changelog, not a rewrite. And inspect one representative item from each before trusting its depth. The earlier piece on keeping one project running is the discipline that makes this stick: the project chooses the resource, never the reverse.
The exercise I would run
No course was completed for this piece and no tutorial was executed end to end, so this is an editorial exercise, labelled as such. Pick one public-document support feature — answer questions about a published policy with a citation, or decline. Map the four resources onto it: the agents course for the first endpoint and a single document-lookup tool; the bootcamp's LLMOps lecture for the logging and deployment shape, with its code updated; a Willison write-up for the citation technique; a Latent Space issue for the note on which model versions changed this month. Define the artifact each stage must produce before starting, and stop at any stage where the artifact cannot be made. That stop is the finding.
Where this holds and where it breaks
It holds for an engineer with working Python who wants a first feature in production and has a bounded task to practise on. It is weaker for someone choosing a career direction, where breadth matters more than an artifact. It breaks if the goal is a certificate; this plan produces a deployed endpoint and a trace, not a credential, and the resources were chosen for that.
FAQ
Which single resource should I start with?
The one whose exercise matches the stage you are at. With no endpoint, the agents course; with an endpoint and no eval, the evaluation guide on this site and a dozen hand-written cases.
Are the dated resources still worth it?
The 2023 bootcamp is, for the application shape and LLMOps lecture — provided you treat its code as a compatibility exercise. Check examples against current library versions before trusting them.
How much reading before building?
One representative item per resource, then build. The artifact list is the syllabus.
What's in it for you
- A four-resource, four-job comparison with prerequisites, access constraints and what to build from each, honest about what was inspected.
- A four-stage path — endpoint, eval, bounded tools, monitored deployment — with one observable artifact per stage.
- A reading discipline: courses for practice, creators for technique, newsletters for change tracking, and a representative item checked before trusting depth.
Choose each AI engineering resource for the production artifact it helps you produce, and let the feature you are shipping, not the reading list, decide what to study next.
