DEV Community

patrik muravski
patrik muravski

Posted on

How do you code with AI 2026?

Hi,

I'm an average beginner developer with about one year of experience, and I'm wondering how people actually use AI for coding.

I've been trying to work in small iterations—for example, first asking AI to write function A, then in a separate prompt function B, and finally asking it to combine both into feature C.

I've also tried implementing end-to-end features by first creating a plan and then implementing it. However, I find it really difficult to validate whether all the security considerations, edge cases, and best practices are actually covered. AI makes it very easy to generate code, but I end up spending a lot of time reviewing both the plan and the implementation separately. Sometimes it feels like it actually takes longer than coding without AI.

I haven't been using frameworks or methodologies like OpenSpec, nor have I used Claude plugins, skills, or similar tools. So far, I've only been using the raw Claude Code harness, GitHub Copilot, and Cursor—nothing external.

I'm curious about how other developers approach this.

How do you prefer to code with AI? For me, long-term maintainability and code quality are essential, but maybe I'm thinking about it the wrong way. Perhaps those things don't matter as much anymore?

I'm also really curious how high-performing engineering teams, like the ones at Google, are actually using AI in their day-to-day development.

Thanks in advance! I'd really appreciate hearing some HUMAN opinions.

Top comments (2)

Collapse
 
marcusykim profile image
Marcus Kim

Splitting function A and function B into separate prompts before combining them into feature C can work, but it also hides the interface assumptions where many bugs appear. I'd use the raw Claude Code/Copilot/Cursor workflow less as a code factory and more as a loop: define acceptance tests and failure cases first, generate the smallest diff, then review only what changed. Security and edge cases still require human judgment, so maintainability matters more, not less, when AI increases the amount of code you can produce. If reviewing the plan and implementation separately costs more than writing the feature, the useful optimization is.

Collapse
 
akbar_952c24f291bf201eb0c profile image
Akbar

Your instinct that reviewing costs more than writing is usually a signal about where you're pointing the AI, not about AI itself. Two things helped me most.

Write the acceptance criteria and failure cases before you generate anything, and have the AI write tests from that spec first. Your review question then becomes "do these tests capture what I meant?" rather than "is all this code correct?" - a much smaller thing for a human to check reliably.

Keep each generated unit small enough that the diff is the review. Your A-then-B-then-combine approach is close, but the bugs tend to live in the seam where they combine, so it's worth specifying that interface yourself rather than letting the model invent it twice.

On security and edge cases: put the checklist in the repo rather than in your head. Even a plain conventions file the tool reads on every request (CLAUDE.md, .cursorrules, Copilot instructions) gets you most of the value of the skills/plugins ecosystem you mentioned, at almost no setup cost. It moves those concerns from something you catch in review to something the model is told up front.

And maintainability matters more, not less - the cost of code you don't understand arrives the first time it breaks at 2am. The split I've landed on: let AI do what you'd have to look up anyway (boilerplate, tests, unfamiliar libraries), and hand-write the core logic you'll maintain for a year.

(I run oxygenlabs.in and teach this workflow to working devs - happy to go deeper on any of it.)