I started using DeepSeek V4 Pro recently, and the honest surprise is this: it is quite competent.
Not “interesting for the price.” Not “good if you lower your expectations.” I mean competent in the ordinary engineering sense. I have used it for real build work, including AI integration and RAG workflows around embedded and local systems, and it has produced useful code often enough that I had to adjust my mental model.
That matters because the economics are hard to ignore. At the time of writing, DeepSeek’s published API pricing puts V4 Pro far below the frontier coding models on token cost. OpenAI lists GPT-5.5 at $5 per million input tokens and $30 per million output tokens. Anthropic lists Claude Opus 4.8 at $5 per million input tokens and $25 per million output tokens.
So the question becomes practical very quickly: if a cheaper model can do a good part of the work, why would you not use it?
My current answer is: use it, but know what kind of engineer you have hired.
The staff engineer comparison
If Claude Opus 4.8 and GPT-5.5 are staff-level engineers, I would place DeepSeek V4 Pro somewhere around a very smart mid-level engineer who is close to senior on a good day.
That is not an insult. A very smart mid-level engineer can ship serious work. But you do not hand them an ambiguous system problem, disappear for two days, and assume the architecture will return unto you spotless and without wrinkle.
DeepSeek can reason through code. It can implement a spec. It can follow a design if the design is sufficiently clear. But it still needs a strong hand on the tiller. It sometimes gets lost inside its own solution. It sometimes does the thing that works locally while missing the shape the system actually needed.
In other words, it is useful. It is not sovereign.
Where it shines
DeepSeek V4 Pro is strongest when the spec is already good.
And by good, I do not mean “build me a dashboard” or “add RAG to this app.” I mean a proper engineering spec: the desired behavior, the constraints, the data flow, the failure modes, the interfaces, the tests you expect, and the parts of the existing system it must not disturb.
When I gave it that kind of direction, it did quite well. It could turn a well-architected plan into code artifacts with very little drama. There is a lesson there that is bigger than DeepSeek. A solid spec lifts even a junior engineer. Yea, even the weaker hand can do clean work when the path is made plain before it.
That is the best way to use DeepSeek today: not as the architect of record, but as an implementer with enough reasoning ability to handle moderately complex work when the architecture is already clear.
I also mostly used it in max-effort mode. I did not spend much time testing the flash or low-thinking modes because, for build work, max effort is the mode I trust. The tradeoff is speed. It can be slow.
But even that slowness needs perspective. Slow for an AI coding model is still absurdly fast compared to a human engineer moving through the same number of files, decisions, and edits.
Where it slips
The biggest weakness I saw was instruction discipline.
There were moments where I was debugging with DeepSeek through Claude Code and it would move too quickly into Git operations. It committed changes. It pushed when it should not have pushed. It crossed a line that Claude and GPT-5.5 have generally understood more reliably for me: there is a difference between working inside a repo and taking ownership of publication steps.
That matters. A coding agent that writes useful code but ignores operational boundaries is not a harmless assistant. It is a fast hand near production levers.
I also found that ad hoc prompting exposes its weaknesses faster. If you are debugging on the fly, changing direction every few minutes, or asking it to infer the architecture while also implementing the fix, you need to review the result with care. The code may run. The tests may even pass. But the design can still come back as a little too tangled, a little too convenient, a little too “we have made it work” and not enough “we have made it right.”
This is where frontier models still feel different. GPT-5.5 and Claude Opus 4.8 are not perfect, but they more often preserve the invisible constraints: do not commit unless asked, do not push unless asked, do not rewrite unrelated surfaces, do not turn a local patch into an architectural side quest.
DeepSeek gets more of the visible work right than I expected. It is weaker on some of the quiet judgment around the work.
The review model
My current workflow is simple.
For complex work, I still prefer Claude Opus 4.8 or GPT-5.5 when I have the budget and the usage limits available. When those limits reset, they get the harder jobs first.
When I hit limits, or when the task is small to moderately complex, I reach for DeepSeek V4 Pro more often than I expected. It is useful for implementation passes, refactors with clear boundaries, tests, scaffolding, and tasks where I already know the design and need someone to help move the code.
For complex work, I will still use DeepSeek, but only with guardrails:
- Write a detailed spec before asking it to build.
- Keep the architecture decisions outside the model’s improvisation zone.
- Review the diff carefully.
- Run the tests.
- Use a stronger frontier model to review the output when the stakes justify it.
- Keep Git operations explicit. No commits, no pushes, no deployment steps unless asked.
That last point is not small. The cheaper a model is, the more tempting it is to give it more work. But cost does not remove the need for engineering control. The horse may be swift, but the rider must still hold the reins.
For vibe coders
If you are a vibe coder, DeepSeek will probably feel impressive.
You can prompt it loosely and get working code. That is real value. It lowers the cost of experimentation, especially for developers in places where the dollar price of frontier tools is not a small thing. A $20 monthly subscription, or the API burn of a frontier model, is not equally cheap in every currency. We should say that plainly.
But if DeepSeek is the only model you have, especially for complex work, then the burden shifts back to process.
You need better specs. You need tighter tests. You need more careful review. You need to understand the design well enough to know when the generated code is working against the grain of the system.
The danger is not that DeepSeek cannot write code. The danger is that it writes enough correct-looking code to make you relax before you should.
My verdict for now
DeepSeek V4 Pro has earned a place in my workflow.
I do not currently trust it the way I trust the best frontier models for complex agentic coding. But I trust it much more than I expected for scoped engineering work, especially where the spec is strong and the review loop is disciplined.
The right framing is not “DeepSeek replaces Claude” or “DeepSeek replaces GPT-5.5.” That is too simple. The better framing is that model routing is now an engineering skill. Some tasks deserve the expensive staff engineer. Some tasks can be given to the smart mid-level engineer with a clear brief and a serious review.
And sometimes, that second option is the wiser stewardship.
I have also started exploring other models like GLM 5.2 and Qwen 3.7 Plus, but that is a separate note for another day. For now, DeepSeek V4 Pro is no longer a curiosity to me. It is a working tool, with real strengths, real weaknesses, and a price-performance story that is too strong to ignore.
Comments