AI-Assisted Development: A Working Engineer's Honest Take

Every engineer I know uses AI tools now. I use them daily — across the Java/Spring Boot services I built at LXME, the C#/.NET work I do at CarWale, and the TypeScript I write for this site. But after months of daily use, I've developed strong opinions about where they earn their keep and where they quietly make you worse.

Where AI genuinely helps

Boilerplate and scaffolding. Generating a DTO, a CRUD repository, a config class, or a test skeleton is faster than typing it. The output is predictable and the stakes are low.

Translating between stacks. Moving from stream().map().collect() to LINQ, or from a Java pattern to its C# equivalent, is exactly what these tools are good at. They've compressed my stack-switch from weeks of friction to days.

Explaining unfamiliar code. Dropping a dense method or a cryptic regex into a chat and asking "what does this do?" is a legitimately great use. It's like a faster Stack Overflow that's read the whole file.

Rubber-ducking design. Asking "what's wrong with this approach?" surfaces considerations I might have skipped — even when I disregard the answer.

Where AI quietly hurts

The confidence trap. AI generates plausible code. Plausible is not correct. In fintech especially, an answer that looks right and compiles is dangerous if you don't verify the edge cases — rounding, concurrency, idempotency.

Skill atrophy is real. If you let the tool write every loop and every query, you stop practising the fundamentals. I deliberately write the hard 10% myself — the transaction boundaries, the tricky algorithms, the state machines.

Context blindness. The model doesn't know your codebase's conventions, your team's constraints, or the business rule that lives in someone's head. It optimises for "looks reasonable," not "fits here."

My working rules

1. I own the design, the AI owns the typing. Decisions about boundaries, data flow, and correctness are mine. Keystrokes are negotiable.
2. Never ship code I can't explain. If I can't walk a teammate through a generated block line by line, it doesn't go in.
3. Verify the edge cases myself. Happy path is what AI is best at; I focus my review energy on what AI handles worst.
4. Use it to learn, not to avoid learning. When it shows me an unfamiliar pattern, I ask why, not just what.

The uncomfortable truth

AI levels the floor and, used carelessly, lowers the ceiling. It makes competent engineers faster and can make struggling engineers dependent. The differentiator is no longer "can you write this code" — it's "can you judge whether this code is right."

The tool amplifies whatever you already are. If you're rigorous, it compounds your rigour. If you're sloppy, it compounds that too.

I'll keep using these tools every day. But I'll keep doing the thinking myself — because that's the part that's actually mine.