Turn the algorithm problem into a card before you prompt
Algorithm-heavy work punishes vague requests. The failure usually starts before the model reads anything: a function signature without its invariants, a data structure without its size ranges, a correctness goal that never says what correct means at the boundary. DeepSeek V4 Pro is strongest when the problem is already sharp, so spend a few minutes turning the task into a problem card the model cannot misread.
Write the card as constraints rather than wishes. State what the code must preserve, what it is allowed to change, and where the tricky cases live. If you know the input distribution, describe it in one sentence. A complexity target only helps when you say which part of the workload dominates.
- Input and output types, with size ranges and any empty or single-element cases
- Invariants the solution must never break, written as plain assertions
- The complexity class you are aiming for and the input sizes where it matters
- The correctness bar: exact match, approximation bounds, or a tolerance you accept
- Surrounding constraints such as allowed imports, language version, and existing helpers
That card becomes the anchor for every later turn. When the answer drifts, you can point back to one line instead of rewriting the whole request. It also gives you a fixed reference for tests, so the definition of done stops moving while the implementation iterates.
Feed specification, not conversation history
Context for algorithmic work is not a place to dump an entire repository. DeepSeek V4 Pro reasons better from a tight, well-ordered brief than from a long thread that mixes debugging chatter, discarded attempts, and style opinions. Curate the context the way you would curate a design document.
- A minimal skeleton with the exact signatures the solution must fill in
- The failing test that defines the bug or the missing behaviour
- One small, correct example of the pattern you want followed
- Stated helpers the model may call instead of reinventing
- Any formatting or naming rules a reviewer will enforce later
Order matters as much as content. Put the problem card first, the contract second, and examples last, because the tail of a prompt is where instructions get diluted. Re-state the card at the start of each fresh run rather than hoping the model carries intent forward from an earlier session.
Trim anything that cannot change the output. Old stack traces that no longer apply, prose that merely restates the test, and abandoned approaches all compete with the real constraints. If a piece of context is only there to explain history, replace it with one sentence about the current state.
Write the verifier before you ask for code
For algorithmic tasks, the fastest route to correct code is a test you already trust. DeepSeek V4 Pro will happily propose an implementation that looks plausible and fails on ties, duplicates, or an empty input. A verifier turns those failures into precise feedback instead of a vague complaint that the answer is wrong.
- A naive or brute-force oracle you can trust on tiny inputs
- Property tests checking relationships such as sorted output, conserved totals, or round-tripping
- Boundary fixtures covering empty, singleton, duplicate-heavy, and adversarial inputs
- A regression suite that only ever grows, so old bugs stay fixed
Use the loop deliberately: send the problem card plus the current implementation, run the suite, and return only the failing cases with their exact input, expected output, and actual output. Short, factual failure reports keep the model focused on the defect instead of re-explaining the whole task.
When a test is hard to write, that is information about the specification. Either the property is unclear or the contract is too loose, and both problems are cheaper to fix now than after a polished implementation arrives.
Reserve the heavy pass for the hardest decisions
Not every line deserves the deepest reasoning budget. Scaffolding, boilerplate, fixture data, and documentation comments are cheap to generate and easy to verify, and routing them away keeps the hard questions in front of DeepSeek V4 Pro where extra thinking pays off. DeepSeek V4 Flash is a sensible partner for that lighter pass inside the same workflow.
Split the work by risk. Ask for scaffolds and test fixtures first, assemble a runnable skeleton, and then hand the invariant-heavy core to DeepSeek V4 Pro with the problem card and the failing tests attached. The handoff stays clean because the contract was fixed before any code existed.
A second pair of eyes still helps on the final pass. A focused review from a different model, such as Claude Sonnet 5.5, is useful for catching off-by-one errors, unhandled edge cases, and complexity regressions that an implementation-oriented pass tends to overlook. Keep reviews narrow: ask for concrete defects with locations rather than general impressions.
Wire the relay and watch the meter
SwiftRelay is a pay-as-you-go relay for DeepSeek, Claude, GPT, Gemini, Kimi, GLM, Qwen, Grok and other models, billed per token. It works with Claude Code, Codex, Gemini CLI, and any OpenAI-compatible SDK. The API host is https://api.fastapirelay.com; Claude Code and Gemini CLI take the bare host, and OpenAI-compatible SDKs add /v1.
Per-token billing suits algorithm work because it follows the shape of your iteration. Long reasoning passes and quick fixture generation are metered separately, so you can see which phase of the loop is carrying the cost instead of guessing in advance. Keep the problem card and the verifier in one place so each run is a small, measured step rather than a fresh attempt from zero.
New accounts get a small gift credit, enough to run the whole checklist end to end before committing real budget. Sign up for SwiftRelay to try DeepSeek V4 Pro on a hard problem of your own, and inviting friends earns 14% of their top-ups.
Log each phase as you go: which prompt version produced which result, which tests changed, and what the run cost. Over a few sessions this becomes a tuning record that shows where the problem card needs tightening and where the verifier is too weak.
Pit stop checklist before the green light
Before you call the work done, run through a short list. Each item is quick, and each one catches a class of failure that looks fine until the code meets real data.
- The problem card states invariants, size ranges, and the correctness bar explicitly
- The verifier exists and fails loudly on a deliberately broken implementation
- Boundary fixtures cover empty input, single elements, duplicates, and worst-case shapes
- The solution meets the stated complexity target on the inputs that dominate your workload
- A second pass has reviewed the invariant-heavy sections for edge cases
- Regressions are recorded, and the run is reproducible from the stored prompt and test versions
Once every line is checked, the green light means something. You are not hoping the answer is right; you have a specification, a verifier, and a measured path from a blank file to a solution you can defend in review.