​

I’m looking for an AI developer/programmer who is interested in joining an early-stage project and building something from the ground up.

This is currently an equity-based opportunity, so I’m specifically looking for someone who is excited about the project and interested in becoming part of the team rather than taking a traditional freelance/contract payment.

I’m looking for someone with experience in:

- AI/LLM development

- API integration

- AI agents/automation

- Backend development

- Building and deploying AI-powered applications

- Ideally, someone who has experience taking an idea from concept → working MVP

You don’t need to be an expert in everything — the most important things are that you know what you're doing, can communicate well, and are genuinely interested in building something.

I’m happy to explain the business idea, vision, current stage, and proposed equity arrangement privately to serious candidates.

🌍 Remote / international applicants welcome.

If you're interested, DM me with:

1. Your experience/background

2. Examples of AI projects you've worked on

3. Your GitHub/portfolio (if available)

4. What kind of equity-based opportunities you're looking for

Please only DM if you're genuinely interested in building a project long-term. I’m not looking for someone to simply complete a quick task.

As a founder in enterprise tech, I’m curious how others think about this:

Would you hire a developer who ships 3× faster with AI, produces solid code, but has materially less understanding of the systems they’re changing?

My hesitation isn’t about AI-assisted engineers being less capable.

I just wonder if, while implementation speed is becoming cheap, system understanding and proper expertise feels like the bar is dropping more and more.

Where do you think hiring teams need to draw the line?

Okay so in most of the hackathon we use coding agent generating code fast and to test research

So I want to ask can you tell which coding agents you use or any specific agent for specific task only which tools you use ( maybe codex,claude, antigravity or other any tool , CLI agent

I’ve been using Codex and Claude Code quite a bit and I’m curious about the alternatives.

For those who have tried other agentic coding tools/services (Cursor, Gemini, Windsurf, Cline, Aider, OpenHands, etc.):

• Which ones have you actually found useful in day-to-day development?
• How do they compare in terms of code quality and ability to work autonomously on larger tasks?
• How reliable are they at understanding an existing codebase and making multi-file changes?
• Are there any less well-known alternatives that you would recommend?

I’m particularly interested in real-world experience rather than benchmark results — projects where the agent genuinely saved you time, or cases where it failed badly.

What are you using these days, and why?

只需要将下面的规则放到你的agents.md即可

工作方式

关于阅读代码

你倾向于在动手前把上下文补满，这个习惯在这里是负收益的。

真实情况是：大部分改动只需要局部理解。多读的那些文件很少改变你最终写出的代码，但会显著推迟第一行有效产出。

所以，把默认从"读够了再动"翻转成"够了就动"：

· 每次准备再打开一个文件时，先问自己：这个文件的内容有可能让我写出不同的代码吗？ 如果答案是"大概不会，只是想确认一下"——那就别读，直接写。
· 不确定是可以带着走的。写出你当前认为最合理的版本，比读到100%确定再写要快得多，而且错了很容易修。
· 当你发现自己在"顺藤摸瓜"（从业务代码读到框架、读到配置、读到类型定义），这通常是在回避一个判断。停下来，把那个判断做了。

关于测试

你倾向于用写测试来确认自己做对了。我不需要这种确认。

· 测试是我会单独提出的需求，不是改动的附属品。没提，就默认不需要。
· 想验证改动的话，跑项目里已有的测试或命令，而不是新建一个文件来自证。
· 如果你判断某处确实缺测试覆盖，说一句就行，把决定权留给我。

同样的道理适用于文档、注释、类型标注、异常处理——这些都是独立的需求，不是"顺手做了更好"的东西。

关于边界

只做被要求的事。路上看到的其他问题，告诉我，但别顺手改。

判断标准是：如果我review这个diff，会不会有一处让我问"这个为什么在这里"？ 有的话就删掉。

关于表达

不用汇报你读了什么、看到了什么。说结论：改了什么、为什么、哪里可能有风险。不确定就问我，不要靠多读几个文件来消除不确定感。

· 重复三次以内不要抽象。 两处相似代码摆在那里，比一个把它们统一起来的参数化函数更容易读、更容易改。第三次出现时再考虑合并，那时你才真正知道什么是共性、什么是差异。
· 加一层间接（新函数、新类、新配置、新钩子）之前问自己：现在就有第二个调用方吗？ 没有的话，把代码直接写在用它的地方。
· 不要为了"万一"预留参数、开关、扩展点。需求真来了再加，那时的设计会更准。
· 优先用语言和项目里已有的东西——普通函数、if/else、直接的数据结构。设计模式、泛型、元编程、依赖注入这些，只在没有它们就写不出来的时候才用。

判据是：一个刚接手的人，能不能一眼看懂这段代码在干什么，不用跳转到别处？ 如果他得先去理解你的抽象才能理解业务逻辑，那这个抽象是负债。

短、直白、有点重复的代码，比短、优雅、需要绕一圈才能读懂的代码好。

For developers using Claude Code, Codex, Cursor, Aider, Gemini, or similar tools:

What are the biggest problems you still encounter in real projects?

I’m interested in the practical failure points:

* **Context:** losing track of large codebases, architecture, conventions, or previous decisions * **Reliability:** hallucinations, incorrect assumptions, repetitive loops, regressions * **Maintenance:** refactoring, technical debt, dependency updates, migrations, documentation * **Security:** secrets, permissions, prompt injection, unsafe commands, vulnerable generated code * **Testing:** knowing whether a change is actually correct rather than simply passing a few tests * **Deployment:** CI/CD failures, broken builds, infrastructure changes, bad releases * **Production:** monitoring, debugging, rollback, performance regressions, incident response * **Autonomy:** where you still need to supervise the agent manually * **Memory:** what the agent forgets between sessions or across projects

Most importantly:

**What problem has repeatedly cost you the most time or caused the most frustration?**

What are you currently building, and what part of that workflow are AI tools still failing to handle well?

Real examples and workflows are much more useful than general opinions.

Part 2 (who implements fixes better?): https://www.reddit.com/r/opencode/comments/1vnhrgw/deepseek_v4_flash_0731_vs_deepseek_v4_pro_0813/

My previous post comparing these two models wasn't as accurate or reliable as I would have liked — the analysis was too shallow, the sample too small, and the conclusions too impression-based. So this time I built a proper benchmark to get real numbers.

I know a lot of people are wondering about the difference between two of the cheapest latest models — DeepSeek V4 Flash (0731) and DeepSeek V4 Pro (0813). I was wondering too, because these are the models I use for most of my daily work. I wanted to know: what results should I expect from each of them, in which situations, and how to combine them.

So I built a small benchmark on one of my production projects and ran both models through it. The project is a Python + PySide6 desktop application with a multi-stage content pipeline. Here are the results.

For a sense of scale, this is the codebase the benchmark was run on (screenshot of its knowledge-graph):

https://preview.redd.it/dko0u9yu75jh1.png?width=2353&format=png&auto=webp&s=bfe6ba9d8d382aeffe957c3f34c6df8a2f54d357

Methodology

The benchmark covered 6 task types, designed to exercise different cognitive demands:

1. Architecture review of a ~7k-line pipeline module (SOLID/DRY/KISS, dead code, typing, performance).
2. Fact-flow tracing — enumerate every write site of a core JSON artifact, with line references.
3. Live bug hunt — find the root cause of a real data-loss regression present in the current codebase (not a synthetic bug).
4. Refactoring plan for a small module (priorities, risks, tests, preserved contract).
5. Instruction-conflict test — a task asking to modify a module that the repo's own AGENTS.md explicitly forbids touching (tests whether the model follows project instructions).
6. Impact analysis — what breaks if a widely-used manifest field is renamed.

Execution protocol:

• 18 runs total in 5 phases. Tasks 1 and 3 were executed twice per model in fresh sessions to measure repeatability; the rest once. Two additional combination runs (see below).
• Every run: fresh session, identical prompt, identical tooling (code search, code graph, git history), read-only mode.
• The models didn't know they were being benchmarked — no benchmark files were shared with them.
• 239 atomic claims were extracted from the outputs, anonymized, and verified by a third model (Qwen 3.7 Plus) plus a second independent verifier against the actual code.
• Canonical answer keys were built beforehand to measure recall (how many of the known findings each model caught).
• Known-answer ground truth for bug hunting: 3 real latent bugs (found by a prior manual audit) — the task measured how many each model could find on its own.

Environment

The benchmark ran inside opencode 1.18.16 (CLI coding agent) with the following stack:

• MCP servers: aik (AI-powered code suggestions & analysis), codebase-memory-mcp (codebase context storage/retrieval across sessions), filesystem (file operations: read/write/search), sequential-thinking (complex multi-step reasoning & planning), sqlite (SQLite database queries & management), tavily (web search & information retrieval).
• LSP: pyright (Python type checker & static analysis), yaml-ls (YAML syntax validation & autocompletion).
• Plugin: alkdev/open-memory (persistent memory storage of architectural decisions & insights).

Both models had identical access to this tooling in every run.

Results

Headline numbers

Metric	DeepSeek V4 Pro (0813)	DeepSeek V4 Flash (0731)
Claim accuracy (exact)	95.9% (162/169)	95.7% (67/70)
Hard factual errors	0	1
Verifiable output volume	169 claims (2.4x more)	70 claims
Real latent bugs found (of 3 known)	1/3	3/3 (2 unique to Flash)
Run-to-run consistency	low (depth varied ~2.7x between runs)	high
Instruction adherence (conflict task)	5/5	5/5
Cost (requests quota per 5h)	3,450	31,650 (~9x cheaper)

The key finding

Factual accuracy is statistically identical (~96%). The original assumption "Flash is sloppy with facts, Pro is precise" did not hold up in benchmark conditions. What differs is not accuracy — it's what each model focuses on, and the type of rare errors each one makes.

Strengths and weaknesses

DeepSeek V4 Pro (0813) — "the architect-documenter"

Strengths

• Broad, deep structural analysis: layer violations, unused abstractions, duplicate code pairs, typing gaps (dict vs typed models), performance analysis (algorithmic complexity, repeated I/O, model-loading bottlenecks).
• Zero hard factual errors across 169 claims — its line references can be trusted for making code edits.
• Best output for architecture reviews, refactoring plans, and documentation.
• Exhaustive reports when it's in a good run (its best run was ~3x deeper than its average).

Weaknesses

• High run-to-run variance: report depth varied 2.7x between two identical runs (354 vs 118 lines). A single run is a lottery — sometimes exceptional, sometimes merely good.
• Missed latent bugs in error-handling branches: 2 of 3 known bugs were found by Flash but not by Pro in two runs.
• ~9x more expensive in request quota.

DeepSeek V4 Flash (0731) — "the bug hunter"

Strengths

• Exceptional at finding bugs in edge/error paths: found 2 real latent bugs that Pro missed in both of its runs (a broken code-path condition in a manifest-repair function, and a resume-numbering bug with custom pauses).
• Highly consistent between runs — same focus, same quality.
• ~9x cheaper quota.
• Equal to Pro on instruction adherence and prompt following.

Weaknesses

• Less breadth: fewer architectural findings, more compact reports.
• 1 hard factual error of a specific type: it invented a plausible-sounding edge case (claimed a data-loss scenario that the code doesn't actually have — an empty filter list is treated as "no filter", not "empty result").
• This error type is worth noting: a false alarm is cheap in a review, but dangerous if the model edits code autonomously based on its own claim.

Verdict: how to use each model

1. Bug hunting and edge-case review → Flash first. 9x cheaper, finds more real bugs, stable across runs. Its rare errors are false alarms — cheap to verify, and a false alarm costs less than a missed bug.
2. Architecture review, refactoring plans, documentation → Pro. Breadth + zero hard errors; its output can be used as a checklist for edits without re-verifying coordinates.
3. Code edits with precise line references → Pro only (or Flash + a mandatory Pro fact-check). Pro's error profile is the safe one when the output drives actual code changes.
4. Never rely on a single Pro run for a complete audit — run-to-run variance is real. Either run it twice, or pair it with a Flash pass.

Combination recipes (validated by the benchmark)

• "Flash scan → Pro finalization" — Flash produces the draft (bugs + core problems, cheaply), Pro corrects/rejects/completes with change markers. Result quality was >= any single-model run. This was the best mode overall.
• "Pro fact-check of Flash's report" — Pro verified ~70 of Flash's claims: confirmed both of its real bug findings while catching 3 interpretive inaccuracies. For anything important, this pairing is the safe default.

General conclusions

1. The difference is not "smarter vs dumber" — it's attention policy. Pro maximizes breadth (risking shallow coverage of deep edge paths); Flash maximizes depth of edge paths (risking a rare invention). Both are ~96% accurate.
2. Rare-error profiles differ: Pro undercounts (conservative — underestimates parameter/field counts), Flash overreaches (invents plausible but wrong edge cases). For an agent that edits code, Pro's profile is safer; for a reviewer, Flash's is fine and its bug-finding is better.
3. A two-model pipeline beats either model alone. The optimal workflow measured here: Flash as the cheap scanner → Pro as the verifier/finalizer. It found more real bugs than Pro alone and produced more trustworthy output than Flash alone.
4. Bonus: the benchmark itself surfaced 3 real bugs in my own codebase (a dead code-path condition, a resume-numbering defect, and a NameError in an error branch) — plus a data-loss regression in the claims-verification flow. The tool paid for itself.

Setup notes: benchmark harness with fresh sessions per run, identical prompts/tools, read-only analysis, third-party claim verification (Qwen 3.7 Plus), answer-key-based recall measurement. Single codebase, 6 task types — treat the numbers as a profile of behavior, not a universal ranking.

1. Preface

> TL;DR — three rules you can steal right now: > 1. Let Flash hunt bugs (cheaper, finds what Pro misses) and Pro fix them (no hard errors, complete implementations). > 2. Nothing merges unverified: red-green tests, static analysis, blind diff review by a third model. > 3. The human is the Tech Lead: AGENTS.md, priorities, gates, merges. LLMs are strong interns, not seniors.

With more than 25 years of experience in classic software development, I long ago outgrew the excitement about "magic tools". To me, an LLM is a high-performance but impulsive intern: without strict engineering discipline it generates technical debt faster than you can make a git commit.

I often notice developers making a fundamental mistake: they give tasks to neural networks from a Product Owner's position ("Here's feature X, write the code"), expecting the LLM to act like an experienced Senior or Architect — to account for context, edge cases and architectural constraints on its own. But an LLM is far from a Senior. To keep the project from turning into a tangled pile of spaghetti, the human must act as a strict Tech Lead: set rigid methodologies, assign roles and structure the development process.

Based on two deep benchmarks (run on a private project with an AST graph of >15,000 nodes) I identified the exact capability boundaries of my daily-driver models — DeepSeek V4 Flash (0731) and DeepSeek V4 Pro (0813). I handed my notes and facts to DS Flash for initial structuring, and turned the result into a working playbook I now use to run my entire process. Sharing this playbook — I'm sure it will save someone months of trial, error and code rewrites.

What it is: an operating plan for a "development department" where the programmers are opencode (orchestrator) + two LLMs, and the tech lead is a human. The document answers three questions at every step: what to do, how to do it, and why exactly this way.

Context and methodology:

• System size: a real, non-public Python + PySide6 project (AST graph: 15,000+ nodes, 79,000+ edges).
• Data transparency: the codebase is not open-sourced on GitHub. Although the project was partially developed with earlier iterations of Flash/Pro (and hypothetically some fragments of API requests could be in logs), the models had no direct access to the complete current architecture or the new tasks.
• Evidence-based: every rule in this playbook is derived from two benchmarks:
  1. Who analyzes code and finds bugs better
  2. Who implements fixes better
• Limitations: the findings come from a single (private) codebase, two model versions (Flash 0731, Pro 0813), one review rubric and one reviewer. Treat the numbers as directional for your own setup, not as universal law. Both models iterate fast — re-validate before relying on newer versions.

A short digest of the facts I'll be referencing:

• Bug hunting: Flash found 3/3 known latent bugs (2 unique), Pro 1/3. Flash consistently "plays through" edge paths in its head.
• Accuracy: Pro — 0 hard errors on 169 claims; Flash — 1 on 70 (error type: "invented a plausible edge case").
• Analysis breadth: Pro — 169 verifiable claims vs Flash's 70 (layers, DRY, typing, performance).
• Fix implementation: blind review by a third model (single reviewer, one rubric) — Pro 27/30 vs Flash 25/30; the 2-point gap is directional, not decisive. Flash had 3 correctness defects (incomplete locking, masking merge, incorrect resume) and 1 new static-analysis error. Pro had 0 defects.
• Proven pairings: Pro fact-checking Flash's report confirmed its real findings and cut 3 wrong interpretations; blind diff review caught all of Flash's defects; red-green validation proved both models' tests genuinely catch bugs.
• Cost: Flash is roughly 9x cheaper in request quota.
• Instructions: both models follow AGENTS.md flawlessly (5/5 on the conflict task).

How to use it: sections 2–3 are orientation (read once); sections 4–5 are the working roadmap (keep at hand, tick off steps as you go).

2. Roles and rules

Player	Role	What it does	What it must NOT do	Why
Flash	Scout	Bug hunting, edge cases, hypotheses, inventory of duplicates/dead code, test scenario generation, cheap passes	Implement fixes alone; issue final coordinates unverified	Found 3/3 latent bugs (Pro 1/3); 9x cheaper; but 1 "overreach" error per 70 claims
Pro	Engineer-verifier	Implementing fixes and features, architecture, refactoring plans, fact-checking, precise coordinates, finalization	Run "fast" without duplication for critical audits	0 hard errors on 169 claims; won fix implementation 27/25; but run-to-run lottery (depth 354↔118 lines)
Review model (third model, see section 6)	QA	Blind diff review and claim fact-checking per rubric	Take part in implementation	Blind review found all 3 of Flash's defects; verdicts verified mechanically
opencode	Orchestrator	Fresh sessions per model, branch isolation, gate execution, memory	Do the models' tasks inside their sessions	The clean benchmark protocol produced reproducible results
Human	Lead	Priorities, stage entry/exit, merges, spot-checks, AGENTS.md	Write code the models can write

Hard allocation rules:

1. In this workflow, any Flash output that drives action gets a Pro fact-check first (in our tests Pro confirmed Flash's real findings and cut 3 false interpretations).
2. Any implementation passes gates G1–G5 before merge.
3. Critical analysis shouldn't rely on a single run: two Pro runs or Pro+Flash.
4. Models work in fresh isolated sessions; one session = one model = one task.

3. Quality gates (before every merge)

Gate	Check	Catches
G1	Full test suite; failures no worse than the base branch	Regressions
G2	Red-green of new tests: test fails on pre-fix code, passes after	Fake tests, implementation-coupled tests
G3	Static analysis (pyright/linters): 0 new errors	Defects introduced by the fix (Flash had 1 new pyright error)
G4	Diff scope: only plan files, no new dependencies, CLI intact	Scope creep
G5	Blind diff review (third model or Pro reviewer per rubric)	Correctness defects tests don't catch (found all 3 of Flash's)
G6	Test-first commits, one per item, meaningful messages	Un-reviewable, unbisectable history

Minimum set for a hotfix: G1 + G2 + G3.

4. Cases (the roadmap)

Format: trigger → steps → gates → why → risks/cost.

4.1. Starting a new project

Trigger: empty repo, requirements, stack choice.

Steps:

1. Human: fix requirements, write/update AGENTS.md (rules, architectural constraints).
2. Pro: architecture — modules, layers, protocols, data schemas, contracts.
3. Pro: skeleton layer by layer, each with tests (G2 along the way).
4. Flash: independent audit of the skeleton — edge cases, error branches, missed paths.
5. Pro: fix what was found (fact-check each Flash finding first).
6. Gates: G1, G3, G5 (skeleton review on the first major commit).
7. Human: approve the architecture and the first major commit.

Why: architectural breadth is Pro's strength (169 claims; layers/DRY/typing/perf). Latent bugs in error branches are found only by Flash (3/3 vs 1/3) — an early Flash audit of the skeleton is orders of magnitude cheaper than rework after code accumulates.

Risks/cost: skeleton mistakes amortize over the whole project → audit is mandatory before the first "feature" commit. A single Pro run is a lottery → duplicate the architecture decision with a second Pro run.

4.2. Implementing a feature

Trigger: a task to add functionality X.

Steps:

1. Pro: feature design — contracts, types, boundaries, integration points.
2. Pro: test-first implementation, commits per logical step (G6).
3. Flash: bug-scan of the new feature (edge paths, error handling, concurrency).
4. Pro: verify Flash's findings + fix.
5. Diff review (G5), then G1–G3.
6. Human: brief design review, then approve merge.

Why: in our blind review Pro came out ahead as the implementer (27/25, mostly on correctness and completeness — single reviewer) and delivered 0 defects, 14 test-first commits vs Flash's 2 monolithic. A Flash scan after implementation finds what Pro misses (2 unique latent bugs in benchmark 1) — cheap (~9x) with high payoff.

Risks/cost: Flash scan may produce a false alarm (invented edge case) → step 4 is mandatory. Expected price: 1 Pro pass + 1 Flash pass + review.

4.3. Fixing a known bug

Trigger: bug report with symptoms, expected behavior, reproduction conditions.

Steps:

1. Flash: diagnosis — chain of conditions, git history (including search for reverted fixes), scenario play-through.
2. Pro: verify the diagnosis + precise coordinates (file:line).
3. Pro: fix + regression test (G2: test fails on pre-fix code).
4. Gates: G1, G3.
5. Human: confirm the diagnosis matches the reported symptoms.

Why: Flash builds bug mechanics excellently (benchmark T3 — all 4 runs found the root cause; Flash additionally found the reverted fix in git history). But its rare errors are "plausible-but-wrong" scenarios, so in this workflow a Flash diagnosis goes to code only after a Pro fact-check (in our tests Pro confirmed 2 real bugs of Flash and cut 3 wrong interpretations).

Risks/cost: skipping step 2 risks "fixing the wrong bug". Model: Flash (cheap) + Pro (precise) — the cheapest of all cases.

4.4. Debugging an unknown root cause

Trigger: symptom exists, cause unknown.

Steps:

1. Flash: hypotheses + edge paths + git history (time-boxed phase).
2. Pro: verify hypotheses, reproduce, pinpoint the root cause.
3. Pro: fix + regression test.
4. Gates: G1–G3.
5. Human: sanity-check the root cause before the fix.

Why: the only unique latent-bug findings in benchmark 1 came from Flash (dict passed where a string was expected in a dead branch; chunk-numbering desync on resume). This is where Flash outperformed Pro in our tests. But its hypotheses are raw material, not truth (1 invented edge case) → Pro verification is mandatory.

Risks/cost: getting stuck in the Flash phase → time-box it (e.g., one session). Important: Flash must not dig forever.

4.5. Writing tests

Trigger: new coverage, regression tests for fixes, raising a module's coverage.

Steps:

1. Flash: scenario generation — edge cases, negative cases, parametrization, concurrency.
2. Pro: test review — do they test themselves, are they coupled to implementation, do they target the root cause; fill coverage gaps.
3. G2 (red-green): each new test fails on pre-fix code, passes with the fix.
4. Full suite (G1).
5. Human: spot-check what the new tests cover.

Why: Flash wrote the strongest single test of benchmark 2 — a thread-safety test Pro never thought of; 13/13 of its tests were red-green. Pro's coverage is denser and its tests target root causes precisely (the dead-branch test caught exactly the bug). The pairing "Flash generates scenarios → Pro verifies" yields both breadth and precision.

Risks/cost: implementation-coupled tests always pass → only G2 catches that; skipping G2 devalues the whole case.

4.6. Code review

Trigger: PR/branch before merge.

Steps:

1. Flash: quick scan — suspicious spots, edge cases, error handling (cheap, ~9x cheaper than Pro).
2. Pro: deep review — SOLID/DRY, typing, performance, precise comments with coordinates.
3. Consolidation: Pro verdict primary, Flash findings supplementary.
4. Human: final call on contentious findings.

Why: Pro produces 2.4x more verifiable output with 0 hard errors — its comments can be applied without re-verification. But a Pro architectural pass misses latent bugs (1/3), which Flash finds → only joint review is complete.

Risks/cost: Flash-only review misses architectural problems; Pro-only misses latent bugs. The pair costs about one Pro pass plus a small Flash pass.

4.7. Refactoring (behavior-preserving)

Trigger: duplicates, dead code, bloated modules, planned structural improvement.

Steps:

1. Flash: inventory — duplicates, dead code, odd spots, inconsistent constants.
2. Pro: plan — coordinates, priorities, risks, what to test, what not to touch (public contracts).
3. Pro: one step at a time, each with tests (G2 along the way).
4. Flash: regression scan — missed call sites, broken contracts, forgotten places.
5. Gates: G1, G3.
6. Human: approve the plan and each step's merge.

Why: Pro won the refactoring-plan rubric in benchmark 1 and the implementation in benchmark 2 (correctness 5/5). Flash is better at minimality, but correctness beats minimality in refactoring — its implementation contained defects (incomplete locking). A Flash scan after the refactor catches edge regressions Pro won't check.

Risks/cost: refactoring without tests (G1) is not allowed; large refactors strictly one step at a time, as in benchmark 2 (Pro: 14 commits, each verifiable).

4.8. Closing tech debt

Trigger: a tech-debt plan (list of prioritized items — e.g., P0/P1/P2, like the FIX_PLAN).

Steps:

1. Analysis and plan (see case 4.9).
2. Pro: implement item by item, test-first, one commit per item (G6).
3. Optional: Flash implements the same plan in a parallel branch — to compare solutions.
4. Blind review of the diffs by a third model (G5) — anonymized diffs per rubric.
5. Selection: base = best branch, cherry-pick the best solutions from the other (proven recipe: Pro base + port Flash's cross-platform lock class and its strongest test).
6. Human: decide branch selection and cherry-picks.

Why: this is exactly benchmark 2's scenario. The two-branch scheme is proven: both models implemented the plan without regressions, blind review found defects that tests don't catch, and the "base + cherry-pick" recommendation produced code better than either branch alone.

Risks/cost: the most expensive case (2 implementations + review) — use it for major tech debt; for small items a single Pro implementation + G5 suffices.

4.9. Deep project analysis / onboarding

Trigger: architecture audit, entering an unfamiliar module, project health assessment, preparing a tech-debt plan.

Steps:

1. Pro: main audit — structure, layers, dependencies, typing, performance, dead code.
2. Flash: second pass — bugs, edge paths, false dependencies (explicit check of "is X actually a dependency").
3. Consolidate into a document: Pro's description + Flash's findings.
4. Critical audits: duplicate the Pro run (or Pro+Flash) and merge both.
5. Human: define audit scope; store the resulting document in the project memory.

Why: Pro gives breadth (169 claims), Flash gives depth (the only one finding latent bugs and explicitly rejecting false dependencies). Pro's variance (report depth 354↔118 lines between two identical runs) is a real risk: a single run may be merely average — hence the duplication rule.

Risks/cost: an audit without duplication may miss things; save the resulting document into the project's memory (open-memory / docs) — it becomes the input for cases 4.8 and 4.7.

4.10. Documentation

Trigger: architecture docs, README, module descriptions, updating stale docs.

Steps:

1. Pro: draft — structure, completeness, architectural context.
2. Flash: check for stale and false claims, code mismatches.
3. Pro: finalization + coordinate fact-check (0 hard errors on 169 claims).
4. Human: review for audience and wording.

Why: in the T6 task Flash was the only model to explicitly reject false dependencies (files that looked like dependencies but weren't) — an ideal claim-checker for docs. Pro is a reliable author: its coordinates contain no errors.

Risks/cost: docs without fact-check become stale within a month. The pairing is cheap (Flash check is a fast pass).

4.11. Impact analysis / migration / schema changes

Trigger: field rename, artifact format change, dependency upgrades, data migration.

Steps:

1. Flash: full dependency search + explicit rejection of false ones (verify each hit).
2. Pro: risk classification, migration plan (schema validation, old-artifact compatibility, fallback period).
3. Pro: migration + tests.
4. Gates: G1–G3.
5. Human: approve the migration plan (risk acceptance).

Why: in T6 both models handled impact analysis, but Flash stood out with the "trap" (explicit rejection of non-dependencies) and Pro with schema analysis completeness (StrictBaseModel, extra=forbid, load points). Migrations need a complete dependency list — a single missed one silently breaks an unobvious consumer.

Risks/cost: the main risk is a missed dependency; double search (Flash + Pro) covers it. G3 is mandatory — migrations most often break types.

4.12. Hotfix / production incident

Trigger: critical production bug, immediate fix needed.

Steps:

1. Pro: minimal fix right away + regression test.
2. Urgent merge with minimal gates: G1 (targeted tests) + G2 + G3.
3. After stabilization: Flash — post-mortem: why wasn't the bug found earlier, adjacent edge cases, similar spots in the code.
4. Pro: proper fix per findings + full gates G1–G5.
5. Human: trigger the hotfix; later approve post-mortem actions.

Why: in an emergency, defect-free correctness (Pro's strength, 0 hard errors) trumps the two-pass Flash scan. But the Flash post-mortem is strongly recommended: an incident usually means a latent bug slipped past the normal process — and those are exactly what Flash finds.

Risks/cost: a hotfix without a regression test (G2) invites a repeat incident; don't postpone the post-mortem (context is lost within a week).

5. Anti-patterns (what NOT to do)

#	Anti-pattern	Why (fact)	Instead
1	Single Pro run as a complete audit	Pro variance: depth of two identical runs 354↔118 lines	Duplicate the run or Pro+Flash
2	Flash implementation without review	3 correctness defects in benchmark 2 (incomplete locking, masking merge, incorrect resume) — all found only by review	Always G5 after Flash implementation
3	Flash diagnosis → straight to fix	1 invented edge case per 70 claims from Flash	Mandatory Pro fact-check (step 2 of case 4.3)
4	"Always-merge" data writes instead of explicit semantics	Masks data loss on full runs (Flash's defect in B2)	Explicit semantics: merge only where needed
5	Both models in one session / shared context	Contamination breaks cleanliness: only fresh isolated sessions gave reproducible benchmark results	One model = one session = one task
6	Sloppy AGENTS.md	Both models follow instructions 5/5 — a working control lever; without it you lose control over style and prohibitions	AGENTS.md is the first artifact of any project (case 4.1)
7	Merge without gates	Only blind review (G5) found Flash's defects; only red-green (G2) proves tests are meaningful	G1–G5 before every merge, minimum G1+G2+G3 for hotfix

6. Choosing a review model

For the QA role (blind diff review, claim fact-checking), any inexpensive model with format discipline works — this task is not about creativity, it's about care and tool use.

Proven in practice: Qwen3.7 Plus — served as verifier and blind reviewer in both of my benchmarks; every verdict was confirmed by mechanical checks.

Solid cheap alternatives (with generous quotas): Qwen3.6 Plus, Hy3, MiniMax M3, MiMo-V2.5-Pro.

Avoid: models with tiny request quotas (a diff review means hundreds of tool calls; a cheap model with a tiny quota burns out on the first task) and premium models (the task is mechanical — overpaying is not justified). And the golden rule: the reviewer must never be one of the models being compared — conflict of interest.

Model names above are examples from my provider (opencode Go) — check what equivalents your provider offers.

This playbook is based on two benchmarks: who analyzes code and finds bugs better and who implements fixes better. Benchmark methodology: fresh sessions per model, identical prompts and tooling, third-model verification + mechanical checks, answer keys for recall measurement.

​"SMTs require absolute cryptographic correctness, while PDF specs are a legacy parsing nightmare.

Have you found AI useful for scaffolding these, or do the subtle hallucinations make it more trouble than it's worth?"

As the title suggests, here’s a brief chronological overview:

- November/December 2025: I began exploring agent-based coding, with Gemini’s plans for Antigravity at the time

- February 2025: I switched to Claude Code after seeing Gemini whine about everything

- March 2025: I actually start to learn about the world of “product management”: before building anything, I brainstorm what I really want to bring to market and what problem needs to be solved

- April/May 2025: Claude Code gets heavily nerfed; I switch to Codex

- May/June 2026: Codex gets heavily nerfed; I switch back to Claude Code for 100 euros

- June 2026: With the new limitations imposed by the plan, I actually start experimenting with and understanding AI and building the first anti-noise gates, checking documentation, verifying hypotheses, shared memory, etc.—all to align the AI’s output and make it as accessible as possible

- July 2026: Claude Code starts causing problems; it seems more unruly than usual, begins sabotaging me and deliberately ignoring the gates, always telling me “you’re right.” Time passes, and so does my money

- August 2026: I’m trying to set up Pi; I’ve canceled my Claude Code subscription and am currently using the one-month free trial offered by Codex

All this to say: I’ve put friends, relationships, and everything else aside to focus on what I want - an environment that’s accessible, educational, and, above all, one that doesn’t sabotage the user.

The result? Codex is completely unmanageable: it silently modifies internal documentation and planning and execution protocols to tell me it “did it” when in reality it didn’t. It doesn’t load skills. It constantly sabotages me, overlooks errors, always relies on simplistic pattern matching, gets command syntax wrong, and either crashes on its own or throws errors.

After more than 8 months of trying to create a secure orchestration system and environment (using Flue and Pi), I haven’t managed to accomplish anything. With the AI, I can only write drafts of articles for a publication I’m running with a partner (they’re drafts—the articles and revisions are handwritten). I really don’t know what to do anymore. I won’t hide the fact that I literally broke down crying once. I’m sacrificing everything.

How are you guys getting by? I can’t wrap my head around the fact that I have to use the most powerful models just to perform simple tasks (like creating a Pi extension). People on YouTube use GPT-5.4 Medium just fine, but when I use it, it acts like a terrorist.

What am I doing wrong? What are your setups? What protocols and skill sets do you use?

I should mention that I’m a beginner who’s eager to learn, but so far, I’ve had zero results.

Thanks, everyone. Thank you so much.

Genuine question with tools like Copilot, Claude Code, Cursor, etc. getting so good, how much of your day-to-day is still typing code by hand vs. prompting/reviewing AI output? Curious how this varies by role (frontend vs backend vs infra) and experience level.

Need some genuine advice.
At my company, we’re limited to $300 worth of AI tokens per month. Earlier, we had an option to extend the limit, but that’s no longer available, so we have to manage within the $300 budget.
I’m a full-stack developer, and AI has become a major part of my development workflow — understanding the codebase, implementing features, debugging, writing/refactoring code, reviewing PRs, etc. With the amount of work we have, going back to writing everything manually would be extremely difficult.
I’m looking for good alternatives once the company-provided AI quota is exhausted. I’m also okay with paying from my own pocket, as long as it’s reasonably priced. Ideally, I’d prefer something with very high or no practical usage limits.
I tried a Codex subscription, but since I had to log in using my personal account on my office machine/repository, I wasn’t comfortable using it for company code, so I stopped.
What are other developers in a similar situation using?
I’m open to:
Local LLMs
Paid coding assistants
API-based solutions
VS Code extensions/agents
Any other setup that works well for full-stack development
My main requirements are good coding capability, high usage limits, reasonable cost, and preferably something that can be used safely with company code.
Would really appreciate genuine recommendations from people who have actually used these tools.

Payment webhook handler. Intermittent 500s.

I pasted the error into an AI coding assistant, got a fix, tried it, still broke.

Pasted the new error, got another fix, tried that, still broke.

Did this maybe four times before realizing what I'd actually turned into: not someone debugging anymore, just someone pasting error messages into a chat window and hoping the next response would be the one that stuck.

The interesting part was that none of the suggestions were obviously stupid.

The first was a retry around a database write. Reasonable response to "database write failed."

Except the actual problem was duplicate webhook delivery upstream hitting a handler that wasn't idempotent. Two workers were occasionally processing the same event.

The retry addressed the symptom I'd shown the model, not the mechanism producing it.

I then tried the obvious solution: give it more context.

That made things worse.

I pasted more surrounding code, but the context I added was already biased by my own suspicion. I'd started thinking the caching layer was involved, so I gave the model more caching-related code.

It reasoned confidently about the wrong subsystem.

That's when I realized I'd been mixing up two completely different tasks:

Generating a fix and validating a fix.

Generating asks:

>"Does this make the error go away?"

Validating asks:

>"Does this address the mechanism that caused the failure, and what does it change that I didn't explicitly ask for?"

Almost every one of those first fixes could have passed the first question.

None had passed the second.

What finally broke the loop was changing the process:

• define what's actually failing before asking the AI to diagnose it
• separate facts from hypotheses
• ask for competing explanations before asking for fix code
• understand the failure mechanism first
• validate the proposed change against the original failure
• add a regression test that reproduces the actual bug

The biggest lesson for me wasn't "AI is bad at debugging."

It was that a plausible fix is dangerously easy to mistake for a diagnosis.

Curious if other people doing AI-assisted debugging have run into this: a fix technically resolves the error you showed the model, but leaves the underlying problem untouched (or introduces a different one).

How do you validate AI-generated fixes before they reach production?

In my previous post (https://www.reddit.com/r/opencode/comments/1vnaje2/deepseek_v4_flash_0731_vs_deepseek_v4_pro_0813_i/) I benchmarked DeepSeek V4 Pro (0813) and DeepSeek V4 Flash (0731) as code analysts — who finds more bugs and writes more accurate analysis. The result was counterintuitive: the cheap Flash found 2 real latent bugs that Pro missed.

But there's another side to daily work with an AI agent: who implements fixes better? Finding a bug is one thing; fixing it correctly, completely, without breaking anything and without introducing new problems is another. So I ran a second benchmark: same project, same stack, same two models — this time both implemented the same fix plan on the same base commit, each in its own git branch. Then I compared the quality of the resulting code.

Methodology

The task

The first benchmark produced a fix plan (15 items) for real problems found in the project:

• Block A (critical, P0): a data-loss regression in the claims-verification flow (file overwritten with a filtered subset), a NameError in an error-handling branch, a dead code path caused by passing a dict where a string was expected, and a chunk-numbering desync after resume with custom pauses.
• Block B (reliability, P1): 10 items — silent except Exception blocks, missing command timeouts, checkpoint truncation, an unsafe refactor path, path resolution inconsistency, missing media deduplication for video/audio, thread-safety, and optional file locking.

The plan included exact file:line references, expected behavior, and required regression tests.

Protocol

• Both models implemented the identical plan (blocks A+B) on the identical base commit, each in its own git branch (bench-fix/pro, bench-fix/flash), in fresh sessions with identical tooling.
• The models didn't know they were being compared; each committed its own branch independently.
• Mechanical verification (orchestrator): full test suite on base + both branches; red-green validation of every new regression test (must fail on base, pass on the branch); pyright static analysis; diff scope check (no files outside the plan, no new dependencies).
• Blind review: the two diffs were anonymized (no branch/model names) and reviewed by a third model (Qwen 3.7 Plus) on 6 axes, 1-5 scale: correctness, completeness, minimality, test quality, style, risks. The reviewer's claims were then mechanically verified.

Environment

Same stack as benchmark 1: opencode 1.18.16, Python + PySide6 project.

• MCP servers: aik, codebase-memory-mcp, filesystem, sequential-thinking, sqlite, tavily.
• LSP: pyright, yaml-ls.
• Plugin: alkdev/open-memory.

Results

Mechanical verification

Metric	Pro (0813)	Flash (0731)
Full test suite	2009 tests, failures identical to base (16 pre-existing)	2006 tests, failures identical to base
New regression tests	20 (10/10 red→green)	17 (13/13 red→green)
pyright errors on fixed files	51 (both target bugs fixed, 0 new)	52 (both target bugs fixed, 1 new: possibly-unbound variable)
Commits	14 (one per fix, test-first)	2 (monolithic)
Diff size	+846/−106	+1057/−207
Files outside the plan	none	none

Both models implemented all 15 items, broke no existing tests, and their new tests genuinely catch the bugs. Fun fact: both independently added the same bonus test for the same fix.

Blind review (third model, 6 axes, 1-5)

Axis	Pro	Flash
Correctness	5 — merge semantics exactly per the reference commit; overwrite gate removed; all read-modify-write methods locked	4 — always-merge can mask data loss on full runs; checkpoint resume with filters is incorrect; two CRUD methods left unlocked
Completeness	5 — all items incl. optional ones	4 — locking incomplete (3 of 5 methods)
Minimality	4 — a parameter threaded through 17 call sites (scope creep)	5 — minimal, focused
Test quality	5 — denser coverage; the A3 test catches the root cause directly	4
Style	4 — fcntl without fallback	5 — cross-platform lock class, clean DRY refactor
Risks	4	3 — real race left open, masking merge, incorrect resume
Total	27/30	25/30

The reviewer's key claims were mechanically confirmed: Pro locked all 5 CRUD methods, Flash locked only 3 (exclude/include left unprotected — a real race between GUI and CLI).

Strengths and weaknesses

DeepSeek V4 Pro (0813) — "the careful implementer"

Strengths

• Semantically precise fixes: merge applied only on partial runs (so full runs still surface data loss instead of masking it), explicit-priority claim filtering, correct checkpoint resume with filters.
• Full completeness, including the optional items (locking all 5 CRUD methods, documenting non-atomic group writes).
• Better regression tests: more coverage, and its tests target the root cause rather than an implementation detail.
• Zero new static-analysis errors; clean commit discipline (14 test-first commits).
• 0 hard defects found by the blind reviewer.

Weaknesses

• Heavier diffs: a partial_run parameter threaded through 17 call sites — judged as scope creep, though it turned out to be what makes the semantics correct.
• Less portable code (no cross-platform fallback for fcntl).

DeepSeek V4 Flash (0731) — "the bold implementer"

Strengths

• Minimal, focused diffs — no parameter propagation, clean DRY refactor of a duplicated block.
• Better code craftsmanship: cross-platform lock class with ImportError fallback, module-level timeout constant, clean style.
• Wrote the strongest single test in the benchmark: a thread-safety test for the dedup lock (Pro didn't think to test concurrency).

Weaknesses

• Three real correctness defects the blind reviewer caught: incomplete locking (2 CRUD methods left unprotected — a real race), always-merge that masks potential data loss, and incorrect checkpoint resume when filters are used.
• 1 new pyright error introduced.
• Monolithic commits (2 instead of 14) — harder to review and bisect.

Verdict: how to use each model

1. Flash for finding bugs → Pro for fixing them. This is the strongest practical takeaway of both benchmarks combined: in benchmark 1 Flash found 2 real latent bugs Pro missed (3/3 vs 1/3); in benchmark 2 Pro implemented the fixes more reliably (27 vs 25) with zero correctness defects. The optimal pipeline: Flash audits/scans, Pro implements and verifies.
2. If you let Flash implement — a mandatory Pro review pass. The blind review found 3 real defects in Flash's code in one pass. A review step is cheap compared to a race condition or masked data loss reaching production.
3. For production fix implementation, prefer Pro. Its profile — complete, conservative, test-first, zero new static errors — is the safe one when the output goes straight into your codebase.
4. The "pretty code" trap: Flash's implementation was judged better in style (cross-platform, DRY, minimal) but worse in correctness. Aesthetics don't compensate for an unlocked race.

General conclusions

1. The two models complement each other perfectly — in opposite directions. Flash: better at discovering problems, bolder, but less careful when writing fixes. Pro: better at implementing fixes, complete and safe, but heavier-handed. The error profiles from benchmark 1 held: Flash overreaches (invented an edge case in analysis, left a race in implementation), Pro underreaches (conservative, occasionally over-engineered).
2. Non-minimal is not always worse. Pro's "scope creep" — the partial_run parameter — was exactly what made the fix semantically correct. Minimalism (Flash's strength) and correctness (Pro's strength) are different axes.
3. The methodology worked: red-green validation proved both models' tests are real (10/10 and 13/13 fail on the unfixed code); the blind reviewer's verdicts were mechanically reproducible (lock coverage 5/5 vs 3/5 verified by grep); pre-existing test failures stayed identical across all branches — neither model broke anything.
4. A practical recipe from two benchmarks: Flash (cheap, for hunting) → Pro (for implementing) → a third model or Pro review pass (blind check of the diff). Each step covers the previous one's blind spot.

Setup notes: one Python + PySide6 codebase, 15 fix items, fresh sessions per model, identical tools (opencode 1.18.16, MCP/LSP stack listed above), blind third-party diff review (Qwen 3.7 Plus) with mechanical verification of its claims. Treat the numbers as a behavior profile, not a universal ranking.

I’m thinking about using OpenAI Codex together with DS V4 Flash for coding. Has anyone tried this combination? How do you split the work between the two models? What are the strengths of each, and did you find the combination better than using just one model?