|
AI writes basically all of my code now.
Here are my actual numbers from the last four months at work:
102 merged PRs.
71,000 lines touched.
6 PRs a week, split almost evenly between application code and infrastructure work. Terraform, Kubernetes configs, Spacelift policies, NewRelic alerting.
Multiple repos and two different orgs.
This is just at my day job btw.
A third of those lines were deletions.
If the tools were producing pure slop, those numbers should look very different. You can't ship 102 PRs through peer review on autopilot.
But How Sway?
Here's what people picture when I say "AI writes all my code": me in a hoodie at my desk, firing off prompts, accepting whatever comes back, and pushing to main.
YOLO.
That is not what's happening.
Before our team writes any large amount of code, we write a document. It explains what we're building, why we're building it, and how it should work.
That document goes through peer review and we argue about it.
Once we agree, that doc gets committed into the repo and versioned with the code. It's not a Google Doc that rots in somebody's bookmarks. It travels with the project.
We write more than we've ever written. And I don't mean code.
That document is now context. When we actually sit down to implement it, the agent has a clear, reviewed, agreed-upon set of instructions.
The code gets faster because the thinking already happened.
Tests are cheap now. So we write a ton of them.
Nobody wants to hear "write more tests."
Unless you're a masochist or something... or a QA engineer.
The boilerplate part of testing like the setup, the mocking, the scaffolding is handled by the agent. What's still hard is deciding what to test and what the expected behavior actually is.
Because tests are so much cheaper to write, we write way more of them. And that means we can deploy multiple times a day with confidence. The tests document the expected behavior, they catch regressions, and they give us a safety net that would've been too expensive to build two years ago.
They also act as documentation for our little robot friends.
More tests. More deploys. More confidence.
Coding is the only the first frontier
I think is genuinely underrated.
We give our agents access to company tools like Confluence, Figma and the GitHub API.
A lot of it is just writing a markdown file that tells the agent how to use an API that already exists.
You can have Claude go across all the repos in your org and write a small catalog.
A document that says: here's what's in each one.
Now when you're working and you ask "do we already have a service that does this," it can actually go find it instead of you leaving your terminal and digging through thirty repos in a browser.
Same thing with project tracking. Linear, Jira or whatever you use has an API
Also, screw you ClickUp. I have a video on that here if you missed the memo
If there's not already an MCP server for it, you can give the agent access directly.
Store the credentials in your environment variables, write a quick doc explaining the endpoints, and now it can update tickets, add notes, close out tasks.
Let the agent do bookkeeping.
Web search is basically built into these tools now too.
"What are the tradeoffs between these two libraries?"
"Is there a known issue with this version?"
You don't have to leave your terminal for any of it.
Share the wealth
Everything I just described gets way more powerful when the whole team does it.
We built shared skills. For example:
-
How to integrate a specific third-party tool.
-
How to write tests for this type of service.
-
How to do a PR review.
-
What the expected patterns are for a new microservice.
Anything you'd normally explain to a new hire over their first two weeks should be put it in a skills folder, and now every agent on the team knows it too.
Some of you are reading this and going:
"That's not what I want to be doing."
Totally fair and you don't have to.
But if you do lean into it, you need to shift your thinking a little. This is a different type of engineering. You're building the system that helps the whole team write better code faster. And those skills need to be maintained. They're a living part of the codebase, not a one-and-done thing.
Most of software development is just writing. It always has been.
JIRA tickets, system design docs, READMEs, Slack explanations. The difference now is that the writing directly feeds the tools that write the code.
If your documentation is garbage, your output will be garbage.
You're the captain matey
I don't want you walking away thinking the agent makes the decisions. It probably shouldn't.
What to build, how to structure it, what the customer needs is still on you bucko.
Now that code is pretty trivial to write, you can run more experiments.
A large refactor used to be brutal.
Days of work and you probably wanted a ton of eyes on it before you even started because unwinding it would be painful.
Now, if your company gives you access to powerful models - just try it. Approach A doesn't feel right? Scrap it. Try approach B. That kind of experimentation used to be a luxury. Now it's Tuesday.
KISD
(keep it simple dummy)
If only there was a better acronym | 
