jgmedr

Currently navigating this situation at my employer. We went from virtually unlimited token spend per software engineer, to $150 per month due the recent change in billing terms from GitHub Copilot. Rationed over a month, about $7.50 per day. Basically, a couple bad apples spoiled the bunch (contractors using Opus to center divs).

We're 15 days into this new policy and its going ~okay~. Engineers adapt as they do, and have been leaning on `gpt-5.6-luna xhigh`. Some contractors have already hit their budget limit for the month.

A couple observations here:

1. Because LLMs/agents are tools, limiting their usage becomes a distraction and ends up being more of a drag on each individual's productivity. Instead of "just doing the work" engineers are now wasting time tinkering with setups (graphs, caveman skills, etc.).

2. Skill atrophy is real. Engineers that hit their budgets are seemingly less productive and less capable which is deeply concerning.

3. There are legitimate conversations happening now to explore open source harnesses (opencode/pi) and open weight models at the company in order offset the costs associated with going through a standard provider.

4. Token prices are venture capital subsidies. Its essentially free samples to get the market hooked on their addictive white collar drug. Remember when an Uber cost $7? As soon as OpenAI and Anthropic go public, they will need to begin showing progress toward profitability. That is when the true price of a token will be revealed.

Our team has found success in treating skills more like re-usable semi-deterministic functions and less like fingers-crossed prompts for random edge-cases.

For example, we have a skill to /create-new-endpoint. The skill contains a detailed checklist of all the boilerplate tasks that an engineer needs to do in addition to implementing the logic (e.g. update OpenAPI spec, add integration tests, endpoint boilerplate, etc.). The engineer manually invokes the skill from the CLI via slash commands, provides a JIRA ticket number, and engages in some brief design discussion. The LLM is consistently able to one-shot these tickets in a way that matches our existing application architecture.

Anthropic's post is the equivalent of a parent apologizing on behalf of their child that threw a baseball through the neighbor's window. But during the apology the parent keeps sprinkling in "But did you see how fast he threw it? He's going to be a professional one day!"

I believe the intent behind implementing such a policy is admirable. By teaching students practical use of A.I. tools, their current limitations and biases, and how to refine the prompts and results will be a necessary skill. However, I also find it problematic.

> As a result, the projects this semester are much better than previous pre-AI classes.

The use of the term "better" is concerning. According the blog, the subject of the class is "innovation". He is essentially praising the A.I. ability to innovate and not his students. If the object of school is to learn, what did his students learn about innovation and how was that measured despite ChatGPT? It reads as if his students learned about using and optimizing a tool and not the subject at hand.

The common argument for A.I. is that it will free humans to pursue more interesting and creative activities. The pervasive theme among many of these articles suggests creativity and thought to become a commodity, where the role of the human is to simply intervene and edit. Many architects are beginning to forfeit design to Midjourney, and editing the results. We need to ask ourselves: is authoring or editing more worthwhile?