These days, most of my code is generated with tools like Claude and GPT. I'm curious how other developers are splitting their time between writing code manually and using AI for implementation. Do you still write most of your code yourself, or mainly review and direct generated code? Also, what techniques help keep AI focused so it doesn't invent unnecessary abstractions, add unrequested code, or burn through tokens?
4 Answers
I’ve shifted from writing nearly everything by hand to spending more time on requirements, architecture, review, and testing. AI can turn a two-hour implementation into ten minutes, especially for repetitive work, but I still inspect the generated code function by function. For anything involving unusual business logic, tricky algorithms, CSS, or outdated APIs, manual implementation is often faster than debugging an overly confident generated answer.
I use AI mostly as a design and brainstorming partner, then implement most of the final solution myself. It often suggests code that works but is poor in performance, API design, maintainability, or plain common sense. Letting it generate everything can also make people less critical during review and gradually weaken their own coding skills.
I still write a large portion manually because I enjoy it, want to understand the implementation, and like having control over the result. AI is useful for boilerplate, experiments, and quick prototypes, but I’m much more comfortable designing the solution and writing the important parts myself. Short, tightly scoped prompts also help prevent it from adding unnecessary extras.
Same here. The less room you give it to interpret the task, the less likely it is to add wrappers, dependencies, or several alternative implementations you never asked for.
My workflow is mixed: I provide the architecture and constraints, let AI handle repetitive CRUD and boilerplate, then review and refactor every meaningful change. The key is to treat it like a junior contractor. Give it a small task, clearly state what it must not touch, ask for a proposed diff or plan first, and keep the context fresh. Strong typing, tests, linters, static analysis, and documented project rules are more reliable than hoping for a perfect prompt.
That approach works best for me too. A project instruction file with explicit boundaries, plus tests that run automatically, cuts down on both token waste and bloated implementations.
Exactly. Debugging code you don’t understand is still programming, and sometimes it takes longer than writing the small feature yourself in the first place.