Studio deliveryAI coding agent, VS Code extension · 2024–2025 · Contributing engineerpythagora.ai
Pythagora
Contributing engineer on Pythagora’s VS Code extension: front-end performance and production defect work on an existing AI coding agent.
Pythagora work was a contributing-engineer role on an already-shipping AI coding agent's VS Code extension: extension-surface features, front-end performance and production defect fixes, delivered inside a previous studio rather than as a client contract with The SyncFlow.
- Studio
- Attribution
- Contribution
- Scope
- Live
- Status
Delivered inside a previous studio. Contract terms belonged to that studio, so none are published here.
The problem
Pythagora’s extension runs inside VS Code’s own extension host, which is a constrained and unusually particular environment: the UI has to stay responsive while an agent streams tool calls and file edits, and a slow render or a leaked listener shows up as the editor itself feeling sluggish, not as an isolated bug in a web app.
The work arrived as an existing, live product with existing users and existing conventions. The job was to extend the extension surface and fix production defects without breaking the patterns other contributors were already relying on.
Constraints
The conditions the solution had to survive, not a wish list.
- Existing codebase
- Conventions, extension architecture and API boundaries were already established. Changes had to fit inside them, not replace them.
- VS Code extension host
- UI work runs inside VS Code’s own process model, with its own performance and lifecycle rules rather than a normal browser environment.
- Live user base
- Defects were reported against a shipping product with real usage, not caught in a staging environment.
- Streaming agent output
- The interface has to stay responsive while an AI agent streams tool calls and file edits in real time.
The approach
In plain English, before the architecture.
Front-end performance work focused on where the extension’s rendering and state updates competed with VS Code’s own UI thread, since a sluggish editor is the failure mode users actually notice and report.
Defect work followed the same discipline as any production bug: reproduce against the reported conditions first, fix the root cause rather than the symptom, and verify against the extension’s existing test and review conventions before merging.
Architecture
The decisions that mattered, and why they were made that way.
- 01
Extension-surface features
New functionality built against the VS Code Extension API, integrated into the existing command, sidebar and webview structure the extension already used.
- 02
Front-end performance
Rendering and state-update paths profiled and tightened where they competed with VS Code’s own UI thread during active agent sessions.
- 03
Production defect resolution
Bugs reported against the live extension reproduced, root-caused and fixed within the project’s existing review and release process.
Outcome
Shipped as a contributing engineer inside an existing product, working to conventions the core team had already set rather than establishing new ones.
The work landed as ordinary releases of a shipping VS Code extension, with no separate before/after figures published by Pythagora.
Stack
- TypeScript
- VS Code Extension API
- OpenAI
- Claude
Timeline
2024 to 2025, ongoing contribution
Tell us what you can’t staff.
Twenty minutes. No deck, no discovery sequence. If we are the wrong fit we will say so on the call and point you somewhere better.