Since early 2025, I have stopped making new first-authored papers the main target of my work. Joining Apodex later that year made this shift clearer: I was increasingly working on systems whose value depended on how they behaved in use.
1. What writing papers taught me
I did my Ph.D. at USC under Prof. C.-C. Jay Kuo, then worked at NUS and A*STAR I²R. Over those years, I published research on representation learning, dialogue summarization, multilingual evaluation, and audio-language models.
Writing papers taught me habits I still rely on:
- Tracing claims to evidence. When reviewing a result, I want to know how the number was measured and which assumptions support it.
- Looking for counterexamples. Anticipating a reviewer’s questions trained me to look for weaknesses before someone else finds them.
- Designing experiments carefully. Controls, repeated runs, and negative results matter as much as an attractive headline number.
- Explaining technical decisions. A limited page budget forces you to decide what a reader needs to understand and what can be left out.
These habits carry into architecture discussions, code review, and evaluation. The value of that training remains, even as my preferred form of output has changed.
2. The work changed
An agent system has to keep working through tool errors, missing evidence, changing inputs, and long tasks. Much of the work is in decisions that are hard to separate: how retrieval falls back, how a tool call times out, how state is preserved, and how a claim is checked.
The feedback arrives quickly. A user gets stuck; a trace shows where; we change the system and see whether it helps. The question is concrete: does this make the task more reliable or useful?
A paper asks for a different kind of artifact. It needs a focused claim, a comparison, a reproducible experiment, and a story that makes sense outside the codebase. That process can clarify the work. It can also take time away from the next problem the system needs solved.
For my current work, I increasingly want to spend that time building, measuring, and improving the system itself.
3. Where the fit became weaker
The important unit of work is often the whole system. A reliable agent may depend on several ordinary design decisions working well together. Splitting them into small publishable contributions can hide the interaction that made the result useful.
The feedback cycles differ. Production changes can be evaluated over days or weeks. A submission may take months to write, review, and publish. By then, the implementation and its constraints may have changed substantially.
The people with useful feedback have changed. Reviewers are valuable when they understand the question and can test its claims. For the systems I build now, users and colleagues often see failures that a benchmark or paper review does not reveal.
This does not make engineering automatically rigorous. Usage can be misleading, a benchmark can miss real failures, and a system that appears to work may have hidden problems. The discipline I learned through research is still needed to interpret the feedback.
4. What papers still provide
Papers create a public record. Other people can cite a method, inspect its assumptions, reproduce an experiment, or challenge a conclusion years later. Engineering work can lose that continuity when products change or teams move on.
Peer review also provides a shared standard for explaining and testing claims. It is imperfect, but I do not have a simple replacement for those functions. For many research questions, a paper remains exactly the right output.
I still contribute to collaborative research and technical reports. I simply no longer organize my own work primarily around producing another first-authored paper.
5. What I measure now
I ask whether a system completes useful tasks, how it fails, how quickly it recovers, and whether people return to use it. When work is public, issues, contributions, and reproducible examples provide another source of feedback.
I also ask whether someone else can understand the decisions and continue the work. Code, traces, tests, and clear documentation can preserve part of what would otherwise disappear when a project changes.
None of these measures is sufficient on its own. Together, they are closer to the work I want to do now.
For someone completing a Ph.D. or investigating a question that needs a controlled study, publishing may still be the best way forward. My choice reflects a change in my own work and the kind of feedback I find most useful at this stage.