AI CodingAI AgentGovernance & Compliance

Business Staff Prototype, Engineers Ship to Production: Why Goldman Sachs Pulled AI Coding Tools After Three Months

A division-of-labor proposal has been gaining traction inside many companies lately. Now that AI coding tools are smart enough, why not let colleagues who understand the business write software prototypes directly through natural-language chat, and then hand them over to software engineers to refine and ship to production? Having non-coding business staff generate program scripts purely through natural-language prompts is widely known in the industry as vibe coding. Goldman Sachs opened up this kind of experimentation internally a few months ago, and in July its chief information officer publicly praised traders and investment bankers in an interview for building their own software prototypes.

Yet that seemingly win-win workflow lasted only three months. According to an exclusive Bloomberg report, Goldman Sachs updated its internal guidance in October 2026, barring most traders and investment bankers from using Claude Code and GitHub coding tools and pulling access back to software engineers. Also in October, Apple lowered the daily compute allowance for some employees calling external large models, and is weighing changes that would open a four- to eightfold gap in daily budget caps between software engineers and non-technical teams.

Both giants tightened tool permissions and compute quotas in the same month, puncturing the optimistic assumption that everyone should write prototypes. AI has indeed pushed the cost of generating code toward zero, but it has not lowered the cost of verifying code, auditing security boundaries, or troubleshooting production outages. Who gets direct access to coding tools no longer depends on department titles; it comes down to whether you can review code yourself and take ownership when production breaks. Large companies are splitting their workforce into two groups: one equipped with high-privilege tools and ample compute to build tools, and another working through ready-made, secure internal services.

Why Doesn’t the Math Work When Business Staff Prototype with AI and Engineers Ship to Production?

Goldman Sachs initially encouraged everyone to build prototypes to clear the bottleneck of business requests waiting in engineering queues. In the spring, Goldman President and Chief Operating Officer John Waldron compared the investment bank to a human assembly line, arguing that many routine steps lent themselves to automation. In a public interview over the summer, Chief Information Officer Marco Argenti sketched out the cross-team handoff in detail: non-technical staff in trading, investment banking, and asset management would use vibe coding to spin up quick software prototypes, then hand them to one of the firm’s 12,000 human software engineers to polish, scale, and deploy to production. Goldman had already piloted autonomous software engineering tools inside that engineering organization the previous summer, and management figured that letting business staff take one step forward would complete the automation pipeline.

By October, however, Goldman Sachs halted this firm-wide experiment. Responding to media inquiries, Goldman spokesperson Nick Carcaterra explained that the firm makes certain AI tools available to employees to explore the best use cases across different parts of the business; after a period of evaluating both productivity and risk management, the firm decided to place those tools in the hands of the people best suited to deliver value with them over the long term. That explanation points to a blunt reality: having business staff write prototypes and toss them to engineers to finish does not pencil out in real production environments.

The explicit exception carved out in Goldman’s new rules is for quantitative strategists. Known internally at Goldman as strats, they sit right beside traders at the intersection of trading, quantitative research, and software engineering. Quantitative strategists serve the front lines of the business just like regular traders, with one critical difference: they understand code, can check data edge cases themselves, and can step in to fix problems if something breaks in production.

A non-coding business employee can generate several hundred lines of script through natural-language chat in just minutes. Once a software engineer inherits that half-finished code, however, not a single line of its logic can be trusted directly. Business users only care whether a script produces numbers on their own laptops; they do not account for concurrency conflicts, API timeouts, malformed inputs, or permission leaks. The engineer taking over has to reverse-engineer the intended business logic from scratch and comb through every line for hidden out-of-bounds data access and logic flaws, an effort that often takes more work than writing the program from zero. Saving a few hours on code generation ends up costing several days in verification, auditing, and rewrites.

Goldman Sachs partner Chris Churchman runs Marquee, the firm’s flagship risk analytics and digital trading platform for institutional investors. In an interview on the firm’s official podcast in late August, he pointed to two further risks. First, in bringing AI into the Marquee platform, the thorniest technical challenge was ensuring system outputs are 100% factual and auditable, because high-level finance has near-zero tolerance for data errors. Second, if junior traders and bankers outsource foundational analysis and modeling to large models, they suffer cognitive atrophy, gradually losing the ability to reason through business problems independently from first principles while eroding Wall Street’s apprenticeship tradition of learning by doing. Letting business staff without engineering audit skills generate code and financial models directly fails financial compliance audits and hollows out the business team’s own professional judgment.

Within three months, Goldman Sachs reversed its plan for business staff to hand AI prototypes to engineers, pulling coding agents back to engineers and quantitative strategists who can audit code.

Why Were Traders Who Don’t Build Software So Eager to Use Programmers’ Command-Line Tools?

Beyond building software prototypes, plenty of traders and bankers who do not develop software systems in their day jobs were also rushing to use Claude Code. Although Goldman Sachs stopped bankers in its Hong Kong office from using Claude earlier this year, the firm has consistently offered general employees its own controlled internal AI assistant, integrating mainstream models from OpenAI, Anthropic, and Alphabet. With a compliant chat assistant already available inside the company, why were traders and bankers who don’t build software systems scrambling for Claude Code, a tool meant for programmers?

The answer lies in what Goldman’s traders and bankers were actually doing with Claude Code and GitHub’s coding tools. They used them primarily for three everyday tasks: monitoring client trading flows, building models of market changes and positions, and generating written and graphic content. A tool like Claude Code is a coding agent; beyond generating code, it can execute command-line instructions directly on an employee’s computer, read and write local files, and call external scripts. By contrast, a standard web chat box is confined to a browser sandbox, unable to access local files on an employee’s computer or run automated batch jobs. Once business staff realized a coding agent could read data off their desktops, run position calculations automatically, and produce charts for reports, a tool built for programmers became the handiest all-in-one office assistant at their disposal.

Treating coding agents as general-purpose personal assistants has become a real trend across Silicon Valley. On the same day the Goldman news broke, Garry Tan, CEO of startup accelerator Y Combinator, revealed in a reported podcast interview that he spends $100,000 to $200,000 a year on AI tokens. Not only has he open-sourced 23 Claude Code skill packs he wrote himself on a code-hosting platform, he also relies heavily on AI agents across his daily work and personal life.

To let agents help manage his affairs, Garry Tan granted permissions for them to read all of his emails, Dropbox files, Apple Notes, and even 20 years of private therapy notes. For an individual developer, opening up local access permissions on a personal computer may feel harmless, but for a financial institution, operating that way leaves the firm completely exposed. The day after the Goldman report was published, Amjad Masad, CEO of cloud development platform Replit, warned on social media that AI agents running on employee computers are turning into a systemic security risk for enterprises and governments, and that the financial industry is bringing down the ban hammer.

According to security media analysis and security guidance published by Replit’s technical team, letting employees run coding agents directly on their own computers introduces three categories of security risk: pulling malicious code into the internal network when downloading external open-source packages, exposing long-lived login passwords and keys stored on the machine to the tool, and having the tool execute dangerous commands in the background without leaving a central audit trail. At Goldman Sachs, financial traders’ computers have direct access to sensitive client trading flows and internal database credentials. Allowing employees without security engineering training to run agent scripts freely in a local terminal means a single bad third-party library installation or poisoned external data input could bypass corporate firewalls and escalate into a security incident touching core trading systems. Replit’s technical team therefore recommends that enterprises run agents inside controlled, dedicated cloud environments rather than directly on employees’ personal endpoints.

Why Is Apple Boosting R&D Spending by 30% While Cutting Daily Quotas Toward $100 and $25?

In the same week Goldman’s move to pull coding tools from traders came to light, media reports revealed that Apple was doing its own internal math. According to Bloomberg reporter Mark Gurman, Apple lowered the daily token spending cap in October for some software engineers calling external large models such as Claude, ChatGPT, and Gemini from $300 to $200, and plans to cut the cap further to $100 a day for certain engineering teams, while employees with genuine needs for higher compute can apply to senior leadership for special exemptions.

Gurman noted that many Apple employees had not been exhausting their previous limits anyway, so how much money the reductions will save remains unclear. Plenty of Apple employees also felt the earlier allowance had been more than generous. Even at the lowest planned tier for engineers, an Apple engineer can still use $2,000 to $3,000 a month in large-model compute. By comparison, after Uber burned through its full-year AI coding budget in the first four months of this year, the per-tool monthly cap it set for employees was $1,500, and the weekly spending cap Tesla later set for staff was just $200. Apple’s latest move is aimed primarily at closing the loophole that allowed a tiny handful of users to run up unlimited bills, leaving engineers’ normal daily R&D workflows unaffected in practice.

Tightening daily quotas stands in sharp contrast to the annual financial results Apple released the very same week. In fiscal year 2026, which ended this fall, Apple’s total revenue reached a record $479 billion, while R&D spending jumped 32% year over year to a record $45.77 billion.

Substantially ramping up R&D investment on one hand while trimming daily external model allowances on the other makes complete financial sense. John Ternus, who succeeded Tim Cook as Apple’s CEO, is pushing a series of organizational overhauls aimed at reducing management layers so the company runs faster and leaner overall. At the same time, Apple is asking some teams to use cheaper external models, or even on-device models running locally on hardware. From management’s perspective, building underlying compute infrastructure and training core models are strategic investments in long-term assets, whereas employees calling external commercial APIs every day is a pay-as-you-go office operating expense. The former merits aggressive investment, while the latter should tilt toward cheaper and local models under standard cost discipline.

The more important signal is that Apple has set different allowances for different roles: many non-technical teams outside engineering previously had a cap of up to $100 a day, and Apple is now considering lowering the allowance for some non-technical teams to $25 a day. Once implemented, compute budgets between software engineers and non-technical staff would separate by a factor of four to eight. Compute quotas are no longer distributed as an equal flat allowance across the board; like Goldman Sachs, Apple is rationing them in tiers based on whether a role can directly generate verifiable engineering value.

Apple boosted annual R&D spending by 32% to $45.77 billion while pulling back redundant $300 daily allowances and weighing tiers that would open a four- to eightfold gap in daily compute quotas between engineers and non-technical teams.

If Not Everyone Gets the Same Heavy Hammer, How Should Teams Divide the Work?

This summer, Meta slammed on the brakes after consuming 73.7 trillion tokens in a single month, and major tech companies like Microsoft moved to set department budget caps. Next, institutions such as JPMorgan Chase began requiring employees to match model tiers to task difficulty, a gear-shifting approach that helped many companies achieve higher usage alongside lower bills. Those two steps mainly addressed how to save money; with Goldman Sachs and Apple, large enterprises have started managing a more fundamental question: how to divide work inside teams.

Seeing what Goldman and Apple have done brings a natural question back to our own companies. If we don’t let business colleagues use Claude Code to build prototypes themselves and hand them to engineers to ship, does that force them back to looking up tables and drawing charts by hand?

Just a few days ago, we analyzed who should build internal data assistants, and the example there points to another path. Teams under xAI initially let employees use their own personal assistants to query data and build team bots as well, but self-built bots lacked unified data-warehouse metric governance and ongoing maintenance; their numbers frequently contradicted one another, and out of 280 team bots only a dozen or so achieved strong retention. What actually handled company-wide daily queries was a shared data bot built centrally and maintained uniformly by a data science team that understood both business metrics and software engineering. Turning every business employee into a makeshift programmer does not solve business productivity. What works is having a specialized team package high-frequency business needs into reliable shared tools.

From Goldman greenlighting quantitative strategists and Apple weighing a four- to eightfold quota gap across roles to xAI’s experience, an internal AI division of labor is taking shape. One group consists of professional developers such as software engineers, Goldman’s quantitative strategists, and xAI’s data science team: companies can equip them with heavy-duty coding agents like Claude Code and ample compute of $100 to $200 a day, holding them accountable for code quality, security audits, and production incidents. The other group consists of traders, investment bankers, and non-technical business teams: companies are better off pulling unguarded terminal command lines out of their hands, having engineering teams build permission-controlled, auditable internal tools for them, and pairing those tools with lightweight allowances in the $25-a-day range to call ready-made services directly.