Chosen for the problem, not the résumé.

Against four questions: does it fit the problem, can it be operated by the team that will own it, is it likely to still be maintained in five years, and does it lock you to one vendor. Novelty is not on that list.

Yes, and usually we should. Rewriting a working system in a technology we prefer is rarely in your interest. We work in the stack you run, and recommend change only where a specific constraint makes the current choice genuinely costly.

Yes, as an accelerant under review, not as a substitute for engineering judgement. All generated code passes the same review, testing and security scanning as anything else. Client code is never sent to services that would train on it.

We bias toward widely-adopted, open technologies with large communities precisely to limit that risk, and we isolate third-party dependencies behind interfaces so a replacement is contained. Where it happens, migration is planned rather than forced.

Extensively, and we track licences as a matter of course, because a copyleft dependency in a commercial product is a real legal exposure. Dependency and licence auditing is part of delivery and part of our due diligence work.