When ChatGPT became publicly available in late 2022, it quickly moved from being an experimental AI tool to a major topic of discussion in businesses. As companies began exploring practical ways to use artificial intelligence, expectations around technology teams also started to change. Engineering leaders were increasingly expected to determine where AI could deliver real value and how it could be introduced into everyday business operations.
For most technology leaders, the first practical decision was not which model to use. It was who should build the thing. Should the existing team pick it up, or should the company bring in people who specialise in AI?
There is no single right answer. But there is a sensible way to think about it, and it starts with being honest about what your current team can and cannot do.
What your current developers already bring
Your existing engineers know things no new hire will know for months. They understand how your data is structured and where it is a mess. They know which internal systems break if you look at them the wrong way. They know your customers, your release process and the shortcuts that were taken three years ago.
That context is worth a lot. Many first AI features are not technically hard from a modelling point of view. Summarising support tickets, tagging documents, drafting replies or adding a search box over internal policies can often be built by calling a hosted model through an API. A good backend developer can get a working version of these quite quickly.
So if your first use case is narrow and low risk, start with the team you have. You will learn a great deal about what the work actually involves, and that knowledge will make any later hiring decision much better.
Where generalists start to struggle
The trouble begins when the feature has to be reliable. Getting an answer from a model is easy. Knowing whether the answer is right, consistently, across thousands of different cases, is much harder. Is anyone on your team building a proper evaluation set? Do they know how to measure whether a change to the prompt made things better or just different?
Retrieval is another common sticking point. Systems that answer questions from your own documents depend heavily on how those documents are split, indexed and searched. Frameworks like LangChain and vector databases such as Pinecone make it easy to get started. They do not make it easy to get good results.
Then there is the work after launch. Models need monitoring and costs need watching. If you train or fine-tune your own models, you need proper pipelines for data, versioning and deployment on platforms like Amazon SageMaker, Azure Machine Learning or Google Vertex AI. These are specialist skills.
Watch for a few warning signs. The prototype works in demos but behaves oddly with real users. Nobody can explain why accuracy dropped last week. The team keeps rewriting prompts without any way of knowing whether they are improving. If you see these, your generalists have probably reached the edge of what they can do without help.
What specialists bring, and what they don’t
AI specialists have usually solved these problems before. They know how to set up evaluation, how to choose between a large hosted model and a smaller one, how to structure retrieval and how to keep a model healthy once it is in production. That experience can save months of trial and error.
But specialists have limits too, and it is worth saying so plainly. A new AI engineer does not know your business. Left alone, some will build something technically impressive that solves the wrong problem. Others may reach for fine-tuning a custom model when a well-designed prompt and good retrieval would have done the job just fine.
Experienced AI engineers are also in heavy demand, which affects both cost and how long hiring takes. That is one reason a lot of companies now look beyond their home market. India has a large pool of engineers working in machine learning, data engineering and generative AI, and businesses that want to hire ai developers often work with recruitment partners who can screen candidates on real technical ability rather than buzzwords on a CV.
The middle path most teams end up on
In practice, the answer for many companies is a mix. Keep your core engineers on the project, because they hold the business context. Add one or two specialists who own the AI-specific parts such as evaluation, retrieval design and model operations. Then make knowledge transfer an explicit part of their job, so your existing team gets stronger over time instead of more dependent.
The engagement model matters here too. If you are testing a single use case, a contract hire for a few months may be enough. If AI is going to sit at the centre of your product, permanent hires or a dedicated team make more sense. Just don’t commit to a large team before you have proof that the first use case works.
Questions to answer before you decide
Before you post a job description or assign the work internally, sit down with your team and answer these honestly.
- What exactly is the first use case, and how will you know it is working?
- What happens if the AI gives a wrong answer? Is it a minor annoyance or a legal problem?
- Does the feature need your own trained model, or can a hosted model do the job?
- Who will monitor it after launch, and how much of their time will that take?
- Does your current team actually want to learn this work, or would they rather stay on the core product?
That last question gets skipped more often than it should. Some developers are excited to move into AI work. Others are not, and pushing them into it rarely ends well.
A final thought
The choice between in-house developers and specialists is not a one-time decision. Most teams start one way and adjust as they learn. What matters is making the first choice with open eyes, based on the actual problem in front of you and not the pressure of the latest board meeting.
And if the board asks about AI again next quarter, at least you will have a better answer than “we’re looking into it.”
About The Author
Nikhil Vaidya
Nikhil Vaidya is the CEO of Prism HRC, a leading recruitment services company in India. Nikhil’s expertise in talent acquisition and has been instrumental in connecting hundreds of top-notch clients with exceptional IT talent over the last 15 years.
