· 6 min read ·

Eight Years of Knowing What to Build: The Scaffolding Problem AI Finally Solved

Source: lobsters

Lalit Maganti works on Perfetto, Google’s open-source system profiling tool. Perfetto uses SQLite’s virtual table interface as its query engine, which means Maganti has spent years writing complex analytical SQL against trace data, watching the SQLite developer experience fail him in predictable ways, and knowing with some precision what a good SQLite language server would need to do. He wanted to build one for eight years. He built it in three months, with AI assistance.

The eight-year number is the part worth examining. It points to a class of project that appears throughout software development: the tool someone is fully qualified to specify and design, has a clear mental model of, and never starts. The core problem is not beyond them. The entry cost is.

The Adjacent-Domain Tax

Building a language server for any language involves prerequisites that have nothing to do with the target language. The Language Server Protocol, which Microsoft introduced in 2016 and which has since become the standard mechanism for editor-language integration, communicates over JSON-RPC via stdio or a network socket. Implementing an LSP server means writing message dispatch, capability negotiation, document synchronization, and the request/response plumbing for operations like textDocument/completion and textDocument/publishDiagnostics. None of this has anything to do with SQLite.

Beyond the protocol, a language server needs a test harness, which requires understanding how to exercise an LSP server programmatically. It needs build system configuration appropriate to the implementation language. It needs editor extension scaffolding for VS Code or Neovim integration. These are all learnable; none are especially hard; but they collectively represent weeks of work producing nothing domain-specific. For someone who knows exactly what the interesting problem is and has a full-time job, that entry cost functions as a blocking condition.

Developer tooling is particularly susceptible to this structure because it combines two features that compound each other. First, the problem domain tends to require genuine depth, the kind that takes years to acquire. Second, the implementation requires competence in adjacent domains that are entirely orthogonal to that depth. The person best positioned to build a good SQLite language server is someone with deep SQLite knowledge, not someone with deep LSP protocol knowledge. To build the tool, they need both.

This pattern shows up across the ecosystem. The database administrator who knows exactly what query analysis tooling their team needs but cannot justify learning enough Rust to build it. The compiler engineer who understands precisely why a given debugger fails at a specific optimization boundary but never writes the fix. The systems programmer who knows what profiling feature their platform is missing but cannot absorb the frontend framework needed to visualize it. In each case, the bottleneck is not insight or expertise, but the cost of earning the right to apply that expertise.

What the Scaffolding Cost Actually Represents

Framing this as a time problem misses something important. Time is fungible; people find time for projects where they can make measurable progress. The real issue is activation energy: the amount of work required before you can tell whether your approach to the interesting problem is sound. When that work consists of learning and implementing things outside your domain, with no guarantee that the interesting core will pan out, the cost-benefit calculation rarely closes.

AI assistance changes that calculation in a specific way. It does not primarily make the hard interesting parts easier, though it helps there too. It makes the scaffolding cheap. LSP protocol handling, JSON-RPC message plumbing, test harness setup, build configuration: these are densely documented, heavily precedented, and richly represented in any code generation model’s training data. Generating a working LSP server skeleton with capability negotiation and message routing is exactly the kind of task where current generation tools perform well. The output is checkable against the protocol specification and against reference implementations. Failure modes are obvious and correctable.

This is a different claim than “AI makes developers faster at what they were already doing.” Faster execution of an existing project is one thing. Making it cost-effective to start projects that would otherwise be deferred indefinitely is another. Those eight years represented persistent non-starts, not slow execution of a project already underway. AI collapses the runway between “I know exactly what this should do” and “I can now write the part that makes it interesting.”

What Stays With the Human

The parts that AI does not handle well in this context are precisely the parts that required the eight years of expertise in the first place. For SyntaqLite, those include the decision to build on the actual SQLite C amalgamation rather than reimplementing the parser, which means inheriting correctness from a test suite that runs around 92 million cases. They include the design of schema introspection through sqlite_schema without requiring an external connection string:

SELECT name, sql FROM sqlite_schema WHERE type IN ('table', 'view');

They include understanding which dialect-specific features need high-fidelity handling versus approximation: STRICT table enforcement (added in SQLite 3.37.0), virtual table column type resolution for FTS5 and rtree, the structured EXPLAIN QUERY PLAN output format that became machine-parseable in 3.31.0, and the exact ways that SQLite’s type affinity rules diverge from what a generic SQL tool would assume.

Those decisions require knowing SQLite well enough to have encountered their failure modes. They require having watched queries pass schema validation in generic tooling and fail at runtime because the tool had no model of what WITHOUT ROWID does to rowid assumptions, or no understanding that a column declared INTEGER in a non-STRICT table accepts text without complaint. That knowledge is not generatable; it is accumulated through sustained exposure to the system. AI can produce the scaffolding that lets Maganti apply that knowledge without first spending weeks on protocol implementation.

The implication is that AI assistance scales with the depth of existing domain expertise. A developer who knows precisely what they want to build, has clear correctness intuitions for the interesting parts, and is blocked primarily by adjacent-domain scaffolding benefits more than someone still forming their understanding of the core problem. The tool amplifies existing competence more than it substitutes for missing competence.

The Class of Projects This Unlocks

The projects most likely to move from deferred to shipped are the ones in this class: domain experts with clear visions, blocked primarily by scaffolding costs in adjacent technical domains, now able to reach the interesting part in weeks rather than months. Developer tooling is one obvious category. Domain-specific analysis tools are another: scientific computing utilities where the scientist knows the algorithm but has never written a parser combinator; niche format processors where the format expert could specify the behavior precisely but has never set up a build system for a native library; debugging and observability tools where the platform engineer understands the failure modes but has never built an editor extension.

The generic SQL language server landscape illustrates the gap well. Tools like sqls and sqlfluff exist and are maintained, but they were built by people with LSP expertise who approximated SQL dialect knowledge. SyntaqLite inverts that: it comes from someone with deep SQLite internals knowledge who could afford, finally, to acquire the LSP scaffolding cheaply enough to apply that expertise.

Maganti’s post on building SyntaqLite is an early concrete example of what this class of project looks like when it ships. The SQLite tooling gap was real, well-understood by anyone who worked with SQLite seriously, and the person best positioned to close it was the same person who had spent years identifying it. That alignment, domain expertise meeting finally-affordable scaffolding, is the pattern worth watching as this tooling matures.

Was this interesting?