GitHub Wasn't For Me, Until It Was

Short answer: I used to think GitHub was proof that someone was already a developer. Then AI made it the safety net that helped me become one.

GitHub Was A Place I Visited, Not A Place I Lived

I used to run across GitHub repos when I was researching homelab things I was interested in. I would find some project that solved a problem I had, or some script that might help me automate something, and almost immediately I would hit language that felt like it belonged to someone else.

Pull down the repo. Clone it. Open a branch. Submit a pull request. Compare branches.

I am not going to lie to you, I did not really understand any of that. I did not understand what "pulling down" a repo meant, I did not really understand what a repo was, and I definitely did not understand GitHub branches, pull requests, diffs, or comparing one branch against another. GitHub felt like a place I was allowed to visit, but not a place I was supposed to live in. I could look at it, copy commands from it, follow instructions if someone had written them clearly enough — but it was not mine. That was developer territory.

The First Time The Words Almost Made Sense

I remember learning about CI/CD when I was at Versapay. I wanted to automate our pipeline for deployments, and this was probably the closest I got to GitHub-esque terminology at the time — but even that was mostly through Gearset positioning because I had watched a 45 minute YouTube video on it. I am not going to lie to you, even then I was pretty lost. The concept sounded great — automated deployments, safer releases, a path from change to validation to production — but what is a commit, really? What does it mean to merge work? Why does a branch matter?

I understood the business value of the process before I understood the mechanics of it, and that has been a recurring theme for me. I could see why a system mattered, why the shape of the workflow was useful, but the actual developer language around it still felt like a foreign dialect. And because I was not a developer, I could keep that distance. GitHub was useful for developers. Gearset was useful for Salesforce teams. I could understand the idea without having to live in the tool.

At least, that is what I thought.

Then Storyweaver Broke

After I destroyed Storyweaver, I started to learn what GitHub was and what Git was for.

I'd been vibing my way through features, asking the model to add this or refactor that — until it offered to cut the codebase by 70%. I said yes. It gutted the project.

That was the moment Git stopped being abstract. Git was no longer some developer ritual I did not understand — it became the thing I wished I had been using correctly before I let an AI agent swing a hammer at something I cared about.

One of my friends was nice enough to hop on a call and help me establish the repo in July of 2025. I remember a week later hopping on another call with Edgar where we went over GitHub concepts, TDD, and how to use Git. He went over commands to get connected to a repo, I recorded the call because I knew I was going to forget everything, and there was supposed to be a test on Monday. Okay, so no test came Monday. But the real assignment was there anyway — start learning how to push and pull work to a repo, start grounding my AI development work in tests, start treating the work like something that needed a history.

Learning Git Like An Associate Admin

So, like an Associate Admin learning to use a new declarative tool, I rolled up my sleeves and began learning the proper ways to work with Git. For something that's been around for so long, I figured the history behind it mattered.

Git was created by Linus Torvalds in April 2005 — Torvalds, also the creator of Linux, famously developed the initial core functionality in about 10 days, which came out of a licensing dispute, but I will not bore you with that. The bigger point for me was simpler: he wanted a better way for people to work together on software.

They say the best software does something in the most boring way possible, and Git delivers on that. You make changes to files, Git tracks those changes, you can save a point in time with a commit, and you can work on an idea in a branch without destroying the main version of the project. If you want to merge those changes back in, you open a pull request — someone, or in my case often an AI agent helping me review, can look at what changed, decide if it makes sense, and merge it. The work is recorded. The decision is visible. The history is there.

That sounds simple when you say it now, but it did not feel simple to me at the beginning. GitHub still felt off limits. I mean, I was not a developer — why would I ever use GitHub?

Then I looked at what actually happened.

The Workshop Appeared

Here is what my repo creation looked like after Storyweaver:

There is an interesting pattern in that chart. As someone who had literally zero experience with Git, GitHub, branches, pull requests, and all of the language around it, I ended up using it consistently for 11 months straight — and that was not because I suddenly became fluent in every developer tool overnight. It was because Git became useful to me.

I found that Git was something you could naturally rely on while working with AI agents. Make a mistake? No worries, go back to the main branch and start over. Working on a feature? Spin up a new branch and let the changes be tracked. Want the AI agent to understand what changed? Let it inspect the diff. Want to try a weird idea without ruining the thing that already works? Branch off.

This was key because, remember, I could not read all of the code fluently yet — I could understand pieces, read enough to be dangerous, explain what I needed, what was not working, what the user experience should feel like. So I left a lot of the code reading to the LLM and kept the designing, testing, and judgment to myself. Git made that division of labor safer. It gave the agent a memory surface, it gave me a safety net, and it gave the project a history.

And as a result, over the months, I learned to lean on Git too — to track my projects, try new things, and put them on the web, privately at first, because remember, to me GitHub was still for developers.

The Commits Tell The Same Story

The repo count tells one part of the story. The commit activity tells another.

Man, did my usage explode. I kept coming up with ideas, and as those ideas came, I wanted to back them up. After understanding what to use Git for and how to move it into my workflow, Git became part of how I worked with LLMs — it was a way to experiment without repercussions, and also a north star that helped keep the LLM aligned with the goal at hand.

That might sound strange if you already know Git well. To a developer, Git is just part of the job — of course you use branches, of course you commit, of course you open pull requests and read diffs. But for me, that process was new, and because I was learning it alongside AI agents, it clicked differently. Git was not just source control. It was context control. It was a way to tell the model: here is what changed, here is what we are trying to protect, here is the branch we are on, here is the point we can return to if this gets weird. That changed the way I built.

From "Commit This" To Workflow Language

There is another funny data point here. When I looked back through my LLM session history, I found that I had said "commit this" 301 times across 286 sessions. Three hundred and one times. That makes me laugh a little because it is such a simple phrase, but it also says a lot about where I was in the learning curve. At first, Git was basically a button I wanted the AI agent to press for me — commit this, push this, save this before we break something. I knew enough to know I wanted a checkpoint, but I did not yet have the full language of the workflow.

But then the language started changing. Across the session history, the broader Git language shows up everywhere:

In January, I said "commit this" 201 times. That was the phrase. By March and April, the language had changed — I was talking about pull requests, branches, diffs, merges, pushes, and reviews. I was no longer just asking the agent to save the work, I was asking it to participate in the workflow. That feels like a small distinction, but it is not. "Commit this" is a checkpoint. "Open a PR, review the diff, make sure the branch is clean, push remote, and link the work back to the ticket" is an operating process. I did not just learn the vocabulary. I started thinking in the workflow.

I Still Do Not Run Every Command

I will be honest with you — I do not actually run the commands that led to all those commits. I also do not usually run the commands to create new branches, open pull requests, or compare branches myself. Most of the time, I lean on the AI agent I am working with to help do those things.

But that is different from not understanding what is happening. I understand why we open new branches. I understand what pull requests are for and how to read a diff well enough to ask better questions. I understand why tests matter before a merge, and why Git history is valuable when an AI agent loses context or when a session gets too long. The overall concept of working on software through Git is no longer lost on me — if anything, it helped me bridge the gap between myself and developers because I understand that process better now. I understand the ritual. I understand the shape of the work. I understand why the boring parts matter.

For a long time, I thought I had to feel like a developer before using developer tools. But using the tools is part of how I became one. Not a traditional developer in the way I had pictured in my head — not someone who hand-writes every line of code from memory or can explain every framework detail without help. But someone who builds software systems, works through branches and pull requests, tests behavior, ships projects, reads diffs, makes product decisions, and uses the tools well enough to direct and verify the work.

GitHub used to be a place I visited. Now it's where I work.