Agent 在 TypeScript 專案中引入 Python，增加團隊維護負擔

Our main app is TypeScript. The build is Vite, the tests are Vitest, the CLI scripts are Node. Every engineer on the repo is comfortable in that stack. That is a feature, not an accident.

A few months ago, we asked the agent to clean up a small data task: pull a JSON dump from a support export, flatten the nested fields, and write a CSV that the finance team could open. The agent came back with a clean PR.

It was a 40-line Python file.

import json, csv
with open('support-export.json') as f:
    data = json.load(f)
rows = []
for item in data['tickets']:
    rows.append({
        'id': item['id'],
        'subject': item['subject'],
        'assignee': item.get('assignee', {}).get('email', ''),
        'tags': ','.join(item.get('tags', []))
    })
with open('out.csv', 'w', newline='') as f:
    w = csv.DictWriter(f, fieldnames=rows[0].keys())
    w.writeheader()
    w.writerows(rows)

It worked. We merged it. It was small, it was readable, it solved the problem.

Two months later, finance asked for the same CSV with an extra column. Nobody on the team wanted to touch the Python file. We all knew TypeScript. We all knew ts-node and npx tsx. None of us had Python 3.11 on our laptops anymore. The agent that wrote it was gone from the session. We spent longer staring at the file than it would have taken to rewrite it in Node.

That is the polyglot sprawl trap. The agent optimizes for the task in front of it. It reaches for the language it knows best for string-munging, which is often Python, and it does not see the second-order cost: every new runtime in the repo is a new thing every future engineer has to understand, a new CI step to install, a new version of a dependency nobody owns.

The drift we did not notice

Over the next quarter, the same pattern repeated. The agent wrote a shell script to walk a directory tree because that felt like a shell job. It wrote a jq one-liner in a Makefile. It wrote a Python script to parse an XML response that should have been a Node test. Each one was the right tool for the tiny task. Together, they turned a single-language repo into a small tower of babel.

The cost is not the code. The cost is the next person who has to:

• know which runtime to invoke;
• install it on their laptop and in CI;
• debug a stack trace in a language they do not use daily;
• decide whether to rewrite the thing or live with it.

We saw it most clearly when a new engineer's onboarding task was "add a column to that CSV export." She came back an hour later and said, "I don't have Python and I don't want to install it just for this." That was the moment we stopped treating it as a joke.

The rule we added

We put one line in the agent's instructions at the repo root:

Stay in this repo's existing stack. If the task can be done in TypeScript, do it in TypeScript. If you reach for a new language, a new runtime, or a new top-level dependency, stop and explain why the existing stack cannot do it.

That is it. It is not a hard ban. It is a requirement to justify.

In practice, the agent now does the task in TypeScript. The data-munging script that would have been Python became a 50-line Node file using fs/promises and a CSV package we already had. It is not as elegant as the Python version. It is also readable by every engineer on the team, runs under the same Node version as the rest of the repo, and shows up in the same test runner.

When the agent does have a real reason to introduce something — a CLI tool that is faster in Go, a query that uses a Python library we cannot easily port — it now says so in the PR description. We review those cases explicitly. The default is "no," not "sure," and that single flip has stopped the slow drift.

The honest exception

There are real polyglot repos. If you have a Python ML service and a TypeScript frontend, the Python belongs. If you have a Go CLI and a React app, the Go belongs. The rule is not "one language forever." It is "do not introduce a new language for a task the existing stack already handles."

A 40-line CSV transformation is not a Python task. It is a Node task that the agent wrote in Python because Python was on its mind. The repo you maintain is the sum of the small choices the agent makes when no human is watching. Those choices add up faster than you think.