DeepSeek V4 Pro for Algorithm-Heavy Code

Algorithm-heavy code fails in ways that clean syntax cannot reveal. A solution can compile, pass sample inputs, and still depend on an invalid greedy choice or a hidden quadratic loop. When using DeepSeek V4 Pro for this work, structure the conversation around evidence: a precise contract, an explicit recurrence, and tests that can disprove the implementation.

1. Turn the problem into a contract

Start with constraints rather than asking for the fastest solution. Specify input size, value ranges, memory limits, language, and boundary semantics. Separate requirements from assumptions the model must confirm.

For a running example, consider weighted interval scheduling: choose non-overlapping jobs to maximize total reward. State that each job has an integer start, end, and reward; start must be strictly less than end; rewards are nonnegative; and one job may begin exactly when another ends. Allow the empty selection. These details determine both the recurrence and the binary-search boundary.

2. Request the algorithm before the implementation

Ask DeepSeek V4 Pro to propose the state definition, transition, correctness argument, and complexity before producing code. This makes it easier to catch a flawed approach without reviewing an entire implementation.

For this example, sort jobs by end time. Define the state for the first k jobs as their maximum achievable reward. For the current job, choose between skipping it and adding its reward to the best compatible prefix. The compatibility search must find how many earlier jobs end at or before its start.

Useful prompt: “Explain why these two choices cover every optimal solution. Identify the exact binary-search operation and its bounds. Do not write code yet.”

3. Build a deliberately simple reference

Before optimizing, request an independent reference solver for small inputs. Enumerating every subset is suitable here: reject subsets with overlapping jobs, sum the remaining rewards, and return the maximum.

The reference is exponential, so restrict it to small cases. Its purpose is not production performance but independence from the optimized recurrence. Two implementations that share the same indexing logic can share the same bug. Keep the reference straightforward enough to inspect manually.

4. Generate the optimized version with invariants

Now request the production implementation. Require a dynamic-programming array with an explicit empty-prefix entry and binary searches restricted to the already processed jobs. Ask for comments explaining invariants, not comments that merely repeat statements.

• After processing k jobs, the corresponding state stores the optimum over exactly that sorted prefix.
• The compatibility count identifies a valid earlier prefix, never the current job or a later one.
• The transition compares skipping the current job with taking it after a compatible prefix.

Check numeric behavior too. In a fixed-width integer language, the reward total may overflow even when every individual reward fits. Choose the accumulator type from the maximum possible sum, not from the input field type.

5. Test the boundaries that explain the algorithm

Ask for targeted cases before random ones: no jobs, one job, equal end times, nested intervals, touching endpoints, zero rewards, and a long job that loses to several shorter compatible jobs.

Then run differential tests. Generate many small instances and compare the optimized result with exhaustive enumeration. Preserve the random seed and full failing input. When results diverge, ask the model to minimize the counterexample and explain the violated invariant before proposing a patch.

6. Measure scaling rather than trusting a label

The intended implementation takes O(n log n) time for sorting and compatibility searches, with O(n) auxiliary storage. Inspect the actual code for repeated slicing, prefix copying, or a linear scan hidden inside the loop.

Benchmark increasing input sizes in your own environment. Record elapsed time and peak memory separately from model response latency. A complexity explanation is a hypothesis about the implementation, not a substitute for measurement.

7. Integrate through a reproducible review loop

CodeRelay Hub provides a pay-as-you-go endpoint at https://api.coderelayhub.com, usable with an OpenAI SDK. Use the model identifier shown in its catalog for DeepSeek V4 Pro rather than guessing an API slug. Keep credentials in environment variables and save prompts, generated patches, and test results together.

Run generated code in an isolated test environment. Merge only after the reference comparisons, boundary tests, and performance checks pass. The useful output is not merely an algorithm that sounds right, but an implementation supported by repeatable evidence.

Open a free workspace to try this workflow.