How AI Changed the Way I Build Software

AI didn't make me a faster typist. It changed which parts of my job take time. The typing got cheap, so the thinking, reviewing and deciding became the whole job, and I had to get better at those.

I use Claude and ChatGPT every day, plus coding agents that can read a repository, run commands and propose changes. I also lead a team now, as a Technical Project Manager at NovaNext, which means I see AI-assisted code from both sides: the code I generate and the code other people generate and send me to review.

This is an honest account of what changed, what didn't, and where I've drawn lines.

What actually got faster

Some work almost disappeared from my week.

• Boilerplate: serializers, form schemas, TypeScript types from a JSON sample, CRUD views that follow an existing pattern.
• First drafts of tests: especially table-driven tests, like the permission matrix tests I described in How I Designed RBAC for 15+ User Roles.
• Reading unfamiliar code: "explain what this module does and who calls it" saves a lot of clicking around.
• Migrations and refactors with a clear rule: "rename this field everywhere and update the serializers and the types" is exactly the kind of tedious, mechanical task agents do well.
• Small scripts: the one-off Node or Python script to convert a data file or build an index.

When I turned my portfolio into a PWA, I used an AI assistant to talk through caching strategies and to draft parts of the service worker. But I rewrote large chunks after testing, because the first draft cached things it shouldn't have. I wrote that process up in I Turned My Portfolio Into a PWA — Here's How.

What didn't get faster

Here's what surprised me. The total time to ship a good feature dropped, but much less than the time to write the code did. Because writing code was never most of the work.

These still take as long as they always did:

1. Understanding the problem. No model knows that a restaurant's captain role needs to void sent items but a waiter shouldn't.
2. Domain modelling. Deciding that an order line, not an order, is the unit of work is a judgment call based on how real people use the product.
3. Trade-offs. Session auth or tokens, one repo or two, build it now or later. AI can list options. It can't own the consequences.
4. Talking to people. Clients, designers, teammates. A lot of my job is making sure everyone means the same thing by the same word.

If anything, these became a bigger share of my day. When the code is quick to produce, a wrong decision gets built faster too.

Review became the core skill

The biggest change is that I review far more code than I write. That was already true as a tech lead, but AI pushed it further, because I review my own generated code the same way I review a teammate's.

AI-written code has a particular texture. It's usually tidy and confident. It compiles. It often looks more finished than it is. The bugs hide in places that look reasonable:

• Permission checks in the wrong layer, or missing on one endpoint out of five.
• Error handling that swallows errors, a catch that logs and returns null and lets the UI pretend all is well.
• Plausible but wrong APIs, especially for frameworks that changed recently. Next.js 16 and React 19 conventions differ from what a lot of training data shows, so I check against the docs on nextjs.org instead of trusting the suggestion.
• Over-engineering: an abstraction layer for a function called once.
• N+1 queries in Django, because a loop over related objects looks innocent in a diff.

AI-generated code looks finished before it is. Review it like it came from a confident new teammate who's never seen your product.

How I work with agents now

I treat a coding agent like a capable new developer on the team. Give it context, give it a narrow task, and check the result.

Context first

Agents do much better when the repository explains itself. I keep an instructions file at the root of projects: the stack and versions, folder conventions, commands to run tests, and the rules that are easy to break, like "every service that changes money calls ensure_can" or "never cache RSC payloads in the service worker". It's also useful for humans joining the project, which is a nice side effect.

Small, verifiable tasks

"Build the billing module" goes badly. "Add a split_by_item service in apps/billing/services.py following the pattern of split_equal, with tests for rounding" goes well. The narrower the task, the easier the review.

Make it prove things

I ask the agent to run the tests, the type checker and the linter, and to show me the output. If something can be verified by a command, I want it verified by a command, not by the agent saying it's done.

Keep the decisions

I decide the architecture, the data model and the public API shapes. The agent fills in the implementation inside those lines. When I've let an agent make structural decisions, I've usually spent longer undoing them than I saved.

What changed for the team

Leading a small team, AI raised a few new questions I didn't expect.

• Juniors can produce a lot of code they can't explain. So in reviews and mentoring sessions I ask "walk me through why this works" more often. If they can't, we go through it together.
• PRs got bigger. I push back on that. A large generated diff is harder to review than the same feature written in three small commits.
• Consistency matters more. When patterns are clear and documented, AI follows them. When the codebase has three ways of doing the same thing, AI picks a random one, often a fourth.
• Nobody merges what they haven't read. That's the one rule I'm strict about.

I also see a real upside for developers here in Nepal. Good documentation and senior mentors aren't always easy to find locally, and an assistant that can explain an unfamiliar Django feature at midnight lowers the barrier a lot. It works best when it's used to learn, not just to paste.

Where it's genuinely great for a designer-developer

Because I came from UI/UX, one change I enjoy is how fast I can go from an idea to something clickable. I can describe a component in terms of the design tokens and states I already defined in Figma, get a first version in minutes, and spend my time adjusting spacing, states and accessibility. The loop between design intent and working UI got much tighter.

What it hasn't replaced is taste. It will happily generate a dashboard with eleven colors and four font sizes. Knowing that's wrong is still my job.

Where I've landed

AI moved my effort from writing to deciding and reviewing. I write less boilerplate, I read more code, and I spend more time on the problem itself. The developers who'll do well with these tools aren't the ones who generate the most code. They're the ones who know what good code looks like for their product and can tell, quickly, when they're not looking at it. That skill came from years of writing code by hand, and I don't think there's a shortcut around it.