The Feasibility Gap: What Eight Years of Wanting a Tool Actually Means

Lalit Maganti built syntaqlite in three months after wanting it for eight years. That gap is not a story about procrastination or motivation. It is a story about a specific class of project that sits in a zone where the idea is clearly good, the need is real, and the implementation is technically within reach for an experienced developer, but where something about the execution cost keeps it from happening.

Understanding what actually changed is more useful than celebrating the outcome.

Why Some Good Ideas Sit for Eight Years

Maganti works on Perfetto, Google’s open-source system tracing tool, which uses SQLite’s virtual table mechanism as its primary query interface. Writing complex analytical SQL against trace data is daily work there. The absence of schema-aware completions and query plan visualization is a real daily cost, not an abstract inconvenience. He knew exactly what the tool should do and why it mattered.

The problem is not knowledge of the domain. The problem is breadth.

Building a language server requires simultaneous competence in several areas that do not naturally cluster together. You need deep understanding of the target language’s semantics, including its edge cases and dialect-specific behaviors. You need working knowledge of the Language Server Protocol, which is a substantial JSON-RPC API surface covering lifecycle management, text synchronization, completion, diagnostics, hover, go-to-definition, and more. You need to wire that to an editor, which means understanding how VS Code extensions work, or how Neovim’s LSP client handles initialization and server capabilities. You need test infrastructure that spans all of this: unit tests for the language analysis logic, integration tests for LSP request/response pairs, and end-to-end tests against a real editor.

No single piece of this is beyond an experienced developer. But sustaining competence across all of them simultaneously, as a solo project without dedicated time, is a different problem. Projects that require depth in multiple non-overlapping technical domains tend to either get built by teams or get built by people who have unusual breadth and a protected block of time. They rarely get built by one person on evenings and weekends, because the context-switching overhead compounds with the learning overhead whenever you hit an unfamiliar layer.

Eight years is how long it takes to keep believing a project is worth building while never finding the right conditions to build it.

What AI Actually Changes Here

The common framing for AI-assisted development is that it makes you faster. That is true at the micro level: generating boilerplate, suggesting completions, producing test cases for code you describe. But for a project like syntaqlite, the more important effect is different. AI does not primarily make experienced developers faster at what they already know. It gives them working scaffolding in domains where they have partial knowledge.

Consider what building the LSP layer requires. The protocol is well-specified, and the specification is public, but implementing it correctly from scratch involves handling a lot of detail: proper capability negotiation during the initialize handshake, text document synchronization with incremental edits encoded as UTF-16 offsets (a choice that surprises most developers), the distinction between a Diagnostic and a PublishDiagnosticsParams, the way completion items carry additionalTextEdits for import insertion, the correct format for Position objects in zero-indexed line and character coordinates. None of this is obscure knowledge, but it requires either prior experience writing an LSP server or reading carefully through the specification.

An LLM can produce a working skeleton of an LSP server in a language of your choice that handles these details correctly. It has seen enough LSP implementations in training data to produce something that correctly handles initialization, text sync, and basic completion response formatting. That skeleton does not solve your actual problem, which is understanding SQLite’s type system and building an analysis layer that gets dialect details right. But it removes a layer of unfamiliar infrastructure that would otherwise require days of reading documentation and iterating on protocol errors before you even get to the interesting part.

This is the distinction that matters: AI as a feasibility tool rather than a speed tool. For projects that require breadth across multiple unfamiliar domains, AI does not compress a six-month project into a three-month one. It compresses a project that was not going to happen into one that is.

The SQLite Case Makes This Concrete

The technical decision at the core of syntaqlite is building on the actual SQLite C amalgamation rather than reimplementing its parser. The SQLite amalgamation is a single-file C distribution that embeds roughly 200,000 lines of the SQLite source, and using it means the tool inherits SQLite’s actual dialect knowledge rather than approximating it.

This decision is correct for the same reason clangd succeeded where earlier C++ language servers like cquery failed: a reimplemented parser accumulates technical debt against every language standard update, every compiler extension, every edge case in the grammar. The real parser is always correct by definition. SQLite’s dialect has enough idiosyncrasies, including its five-type affinity system, the STRICT keyword added in 3.37.0 that changes type enforcement semantics, the way FTS5 virtual tables expose column metadata at runtime rather than statically, that an approximated implementation will produce wrong results on any non-trivial query. The right architectural choice was never in doubt.

But implementing FFI bindings to a C library, bridging between that C library and whatever Rust or Go or TypeScript LSP framework you chose, and handling the lifetime and threading requirements of the amalgamation across async request handlers is another domain of implementation complexity that sits outside the core language analysis problem. Generating a working first pass of that bridge layer is exactly the kind of task AI handles well, because it is pattern-recognizable from large amounts of similar FFI code in training data.

Three months from idea to working implementation makes sense when you have deep domain expertise in SQLite internals (from years of Perfetto work), and AI handles the connective tissue across the LSP protocol, editor extension infrastructure, and FFI binding layers.

The Backlog This Points At

Syntaqlite is not a special case. There is a category of developer tooling that has the same shape: the need is real and well-understood, the person best positioned to build it knows exactly what it should do, and it has not been built because the implementation spans too many domains for a solo effort without dedicated time.

The SQLite ecosystem has several other gaps like this. The existing query analysis tools, including litecli for interactive use and Datasette for data exploration, are well-built within their scope. Neither exposes WAL state, execution traces via sqlite3_trace_v2, or a properly structured rendering of the query plan tree that became navigable with SQLite 3.31.0’s EXPLAIN QUERY PLAN restructuring. The infrastructure to surface this has been in place for years. The tooling layer on top of it has not appeared because it requires the right intersection of SQLite expertise and developer tooling breadth to build.

Beyond SQLite, the same pattern applies to language servers for specialized query languages, dialect-aware formatters for embedded DSLs, debuggers for query engines that expose rich introspection APIs without any visualization layer, and profilers for runtimes that log detailed execution data without anything to render it usefully. These projects tend to live on maintainer wishlists for years.

The meaningful shift is not that AI makes all of this easy. Building something correct still requires deep domain knowledge, careful design decisions, and sustained attention to the details that determine whether a tool is useful or merely functional. What has changed is that the breadth tax on solo developer tooling projects has dropped substantially. The projects that were stuck in the feasibility gap because one person could not reasonably carry the implementation load across four different technical domains are now in a different position.

Eight years is a long time to want a tool. Three months is fast. The space between those two numbers is what AI-assisted development has started to close.