It was 3am when I realized that something was a bit off. I was refactoring an events logging subsystem. And my brain kept insisting I was pair programming with a star developer in another timezone.
That was the only explanation that made sense. Who else would be this eager to dive into a gnarly refactor at 3am? Who else would say “yes, let’s do it” to rearchitecting a core subsystem without a hint of resistance?
The terminal. The text-based back-and-forth. The async rhythm. It felt exactly like remote collaboration with a colleague on Slack. Not like using a tool. Like working with someone.
A co-founder, almost. Completely aligned with me. Full of energy and crazy ideas. Sometimes I had to be the adult in the room: “no, let’s write tests first”, “that’s too risky for now.” But the enthusiasm was infectious.
It wasn’t a person, obviously. It was Claude Code. But that night something clicked that hadn’t clicked before.
I’ve been sharing this with engineers I respect. Gray-bearded skeptics. The kind who’ve seen hype cycles before and learned to wait them out. Their responses weren’t what I expected.
“You officially destroyed my Christmas.”
“I tried and I can’t sleep.”
“I haven’t felt this productive in 15 years.”
That last one hit me. 15 years. That’s how long it’s been since coding felt like this for some of us - before the endless meetings, the ticket theater, the tooling complexity that buried the actual craft.
If you’ve tried ChatGPT for coding, or Copilot, or Cursor - and concluded this AI stuff is overhyped - I get it. I was there. But you might be evaluating the wrong thing, maybe also using outdated information.
Chat is you doing the work with occasional help. You prompt, it responds, you copy-paste, you prompt again. You’re still the one driving every step.
Agents are different. You describe what you want, provide context, and they go figure it out. They plan. They try things. They iterate. They come back with a result or a question. Agents are just like loops.
It’s less like having an assistant and more like finally having that tech co-founder who handles implementation while you focus on direction.
Three or four agents running in parallel, each on a different part of the system - that doesn’t feel like using a tool. It feels like leading a team. Except this team is available at 3am, doesn’t get tired, and never hands in surprise notice.
Here’s what actually unlocked this for me. I’m still refining these, but they’ve held up so far:
An agent is just a job description.
I kept thinking agents were complex orchestration systems. They’re not. An agent is just a job description - role, responsibilities, examples of good work, things to avoid. The same thing you’d write when hiring. You’re not configuring a machine. You’re onboarding a collaborator.
This reframe changed everything for me. Instead of thinking “how do I prompt this AI”, I started thinking “how would I brief a capable engineer who’s new to this codebase?”
Context is the constraint you’re actually fighting.
Most “AI is stupid” complaints trace back to context problems. The model isn’t dumb - it’s working with incomplete information. You didn’t give it what it needed, or you let the context window fill with irrelevant stuff.
AGENTS.md files, project docs, examples of patterns - these aren’t optional anymore. You’re writing onboarding docs for your AI collaborators. When I started treating context management as a core skill, the quality of output jumped dramatically.
Feedback has to be faster than generation.
When code is being generated this fast, your verification needs to keep pace. Run the tests constantly. Check diffs early. Don’t let the agent run for twenty minutes unsupervised and then wonder why it went sideways.
I learned this the hard way with that logging subsystem. Let it run too long without checking, came back to find it had “helpfully” refactored three other modules I hadn’t asked about.
It’s a thinking partner, not a code monkey.
The best sessions aren’t “write this function.” They’re “I’m thinking about restructuring this module - what are the tradeoffs?” or “here’s my half-formed idea, help me find the holes.”
You’re thinking out loud with a collaborator who’s read a lot of code, has no ego about being wrong, and can implement a textbook algorithm in minutes.
Now here’s the part I’m still wrestling with.
I love programming. The craft of it. And suddenly… typing code myself started to feel inefficient. Almost wasteful.
If the agent writes it faster - and often cleaner - why am I typing it manually?
That’s a hard pill. We built identities around this. “I’m a developer” meant something specific: I solve problems by typing solutions into a machine. That was the skill.
What happens when typing isn’t the bottleneck anymore?
I don’t have a clean answer. Some days it feels like loss. Like the thing I loved got automated while I wasn’t looking.
What I’m finding - and this is tentative, ask me again in six months - is that the value shifts. Less typing, more orchestrating. Less implementing a single class, more holding the shape of the whole system. The problems that require judgment, taste, understanding of context - those are still mine.
Maybe the value was never in the typing. Maybe it was always in knowing what to type.
But I won’t pretend I’ve made peace with it.
Some things I’m learning matter more now. This list will probably look different in a year.
Reading beats writing. You’re reviewing output constantly now. Scanning diffs. Catching when something’s off. The ability to read code fast and spot problems is more valuable than typing speed ever was.
“Why” beats “how.” The hard part was never syntax. It was turning fuzzy human intent into precise computational thinking. That’s still the hard part. The agent handles implementation; you handle intention.
Being the adult in the room. The agent will happily refactor your entire codebase at 3am if you let it. Knowing when to say “stop”, when to add constraints, when to demand tests first - that’s your job now.
Working with the mess. The legacy systems, the weird CI configs, the git history nobody understands. Agents can navigate this stuff without complaining. But you need to know enough to guide them through it.
A necessary warning.
Simon Willison - whose judgment I trust - calls these models “the wild summer intern who also believes in conspiracy theories.” That’s accurate. Brilliant, eager, tireless. Also confidently wrong sometimes. Will hallucinate a library that doesn’t exist and defend the choice with conviction.
You’re the senior partner. They bring energy and fearlessness. You bring experience and judgment. Think of it as an amplifier: it makes a sharp engineer sharper, but it also makes a sloppy one produce slop faster.
Treat it as “AI does my job now” and you’ll produce garbage.
Treat it as “I have a brilliant collaborator with no judgment” and you’ll build things you never could alone.
Treat it as a sparring partner with infinite patience, and you’ll finally build the things you’ve been sketching on napkins for years.
One more thing - and this is important.
Everything I’ve written here is a snapshot. The tools are changing weekly. Claude Code today isn’t Claude Code from six months ago. The techniques that work now might be obsolete by Easter.
There’s no playbook yet. Everything’s still malleable. You can find your own path: for your project, your stack, your way of working.
That’s actually part of what makes this exciting. And part of what makes it exhausting.
If you’ve read this far, here are some practical things that have helped me:
Start with a real project, not a toy. The learning happens when you hit real constraints - existing codebases, actual requirements, legacy systems. Toy projects teach you toy lessons.
Write your AGENTS.md first. Before you start a session, write down what you’d tell a new engineer about this part of the codebase. That document becomes your context foundation.
Check in every few minutes. Don’t let it run unsupervised for long stretches. Short feedback loops. Catch drift early.
Keep a log of what works. The prompts that produce good results, the context setups that help. You’re building a personal playbook. Write it down.
Set a grumpy voice. Seriously. When I assess the tradeoffs, I often throw a line: “Put on the hat of Grumpy, this senior programmer…” The output has more edge, more opinion. Less corporate fluff. Try it.
I wrote a companion piece for CTOs - the strategic angle, org implications, that stuff.
But this one is more personal. This is for the engineers I’ve worked with over the years, the people I’ve interviewed, the ones who got into this field because they wanted to build things.
The craft changed. We’re still figuring out what that means - the joy and the grief of it. One thing’s certain: there’s no going back.
But I know the engineers who are experimenting now, who are learning to direct rather than just type, are building intuitions that will compound. And the ones still dismissing this will look up one day and realize the craft moved on without them.
It’s 3am somewhere. Your co-founder is waiting.
What do you want to build?
