Start here
Make one small thing you can put to use.
Bring a problem you understand, a coding assistant and somewhere to keep the project. Learn the workflow through one change you can see and check.
You can use an agent in an editor or a hosted coding environment. Ask it to explain unfamiliar terms and show you how to open the running result. Git and GitHub make the work easier to keep, review and return to.
Choose something small
A reading list, a simple calculator or a page that answers a recurring question is enough. Choose one person and one useful action. You will learn more from getting that action to work than from describing an entire business at once.
To follow this site's example, make a tiny mock feed with a few fictional posts. Let a reader hide a post and undo the action. This gives you something concrete to inspect without connecting to anyone's real account.
Give the project a home
Git records changes to files. A repository is the project and its history. GitHub hosts repositories and provides a shared place for tasks and reviews. Your coding tool may be able to create or connect one for you.
If those ideas are new, GitHub's short exercise takes you through a repository, branch, commit and pull request in the browser. You can do it before installing Git or learning command-line commands.
Try GitHub's Hello World exerciseDescribe one change and how you will check it
An issue is a written task. Give it a purpose and a few things that must be true when it is finished. These are its acceptance criteria. Start from the working project and keep the request small.
An example brief for your coding agent
Add an undo action to this mock feed so I can recover a post hidden by mistake.
- Hiding a post shows an undo button.
- Undo restores that post in its original place.
- The controls work with a keyboard and on a phone-sized screen.
- Keep the existing feed behaviour working.
Work on a separate branch. Explain your plan, make the change, run the available checks and show me how to try it. Summarise anything you could not verify.
A branch is a separate line of changes. It gives you a place to work on an idea before accepting it into the main version.
Try the result yourself
Open the preview: a running version of the proposed change. Use it as the intended reader would. Hide and restore a post, repeat the action and try the controls using the Tab and Enter keys. Look at it on a small screen.
Ask the agent which automated checks passed and which parts still need a person to try them. Describe any failure precisely: what you did, what happened and what you expected. That gives the next change a clear target.
A passing test tells you something about the software. Seeing whether someone finds it useful starts a different kind of investigation.
Save what worked and leave a clear next step
A commit saves a set of changes in Git. A pull request, often shortened to PR, gathers a branch's proposed changes so they can be reviewed. Ask for a plain-language explanation of what changed, why and how it was checked.
When you accept the change, merge brings it into the main version. Deployment publishes a running version. A project can automate deployment after a merge; check whether yours does, and open the published page to confirm the result.
Write down what you learned and the next question. You now have a repeatable cycle: describe, change, try, review, save. That is the foundation for delegating longer pieces of work.
When the project starts to grow
Put the instructions for running and checking it in the repository. As more agents join, give each a clear task and a separate working folder, called a worktree. Then automate the coordination you find yourself repeating.
Continue the journeyKeep the glossary nearby for unfamiliar words.