What Do Remote AI Developers Build? Project-Type Breakdown from Cortance's Expert Network

A job post that asks for an "AI developer" can describe nine different jobs. One developer in our network spent fourteen months training detection models that run on board a drone. Another built the approval queue that stops a CRM agent from acting on a lead on its own. Both count as AI developers, and their daily work barely overlaps.

Remote AI developers mostly build the layers around a model rather than the model itself. Of 69 AI products in our developers' project history, 42 were built around existing models. They covered LLM features inside existing apps, retrieval over documents, agents with human approval steps and AI tooling for codebases. The remaining 27 trained or tuned models for computer vision, prediction and autonomous drone navigation.

Knowing that split matters before anyone writes a job description. A team that needs a booking assistant is hiring for different skills than a team that needs a model to find a football in a crowd of legs. The breakdown below shows what each type of work involved, with real projects and the developers who built them.

How We Counted 69 AI Projects

Cortance developers document each project in their profiles: what the product does, what they owned and which stack they used. Industry tags alone undercount AI work, so we pulled records four ways. We used the AI industry tag, AI skills such as OpenAI, LLM and RAG, free-text searches for agents, machine learning and computer vision, and the Defense tag. That gave 95 project records from developers who were active and available as of October 2026.

Every record was read in full rather than trusted by its tag. Fifteen records carried an AI-related tag but described no AI engineering, such as a storage protocol, a video marketing dashboard or a security guard app. Two adult-entertainment chat projects were excluded. Nine more records described a product already counted under another developer's name, so each product counts once, leaving 69 distinct products.

Two limits apply to the numbers. The sample reflects what AI developers chose to document, not every hour they billed. A product can also involve several kinds of work, so each one sits under its main type, and the categories never overlap in the counts below.

The Breakdown: What AI Developers Build, by Project Type

Computer vision and LLM features inside existing products tie for the largest group, with 11 products each. Retrieval, agents and AI tooling for software teams follow, and all language-model categories together account for 37 of the 69 products. Defense autonomy forms a separate cluster of six, almost all of it navigation, tracking and guidance for drones.

Job titles predicted the project type poorly. A developer with a mobile profile built optical tracking for drones, and several frontend engineers built the parts of AI platforms that users actually see. Reading the project record told us more than the role field ever did.

Building on Language Models

Language-model work made up 37 of the 69 products, and very little of it involved training. Most AI developers in this group connected an existing model to a business system, a document store or a content pipeline. The engineering problem was control: what the model may touch, what it must cite and what happens when a provider fails.

LLM Features Inside Existing Products

Yaroslav R. built the AI assistant layer for a flight-booking system with a .NET backend. The assistant could call only pre-approved operations through an allow-listed tool layer, and every input passed JSON Schema validation before reaching the database. Each booking action the AI started went into an audit log with its inputs, resolved parameters and outcome. In practice, the model behaves like a user with narrow permissions rather than like the system itself.

Retrieval and Document AI

Bohdan B. built a contract compliance tool on retrieval-augmented generation. Instead of an open chat over a document, the system runs each contract against a structured checklist and returns a verifiable result per rule. His quote-matching engine maps every finding back to its exact position in the source file, so auditors check evidence instead of rereading the whole contract. Each rule also runs in isolation, and one failed check never stops the rest of the review.

Retrieval shows up far beyond this one tool. Across the sample, 10 products used retrieval and 5 fine-tuned or custom-trained a language model, with two products doing both. Most retrieval projects in the sample answered questions about a company's own documents or knowledge base, which a general model cannot know without that context.

Generated Content as the Product

Ivan V. built the backend for Mindcast, an app that generates podcasts with cloned voices and avatars. Text came from OpenAI, while voices came from ElevenLabs, Resemble and Azure. He designed one internal model for all those providers, so the team could add or swap a vendor without rewriting the app. Audio reached listeners through WebSocket streaming, which turned latency into a product requirement rather than a backend detail.

Agents That Know When to Stop

Agent projects in the sample share one design habit: the agent stops before it does anything expensive. Six products describe allow-listed tools, human approval queues or confidence thresholds that pause the workflow. Market data points the same way. In McKinsey's State of AI survey (2026), about two in ten respondents said their organizations had reached the scaling phase with AI agents.

Oleh Sh. designed a multi-agent pipeline for a consumer veterinary health app. Separate stages built on LangGraph and Temporal handle symptom intake, retrieval, differential reasoning and the final recommendation. When confidence drops below a set threshold, the workflow halts at an explicit interrupt point instead of guessing. Every recommendation leaves the system as a structured verdict with a confidence score and a written rationale.

On a separate project, Oleh built a CRM agent that scores and routes leads, then halts and passes its recommendation to an operator for review. An immutable audit log records the recommendation, the confidence score, the operator and the final action. For a buyer, that detail is the useful signal. AI developers who can explain where an agent stops and who approves it have usually shipped one.

Pointing AI at the Codebase Itself

Seven products in the sample used AI to change how software gets built rather than what it does for end users. The same McKinsey survey found that 32% of respondents' organizations had decided against buying at least one software product because they could build it with agentic coding tools. Building that way still needs someone who sets the rules a coding assistant follows.

Danylo P. took over the frontend of a multi-tenant enterprise AI platform and refactored it for modularity. He wrote documentation aimed at both developers and AI coding assistants such as Claude Code, plus project-wide guidelines on conventions and architectural boundaries. A later UI redesign ran through Claude Design and Claude Code while existing business functions stayed intact. We describe this profile as AI-first software engineers: developers who make a codebase workable for AI assistants, not only for people.

Ivan S. worked one level lower, building custom Claude Code plugins and adapting skills to specific languages and framework versions. He packaged them so several teams could reuse the same setup across projects. Prompt iterations then targeted a specific failure: hallucinated APIs in generated code.

Models Trained for One Job: Predictive ML and Custom LLMs

Ten products trained or tuned a model for a single task. The list covers player-behavior forecasts for a game studio, oil-basin DNA classification, predictive maintenance for factory systems and research on agents that learn by playing a game. Work of this type calls for a developer who owns data preparation and evaluation, not only API integration.

Ivan S. also built an estimation system for a service company. A client describes a project in plain language and gets back a task breakdown with effort and cost. Ivan fine-tuned Phi-3 and later Phi-4 models at 8 billion parameters on the company's historical data, then exported them to ONNX for fully on-premise inference. No client data reached an external provider, and evaluation datasets let the team compare model versions before each rollout.

Computer Vision Outside the Lab

Computer vision accounted for 11 products, and most of them ran in conditions no benchmark dataset prepares a model for. Greenhouses, washing stations, sports pitches and phone cameras all appear in the sample. One handwashing monitor ran on a Raspberry Pi with an Intel Neural Stick, where every millisecond of inference mattered.

Michael Y. led a football analytics system that detects and tracks players and the ball from match video. The ball module had to cope with heavy occlusion and fast movement. To keep inference real-time, the team ran PyTorch models through NVIDIA TensorRT. Tracking coordinates then became player statistics such as distance covered, sprint counts and positional heatmaps, while GPU instances on AWS scaled up for match-day loads.

Defense: Autonomy Without GPS

Defense work forms a separate cluster of six products, and none of it resembles a chatbot. Two products solve navigation where GPS is jammed or missing, and four handle onboard detection, tracking and guidance for drones. The AI developers behind them moved between simulators, flight controllers and field tests, and half of these projects ran for more than a year.

Alexander C. led OMON, a visual-inertial navigation system for copter drones that fly without satellite signals. The system fuses camera images with IMU data, builds on the open-source OpenVINS estimator and runs on a Raspberry Pi connected to ArduPilot. In simulation, it held a 4 m error over a 1 km mission. Real flights were harder: a 5 km mission finished with a maximum error under 500 m, about 2-5% of the distance flown.

Viktoriia A. spent 14 months on onboard target detection and tracking, with YOLO models tuned to run on the drone and guidance through Pymavlink. Alex Kh. worked on optical tracking for FPV and fixed-wing UAVs, moving algorithms from the Liftoff and Gazebo simulators to field tests on real hardware. In his project, that sim-to-real step took a large share of the work. Lighting, background noise and speed in the field never match a simulator.

The AI Work That Isn't Model Work

Five products in the sample needed AI engineering with no model work from the developer at all. A voice-AI platform for medical practices needed a frontend, a workplace copilot needed a browser sidebar, and a computer vision product needed live dashboards for its detections. Searching for AI developers to fill these roles misses the point, because the core skill is product engineering.

Pavlo H. built the client-side WebRTC layer for an enterprise AI platform that streams a remote containerized browser to users. People click, type and scroll in that browser as if it ran locally, while WebSocket signaling routes their commands to the remote session. Pavlo also built a monitoring view for bitrate, packet loss and round-trip latency. None of it touches a model, yet it all decides whether the AI product feels usable.

Matching AI Developers to the Project Type

The project type should shape the job description before the first interview. The table below pairs each type of work with the profile that fits it and the evidence worth asking for in a first call.

For the first four rows, the strongest signal is a described control mechanism, not a model name. For the last three, the signal is a number from evaluation or field testing. Every case in this article comes from a developer's own project record, and that record is the first place to look for this evidence. Our AI engineer profiles list projects in the same format.

AI Developer Projects FAQ

1. Do AI developers mostly build on existing models or train their own? Most AI developers in our sample built around existing models: 42 of 69 products centered on integration, retrieval, agents or tooling. The remaining 27 trained or tuned models for computer vision, prediction or drone autonomy. Training-heavy work usually points to a data science profile, while integration work points to backend and full-stack engineers.
2. What is the difference between an AI engineer and a full-stack developer with AI experience? An AI engineer owns model behavior, while a full-stack developer with AI experience owns the product around the model. In our sample, the second profile built booking assistants, streaming layers and browser sidebars. The first trained detection models, tuned retrieval and ran evaluations. Many products need both, and the project type decides who leads.
3. RAG or fine-tuning: which do real AI projects use more often? Retrieval-augmented generation appeared twice as often as fine-tuning in our sample: 10 products used retrieval, while 5 fine-tuned or custom-trained a language model. Two products did both. Retrieval fits when answers must cite current documents, and fine-tuning fits narrow tasks that need consistent output, such as project estimates.
4. How can I check an AI developer's project experience before hiring? Ask for one control mechanism or one measured result from a past project. A developer who shipped an agent can explain where it stops and who approves its actions. Computer vision engineers can quote error or accuracy figures from evaluation or field tests. Vague answers about "working with AI" usually signal adjacent rather than hands-on experience.
5. Are AI agents used in production or mostly in prototypes? AI agents do run in production, but mostly behind human checkpoints. Six products in our sample describe allow-listed tools, approval queues or confidence thresholds that pause the agent. McKinsey's survey found that about two in ten respondents had reached the scaling phase with agents, so most organizations remain early in adoption.

Hiring for the Work, Not the Label

"AI developer" covers drone navigation, booking assistants and coding plugins, and these 69 products show how little those jobs share. About six in ten were built around existing models, where the hard part was control, retrieval quality and product engineering. The rest trained models and stood or fell on evaluation numbers.

Once you know which row of the table your project belongs to, the search gets narrower and faster. A Cortance shortlist can start from AI developers who have already built that type of system.