Skip to content

Initial review thoughts for consideration #2

@reneenoble

Description

@reneenoble

Sorry this is a bit chunky, but I wanted to give some broad perceptions from a first glance through the whole curriculum and then with thoughts on each section. I think there is some really good stuff here, but I think refining the structure, flow, and pacing could help learners get the most out of it.

I will note I have not gone through and done all of the curriculum, I have (1) looked quickly through the whole thing for my initial vibes (2) gone back and looked through each part thinking on what I would personally include in beginners content. This perspective is based on how difficult I think it would be for the young devs I mentor to progress through the entire curriculum and feel like they had grasped each of he concepts by the end of each module - such that they can combine them and build on them in the following sections (most of the devs I mentor have never used AI tools, or have very limited access to internal-only proprietary tools through their workplaces).

Overall thoughts

  • Looking through the whole course, I don’t get a good understanding of the level of developer this is targeted at. It assumes a lot of knowledge about various pieces of technology with little explanation, but then includes very beginner-targeted graphics/analogies. It doesn’t really land as a “For Beginners” repo for me just yet.

    • The current level requires a lot of understanding of a combination of command line tools, Node terminology, infra, etc. I don’t think that this will be accessible to a uni student / grad / early career audience. I think there are ways to get the concepts you’ve included across while reducing the number of non-CLI terms needed. This won’t feel like a toy project, but it puts more focus on the skills we are trying to teach, with reduced cognitive load spent on understanding an unfamiliar stack.
    • This could be used to onboard devs who are already experienced (mid–senior), but an “Intro to Copilot CLI” is more suitable because they are not “true beginners”. At the same time, verbiage and images would need to change to make it less disjointed from the complexity of the examples.
  • This course ramps up very fast and doesn’t spend a lot of time on just getting comfortable with the CLI.

    • No AI experience is explicitly stated in the pre-reqs, so more time spent on basic topics before getting to anything that interacts with other AI tech is needed (agents, MCP).
    • I would aim to spend ~65% of the course on just using the CLI: first on a local system without any new repos, then on a very small/basic repo (e.g. a todo app).
    • The final ~35% can get into agents, MCP, and combinations of those. But there is a lot of content that is essentially “Copilot Chat, but now in your terminal” to cover first, including guidance on when to use chat vs when to use the CLI.
  • There are a lot of different small demos, which makes the flow through each module and the overall project hard to follow.

    • There is a lot of context switching, and it doesn’t provide an authentic developer flow.
    • Could we use just 2–4 mini projects with less complex code, reused across more examples?
      • This would mean learners need to understand less JavaScript and less infra to understand the benefit of Copilot CLI. They’ll better understand what the CLI is doing and that it solves problems similar to ones they already have.

Top-level README

  • More context on what GitHub Copilot CLI is is needed to sell someone on why to embark on this learning journey.

    • This page should include more of an explainer on what GitHub Copilot CLI is.
    • More explanation of the skills learners will take away after finishing the course.
  • The flow of this top-level README is a bit hard to follow. The content is all great to have, but it may need rearranging and possibly moving some content to other pages to keep it approachable.

    • For example, I like having the glossary. However, for a true beginner, seeing all of those terms up front (some of which may not be essential concepts to internalise early) can be intimidating.
  • Making the titles of each module more outcome-driven (rather than tool-driven) would make this more approachable.

    • For example, we’ve said that no AI experience is necessary, but this first page contains agents and MCP as individual modules.
    • Something like “Access MCP tools from Copilot CLI” might be friendlier, because it provides context and signals that learners don’t need to create an MCP server themselves—there are pre-existing tools they can use.

Module 00 – Quick Start

  • It would be worth explicitly mentioning that the free tier of GitHub Copilot for individuals does not include CLI access.
  • I would probably update the link to go directly to the plans and pricing page, rather than the general GitHub Copilot page.

Module 01 – Setup and First Steps

  • This dives quite quickly into more complex-looking interactions.

    • Can we start with some very basic CLI commands that don’t require cloning a repo?
    • This may help people get comfortable and invested enough that they are willing to clone a random repo to their computer, which is currently friction-adding.
  • Extending should probably be moved to a later module.

    • Consider how this can be split up after adding more beginner-friendly content.
    • Don’t mention agents or MCP in the first module.

Module 02 – Context Conversation

  • I’d love to see some of this content moved earlier, as initial activities learners do to get a feel for very basic CLI interactions.
  • This could be split into at least two modules:
    • One for basic functionality and things like @, --resume, and --continue.
    • More advanced interactions could move to a later module once learners are more comfortable using the CLI.

Module 03 – Development Workflow

  • I think this could be split into more modules.

    • This content underpins many beginner tasks, and it feels rushed and cluttered when all placed into a single section.
  • I’m not sure I personally see these as part of a single linear workflow.

    • They are tools, but you don’t always use them in this specific order.
    • Teams that follow test-driven development (or similar approaches) may also see generating tests after code as antithetical to their workflows.

Module 04 – Agents & Custom Instructions

  • I find the flow of this module a little confusing in terms of where we are and aren’t using Copilot CLI.

  • If I’m understanding correctly:

    • We are creating an agent (not using the CLI),
    • Then connecting the CLI to it with the /agent command.
  • This feels like a lot of non-CLI work where we are mostly copying code.

  • If we are already cloning a repo, do we need to also write the agent code ourselves?

    • Since this module isn’t really about agents, it would probably be better to have a very basic, intuitive toy agent already included.
    • That agent could then be leveraged via the CLI, keeping the focus on CLI usage.

Module 05 – Skills

  • This feels broadly good at the moment, pending alignment with the broader changes suggested above.

Module 06 – MCP Servers

  • This looks pretty clear as-is.

Module 07 – Putting It All Together

  • As a capstone project, I think we should aim for something less technical.
    • Skip as many concepts as possible that a junior developer wouldn’t know and that haven’t been taught in this course (e.g. pre-commit hooks, WebSockets).
  • Ideally, when learners ask things like “analyse this codebase”, they should receive a very basic explanation.
    • Explanations should use minimal jargon and avoid introducing lots of new concepts they aren’t already familiar with.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions