Codentell

Inspiration

We were inspired by developers who want to stay productive in the editor but find fine motor control or sustained pointing and typing difficult. Generic AI chat can help with text, but it does not always give trustworthy, code-accurate views of who calls what or what a rename will touch. We wanted something grounded in the real TypeScript/JavaScript program(call relationships, structure and safe refactors) while staying voice- and accessibility-friendly. That led to Codentell: a hands-free layer that pairs structural analysis with clear impact visualization inside VS Code.

What it does

Codentell adds a panel inside VS Code that reacts to where your cursor sits in TypeScript or JavaScript. When you select a function, it builds an impact-oriented view: who calls it, what it calls, a short natural-language narration derived from the AST, and a graph with risk styling (for example highlighting high-impact nodes and critical edges). You can adjust speech rate and pitch for listening to narration, explore “what breaks” style emphasis on risky connections, and rename a function from the UI; the extension runs a real rename through the analysis engine, reloads touched files, and refreshes the graph so the UI stays in sync with the codebase.

How we built it

We used a pnpm monorepo so each concern could ship and typecheck on its own:

@codentell/shared — shared types and extension ↔ webview message contracts (AnalysisResult, settings, editRequest, and related messages). @codentell/analysis — ts-morph for project loading, symbol-at-cursor, call graph construction, narration, and rename, with a project cache invalidated after disk writes. @codentell/extension — VS Code activation, webview panel hosting, CSP-safe HTML loading of the Vite-built UI, debounced selection handling, settings from contributes.configuration, and orchestration of analysis + rename + postMessage updates. @codentell/webview — React UI with React Flow and dagre for layout, side panel for details and rename, and hooks to post messages back to the extension. The extension bundle is produced with esbuild; the webview is built with Vite (base: './') into packages/webview/dist for reliable asset paths inside the webview.

Challenges we ran into

Parallel work on multiple branches meant different prototypes assumed different message shapes and UI models; merging required picking one protocol and updating extension + webview + shared types together. Webviews are strict: getting CSP, nonces, and asWebviewUri right took iteration, and forgetting to build dist/ produced confusing “blank panel” failures. Debugging with F5 exposed another sharp edge: preLaunch watch tasks that never signal completion can block the debugger indefinitely, so task definitions and matchers had to be treated as part of the product, not glue code. On the analysis side, path normalization, tsconfig discovery, and cache invalidation after rename were easy to get subtly wrong across machines and folder layouts.

Accomplishments that we're proud of

We are proud of keeping the product anchored to the program: graphs and narration come from parsed TypeScript, not from guessed prose. We unified a split codebase (analysis, visuals, extension) into something that can run end-to-end: cursor on a function → analysis posted to the UI → rename → files updated → analysis refreshed. We also invested in accessibility-minded UX direction—clear impact cues, speech-related settings, and a workflow that reduces dependence on precise pointer work for structural understanding.

What we learned

We learned that contracts matter more than clever UI: if AnalysisResult and message types are clean, three packages can move in parallel without constant breakage. We learned ts-morph is powerful but demands respect for project boundaries and lifecycle (especially after mutating and saving files). We learned VS Code extension development is as much tooling as features: esbuild, Vite, tasks, and launch configs are part of the user experience for contributors. We also learned that accessibility is not a single feature. It is a combination of input flexibility, legible visualization, and predictable structural actions.

What's next for Codentell

Next steps that would deepen the vision include a more complete voice command layer in the webview (recognition + robust parsing) wired to the same structural actions, richer error reporting in the panel when analysis or rename fails, a demo codebase packaged for predictable demos and tests, and automated tests around graph construction and rename behavior. Longer term, we would explore broader language/project support, performance tuning for large repositories, and user studies with developers who rely on assistive workflows to validate what actually reduces friction versus what only looks impressive in a screenshot.

Built With

• dagre
• esbuild
• pnpm
• react
• react-flow
• ts-morph
• typescript
• vite
• vitest
• vs-code-extension-api