Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Opening the Markdown preview for certain Chinese/English mixed-content documents renders a completely blank panel — no error message, no “content disabled” banner, nothing in the panel at all. The source view works fine. The same content renders correctly (in ~9 ms) with vanilla markdown-it + @vscode/markdown-it-katex, so the file itself is valid CommonMark.
Steps to Reproduce
Steps to reproduce
Open the attached cursor-bug-repro.md (~9 KB) in Cursor.
Open Markdown preview (Cmd+Shift+V).
Operating System
MacOS
Version Information
Environment
Cursor Version: 3.9.16 (Universal), Build: Stable, Release Track: Default
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80 (2026-06-27)
VS Code Extension API: 1.105.1
Electron: 40.10.3 / Chromium: 144.0.7559.236 / Node.js: 24.15.0
OS: macOS (Darwin arm64 25.5.0)
Additional Information
cursor-bug-repro.md
Keynote Summary — LLMTrust 2026 (FSE 2026 Workshop)
Talk: The Next Era of Software Engineering: From Writing Code to Engineering Trust
Speaker: [Baishakhi Ray](— Associate Professor, Columbia University; Amazon Scholar
Venue: [LLMTrust 2026], 1st International Workshop on SE for and with Trustworthy LLMs, co-located with ACM FSE 2026 — July 5, 2026, Concordia University (MB 3.445), Montreal, Canada
TL;DR
As AI agents make code generation nearly free, the bottleneck of software engineering shifts from producing software to trusting it. Ray argued that the field is entering an era where verification, behavioral reasoning, executable knowledge, and trustworthy human–AI collaboration become first-class engineering activities. The talk combined a conceptual framework (four first-class activities, a trust/autonomy ladder) with concrete research from her group: a context-aware patch refinement pipeline (REFINE) and a red-teaming attack showing “correct” agent patches can hide vulnerabilities (SWExploit).
中文摘要
演讲主题：软件工程的下一个时代——从编写代码到构建信任
随着 AI 智能体让代码生成变得几乎免费，软件工程的瓶颈正从"生产软件"转向"信任软件"。Ray 教授指出，隐性的生产力损耗正在显现：调试时间增加、代码返工（churn）增多、代码库结构熵不断上升。信任包含两个维度：技术信任（正确性、安全性、回归安全、可验证性）与人际信任（可解释性、团队实践、过度依赖风险、协作规范）。
她提出新时代的四项一等工程活动：
- 理解（Understand）——行为推理是基础：从有缺陷的代码中推断意图，生成可检查的规约（定位 → 分析 AST/数据流/调用图 → LLM 推断行为 → 起草前置/后置条件 → 验证并给出理由）。
- 编码知识（Encode）——把理解转化为机器可检查的产物：规约、不变式、契约，以及作为"编码意图"的测试。核心口号：“让机器能检查的意图，而不是 wiki 里的散文”——行为一旦漂移，可执行知识会立刻报错。
- 验证（Verify）——从测试走向证明：轻量级用生成测试 + 静态分析，最强用 F*/Dafny/Verus 证明式编程；原则是"用合适的成本换取合适的保证"，验证强度应与变更的风险匹配。
- 协作（Collaborate）——可信的人机协作：AI 代码与人类代码接受同等评审、附带来源与置信度标签；防御三大威胁（提示注入、恶意代码、脆弱代码）；正视"AI 写得比人审得快"的规模问题。
两项代表性研究：REFINE（多智能体补丁精化流水线：Issue 上下文 → 代码上下文 → 增量补丁生成 → 评审 → 聚合 → 验证，用测试时扩展使补丁多样化）；SWExploit（红队攻击：仅通过伪造 GitHub issue 文本，就能诱导修复智能体产出"通过全部测试却暗藏漏洞"的补丁，如 CWE-78 命令注入——说明单元测试不是充分的信任判据，issue 本身就是攻击面）。
在评测方面，她强调 通过率 ≠ 信任：SWE-bench、SWE-Lancer 等基准受限于不完整的测试判据，需要补上差分测试/模糊测试、回归安全和可审查性（最小补丁 + 来源追溯）。最后以"自主性是挣来的，监督永不结束"收尾：类比儿童成长与自动驾驶分级（L0–L5），自主权随可靠性记录逐步放宽，但监督永远不会降为零——能力越强，破坏半径越大，监督反而要随之加强；鲁棒性靠工程构建，而非自然长成。
对团队的启示： AI 变更走同等评审关卡并打上来源标签；投资"判据"（规约推断、基于属性/差分的测试、必要时的形式化证明）而非仅投资生成；不要把测试套件当唯一闸门，对 issue 等不可信输入做净化；按 0–5 级自主度谨慎授权，验证强度匹配影响范围。
1. Why trust is the new bottleneck
- Developers are increasingly “learning logic rather than coding” — the skill shifts from syntax to intent and system reasoning.
- Code generation is rapidly becoming the cheapest part of building software; the expensive parts are validating, debugging, and maintaining it.
- Hidden productivity losses from AI-generated code: debugging time, more churn, and growing structural entropy in codebases.
- Trust has two faces:
- Technical trust — correctness, security, regression safety, verifiability.
- Human trust — explainability, team practices, over-reliance risk, experience fit, and collaboration norms.
2. Four first-class activities of the new era
Ray organized the talk around four activities (Understand → Encode → Verify → Collaborate):
Understand — behavioral reasoning as the foundation.
Code comprehension and specification inference underpin everything else; failures here produce overfitted or partial agent patches. She walked through an “Inferring intent: from buggy code to a checkable spec” pipeline: Localize (code search finds relevant functions) → Analyze (AST, data-flow, call graph) → Infer (LLM maps code + issue to intended behavior) → Draft spec (pre/post-conditions) → Validate & explain (check against tests, emit rationale). Example: a buggy max() function with no spec, from which the tool recovers a contract (requires n >= 1; ensures forall i. a[i] <= result; ensures exists i. a[i] == result). The human-readable rationale is what earns developer trust.
Encode — executable knowledge.
Turn understanding into machine-checkable artifacts: specs, invariants, and contracts (pre/post-conditions, loop invariants); tests as encoded intent, ideally derived from natural-language task descriptions. Key line: “Intent a machine can check — not prose in a wiki.” Unlike a wiki, executable knowledge fails loudly the moment behavior drifts. She demoed a verified Dafny Max method — requires (caller’s obligation), ensures (guaranteed for every input), loop invariant — where an SMT solver discharges proof obligations over all inputs, not just the ones you tested.
Verify — from testing toward proof.
Check every AI-generated change against encoded knowledge, layered by the strength of guarantee needed:
- Lightweight: generated tests + static analysis retrofitted into the agent (hard part: meaningful test oracles).
- Strongest: proof-oriented programming in F*, Dafny, or Verus — code generated together with its verifiable specification.
- Principle: right guarantee, right cost — match verification strength to what the change actually puts at risk.
Collaborate — trustworthy human–AI collaboration.
The sociotechnical layer: how humans and agents share responsibility for mission-critical code.
- Review parity & transparent scaffolding: AI changes face the same peer-review gates; tag AI code with authorship provenance and confidence.
- Guardrails against three threats: prompt injection, malicious code, vulnerable code.
- Volume & autonomy: AI writes faster than humans can review; async cloud agents sharpen the question — can they be trusted unattended?
3. Case study: refining agent patches (REFINE)
Ray presented her group’s work on why program-repair agents produce draft patches that are close but wrong, and how to systematically refine them (REFINE, arXiv:2510.03588).
Two challenges → two solutions:
| Challenge | Solution |
|---|---|
| Lack of precise context | Getting the right context |
| Over-reliance on (often incomplete) test suites | Diversify generated patches with test-time scaling |
- Better context: reason about the issue (issue text + codebase → “Issue Context”) and about the code (dependency analysis of the related codebase → “Code Context”). Illustrated with the astropy
ascii.qdpcase-sensitivity bug (from SWE-bench): the issue context identifies all places QDP commands are string-compared; the code context surfaces the exact diffs needed (re.IGNORECASE,v.upper() == "NO").
中文解析（图：How to refine the draft patches?） 上半部分的表格给出两组"挑战 → 解法"：缺乏精准上下文 → 获取正确上下文；过度依赖往往不完整的测试套件 → 用测试时扩展（test-time scaling）使生成的补丁多样化。下半部分是 REFINE 的六智能体流水线：输入为代码库、GitHub issue、回归测试和一份草稿补丁（draft patch，来自任意现成修复智能体），依次经过 (1) Issue Context Agent（提取 issue 上下文）→ (2) Co
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor