Most of the conversation around AI and software development is about writing code. Can it write a function? Can it build a feature? Can it replace a developer?
\nI think that’s the wrong question.
\nWriting code is only part of what I do every day. There’s debugging, diagnosing, planning, communicating, reviewing. A lot of it isn’t glamorous and honestly, a lot of it takes up more time than the actual coding.
\nI’ve been using Claude Code for a while now and the most interesting ways I use it have nothing to do with writing code.
\nWhen a Playwright test fails you get an artifact. Screenshots, traces, logs. There’s a UI you can use to navigate all of this but poking around it takes time. By the time you’ve figured out what went wrong you’ve already lost momentum.
\nThe Playwright UI is fine. It’s not the problem. The problem is that it requires you to already have a hypothesis. You’re clicking through traces looking for the thing you think went wrong. If you don’t know what you’re looking for yet, it can take a while.
\nI started piping the artifacts directly into Claude Code and asking it to tell me what happened.
\nIt’s faster. A lot faster. Claude reads the output, figures out what the failure is, and gets me pointed in the right direction. What used to be ten minutes of clicking around is now thirty seconds of reading. More importantly I’m starting from a diagnosis instead of starting from scratch.
\nThe other thing I noticed is that Claude will often catch something I wouldn’t have looked at first. It’s not constrained by whatever assumption I walked in with.
\nWe started running into an issue where TypeScript was running out of memory during compilation in dev mode. Before jumping to solutions I wanted to understand the problem better. Was this something that had been building up gradually or was there a specific change that caused it?
\nThose are two very different problems. A gradual accumulation points to something like type complexity creeping up over time. A specific commit points to a bad import, a new dependency, a file that exploded in size. You approach them differently.
\nI checked out different points in our git history, ran the TypeScript compiler with diagnostics enabled, and captured the output at each point. Then I fed all of it into Claude and asked it to look for a pattern.
\nThere was one. Gradual accumulation across a long stretch of commits, not a single culprit. That changed the direction of how we approached fixing it. We weren’t hunting for a bad commit anymore.
\nWithout Claude I would have been staring at a wall of compiler output trying to do the same analysis by hand. That’s the kind of thing that either takes a very long time or doesn’t get done at all.
\nI built a Claude Code skill for ticket grooming. It pulls the ticket directly from Jira using MCP, so there’s no copying and pasting. Then it works through the ticket category by category: data access, state management, edge cases, potential gotchas, things worth flagging before work starts.
\nThe part I care about most is that it doesn’t just produce a wall of output and call it done. It asks questions. It goes back and forth with you. If something is unclear in the ticket it will surface that instead of making an assumption and moving on. The output also comes back in ADF formatting so it can be pasted directly back into Jira without any cleanup.
\nMy team uses it now. It’s changed how we prep work. We catch more things before we start than we used to.
\nI built a second skill that takes a ticket and produces a test strategy. What should be covered with e2e tests, what with unit tests, what needs to be manually verified.
\nThis is a decision developers make constantly and it’s almost never documented. You make the call in your head and move on. The problem is that without any structure around it, coverage ends up being inconsistent. Some things get over-tested, some things get missed entirely.
\nHaving a starting point that’s specific to the ticket, and that you can push back on and refine, is more useful than it might sound. It creates a conversation about coverage before the code gets written instead of after.
\nNone of these are about generating code. They’re about the parts of the job that surround the code.
\nDebugging takes time. Diagnosing takes time. Planning takes time. These are real costs and they don’t always show up in the same way that shipping a feature does, but they are very much part of the job.
\nThe question I keep coming back to isn’t “can Claude write this code for me?” It’s “what part of my job am I spending time on that Claude could help with?”
\nThe answer keeps surprising me.
","frontmatter":{"title":"There's More to Being a Developer Than Writing Code","date":"April 30, 2026","description":"How I've been using Claude Code for the parts of the job that have nothing to do with writing code"}}},"pageContext":{"slug":"/more-than-coding/","previous":{"fields":{"slug":"/resume/"},"frontmatter":{"title":"My Resume"}},"next":null}}}