Beyond "Uses Copilot" — Developers Who Build With LLMs
A discipline-specific hire for teams building systems that use large language models as a working part — agent orchestration, tool-calling, retrieval-grounded prompts, and evaluation of AI output.
Using AI Tools to Code, or Building Systems That Use AI
These get conflated constantly, and they are different skills.
AI as a tool for writing ordinary software
- Uses an AI coding assistant to build a web app, an API, a mobile screen — the LLM helps write the code.
- The finished product does not itself call a language model at runtime.
- Right fit for the large majority of projects on this marketplace.
AI as a working part of the system itself
- Builds the product's own agent logic, tool-calling interfaces and retrieval pipelines — the LLM is load-bearing at runtime.
- Designs for graceful failure, grounding and drift, not just correct-looking output on a good day.
- Right fit specifically when the product itself is built around an LLM doing real work.
What This Role Actually Builds
Closer to operating a system than writing a clever one-off prompt.
Agent orchestration
The logic that decides what an agent does next, when it hands off, and when it stops rather than looping forever.
Tool-calling
Defining what tools a model can invoke, how it decides which one, and what happens when it picks the wrong one.
Retrieval-grounded prompts
Pulling real data into a prompt so answers are grounded in your content, not the model's unverified memory of the world.
Evaluation of outputs
Building the harness that scores whether responses are actually correct and catches quality drift over time, not eyeballing a handful of examples.
Judgement Specific to This Discipline
The same dual-axis philosophy as every developer here, aimed at a different kind of system.
Graceful failure
Can they design a prompt or agent step that fails in a visible, handled way, instead of returning a confident wrong answer that looks fine until someone checks it?
Grounding and hallucination
Do they actually understand why a model hallucinates and design against it, rather than treating it as an occasional glitch to patch over later?
Evaluation built in
Do they ship an evaluation step alongside the feature, or treat quality checking as an afterthought once something has already gone wrong in production?
Do You Actually Need This Discipline?
Being specific about who does not need this earns more trust than another feature list.
What a Good Brief Looks Like
The more specific the brief, the better the match — this discipline in particular covers a wide range of actual work.
Useful to tell us
What the agent or prompt system is meant to do, what data it needs to stay grounded in, whether it takes real actions or only produces text, and what "wrong" costs you if it happens in production.
Not required upfront
A finished architecture or a chosen model provider. Part of what this discipline brings is helping you make those calls, not just executing a spec you already wrote.
Questions About This Discipline
What does a prompt and agent engineer actually do day to day?
They design and maintain the systems that use large language models as a component — agent orchestration logic, tool-calling interfaces, retrieval pipelines that ground prompts in real data, and the evaluation harnesses that check whether the output is actually good. It is closer to building and operating a system than to writing a clever one-off prompt.
How is this different from a general AI-fluent developer?
A general AI-fluent developer uses AI coding tools well to build ordinary software — a web app, an API, a mobile screen. A prompt and agent engineer builds software where an LLM is a load-bearing part of the system itself. The first is about how you build; the second is about what you are building. Most projects need the first. Some need both.
What do you specifically vet for in this discipline?
Whether they can design a prompt that fails gracefully instead of failing silently, whether they understand grounding and hallucination well enough to reduce it rather than just hope it does not happen, and whether they build evaluation into what they ship rather than eyeballing outputs and calling it done. Fundamentals like error handling and system design are checked too — the same engineering judgement bar applies here, aimed at a different kind of system.
When does a client actually need this specific discipline?
When the product itself is built around an LLM doing real work — an agent that takes actions, a support system that has to stay grounded in your documentation, a pipeline where the model's output feeds directly into something consequential. If AI is a feature bolted onto otherwise ordinary software, a general full-stack developer who uses AI tools well is usually the right hire instead.
Can a prompt and agent engineer also do general full-stack work?
Often, yes — most come from a full-stack or backend background and added this discipline on top. But the reverse is not automatically true, and we match against the specific need you describe rather than assuming general AI-tool fluency covers agent and prompt work.
How do you evaluate whether a prompt or agent system is good, given there is no fixed benchmark to cite?
By looking at what the candidate builds into their own work: does their system fail predictably when the model gets something wrong, is there an evaluation step that catches drift over time, and can they explain why a design choice reduces hallucination in a specific case rather than gesturing at a tool's general reputation. We do not cite benchmark scores because they date badly and rarely predict real-world behaviour.
Building a System That Runs on an LLM?
Tell us what the agent or prompt system needs to do. We match against this specific discipline, not general AI-tool fluency.