Scaling AI Coding Tool Adoption Across Engineering Teams

plaid · Finance · 2025 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: AI coding adoption in regulated fintech engineering

Plaid needed to turn hundreds of effective engineers into AI power users without disrupting existing workflows, violating security/legal expectations, or treating AI tools as replacements for engineers' preferred IDEs.

Constraints:

Architecture

Plaid scaled adoption through a dedicated adoption team, streamlined procurement, quick-value pilots, legal/security input-output classification, internal dashboards for usage and retention, in-house videos on Plaid's actual codebase, engineering-manager outreach, dual-wielding with existing IDEs, AI Day workshops, and ongoing work on benchmarking, cost control, and AI-aware code review.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  A["Plaid engineers"] --> B["AI coding tools"]
  B --> C["Existing IDEs and codebase"]
  D["AI adoption team"] --> B
  D --> E["Adoption dashboard"]
  D --> F["AI Day and internal content"]
  D --> G["Legal and security review"]
  E --> H["Engineering managers"]
  H --> A
  F --> A
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
Plaid engineers Engineers adopting AI coding tools while maintaining existing workflows and code quality. AI coding tools, AI Day and internal content
AI adoption team Core team owning adoption metrics, outreach, tool rollout, and enablement. AI coding tools, Adoption dashboard, AI Day and internal content, Legal and security review
AI coding tools Advanced coding assistants and agentic editors evaluated and rolled out to engineers. Existing IDEs and codebase
Existing IDEs and codebase Engineers' existing development environments, Bazel setup, and Plaid-specific systems. AI coding tools
Legal and security review Input/output classification and pilot-stage risk review for AI tools. AI adoption team
Adoption dashboard Internal tracking for usage, retention by cohort/team, and adoption trends. Engineering managers
Engineering managers Managers targeted with Plaid-specific examples and reports to influence team adoption. Plaid engineers
AI Day and internal content Workshops, short videos, organic sharing, and Plaid-codebase examples used to drive adoption. Plaid engineers

Data flow

Potential tools are screened through fast pilots and legal/security classification. After launch, a core team tracks adoption, retention, cohorts, teams, and feature usage in an internal dashboard. Internal videos, Slack sharing, manager training, and AI Day workshops convert examples into adoption. Later metrics dig beyond usage into agentic editing capabilities, productivity, reliability, cost, benchmarking, and review-process changes.

3 supporting quotes
“we prefer piloting tools where we can get a strong value signal very quickly.”article, stated
“This team spun up a basic internal dashboard to think of adoption as our own product.”article, stated
“Every AI tool will have its own videos and articles, but there will be none showing exactly how they work on your own systems.”article, stated

Why this architecture

Plaid treated AI adoption as a product with owners, dashboards, user outreach, relevant examples, and workflow fit. This was necessary because generic vendor materials do not show how tools behave on Plaid's systems, and adoption plateaued when tools were merely enabled without deliberate enablement.

3 supporting quotes
““Enable it in Okta, and they will come” is not enough.”article, stated
“This team spun up a basic internal dashboard to think of adoption as our own product.”article, stated
“there will be none showing exactly how they work on your own systems.”article, stated

Models used: AI coding tools · agentic editors · Cursor

Scale

Alternatives considered (roads not taken)

Enable a tool and wait for adoption

Rejected because: Adoption plateaued after general availability announcements without targeted ownership and outreach.

“we’d find that adoption quickly plateaued. We convened a core team to solve this problem for current and future tools.”article, stated

Force engineers to replace existing IDEs

Rejected because: Engineers are attached to their editors, so Plaid positioned AI tools as complements and allowed dual wielding.

“Engineers have a famous passion for their favorite code editors, so it’s an uphill battle to convince them to replace them entirely.”article, stated

Vendor-generic enablement

Rejected because: Engineers needed examples showing tools on Plaid's own systems and codebase.

“making a small amount of in-house content showing common workflows in action was very helpful”article, stated

Patterns

eval-driven-development (evaluation)

Plaid tracks usage, retention, feature usage, productivity, reliability, costs, and AI-tool benchmark tasks to guide adoption.

“We were able to track not just usage over time but retention by cohorts and teams. This allowed us to spot trends that led to further investigation, like when a tool seemed to be working well for frontend engineers but not infrastructure teams.”article, stated
“We are building a catalog of these tasks to use internally as reference points as foundation models improve and new tool updates arrive.”article, stated

human-in-the-loop-gate (governance)

Plaid keeps adoption human-centered through manager training, peer sharing, internal videos, and complementing existing workflows rather than replacing them.

“This also creates positive feedback loops. We encouraged engineers to share their wins (and losses!) via Slack, which is its own form of in-house content creation that helps drive more adoption.”article, stated
“Engineers have a famous passion for their favorite code editors, so it’s an uphill battle to convince them to replace them entirely. Instead, we found the most success by emphasizing that new AI-enabled tools can be used alongside engineers’ current IDEs or tools.”article, stated

safety-policy-enforcement (governance)

Plaid classifies each tool by data inputs and output implications so legal/security review can match pilot risk.

“We developed a framework for classifying each tool based on the inputs (what kind of data is being sent, where is it being sent to, etc) and outputs”article, stated

context-engineering (context)

Plaid is working to integrate its codebase more deeply with AI tools through settings, sensitive-file filtering, memory, and context hints.

“version-controlled settings, filtering sensitive files from AI usage, or memory/context hinting mechanisms.”article, stated
“We believe there is a lot of room to help engineers write better prompts and integrate our codebase more deeply with the tools, but we want to increasingly use data to guide our work.”article, stated

Tradeoffs

Pilot strategy

Chose quick value signals and low-infrastructure pilots over heavy internal setup before deciding whether a tool is useful.

Rationale: Tool quality varies and the market moves quickly, so Plaid screens tools quickly before procurement depth.

“We mostly avoid anything that requires a significant internal infrastructure setup or other engineering pre-work.”article, stated

Workflow integration

Chose AI tools alongside existing IDEs over full editor replacement for everyone.

Rationale: Complementary adoption reduced friction for engineers whose existing IDEs still had important features.

“we found the most success by emphasizing that new AI-enabled tools can be used alongside engineers’ current IDEs or tools.”article, stated

Initial scope

Chose coding first over all SDLC tasks at once.

Rationale: Coding gave quick organizational wins before expanding into incident response, data analysis, and code review.

“We deliberately focused our initial effort on coding to deliver quick impact and organizational wins, but we’re starting to look more at other areas of the SDLC, like incident response, data analysis, and code review.”article, stated

Gotchas (what bit them)

Procurement speed can block AI experimentation.

Root cause: Traditional software purchasing is slower than the AI tool market.

Resolution: Plaid streamlined pilots and procurement so tools can be tested in days instead of weeks.

“With the AI tool landscape moving extremely fast compared to traditional software and services, we’ve found we need to adapt our approach.”article, stated
“* Streamlining our procurement process to start new AI tool pilots in days instead of weeks.”article, stated

Adoption plateaus without dedicated ownership.

Root cause: General availability announcements did not create sustained usage.

Resolution: Plaid formed a core team, dashboarded adoption/retention, and performed direct outreach.

““Enable it in Okta, and they will come” is not enough. After we completed a pilot, we would send out a message announcing it was generally available internally, but we’d find that adoption quickly plateaued. We convened a core team to solve this problem for current and future tools.”article, stated
“* Own adoption: Scaling AI tools requires dedicated ownership, data tracking (usage/retention), and direct user outreach.”article, stated

AI coding tools still lack common enterprise mechanisms.

Root cause: Settings, sensitive-file filtering, memory, and context hints differ across tools.

Resolution: Plaid is cataloging benchmark tasks and support requirements as models and tools evolve.

“There is also not yet a consensus on the precise mechanisms that AI tools use to handle common functionality, like version-controlled settings, filtering sensitive files from AI usage, or memory/context hinting mechanisms.”article, stated
“tweaking these settings and context hints further exacerbates the problem of the lack of benchmarking techniques.”article, stated

Evaluation

Plaid evaluates adoption through usage and retention dashboards, team/cohort analysis, manager reports, AI Day participation and CSAT, benchmarking tasks, productivity/reliability analysis, feature-usage depth, and cost-control monitoring.

Metrics: >75% regular advanced AI coding tool usage · AI pilots started in days instead of weeks · 80%+ engineering AI Day participation · 90%+ AI Day CSAT · Usage and retention by cohort/team · Feature usage such as agentic editing versus tab completion · Cost controls and benchmarking

“* Having > 75% (and climbing!) of our engineers use advanced AI coding tools on a regular basis.”article, stated
“This team spun up a basic internal dashboard to think of adoption as our own product. We were able to track not just usage over time but retention by cohorts and teams.”article, stated

Outcomes

Plaid reports hundreds of engineers, six months of adoption work, more than 75% regular usage, pilots in days instead of weeks, 80%+ engineering AI Day participation, 90%+ CSAT, and a one-hour hands-on workshop.

“Over the past six months, we were able to scale our AI engineering program by:”article, stated
“We have our work cut out for us, but now at least we have AI to help along the way.”article, stated