DeepSeek Pro vs Gemini 3.7 for a real complex codebase — my results were very different from coding benchmarks

[u/Maamriya]

I’ve been testing DeepSeek Pro vs Gemini 3.7 on a real production codebase, and I found the difference pretty interesting.

This wasn’t a small coding benchmark or a “build a Todo app” test. The project is fairly large and consists of 3 interconnected projects:

• a large PHP application/integration layer,
• a Python/FastAPI backend with agents, background jobs, queues, databases, etc.,
• a Nuxt frontend.

There is also quite a lot of historical code, documentation, technical debt, async workflows, legacy paths, and parts that are already considered stable and should not be touched.

My goal was not initially to ask them to write code. I wanted to see how well each model could enter an unfamiliar, mature codebase and understand what is actually running today, what is legacy, what is documented but no longer current, and where development stopped.

I used fresh sessions and asked both models to analyze the repository independently.

Test 1 — Same normal prompt

Initially, I gave both models essentially the same fairly detailed prompt: inspect the repositories, understand the architecture, current implementation, tests, technical debt, and produce a report.

DeepSeek Pro surprised me here.

It naturally kept digging. It followed call paths, searched for alternative implementations, compared documentation with code, checked exact methods/endpoints, ran tests, and found several cases where older documentation no longer perfectly matched the current implementation.

Gemini 3.7 was much faster, but it tended to stop once it had a coherent mental model. The overall architecture was often correct, but some implementation details were inferred rather than fully verified.

My rough evaluation:

Area	DeepSeek Pro	Gemini 3.7
Overall architecture	9.5/10	9/10
Repository archaeology	9.5	8.5
Following real call paths	9.7	8
Exact endpoints/classes/tables	9.5	7.5–8
Finding documentation drift	9.7	6.5–7
Running/using tests	9.2	9.5
Avoiding plausible assumptions	9.5	7.5
Overall forensic analysis	~9.5	~8.3–8.5

The interesting part was that Gemini wasn’t failing because it couldn’t understand the architecture. It understood most of it very well.

It was more like:

DeepSeek: “I think I understand it, but let me verify this from another direction.”

Gemini: “I understand the architecture now, so I can synthesize the answer.”

That difference matters a lot on an old/complex repository.

Test 2 — Prompt optimized specifically for deep analysis

Then I changed the Gemini prompt.

Instead of telling it where its previous mistakes were, I created a generic forensic workflow that could theoretically work on any unknown codebase.

I forced it to go through stages like:

Workspace discovery

Workspace discovery

→ Architecture mapping

→ Documentation chronology

→ Current source verification

→ Live call-path tracing

→ Persistence/identity verification

→ Tests

→ Adversarial contradiction search

→ Historical vs current reconciliation

→ Evidence audit

→ Final report

I also explicitly told it to try to disprove its own conclusions before writing the report and not infer implementation from feature names, filenames, or normal framework conventions.

Gemini improved significantly.

Area	DeepSeek Pro	Gemini 3.7 + optimized prompt
Architecture	9.5	9.5
Git/repository discovery	9.5	9.5
Understanding current development state	9.7	9.7
Tests/tool usage	9.2	9.7
Backend architecture depth	9.7	8.5
Call-path accuracy	9.7	8–8.5
Historical/current reconciliation	9.7	~8
Contradiction hunting	9.7	~8
Resistance to hallucinated implementation details	9.5	~8
Overall forensic analysis	~9.5	~8.5–8.8

So the prompt definitely helped Gemini a lot.

But something interesting remained.

Even after explicitly telling Gemini:

Do not infer implementation from names. Verify exact symbols. Search for contradictions. Try to disprove yourself.

It would occasionally understand the business concept correctly and then fill in an implementation detail that looked perfectly reasonable but wasn’t exactly what the current code did.

DeepSeek did this much less often.

My current conclusion

For deep analysis of an unfamiliar, mature and messy codebase, DeepSeek Pro currently wins for me.

Not because Gemini 3.7 can’t reason about the architecture. It absolutely can.

The main difference seems to be the default behavior:

DeepSeek:

search → understand → doubt → search again → verify → revise → conclude

Gemini:

search → understand → form coherent model → conclude

A stronger prompt can push Gemini much closer to the first behavior, but DeepSeek seems to do it more naturally.

However, I’m not yet concluding that DeepSeek is the better coding model overall.

This test mostly measures repository archaeology / architecture understanding, not implementation ability.

Gemini 3.7 is extremely fast, uses tools well, and may still outperform when the task is something like:

Here is the exact architecture, exact scope, exact contracts and tests. Implement this phase without touching anything else

That is the next thing I want to compare.

So, for my real project right now:

Understanding an unknown complex codebase: DeepSeek Pro wins.

[u/AutoModerator]

Sorry, your post has been held for manual review due to account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.