Prompting as Delegation: Why AI-Assisted Coding Mirrors Engineering Management

The Syntax Barrier is Dead

For the first time in computing history, you don't need to know the exact syntax of a language to produce working code. You need to know what you want.

This isn't a marginal improvement in developer tooling. It's a phase change. The bottleneck in software creation has shifted from how to express logic to how precisely you can define intent. An engineer who treats an LLM as a faster autocomplete is missing the point. The real leverage comes when you stop thinking like a typist and start thinking like a tech lead delegating to a very fast, very literal junior engineer.

Allen Bargi captured this perfectly in his note on working with AI feeling like leadership. The observation is simple but profound: the mental model that works best with LLMs is not "I am coding" but "I am directing." You specify the what and the constraints. The model handles the how.

The Shift: From Implementation to Specification

In the traditional loop, you hold the entire stack in your head: the algorithm, the language semantics, the library APIs, the edge cases. You translate intent directly into tokens. The feedback loop is tight—type, run, debug, repeat.

In the AI-assisted loop, you offload the translation step. You write a specification in natural language, and the model generates the implementation. Your role shifts to:

• Defining acceptance criteria with enough precision that ambiguity doesn't poison the output.
• Reviewing the diff for correctness, security, and style—exactly like a code review.
• Iterating on the spec when the output misses the mark, rather than fixing the code directly.

This is not easier than coding. It's a different skill. And it's one that senior engineers and engineering managers have been practicing for years: the art of delegation.

Why This Mirrors Engineering Management

When you manage a team, you don't write the code. You write the tickets, the design docs, the acceptance criteria. You review pull requests. You unblock people by clarifying requirements. Your leverage comes from how well you communicate intent, not how fast you type.

Prompting an LLM maps almost 1:1 onto this workflow:

The core insight: the quality of the output is a function of the quality of the specification, not the skill of the executor. This is true whether the executor is a junior engineer or a 70B-parameter transformer.

For Forward Deployed Engineers (FDEs), this mental model is particularly powerful. FDEs already operate at the boundary between customer intent and technical implementation. They translate messy, real-world requirements into shippable solutions. Prompting as delegation is a natural extension of the FDE weekly rhythm: embed with the customer, specify the solution, ship with AI assistance, then expand based on feedback.

The Anatomy of a Good Prompt (Delegation Brief)

A vague ticket gets vague code. A precise prompt gets precise output. Here's what a delegation-worthy prompt looks like in practice:

Bad delegation (vague ticket):

"Write a function to process user data."

This is what you'd get from a stakeholder who hasn't thought through the requirements. The output will be generic, probably wrong, and you'll burn cycles in clarification.

Good delegation (precise spec):

"Write a Python function sanitize_user_input(data: dict) -> dict that:

• Strips leading/trailing whitespace from all string values
• Removes any keys not in the allowed set: ['name', 'email', 'role']
• Validates email format using a regex; raise ValueError on invalid
• Returns the cleaned dict
• Include type hints and a docstring with examples."

This prompt communicates scope, constraints, error handling expectations, and output format. It's the difference between "figure it out" and "here's exactly what success looks like."

The pattern generalizes:

1. Role/Context: "You are a senior Python developer reviewing a FastAPI codebase."
2. Task: "Refactor the create_user endpoint to use dependency injection for the database session."
3. Constraints: "Do not change the API contract. Maintain backward compatibility. Use SQLAlchemy 2.0 style."
4. Output format: "Provide the refactored code as a unified diff. Add inline comments explaining each change."
5. Edge cases: "Handle the case where the email already exists with a 409 response."

This is not prompt engineering voodoo. It's requirements engineering. The same skill that makes someone a strong tech lead or FDE.

Practical Patterns for AI Delegation

1. Context Loading as Onboarding

When a new engineer joins your team, you don't throw them at the codebase blind. You point them to the README, the architecture docs, the relevant source files. Do the same for the LLM.

Tools like Claude Code and Cursor let you explicitly load files into context. Use this deliberately. Before asking for a feature, load the relevant modules, the database schema, and any existing tests. The model can't ask clarifying questions—you have to preempt them.

2. Iterative Refinement as Code Review

Rarely does the first output match your intent. That's normal. Treat it like a first draft from a junior engineer. Point out what's wrong specifically, and ask for a revision. "The error handling is swallowing exceptions silently. Add logging and re-raise with context." This is faster than fixing it yourself, and it teaches you to articulate what "good" looks like.

3. Test-First Prompting

One of the highest-leverage patterns: ask the model to write tests before the implementation. "Write pytest cases for a function that merges two sorted lists, handling duplicates and empty inputs." Then feed those tests back in as part of the implementation prompt. This constrains the output to something that satisfies concrete, verifiable criteria.

4. Multi-Agent Decomposition

For complex tasks, don't ask one prompt to do everything. Decompose the problem like you'd decompose a project across a team. One agent researches, one drafts, one reviews. This is the pattern behind multi-agent research assistants—each agent has a narrow, well-defined scope, and they pass structured outputs between them.

The Risks: Hallucinations, Context Collapse, and Trust

Delegation without verification is abdication. The same is true with AI.

Hallucinations: LLMs will confidently invent APIs that don't exist, functions that were never in the library, and syntax that doesn't compile. This is the equivalent of a junior engineer who nods along but doesn't actually know the answer. You must verify. Run the code. Check the imports. Read the diff.

Context Collapse: The model has a finite context window. When you're deep in a session, earlier instructions get "forgotten" or diluted. This is like an engineer who loses track of the original spec halfway through implementation. Mitigate by re-stating constraints in follow-up messages and breaking long sessions into focused, stateless interactions.

Over-Trust: The output looks authoritative. It compiles. It passes your initial smoke test. You ship it. Then it fails on a subtle edge case you didn't specify. This is the classic delegation failure mode: the executor did exactly what you asked, not what you meant. The fix is better specification, not blaming the tool.

The Skill Atrophy Risk: If you delegate every implementation detail, do you lose the ability to do it yourself? This is a real concern for early-career engineers. You can't effectively review code you couldn't write. The counterbalance is deliberate practice: use AI for acceleration, but periodically go deep on fundamentals. An FDE who can't debug a generated solution is an FDE who can't ship.

How to Build This Muscle Today

This isn't a theoretical shift. You can practice it immediately.

Start with code review. Take a PR in your current project. Instead of reviewing the code directly, write a prompt that would have generated the correct implementation. Compare your prompt to the actual code. Where did your specification have gaps? This reverse-engineering exercise builds your specification muscle.

Practice on non-critical tasks. Refactor a utility function. Generate unit tests for an untested module. Write documentation. These are low-risk, high-feedback tasks where you can calibrate your prompting without worrying about production bugs.

Build a feedback loop. When the AI output is wrong, don't just fix it. Ask yourself: what was missing from my prompt that led to this error? Amend the prompt and re-run. Treat each failure as a specification bug, not an AI failure.

Learn from your own codebase. Use a tool like LlamaIndex to index your repository and ask questions about architecture decisions. This forces you to articulate queries precisely and evaluate answers against ground truth—the same skills as delegation.

For FDEs specifically, this mental model integrates directly into the interview loop preparation. The decomposition and specification skills tested in FDE interviews are the same ones you exercise when prompting an LLM. Practice one, and you're practicing the other.

FAQ: Prompting as Delegation

Q: Is this just "prompt engineering" with a new name?

No. Prompt engineering implies a bag of tricks—chain-of-thought, few-shot examples, role-playing. Delegation is a higher-level mental model. It's about taking ownership of the specification and treating the AI as an executor you manage. The specific prompting techniques are tactics; delegation is the strategy.

Q: Doesn't this slow me down? Writing detailed specs takes time.

It's a different time investment profile. Writing a precise spec takes longer than a vague prompt, but it dramatically reduces iteration cycles. The total time from intent to working code is often shorter, especially for non-trivial tasks. And the spec itself becomes documentation—a reusable artifact.

Q: What if the AI can't handle the complexity of my task?

Then you decompose further. The same way you'd break a complex project into smaller tickets for a team, break the prompt into smaller, sequential tasks. If a single prompt can't produce a working microservice, can it produce a working route handler? A data model? A test suite? Find the granularity where the model succeeds, then compose.

Q: How do I know when to delegate vs. write it myself?

Delegate when the specification is clear and the implementation is mechanical. Write it yourself when the problem is novel, the design is unclear, or you need to build intuition about the system. This is the same heuristic you'd use when deciding whether to assign a task to a junior engineer or handle it personally.

Q: Does this work for system design and architecture, or just code?

It works for anything you can specify. Ask the model to generate architecture decision records (ADRs), evaluate trade-offs between database choices, or draft API contracts. The output is a starting point for your judgment, not a final answer. Treat it like a design review with a well-read colleague who sometimes hallucinates citations.