AI coding đã đủ phổ biến để research không còn chỉ hỏi model có sinh được code hay không. Các bài mới chuyển sang những câu hỏi khó hơn: agent có giữ được tính nhất quán khi làm việc trên cả repository, có sửa đúng issue trong hệ thống thực, có nhận ra tool thất bại, có bảo toàn security sau nhiều lần chỉnh sửa và có thể được đánh giá bằng một tiêu chuẩn đáng tin cậy hay không. Song song với đó, requirements, architecture, testing, dependency management, program repair và performance vẫn tiếp tục là những hướng nghiên cứu lớn.

Agent không thiếu khả năng viết code; vấn đề là nó phải hiểu cái gì cần thay đổi

Một function độc lập có thể được đánh giá bằng test. Một issue trong repository thì khác: nguyên nhân có thể nằm ở nhiều file, behavior có thể được quyết định bởi dependency, và thay đổi ở một nơi có thể phá vỡ một nơi khác.

The Working Set of a Coding Agent: Coherence Debt in Repository-Scale Tasks gọi tên chính vấn đề này là coherence debt. Nghiên cứu đặt trọng tâm vào working set mà coding agent duy trì khi giải quyết task ở quy mô repository, thay vì xem mỗi lượt sinh code như một hoạt động độc lập. The Working Set of a Coding Agent

Temporal Validity on Real Software Histories tiếp cận một lỗi khác: thông tin từng đúng trong repository có thể trở thành thông tin sai sau những lần sửa đổi. Nếu assistant dựa vào một fact cũ về cách hệ thống hoạt động, câu trả lời có thể hợp lý nhưng vẫn sai đối với phiên bản hiện tại. Temporal Validity on Real Software Histories

The Recall Trap còn cho thấy một vấn đề ngược trực giác: cố lấy càng nhiều context không nhất thiết giúp agent giải quyết issue tốt hơn khi ngân sách context bị giới hạn. Trong một fixed-budget setting, tăng recall của retriever có thể làm giảm issue resolution. The Recall Trap

Ba nghiên cứu đặt cạnh nhau cho thấy context của coding agent không phải bài toán “càng nhiều càng tốt”. Agent cần đúng thông tin, đúng thời điểm và đúng phạm vi.

Agent giải quyết được issue không đồng nghĩa với agent hiểu software

SWE-bench Science đưa coding agents vào các engineering task xuất phát từ software dùng trong khoa học, thay vì chỉ đánh giá trên những repository phần mềm thông thường. Câu hỏi ở đây quan trọng hơn việc agent viết được bao nhiêu dòng code: các issue trong scientific software thường gắn với logic domain, numerical behavior và các quy tắc mà chỉ nhìn vào syntax không đủ để suy ra. SWE-bench Science

SkillForge giải quyết một phần khác của vấn đề bằng cách để agent tích lũy kỹ năng gắn với từng project trong quá trình giải quyết issue. Thay vì coi mọi repository như cùng một môi trường, phương pháp này khai thác kinh nghiệm giải quyết task trước đó để tạo năng lực phù hợp hơn với project hiện tại. SkillForge

BC-Bench lại đưa agent vào ERP với một domain-specific language. Đây là loại benchmark có ý nghĩa hơn một bài coding thông thường vì ERP chứa business rules và domain conventions mà agent phải xử lý cùng với ngôn ngữ lập trình. BC-Bench

Điểm chung của ba hướng này là khó khăn không nằm ở cú pháp của ngôn ngữ mà ở kiến thức cần thiết để thay đổi đúng một hệ thống cụ thể.

Specification đang được biến từ tài liệu mô tả thành tiêu chuẩn để kiểm tra behavior

Specification Portability Across LLM Development Agents đặt một câu hỏi rất thực tế: nếu một team chuyển từ coding agent này sang coding agent khác, specification có tiếp tục dẫn tới cùng một software behavior hay không? Đây là vấn đề khác hoàn toàn với việc prompt nào cho ra code tốt hơn. Specification Portability Across LLM Development Agents

Measuring What a Specification Determines đi vào phần khó hơn: một specification thực sự ràng buộc được bao nhiêu behavior? Nghiên cứu xây dựng semantic-block model và benchmark dựa trên execution để đo mức độ mà specification xác định được hành vi của chương trình. Measuring What a Specification Determines

Grounding AI Agents in Contracts dùng contract để tạo test và kiểm tra xem agent có thực hiện đúng behavior được yêu cầu hay không. Specification ở đây không còn chỉ để developer đọc; nó trở thành nguồn để tạo cơ chế kiểm chứng. Grounding AI Agents in Contracts

SDAD: Spec-Driven Agentic Development for the AI-Native SDLC đưa cách tiếp cận này lên cấp độ development process. SDAD: Spec-Driven Agentic Development

Các nghiên cứu này cùng đặt specification vào một vị trí mới: không chỉ nói software phải làm gì, mà còn cung cấp căn cứ để generation, migration và testing kiểm tra software có làm đúng hay không.

Requirements có thể trở thành điểm yếu khi con người làm việc với LLM

Human-AI Collaboration in Requirements Engineering báo cáo một kết quả đặc biệt đáng chú ý: việc sử dụng LLM có thể làm giảm hiệu quả của requirements inspection trong bối cảnh nghiên cứu của họ. Human-AI Collaboration in Requirements Engineering

Điều này quan trọng hơn một kết quả “LLM tốt” hay “LLM xấu”. Requirements inspection phụ thuộc vào khả năng phát hiện ambiguity, inconsistency và missing information. Nếu người dùng quá tin vào nội dung được LLM hỗ trợ, chính hoạt động kiểm tra có thể bị ảnh hưởng.

The Specification Paradox đặt vấn đề ở cấp rộng hơn: khi AI làm cho việc biến yêu cầu thành implementation rẻ hơn, requirements engineering có thể phải thay đổi cách xác định và biểu diễn yêu cầu. The Specification Paradox

An Empirical Study on the Impact of Normalized Use-Case Specifications on Traceability tiếp tục từ góc nhìn traceability: cách chuẩn hóa use-case specification ảnh hưởng đến khả năng liên kết requirement với các artifact khác của software. Normalized Use-Case Specifications and Traceability

Vấn đề vì vậy không phải “AI có viết requirement được không”. Vấn đề là requirement có đủ chính xác để con người và machine cùng sử dụng mà không làm mất traceability hay không.

Testing đang chuyển từ tạo test sang kiểm tra chất lượng của chính test

BreakGuard dùng LLM-generated tests để phát hiện breaking changes trong dependencies. Cách tiếp cận này đặc biệt phù hợp với dependency evolution: lỗi không nhất thiết nằm trong code vừa sửa mà có thể xuất hiện khi contract của dependency thay đổi. BreakGuard

Nhưng sinh test chỉ giải quyết một nửa bài toán.

Auditing and Decomposing Feedback-Driven Evolution in LLM Test Generation under the Oracle Problem tập trung vào việc audit quá trình test generation khi hệ thống không có oracle hoàn hảo. Oracles That Cannot Fail cũng đặt correctness oracle vào trung tâm. Auditing and Decomposing Feedback-Driven Evolution Oracles That Cannot Fail

Nếu AI tạo được 10.000 test nhưng không xác định được expected behavior một cách đáng tin cậy, automation chỉ làm tăng số lượng artifact cần kiểm tra.

Đó là lý do research về AI testing đang đi song song theo hai hướng: tạo thêm test và tìm cách xác định test nào thực sự có giá trị.

Code review đang chuyển từ đánh giá code sang đánh giá cả cơ chế tạo code

AI-to-AI Code Reviews of GitHub Pull Requests nghiên cứu việc một AI review pull request do workflow phát triển phần mềm tạo ra. AI-to-AI Code Reviews of GitHub Pull Requests

Adversarial Review đưa structured disagreement vào agentic code review. Thay vì chỉ yêu cầu một model đưa ra nhận xét, thiết kế này khai thác sự bất đồng có cấu trúc để tìm vấn đề trong code. Adversarial Review

Nếu AI vừa tạo code vừa tự đánh giá code, hai bước có thể chia sẻ cùng một blind spot. Việc đưa một cơ chế đánh giá độc lập vào workflow vì thế không chỉ là thêm một bước review; nó thay đổi cách thiết kế feedback loop của coding agent.

Production đặt ra một loại failure mà chatbot không gặp

Outcome Monitors tập trung vào silent tool failures: tool có thể thất bại nhưng agent vẫn tiếp tục như thể hành động đã thành công. Đây là một failure mode khác với câu trả lời sai của chatbot vì sai lầm nằm trong chuỗi hành động. Outcome Monitors

One Gate Is Not Enough nghiên cứu stateful pre-action controls, tức hệ thống kiểm soát trạng thái trước khi agent được phép thực hiện hành động. One Gate Is Not Enough

Towards Risk-free AI Agent Deployment và AgentR tiếp tục tập trung vào deployment, state và recovery của các workflow có agent. Towards Risk-free AI Agent Deployment AgentR

Khi agent có quyền gọi tool và thay đổi hệ thống, lỗi không còn chỉ là “model trả lời sai”. Một hành động đúng về mặt cú pháp nhưng được thực hiện trong sai trạng thái cũng có thể làm hỏng workflow.

Observability phải giải thích được đường đi đến failure

Beyond Fault Localization nghiên cứu root cause analysis cho microservices ở mức trajectory của LLM agent. Thay vì chỉ hỏi service nào hỏng, nghiên cứu theo dõi chuỗi hành động của agent để tìm nguyên nhân. Beyond Fault Localization

When Agentic Executions Fail cũng tập trung vào việc phát hiện và định vị runtime faults từ telemetry. LongRCA Bench xây benchmark để xác định responsible roles và root causes trong long-horizon agent failures. When Agentic Executions Fail LongRCA Bench

Graphectory Viewer đưa agent trajectory thành đối tượng để phân tích process. Graphectory Viewer

Với agentic systems, log “request failed” thường chưa đủ. Người vận hành cần biết agent đã đọc gì, gọi tool nào, nhận kết quả gì và quyết định bước tiếp theo dựa trên dữ liệu nào.

Security không thể chỉ kiểm tra một lần sau khi AI sinh code

Securing AI-Generated Code đề xuất pipeline phát hiện và remediation vulnerability theo thời điểm code được tạo hoặc chỉnh sửa. Securing AI-Generated Code

WeSCE đặt tên trực tiếp cho một vấn đề khác: security drift trong LLM-driven code editing. Code có thể bắt đầu an toàn nhưng trở nên kém an toàn sau các lần chỉnh sửa tiếp theo. WeSCE

Điều này làm security review trở thành một quá trình liên tục hơn. Nếu AI liên tục chỉnh sửa code, trạng thái security cũng phải được theo dõi qua các lần thay đổi thay vì chỉ kiểm tra artifact cuối cùng.

Ở tầng dependency, DCI: Dependency Confidence Index tìm cách đánh giá mức độ đáng tin của open-source dependencies. The Software Supply Chain as a Market for Lemons lại tập trung vào sự suy giảm của trust signals trong supply chain. DCI: Dependency Confidence Index The Software Supply Chain as a Market for Lemons

Evaluation đang trở thành một phần của engineering infrastructure

The Evaluation Context Protocol đề xuất một portable contract để chuẩn hóa context mà agent evaluation cần có. The Evaluation Context Protocol

What Aggregate Scores Miss cho thấy điểm tổng hợp có thể che giấu regression ở từng item khi thay đổi commercial LLM API. What Aggregate Scores Miss

DreamBench-SWE xây benchmark cho multi-session memory hygiene. OpenHarmony Bench đánh giá LLM và coding agents trên OpenHarmony app development. AppEval tập trung vào mobile application repair trên ArkTS, Swift và Kotlin. DreamBench-SWE OpenHarmony Bench AppEval

Evaluation đang được chia nhỏ theo đúng loại failure mà engineering team cần biết: model có giải được task không, có giữ memory qua session không, có regression sau model migration không, có repair được mobile application không.

Một điểm số chung cho “model intelligence” không trả lời được những câu hỏi đó.

Productivity cũng đang được đo lại

Vibe Coding: Practice, Performance, Productivity, and Risk đặt vấn đề productivity cùng với performance và risk thay vì chỉ nhìn tốc độ tạo code. Vibe Coding

Factors Impacting Developer Efficiency và ADEMM nghiên cứu developer efficiency trong thời gian dài và trong môi trường industry. Factors Impacting Developer Efficiency ADEMM

Comparing the Quality of Code Generated by Vibe Coding Tools chuyển câu hỏi sang quality của output. When Uncertainty Isn’t Enough kiểm tra khả năng self-correction trong code generation. Comparing the Quality of Code Generated by Vibe Coding Tools When Uncertainty Isn’t Enough

Như vậy, productivity không còn có thể đo bằng số dòng code hoặc số task hoàn thành. Một workflow nhanh nhưng tạo nhiều rework, review hoặc regression có thể không làm engineering team hiệu quả hơn.

100 chủ đề nghiên cứu trong danh sách

Danh sách gốc: arXiv — Software Engineering (cs.SE)