Agentic Development, Part 1: GitHub, Deploys, and Picking a Harness

Most posts about coding with AI agents jump straight to the cool stuff — five agents in parallel, custom AST rules, hooks firing on every file write. That's where I ended up too, but it took me a while to admit that none of it matters if the foundation underneath is wobbly. If your git workflow can't absorb a flood of agent commits, if your deploys are a coin flip, or if you picked a harness that fights how you think — none of the fancy stuff will save you.

This is Part 1 of a three-part series on agentic development. Part 2 is about teaching the agent your conventions; Part 3 is the deep end — the guardrails I run once the basics aren't enough. This post is the boring, load-bearing pieces you set up once and stop thinking about.

If you've been writing software for a decade, skim and move on. If you're newer, or you've been getting by with "Cursor and vibes," this is the post I wish someone had handed me.

GitHub: agents commit a lot, plan for it

You don't need to master git to work with agents, but you do need a few habits.

One feature, one branch. Agents are prolific. They'll touch ten files when you asked for one. If you do that work on main, your history turns into a swamp inside a week. Branch per task — even tiny tasks — and merge through a PR. Treat the agent like a collaborator whose work needs review, because it is.

git checkout -b add-search-input
# let the agent cook
git push -u origin add-search-input
gh pr create --draft

Commit small, commit often. When the agent finishes a coherent chunk, commit it. If the next chunk goes sideways, you have a clean point to roll back to. Agents are great at writing code and bad at remembering what state the repo was in five minutes ago. Git remembers for them.

Use draft PRs as scratchpads. Open the PR while the work is still in progress. CI runs against every push, which means you find out about lint errors and broken types before you've committed to a direction. It also gives you a stable URL to share with your future self when you forget what you were doing.

Protect main. In repo settings, require PRs to merge into main and require status checks to pass. This is the single highest-leverage setting on GitHub. It costs nothing and it stops "I'll just push this real quick" from becoming a postmortem.

Hosting: pick one, ship today

The deploy story for indie projects in 2026 mostly comes down to three platforms: Vercel, Railway, and Render. They all do the GitHub-connected, push-to-deploy thing well. The differences are about what you're shipping.

Vercel is the default for Next.js, React, and other frontend-heavy stacks. Push to GitHub, get a preview URL per branch, promote to production by merging. The DX is genuinely the best in the category. The catch is pricing: $20/user/month on Pro plus bandwidth and function-invocation charges that can spike if your app gets attention. For frontends and serverless API routes, it's worth it. For anything that wants to be a long-running process, it isn't.

Railway is what I reach for when I have a backend that needs to actually run — a worker, a websocket server, a Postgres instance, a cron job. Usage-based pricing means you pay for the compute you use. The first month gives you $5 of free credit, then $1/month after, which isn't a real free tier but is enough to kick the tires. The killer feature is that "deploy a Dockerfile" and "deploy a Postgres database" are the same three clicks.

Render sits in the middle. Web services start at $7/month with predictable per-instance pricing — no per-seat fees, no surprise bandwidth bills. It does Docker, managed Postgres, background workers, and cron jobs in one place. If you want a single bill and steady-state pricing, Render is hard to beat.

The hybrid most people land on: Vercel for the frontend, Railway or Render for the backend. Don't overthink this. You can move later. The point is to have a URL you can share and a deploy that happens automatically when you merge.

One note specific to AI work: if your app calls Claude or OpenAI, set the API keys in the platform's environment variable UI, not in .env files committed to git. Every host above does this; it takes thirty seconds; it saves you from the rite-of-passage moment of leaking a key on GitHub and getting a $4,000 bill.

Harnesses: pick the one that fits your brain

A "harness" is the program you actually drive when you code with AI — the thing that takes your prompt, calls the model, edits files, runs commands, and shows you the diff. The model matters, but the harness is what you spend your day in. They're not interchangeable.

Here's the lay of the land in May 2026:

Claude Code — Anthropic's official CLI. Lives in your terminal, reads CLAUDE.md for project context, supports hooks, MCP servers, custom skills, and slash commands. It's opinionated about how it works and it's the harness I use most. If you want the deepest agentic runtime and you're okay being on the Anthropic stack, this is the one.

Cursor — The "VS Code with a brain" option. Cursor 3 (April 2026) added cloud agents on isolated VMs, parallel Agent Tabs, and /worktree for isolated branch work. If you want the AI to live inside your editor instead of a separate terminal, Cursor is the path of least resistance.

Codex CLI — OpenAI's terminal agent. Same shape as Claude Code, different model. Worth installing alongside Claude Code so you can A/B specific tasks; some problems just go better on one side.

opencode — Open-source terminal harness that routes to 75+ LLM providers via models.dev. Use a cheap model for chitchat, a reasoning model for planning, a coding model for implementation, all in one session. If you want maximum flexibility (and you don't mind tuning), this is the choice.

Conductor — A Mac app that orchestrates parallel Claude Code and Codex sessions in isolated git worktrees. You point it at a repo, it clones a workspace per agent, and you babysit four conversations at once instead of one. This becomes much more useful once you've read Part 3, but it's worth knowing exists.

T3 Chat — Not a coding agent so much as a fast multi-model chat UI. Useful as a sidecar for "explain this stack trace" or "what's the idiomatic way to do X" without firing up a full agent session.

My honest recommendation if you're starting from zero: install Claude Code, point it at a project with a CLAUDE.md, and ship something. Add a second harness when you have a specific reason. The most common stack I see is Cursor for daily editing plus Claude Code in the terminal for longer-running tasks — but you'll figure out your own combination after a week of using one well.

What "good enough" looks like

If you have all three of these, you're done with Part 1:

1. A GitHub repo with branch protection on main and a draft PR workflow.
2. A connected hosting provider (any of the three) that auto-deploys on push.
3. One coding harness installed locally and configured with API keys.

That's it. No hooks yet, no linters, no AST rules. Those come in Part 2 and Part 3. The reason to set up the foundation first isn't dogma — it's that every piece of the next two posts assumes you have a place to push code, a way to deploy it, and an agent you can actually drive.

Build the runway before you start the engines.