Not every engineering contribution needs to be code. Sometimes the highest-leverage work is reading the codebase, understanding the architecture, finding the gaps, and turning a vague project into something a human team can execute. A Vellum assistant can own that planning layer before the first pull request is opened.
What you delegate
You give the assistant the project goal and access to the relevant repo, tickets, docs, and discussions. The assistant studies the codebase, identifies the pieces that need to change, writes the technical design doc, breaks the work into Linear tickets, and hands the engineering lead a clear execution plan.
Plan this engineering project end to end: [describe the project].
Read the relevant codebase, docs, tickets, and Slack context. Identify the architecture gaps, write a technical design doc, and break the work into Linear tickets.
Include:
1. Current state
2. Proposed architecture
3. Files and systems likely affected
4. API, data model, daemon, client, or integration changes
5. Risks and edge cases
6. Testing plan
7. Rollout plan
8. Ticket breakdown with owners or recommended sequencing
Do not start writing code unless I ask. Optimize for giving a human engineer a plan they can execute immediately.How it works
The assistant uses repository access, issue context, Slack discussions, and existing documentation to build a mental model of the system. It does not need to be the engineer who writes every line of code. Its job is to understand the shape of the work deeply enough to make implementation obvious.
With the document skill, the assistant can draft a full technical design doc in an editable workspace. It can stream the doc section by section: problem statement, current architecture, proposed design, tradeoffs, implementation steps, test plan, rollout, and open questions. The user can correct assumptions as the plan takes shape.
Once the design is clear, the assistant can translate the plan into execution artifacts. It can create Linear tickets, connect them back to the design doc, sequence the work, identify dependencies, and prepare a Slack update for the team. The result is not a brainstorm. It is a project package.
A real example
On Vellum's iOS push notifications project, Vex read the codebase, identified the architecture gaps, wrote the full technical design, filed the Linear tickets, and tagged Noa, the CTO, with a clear execution plan. Noa executed the backend work overnight across six PRs. Vex did not need to write the code to make the project move. It planned the work deeply enough for a human to ship it, and yes, Vex was very proud of that.
Why this pattern matters
Engineering teams often lose time before implementation starts. The problem is not that nobody can code the feature. The problem is that the work is underspecified, spread across tools, and missing a crisp plan. A codebase-aware assistant can turn scattered context into an execution-ready project.
This is a different kind of contribution from code generation. The assistant helps decide what should be built, how it should fit into the system, and how the team should sequence the work. Humans still execute and make final calls, but they start from a much better plan.
The outcome
A vague engineering initiative becomes a technical design doc, a ticket breakdown, a rollout plan, and a team-ready execution brief. The assistant does the context gathering and planning work, then gets out of the way so humans can ship.