How To Scale Your Writing Output With AI and Human Taste

How I use LLMs as a staff engineer in 2026. This is by Sean Godek, or G, if I'm not pronouncing that right. Sean says, a bit over a year ago, I wrote how I use LLMs as a staff engineer. That article went pretty viral, and this is his update for 2026. For last year, in 2025, he says he used for AI, as of last year, smart autocomplete with GitHub Copilot, short tactical changes in areas I don't know well, always reviewed by a subject matter expert, writing lots of use-once-and-throw-away research code, asking lots of questions to learn about new topics like the Unity game engine, last resort bug fixes just in case it can figure out things immediately, big picture proofreading for long-form English communication. And here are some tasks he explicitly did not use for AI last year: writing whole PRs for me in areas I'm familiar with, writing ADRs or architectural decision records or other technical communications, research in large code bases and finding out how things are done. February 2025, that was, uh, so last year and eons have happened in between. And he's basically asking what's changed since then and now. And he says agents are good now. I love that this was a headline, just bold heading. Agents are good now. And we talked about this earlier on the pod. Jonathan was saying, you know, in September he was testing things and could we just let an agent just drive everything and we could build apps? And it was like, clearly no. But as of December when Opus dropped and then all the big acceleration of LLM model, I think capacity for coding agents, I should say, really improved. Agents are good now. That's a great way to put it. Kind of moving ahead, I'll summarize what he uses AI for now, and then me and Jonathan will give our own takes. Overall, in 2026, what's Sean using AI for now as a staff engineer? Writing or drafting, depending on complexity, every code change I make. Investigating and fixing bugs, either autonomously for most bugs or with my close involvement for trickier ones. Research in large code bases since current agents are now good enough to give the right answer almost all the time. And when they're wrong, it's clear from reading the explanation that they missed something. Manual testing and local machine setup or troubleshooting. And I still use AI for asking lots of questions to learn about topics and for proofreading. What Sean does not use AI for in 2026 still: writing any kind of public communication for me, pull requests, descriptions, architectural decision records, messages, with the exception of trivial 2-line PRs, writing code that I don't carefully review. Testing any kind of UI. In my view, the current core AI skill is shifting as much work onto AI agents as possible without going too far. Many people are underutilizing agents, not allowing them to investigate bugs or test their changes, or not throwing enough simple tasks at them. Other people, Sean says, are overutilizing them, using them to write messages that ought to be handwritten, or trusting them to make sweeping changes that need careful human review. Since the 2025 post, Sean says the balance has tilted more towards the agents, but finding the balance remains as tricky as ever. All right, so for What's the Meta, since we're AI builders ourselves, thoughts on this take, Jonathan?

Yeah, it seems very pragmatic, and it's cool to see it year over year. Hopefully we'll get like a 2027 version from him too. And I guess the, the most interesting part that relates to my own work is that the stuff he doesn't use AI for, I use AI for some of that stuff. And it's, uh, it's questionable.

So, you know, questionable which way, that he's not using it or that we are?

Well, yeah, like, say, um, as of like late last year, I had a rule I would review every line of code that the AI wrote. I've abandoned that rule because I can write so much code so quickly. You know, there's a, there's a higher level of like, are the tests doing the right thing and are they passing? And is that, that's more the kind of heuristic that I'm looking at as I'm generating code now. I don't feel like my code quality is as high as it was before, but I can write a whole lot more and I can usually get it to the quality if I invest enough time. So there's kind of like a trade-off, you know, it's a little bit like our first conversation today. And then the writing any kind of public communication for PR, PR descriptions, ADRs, you know, I think we do a lot of that in general. Like our whole linear ticket backlog is like, you know, written by ADRs. AI. And for me, like, when I write a ticket or a project, I might redraft it, like, you know, a dozen times to make sure that I like the way that it sounds. But I, I don't want to actually write it myself. So I feel like that's leveraging the tools and figuring out, like, what my taste profiles are and stuff like that. I can be more prolific that way personally. Those are two pretty big differences and sort of where our independent judgments as, um, you know, as engineers using the tool are.

What about the testing of UIs? So that's like writing and then—

Yeah, I found like a kind of love-hate relationship with this because I mean, uh, I think Chrome DevTools and Claude Code was like a step function and like, oh, we can test UIs now. And I've got a lot of productive testing done that way. It can only get us so far. And I also feel like my, probably my front end, uh, QA review skills have atrophied a bit as I've relied on the, on Claude Code. And then Codex recently came out with their vision tools and they have desktop browser integration. Actually activated at the same time as I did the mobile phone this last week. I was just really impressed at what it could test and how it, how it could sort of run nice row tests against UI. Does it catch everything? No, I mean, but like it catches a whole lot of stuff and we make sure that the system is basically working for its prescribed purposes on staging before we push out to production. It's really helpful. The first two I use like prolifically and the third one, I wish I used it more, but it's just kind of slow. You know, the UI testing is still pretty slow.

So I guess I'll comment. Um, you got it. Jonathan, our CTO's take. I definitely use this to write public communication, like for sure. So his take on, I'll use this, I'll use this to write things, but then I'll, for very sensitive communications, he deems these ones sensitive, like PR descriptions, ADRs, Slack messages, uh, he chooses to write them himself. This is also a staff engineer at like a big company sort of situation. Like kind of different, you know. My take on this is that I have to draft so many client updates, uh, because we're operating as AI builders and for deployed engineers. It would be impossible to— I would be spending way more time drafting comms and getting tickets updated and stuff like that. Linear MCP with Cloud Code with Google Workspace MCP, so you could draft emails. I write— if I have to give a Slack update to a client or to Jonathan or or contractors on the team, I'll have it draft me a Slack message and store it in my Obsidian, my personal vault. That's usually my meta. And then I'll copy paste that Slack formatted thing into Slack and then I'll tweak some stuff. But like Jonathan says, I'm usually drafting these comms with the AI. I'd say for my other stuff like social content, definitely drive that, the draft generation with AI. A lot. And I've seen some misses where it's gotten through a quality review for me. But my trade-off is like, if I could do this for our content engine and it keeps me consistent, and if everybody's doing it, then it's just more about, okay, at some point you figure out the evals and the harness for every content case you have, and then it gets better, and then you scale and leverage yourself infinitely, right? And ultimately, we're a startup, so scaling and leveraging infinitely Sounds pretty fucking great. So I'm gonna keep writing with AI and then curating with my own human taste and then evolving my own harnesses around that.