How I Use AI as a Software Engineer

I thought it would be fun to write this one as a self-interview. Instead of a traditional post, here’s a Q&A about how AI has worked its way into my daily engineering routine.

Q: What AI tools do you use day to day?

My primary tool is Claude Code, an agentic coding assistant that runs in the terminal with full context of my projects. Beyond that, I use ChatGPT and the Claude.ai web interface for different tasks depending on what I need. Claude Code handles the heavy lifting when I’m deep in a codebase, while the web-based tools work well for quick research and one-off questions.

Q: What do you mainly use AI for?

Writing code, researching problems, automating repetitive tasks, building tooling. It touches nearly every part of my workflow. Whether I’m scaffolding a new service, debugging an issue, or writing a script to automate something tedious, AI is usually involved somewhere in the process.

Q: How has it changed your workflow?

The core workflow is the same. I still think through problems, design solutions, and write code. But everything moves faster. Boilerplate, looking up API details, writing tests; those used to eat up hours of my week. Now they take minutes. AI has amplified how I work without replacing it.

Q: What surprised you about using AI?

The non-code tasks. I expected AI to help with writing and debugging code, since that’s the obvious use case. What I didn’t expect was how useful it would be for writing documentation, drafting emails, and project planning. Those tasks used to feel like a chore, and now they take a fraction of the effort. That surprised me.

Q: This site was built with AI too, right?

It was. This blog (the theme, the design) was built with the help of Claude Code. The site runs on Hugo with a custom theme, and Claude Code helped with everything from scaffolding to CSS refinements. I’m no frontend engineer and I don’t particularly enjoy the finicky details. If it weren’t for Claude, this would probably have Bootstrap CSS slapped onto it or an off-the-shelf theme.

Q: Do you have any concerns about the next generation of engineers using AI?

Yeah, and it’s something I think about often. My worry is that newer engineers, the ones entering the field right now, are leaning on AI to do the problem-solving for them. The bug gets fixed, the feature ships, but they never understood why it worked or what was going on under the hood. AI did the footwork, and they moved on.

That might be fine day to day. But in a few years, when these engineers sit in interviews and have to reason through problems on their own, many of them are going to struggle. Interviews still test whether you can think through a problem, break it down, and explain your reasoning. If you’ve spent years accepting AI output without building that muscle yourself, you won’t have it when it matters.

AI can be great for learning if you engage with it critically. The danger is treating it as a black box that produces answers. If you’re early in your career, you owe it to yourself to understand the why, not the what.

This extends beyond interviews into codebases. If people blindly paste in whatever AI gives them without understanding it, codebases will accumulate unmaintainable code industry-wide. Dead code, cargo-culted patterns, subtle bugs baked in because nobody questioned the output. Code that compiles and passes tests but no human on the team understands. That’s a maintenance nightmare waiting to happen. AI output needs the same scrutiny as any other code contribution; maybe more, because it can look convincingly correct while being subtly wrong.

Q: Any advice for engineers who haven’t started using AI yet?

Two things. First, start with a real task, not a toy example. Pick something you’re working on and see how AI fits into that. Toy problems don’t give you a sense of where these tools shine or where they fall short. Second, always be critical of the output. AI gets things wrong. It hallucinates. It writes plausible-looking code that doesn’t work. Treat it as a fast collaborator who needs code review, not as an oracle.

Comments

You can also comment directly on GitHub Discussions.