What Are Remote AI Developers Actually Building? A Full Breakdown of 69 Real Projects

When a job posting says "AI developer," it might be describing nine completely different jobs. Cortance's review of 69 AI product projects across its developer network delivers an answer far more fragmented than expected.

Core Insight: Hiring teams often treat "AI developer" as a single unified role, but real AI projects vary enormously in engineering complexity. Understanding the mapping between project types and developer profiles is the prerequisite for building an AI team efficiently.

One Label, Nine Professions

In Cortance's developer network, one developer spent fourteen months training detection models that run on drones; another built an approval queue that stops a CRM agent from disposing of sales leads on its own without human confirmation. Both count as "AI developers," and their day-to-day work has almost no overlap.

Remote AI developers mostly build the engineering layer around models, not the models themselves. Of the 69 AI products, 42 are built on existing models, covering LLM features inside existing applications, document retrieval, agents with human approval steps, and AI tools aimed at codebases. The remaining 27 train or fine-tune models for computer vision, prediction, and autonomous drone navigation.

This split needs to be clear before writing a job description. A team that needs a booking assistant and a team that needs a model to identify a soccer ball in a crowd require completely different skill sets.

How the 69 Projects Were Counted

Cortance developers record each project in their profiles: product features, their own responsibilities, and the tech stack. Industry labels alone undercount AI work, so the team extracted records along four dimensions: AI industry tags, AI skill tags such as OpenAI/LLM/RAG, full-text searches for agents/machine learning/computer vision, and defense tags. As of October 2026, active available developers produced 95 project records in total.

Every record was read in full rather than judged by its labels. Fifteen records carried AI-related tags but did not describe AI engineering, such as storage protocols, video marketing dashboards, or security applications. Two adult entertainment chat projects were excluded. Another nine records described products already counted under other developers' names, leaving 69 unique products after deduplication. Two boundaries need stating: the sample reflects what developers choose to record, not all hours worked; and a product may involve multiple kinds of work, so it is classified by primary type, with categories that do not overlap.

The Project Type Distribution Behind the Numbers

Computer vision ties with LLM features inside existing products as the largest category, at 11 products each. Retrieval, agents, and AI tools for software teams follow closely, and all language-model-related categories together account for 37 of the 69 products. Defense autonomy forms a separate cluster (6), almost entirely navigation, tracking, and guidance for drones.

Job titles barely predict project type. One developer with a mobile profile built an optical tracking system for drones, while several frontend engineers build the parts of AI platforms that users actually touch. Reading project records is more informative than any title field.

Building Around Language Models

Language model work accounts for 37 of the 69 products, and very little of it involves training. Most AI developers in this group connect existing models to business systems, document stores, or content pipelines. The engineering problem is control: what the model can touch, what it must cite, and what happens when the service provider goes down.

LLM Features Inside Existing Products

Yaroslav R. built an AI assistant layer for a flight booking system on a .NET backend. The assistant can only invoke pre-approved operations through a whitelisted tool layer, and every input passes JSON Schema validation before reaching the database. Every AI-initiated booking action enters an audit log recording the input, parsed parameters, and result. In practice, the model behaves more like a user with very narrow permissions than like the system itself.

Retrieval and Document AI

Bohdan B. built a contract compliance tool on top of RAG. Rather than open-ended conversation over documents, the system runs each contract through a structured checklist, returning verifiable results rule by rule. Its citation matching engine maps every finding back to the exact location in the source file, so auditors can check the evidence directly without rereading the whole contract. Each rule runs independently, so one failed check does not interrupt the rest of the review.

Retrieval is applied far beyond this one tool. Ten products in the sample use retrieval, five fine-tune or custom-train language models, and two products do both. Most retrieval projects in the sample answer questions about a company's own documents or knowledge base, context a general model cannot answer without.

Generated Content as the Product

Ivan V. built the backend for Mindcast, an app that generates podcasts with cloned voices and avatars. The text comes from OpenAI; the voices come from ElevenLabs, Resemble, and Azure. He designed an internal model over all of these providers so the team can add or swap vendors without rewriting the app. Audio reaches listeners via WebSocket streaming, which makes latency 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 doing anything expensive. Six products describe whitelisted tools, human approval queues, or confidence thresholds that pause the workflow. Market data points the same way. According to McKinsey's State of AI survey (2026), about one in five respondents say their organization has reached the scaling stage 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 stops at an explicit interruption point rather than guessing. Every recommendation leaves the system as a structured verdict with a confidence score and written rationale.

In another project, Oleh built a CRM agent that scores and routes leads, then pauses and passes the recommendation to an operations person for review. An immutable audit log records the recommendation, the confidence score, the operator, and the final action. For buyers, this detail is the useful signal — an AI developer who can explain where the agent stops and who approves it has usually actually shipped an agent.

Pointing AI at the Codebase Itself

Seven products in the sample use AI to change how software is built, not end-user features. The same McKinsey survey found that 32% of surveyed organizations decided not to buy at least one software product because they could build it themselves with agentic coding tools. But building this way still requires someone to set the rules for the coding assistant.

Danylo P. took over the frontend of a multi-tenant enterprise AI platform and refactored it into a modular architecture. He wrote documentation aimed at both developers and AI coding assistants such as Claude Code, plus project-level guidance on conventions and architectural boundaries. A later UI redesign was done through Claude Design and Claude Code, with existing business functionality kept intact. Cortance describes this profile as an "AI-first software engineer": someone who makes a codebase usable for AI assistants, not just for people.

Ivan S. works lower in the stack, building custom Claude Code plugins and adapting skills for specific language and framework versions. He packages them so multiple teams can reuse the same configuration across projects. Prompt iteration then targets a concrete failure mode: API hallucinations in generated code.

Models Trained for a Single Task: Predictive ML and Custom LLMs

Ten products train or fine-tune models for a single task, spanning player behavior prediction for a game studio, DNA classification for oil fields, predictive maintenance for factory systems, and agent research that learns by playing games. This kind of work needs developers who can own data preparation and evaluation, not just API integration.

Ivan S. also built an estimation system for a services company. Clients describe a project in natural language, and the system returns a task breakdown with effort and cost. Ivan fine-tuned Phi-3 and later Phi-4 models at the 8B parameter scale, using the company's historical data, and exported to ONNX for fully local inference. Client data never reaches any external provider, and an evaluation dataset lets the team compare model versions before every deployment.

Computer Vision That Leaves the Lab

Computer vision accounts for 11 products, and most run under conditions benchmark datasets cannot prepare for. Greenhouses, car washes, sports fields, and phone cameras all appear in the sample. One handwashing monitor runs on a Raspberry Pi with an Intel Neural Stick, where every millisecond of inference time matters.

Michael Y. led a soccer analytics system that detects and tracks players and the ball from match video. The ball module must handle severe occlusion and high-speed motion. To keep inference real-time, the team runs PyTorch models through NVIDIA TensorRT. Tracking coordinates are then converted into player statistics such as distance covered, sprint counts, and positional heatmaps, with GPU instances on AWS scaling on demand on match days.

Defense: Autonomous Navigation Without GPS

Defense work forms a separate cluster (6 products), none of which looks like a chatbot. Two products tackle navigation when GPS is jammed or missing, and four handle onboard detection, tracking, and guidance for drones. These AI developers switch between simulators, flight controllers, and field tests, and half of the projects ran for more than a year.

Alexander C. led OMON, a visual-inertial navigation system for rotorcraft drones flying without satellite signals. The system fuses camera images with IMU data, running the open-source OpenVINS estimator on a Raspberry Pi connected to ArduPilot. In simulation, a 1 km mission stays within 4 meters of error. Real flights are harder: a 5 km mission completed with a maximum error under 500 meters, about 2-5% of the distance flown.

Viktoriia A. spent 14 months on onboard target detection and tracking, tuning YOLO models to run on drones and guiding via Pymavlink. Alex Kh. worked on optical tracking for FPV and fixed-wing drones, moving algorithms from Liftoff and Gazebo simulators to field tests on real hardware. In his projects, this sim-to-real step took up a large share of the work. Lighting, background noise, and speed in the field never match the simulator.

Visual-inertial odometry (VIO) works by fusing camera images with IMU (inertial measurement unit) data for pose estimation instead of relying on GPS. The IMU provides high-frequency acceleration and angular velocity, but integrating it drifts over time; camera images provide low-frequency but long-term stable visual constraints. VIO algorithms use tight coupling to place both into a single optimization framework, using visual observations to constrain IMU integration error and achieve long-duration, high-precision position and attitude estimation. OpenVINS is one of the open-source tightly-coupled VIO estimators in this field, able to run directly on embedded platforms like the Raspberry Pi and interact with ArduPilot flight controllers via protocols such as MAVLink, enabling autonomous drone flight when satellite signals are unavailable.

Sim-to-Real refers to moving algorithms trained or tuned in simulators like Gazebo and Liftoff onto real hardware. Simulators cannot fully reproduce lighting changes, background noise, aerodynamic disturbances, and sensor error, so algorithms that perform well in simulation often degrade quickly in the field. Closing this gap usually requires domain randomization, online calibration, and extensive field tuning — which is why it takes up so much of the time in projects by Viktoriia A., Alex Kh., and others.

AI Work That Is Not Model Work

Five products in the sample need AI engineering but involve no model work by the developer at all. A healthcare organization needed a frontend for a voice AI platform, a workplace copilot needed a browser sidebar, and a computer vision product needed a real-time detection dashboard. Searching for an AI developer 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, streaming a remote containerized browser to users. People click, type, and scroll inside that browser as if it ran locally, while WebSocket signaling routes their commands to the remote session. Pavlo also built monitoring views for bitrate, packet loss, and round-trip latency. None of this touches a model, yet all of it determines whether the AI product is usable.

Matching AI Developers to Project Types

Project type should shape the job description before the first interview. The table below pairs each kind of work with the profile that fits and the evidence worth requesting on a first call.

For the top four rows, the strongest signal is a clearly described control mechanism, not model names. For the bottom three rows, the signal is numbers from evaluation or field tests. 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.

Conclusion: Hire for the Work, Not the Label

"AI developer" spans drone navigation, booking assistants, and coding plugins, and these 69 products show how little these jobs have in common. About six in ten build on existing models, where the hard part is control, retrieval quality, and product engineering. The rest train models, where success or failure comes down to evaluation numbers.

When you know which row of the table a project falls into, the search becomes narrower and faster. Starting from AI developers who have already built that kind of system is the more practical starting point.