Node.js interview questions: Working with an AI assistant

I try to verify as I go, I don't save it all up for one big pass at the end. Every slice the assistant generates gets a read before I move on, and I run the tests pretty often so problems show up early. If something looks wrong I'll ask the assistant to explain what it did, or just tell it to fix it. Before I call a change done I make sure the whole suite passes and I read the final diff one more time. The type checker and the linter are running the whole time anyway, so they catch the mechanical mistakes for me. My main rule is basically that unverified code shouldn't pile up. The assistant is fast, it's easy to just keep generating, so I try to keep my checking pace matched to the accept.

I keep it away from anything where a mistake would be expensive. So core business logic, security-sensitive code, anything touching authentication or payments, I write that myself, because those need careful human judgment. Architecture decisions too, since they depend on context about our systems and our team that the model just doesn't have. Where it does well is the routine work. Boilerplate, tests, small utilities, documentation, explaining code, all of that fits. So I lean on it when the task is well-defined and low-risk, and I do the high-stakes thinking myself. It's a tool with limits, and I think the job is knowing where it's strong and using it there. When I'm not sure which side a task falls on, I default to writing it myself and only reach for the assistant once the shape is clear.

I hold it to the same standard as anything else, honestly. It has to be correct, readable, tested, consistent with our patterns. The difference is I read it more carefully, because AI code can look right while being subtly wrong. So I check that it actually solves the problem, that the edge cases are handled, that the tests mean something. I also watch for code that reads like it came out of a generic tutorial instead of being fitted to our codebase, and for unnecessary complexity, since the models sometimes over-engineer things. If an API looks unfamiliar I'll verify it's real. But the author is still responsible for what they submit, so I treat the human as the author no matter what tool produced the text.

My main defense is just never trusting code I haven't run. Hallucinated APIs usually fail the first time they execute, so running the code or its tests catches most of them right away. For anything unfamiliar I'll check the official docs, make sure the method actually exists and takes the arguments the model says it does. Type checking helps here too, TypeScript will flag a method that doesn't exist on a type. I'm extra careful with the less common libraries, that's where the model invents things more often, and with anything version-specific. And when it suggests a package to install, I confirm the package actually exists and is maintained, not something the model made up. Between running the code, the types, and a quick docs check, I think very little gets through.

I give it as much context as I can. What the code should do, the language and framework, our conventions, and I paste in relevant snippets from the codebase so the output actually fits in. I try to be specific about requirements, and I break big asks into smaller steps. If the first answer misses, I refine the prompt and run it again until it converges. I usually ask for tests along with the implementation too, and sometimes I'll have the model explain its approach first so I can course-correct before it writes any code. Treating it like a very fast junior developer works pretty well for me. Clear instructions go in, decent code comes out. The quality of what you get back tracks the quality of what you asked for, basically.

I always ask for tests along with the implementation, and then I review both. The tests need to cover the main functionality, the edge cases, the error handling. I add whatever cases the model missed, especially around boundaries. Everything runs locally before it goes into a PR, and then CI runs the full suite again anyway. One thing I do check is whether the tests assert meaningful behavior, because generated tests sometimes only check that a function returns something. Coverage tools help me confirm the new code is actually exercised. The bar is the same as for human code, really. If the tests wouldn't catch a regression they're just decoration, so I make sure they genuinely pin down the behavior.

I apply the same security fundamentals I'd apply to any code. Validate inputs, parameterize queries, never build shell commands from user data, keep secrets out of source, least privilege everywhere. Generated code just gets extra scrutiny, because the model doesn't know our threat model or which inputs are attacker-controlled. So I check the authentication and authorization paths carefully, I look at how errors are handled so we're not leaking internals, and I make sure any crypto uses standard libraries rather than something homemade. On dependencies I stick to well-known packages and run the usual audit tooling. The model produces plausible code, and security is kind of where plausible gets dangerous, so a human review is always required. That's the rule I'd hold no matter what.

My rule is pretty simple, I never merge code I don't understand. I read everything the assistant produces, and if something's unclear I ask it to explain until I could have written the code myself. I try to stay the architect too. The assistant fills in implementations, but I decide the structure, so the overall design stays in my head. Regular code review keeps the team familiar with each other's changes, and decent documentation captures the intent behind the code. When I feel some distance from a module, I'll spend an afternoon reading it or stepping through it in the debugger. Understanding is something you keep up on purpose, I think. The tool tempts you to go faster than your comprehension, and you kind of have to refuse, because you're the one who'll maintain the result.

The policy I'd write is basically, assistants are allowed and honestly encouraged, but the engineer is fully responsible for anything they submit. The AI wrote it is never an excuse. All code goes through the same review process regardless of where it came from, though reviewers should know when a change is heavily AI-generated so they can review accordingly. Nothing sensitive goes into prompts, so no secrets, no customer data, and only approved tools with the right data-handling agreements in place. Tests and CI checks apply to everything equally. And for the genuinely sensitive areas like security and payments, a senior engineer stays closely involved rather than leaving the work to generation. It mostly boils down to one idea, I think. Use the productivity, and keep the accountability with humans.

First I'd make sure I understand the problem myself before involving the tool at all. So restate the requirements, sketch an approach. Then I'd use the assistant to speed up the implementation, have it generate boilerplate, write helpers, draft tests, that kind of thing. I'd review each suggestion before accepting it rather than trusting it blindly, and I'd keep you in the loop by explaining what I'm asking for and why. I'd test as I go instead of hoping it all works at the end. The division is basically that I direct and the assistant accelerates. The design decisions are mine, the typing is shared, and everything gets verified before I build on it. And I'd say when I disagree with a suggestion, since that shows judgment rather than dependence, I think.

Before I accept anything I read the whole diff and make sure I understand what it's doing. If I can't explain it, I don't accept it, simple as that. I check that it handles errors and edge cases, that it matches our codebase conventions, and that any APIs it calls are real and used correctly. Then I run the tests, or write a quick one if nothing covers the change, and I only build on the code once it passes. If a piece is unclear I'll ask the model to explain it or simplify it. My rule is basically to assume nothing about generated code and verify everything that matters. The speed of generation should never push code through faster than I can actually evaluate it.