I’ve been using LLMs and coding agents for a while. Until recently, they hadn’t quite clicked with me. I’d used them for small tasks, but after some experimentation, I started implementing bigger features in production. For context, I’m working on a greenfield Android project with approximately 150 modules.
There are pros and cons to using coding agents. I wanted to write down my thoughts to reflect back on when enough time passes.
Understanding Context
When you understand the problem and only need help with implementation, coding agents excel. You can navigate them directly to what you want, provide the relevant context files, and discuss the implementation plan before writing code. The agent has constraints—you know what code will be added and how it will be tested.
It takes time to learn how to instruct coding agents to work the way you like. Once you figure it out, it’s enjoyable. The code they implement feels like the code you would have written yourself if you had enough time. The productivity gains from implementing a single feature represent a significant shift.
Working with Familiar Problems
Recently, I implemented a feature that would have taken me 1 to 1.5 days in just under three hours. I knew exactly what to implement: the data layer, domain layer, and UI layer were all predetermined. The problems were already solved.
Coding agents excel at this. The implementation they provided matched what I would have written myself. Over time, composing skills or creating agents for familiar problems will increase productivity dramatically. For most projects, 50-60% of new work reuses solutions you’ve used before (This generalization obviously might be wrong but the general idea is still valid). You’re not inventing new solutions for new problems constantly.
You still need to test and verify everything works, ensuring you don’t introduce regressions with the new feature. But that’s the default way to operate anyway.
Tackling New Problems
This is where things get tricky. You’re in uncharted waters, implementing a new solution that might not be your area of expertise. You describe the problem to the coding agent and examine the solution.
The solutions coding agents offer aren’t groundbreaking or novel. But they have better search context than humans and can find and compose solutions faster. That doesn’t mean a human can’t find those solutions—the agents are just faster at it. If they discovered truly groundbreaking approaches, I’d be excited and concerned. But for now, we’re just writing code and implementing things faster.
Learning Abstractions
This is the main challenge. When you work on new problems and find new solutions, you create new abstractions. Not learning those abstractions and delegating understanding to coding agents won’t benefit me in the long run. I try to learn from my conversations with coding agents as much as possible.
I believe Coding agents won’t be the final solution but a transition period to something different. As the abstraction layer rises, we need to acquire skills to manage it. We’ll need to invent, create, and update those abstractions as new problems arise—ideally without relying on coding agents.
What I’m Experimenting With
Testing on your personal website is helpful if you have one. If not, create one using coding agents. Showcasing your work and what you can do will be more important for the future. Creating a personal website is easier than ever and serves as a good warm-up exercise to test different coding agents. When I see an interesting detail I saw in another website, I usually spin up Claude code and test that idea quickly.
I’m also building small tools that help my workflow. When you start a new project, finding a good idea can slow down or paralyze many developers. Focusing on problems you actually have and building things just for yourself breaks this developer lock. It enables you to find solutions to the problems you see around you.
For example, I have a lot of repositories both in my work and personal machine. I often switch projects using terminal, so I built a tool for this called grip. It also shows the current branch I am in, so managing different checkouts of the same project will be much easier for me. This was something I saw from the Boris Cherny’s tweet about his Claude setup.
I'm Boris and I created Claude Code. Lots of people have asked how I use Claude Code, so I wanted to show off my setup a bit.
— Boris Cherny (@bcherny) January 2, 2026
My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don't customize it much. There is no one correct way to…
Closing
I can say that right now, with enough oversight, coding agents accelerate my routine development, but active engagement with their output is crucial to prevent skill atrophy. I see them as powerful implementation engines offloading lower-level tasks, allowing me to focus on complex architecture and problem definition. But this handoff won’t happen overnight.