Sujay Jayakar

Sujay Jayakar’s AI-relevant work centers on making software systems easier for coding agents to use and debug. In his Convex writing, he explains Fullstack-Bench, an evaluation of agents implementing application backends, and the team’s MCP server design. His recommendations emphasize automatic feedback, standard procedural code, and strong abstractions. Convex’s author index also identifies him as @sujayakar314; Latent Space featured him in its Fullstack-Bench episode as Convex’s chief scientist.[3][5][2][1]

In Introducing Fullstack-Bench, Jayakar describes the team’s effort to understand why an agent can implement one feature quickly yet become trapped in debugging loops on another. Each task supplies a working Next.js frontend and asks the agent to implement its backend. The reported experiments used Cursor Composer on chat, todo, and files applications, comparing Convex, Supabase, and FastAPI with Redis. Functional rubrics checked the resulting applications, while operators counted error reports and hints needed to get the agent unstuck.[3]

Jayakar reports that the chat and todo tasks needed no hints on Convex, although the todo task required three human error reports. The more complex files task reached the time limit on every backend. These were manually graded, vendor-run experiments with human assistance. The public repository documents the process of combining frontend tasks with generic backend templates; its README lists Convex and Supabase, whereas the article also describes FastAPI with Redis.[3][4]

• Give agents immediate feedback. Jayakar reports that Claude invented a requirement to include Convex’s _creationTime field when inserting a document. A type error let the agent correct the mistake autonomously. By contrast, an agent mixed Redis set and sorted-set operations on the same key, and the bug surfaced only during manual testing. He argues that type checking both catches mistakes quickly and directs an agent toward unfinished or broken code.[3]
• Keep behavior visible in ordinary code. In the experiments, Jayakar reports repeated difficulty with Supabase’s row-level security execution semantics, including cycles in rule evaluation. He contrasts this with authorization expressed as TypeScript functions in Convex, while noting that Convex’s own distinction between null and undefined also confused the agent and required a hint. His recommendation favors APIs that match a coding model’s expectations.[3]
• Package difficult distributed-state problems into abstractions. Jayakar describes bugs involving streaming responses and the reconciliation of optimistic client updates with backend state. He attributes part of the agent’s success on Convex to the platform handling state management and WebSocket communication internally, leaving the agent to implement business logic.[3]

In Convex MCP Server, Jayakar explains a tool interface that lets agents inspect deployment tables and functions, execute functions, and read and write data. He demonstrates it using his “Claude at Home” chat application, a sandbox for exploring tool use. His rationale is direct: “Models are really good at writing code, so exposing a tool that lets them safely run code makes them really powerful.” The runOneoffQuery tool executes sandboxed query code that cannot modify the database; that restriction does not apply to every tool exposed by the server.[5]

Jayakar connects one interface decision to the benchmark experiments. The team chose a global MCP server for compatibility across clients, but had observed Cursor Agent becoming confused when repeatedly passing a project’s working directory during debugging. Their protocol therefore asks for the directory once, in an initial status call, and returns an opaque deployment selector. Subsequent calls reuse that selector without requiring the agent to reconstruct the directory context.[5]

Before this AI-coding work, Jayakar publicly explained another team effort involving distributed state and correctness: Dropbox’s Nucleus sync-engine rewrite. That earlier account provides context for his systems-engineering judgment.[6]

On March 9, 2020, Jayakar announced in Rewriting the heart of our sync engine that Dropbox’s team had shipped Nucleus to all users after four years of work. He argued that the old engine’s foundational data model had exhausted the possibilities of incremental improvement: files lacked stable identifiers across moves, and permissive outcomes made correctness difficult to test. His advice was conditional rather than a blanket endorsement of rewrites: “before embarking on a rewrite, you must deeply understand and respect the ‘Classic’ system.”[6]

Jayakar explains how the team used Rust’s type system to encode invariants and placed most execution on a single control thread. With inputs and scheduling decisions fixed, that thread behaved deterministically, allowing randomized simulation failures to be reproduced from their original seeds. The redesigned protocol gave files and folders globally unique identifiers and supported atomic moves. In his example of two users moving nested folders while offline, Classic duplicated directories to merge the changes; Nucleus retained the original directories, with the final order determined by which move uploaded first. He credited current and past Sync team members with building Nucleus.[6]