Continued in my AI series….
I don’t write code (I know, broken record) . I read it a bit. My contribution to any codebase is mostly vibes, bad variable name suggestions, and extremely strong opinions about what the button should look like. What I am is someone who has spent a lot of time building real, working things using AI — and making every possible mistake along the way before stumbling backwards into something that actually works.
I call myself a builder but really I am a AI Slop Builder. It’s self-aware. It’s accurate. And I’m not embarrassed by it — because I’m trying to do it better.
This week: two things that changed how I build. Neither of them requires you to know how to code. Both of them require you to change a habit that feels comfortable right now but is quietly killing your projects.
First, Let’s Talk About the Mess You’re Already In
If you’ve been using AI to generate code, there’s a good chance you’re doing something like this:
You open ChatGPT, or Grok, or Claude. You paste in some context. You ask it to write something. It does. You copy it somewhere. Then, twenty prompts later, you can’t remember what it changed, why it changed it, or whether the version you have in your editor is even the same thing you were just talking about. The AI has forgotten everything you told it in session one. You’ve got three browser tabs open, a folder called project-final-FINAL-v3, and a vague sense of dread.
Sound familiar?
Here’s the core problem: the context window is finite, your project is not. Every conversation starts fresh. As your project grows, the gap between what the AI knows and what your project actually is gets wider and wider. You spend more time re-explaining than building. You’re not an engineer. You’re a copy-paste operator with ambitions.
There are two habits I changed that fixed most of this. One is about memory. One is about who you’re talking to.
Tip 1: Stop Being Afraid of GitHub. Your AI Isn’t.
I avoided GitHub for years. It felt like something developers did — something with terminals and commands and merge conflicts that would make me feel stupid. And honestly? The first time I poked around in it, I did feel stupid.
Then I realized something: I don’t have to understand Git. My AI does.
GitHub isn’t just version control. It’s a project memory system. And once I started treating it that way, everything clicked.
Here’s what I mean. GitHub has a built-in feature called Issues — it’s basically a ticketing system baked right into every repo. You can log a bug. You can describe a feature you want. You can write out a problem you hit and how you think it should be solved. And then — this is the part that changed things for me — you can hand that issue directly to an AI agent and ask it to resolve it.
The beautiful side effect? You now have a paper trail. Every issue you close is a record of a decision that was made, a problem that was solved, a feature that was built. That record doesn’t disappear when you close your browser tab. It lives in the repo. Permanently. I even use it for research purposes, if I have ideas, I log it as an “idea” and then ask an agent to go off and research it for me.
And here’s why that matters more than you think: the agents also have access to it.
Tools like Claude Code, Cursor, and GitHub Copilot Workspace can read your issues, your pull requests, your commit messages. When you build with GitHub as your source of truth instead of a chat window, the AI isn’t starting blind every session — it has context. Real, structured, version-controlled context that you built up over time just by logging your work like a normal human being. It can operate Retrieval Augmented Generation on our issues.
You don’t need to run a single terminal command to start. You can create a repo, write issues, and review pull requests entirely through the GitHub web interface. Ask your AI how. Seriously — just ask it to walk you through it. That’s exactly the kind of thing it’s good at.
The habit shift: Before you ask AI to build something, write it as an issue first. One or two sentences is fine. “Add a login page that accepts email and password.” Done. Now you have a record, a reference, and a task your agent can actually grab and run with — instead of trying to hold all of that in one immortal chat thread. More important, before you start a project, open a Github repo right away, start with a great environment.
Tip 2: Stop Asking Your Chat Window to Write Code. That Is Not Its Job Anymore.
This one is where I felt the biggest shift — and where I also made the most embarrassing mistakes before I figured it out.
Most people start the same way I did. You’re in a chat window. You’re talking to the AI. You ask it to build something. It builds it. You copy it. You paste it. You come back, ask it to fix something, copy it again, paste it again. Rinse and repeat until you want to throw your laptop out a window.
The problem is you’ve turned your AI into a code vending machine instead of what it could actually be: a manager.
Here’s what I mean. Modern agentic AI — the kind baked into tools like Claude Code, Cursor, Windsurf, or even more advanced configurations of ChatGPT — isn’t just a chat box anymore. These tools can spawn subagents: separate, focused AI workers that handle specific tasks in their own isolated context, then report back. One subagent writes code. Another reviews it. Another runs tests. The manager — the agent you’re actually talking to — coordinates all of that without dumping it all into one giant, bloated conversation.
Every developer who uses these tools long enough hits the same wall. The session starts fast. The first hour is productive. Then, somewhere around the third or fourth hour, responses get vague, the model starts forgetting decisions made earlier, and code suggestions drift. The context window is full — and it’s full of noise.
Subagents are the fix. The orchestrator — the agent you talk to — doesn’t do the heavy lifting. It coordinates. Each subagent receives a focused prompt with a clear objective, does the work in its own clean context window, and returns only the relevant result to the manager. You don’t see the mess. You just see the outcome.
But here’s what nobody tells you: the AI will not do this automatically just because you asked it to build something complex. You have to prompt it differently.
When I stopped asking “can you build me X” and started saying “you are a manager agent — plan this work and delegate the implementation to subagents, I don’t need to see every step” — the quality went up, the conversation stayed clean, and I stopped copy-pasting like a maniac.
Think of it like being a project manager who delegates to specialists. You wouldn’t ask your designer to run security audits or your QA tester to write marketing copy. Same logic applies here. Stop asking your chat window to be everything. Give it a role. Give it authority. Tell it to delegate. “I have this cool idea for a new way to this thing, here’s the idea, but I want to research it, spin up a sub agent to research it and document the findings in an issue”
The other shift: if you’re doing this in a plain chat window, you’re leaving tools on the table. Most of the serious agentic tools — Claude Code, Cursor, Windsurf — have proper support for subagent workflows baked in. They can read files, write files, run commands, check your GitHub issues, and loop back for review. A chat window can describe doing all that. A code agent can actually do it. That’s not a small distinction. That’s the whole ballgame.
You don’t need to understand how subagents work under the hood. You just need to know they exist, prompt for them, and get out of the way.
The Real Lesson Under Both Tips
What both of these tips have in common is this: AI works better when you give it structure, not just requests.
GitHub Issues give your project structure. A manager-agent prompt gives your workflow structure. Without structure, you’re just vibing your way through a chat window hoping something sticks. With it, you’re running something that looks a lot more like an actual software team — even if that team is entirely made of ones and zeros and you’re the only human in the room.
I’m still an AI Slop Builder. I’m not going to pretend I’ve got this all figured out. But I’ve at least graduated from copy-paste chaos to something that feels intentional — and honestly, that’s more than I expected when I started.
Next time, we’re going to talk about something that sounds simple but is probably where most people are losing the most ground: prompt engineering. Specifically — what do you actually put in that little empty box? I’ve been building up a set of tips, bootstrapping tricks, and hard-won lessons about how to talk to these things so they actually do what you want. It’s less mystical than the name suggests, and more impactful than you’d expect.
cantechit - Technology and IT BLOG 