Reports that Goldman Sachs has restricted AI coding tools are easy to read as a sign that big business has become disillusioned with “vibe coding.” The conclusion is appealingly simple: first everyone believed anyone could program, then reality intervened. Yet the story deserves a closer look. It raises a question that many companies will have to address: how to turn widespread access to code creation into a managed software development process.
According to reports published on November 2, 2026, citing Bloomberg, Goldman Sachs narrowed bankers’ and traders’ access to certain AI coding tools in October. Engineers retained access, as did quantitative strategists, whose work combines financial modelling and software development. These are reports about the bank’s internal rules; describing them as an “official rejection of vibe coding” goes beyond the facts presented. State of AI: Goldman Sachs restricts AI coding tools, November 2, 2026.
Meanwhile, Goldman Sachs explicitly includes the use of Claude Code, GitHub Copilot and other agents in engineers’ responsibilities in its job listings. It also requires engineers to critically assess the generated code, maintain its quality and ensure that it is fit for production. The bank continues to treat AI as a tool for professional software development. Goldman Sachs: Software Engineer, Global Banking & Markets, AI/ML Technology vacancy.
For Ukraine’s IT industry, the important issue is the connection between being able to create a program and being able to take responsibility for how it works.
Vibe coding generally describes an approach in which a person states the desired behaviour in natural language and gives AI substantial freedom to build the program. The person evaluates the result, refines the request and tries again. This approach can be useful for prototypes and testing ideas. But the visible result reveals only some of a system’s properties. A working interface does not yet tell us how the program handles invalid data, who can access information or what will happen when an external service changes.
Imagine a financial analyst who uses AI to build a tool for reconciling payments. Everything works on a test file. Colleagues begin using it every day, and eventually its results feed into management reports. Yet no one has separately checked partial payments, duplicate transactions or different rounding rules. This is a hypothetical example, but it illustrates the moment when personal automation becomes part of a business process. That transition calls for validation, someone responsible for maintenance and clear limits on use.
The consequences of an error determine the level of oversight required. The UK’s National Cyber Security Centre, NCSC, explicitly distinguishes low-risk prototypes from systems that process sensitive data, handle authentication or work with access credentials. The latter require an understanding of the code, vulnerability checks and verification of the expected behaviour. NCSC: levels of oversight in AI-assisted development, 2026.
This leads to an important management distinction: the job title of engineer does not itself guarantee a safe result. An experienced developer can also make a poor decision or place excessive trust in an agent. Competence, the review process and the tool’s permissions all matter. Role-based restrictions may be a convenient administrative measure, but they need to be complemented by rules for working with specific systems and data.
The second aspect is economics. The cost of software includes requirements analysis, integration, validation, operation, updates and incident resolution. If code generation becomes faster while review and rework increase, the overall savings need to be measured separately.
The history of METR’s research is instructive. In an experiment published in July 2025, 16 experienced developers completed 246 tasks in familiar open-source projects. With access to the AI tools available at the time, they took 19% longer on average, even though they believed they had worked faster. The result applied to those particular tools, participants and tasks. METR: the impact of early-2025 AI tools on experienced developer productivity.
In February 2026, METR published an update. The researchers considered it likely that newer tools were delivering greater benefits, but warned that participant and task selection effects prevented a reliable estimate of the effect’s size. Some developers did not want to work without AI even for the sake of the experiment. This sequence demonstrates how carefully a single figure should be applied to an entire industry. METR: developer productivity study update and methodological limitations, February 2026.
For managers, the practical lesson concerns the choice of metrics. It is worth measuring time to an accepted and verified result, the amount of rework, defects after release and maintenance costs. The number of generated lines or activated licences shows tool usage, but explains little about its economic value.
DORA’s 2025 research also links the outcomes of AI use to organisational conditions. Important factors include a clear policy, high-quality internal data, version control, small batches of changes and a focus on user needs. This supports treating AI adoption as a change to the development process that requires more work than buying subscriptions. DORA AI Capabilities Model: organisational conditions for effective AI-assisted development, 2025.
Companies would benefit from defining several levels of autonomy. An experiment using synthetic data can have a simple launch procedure. An internal tool that colleagues regularly rely on already needs a designated owner and validation. Changes to a payment system or a service handling personal data should pass the appropriate engineering procedures regardless of who wrote the first version of the code.
It is also important to preserve business specialists’ ability to propose and test ideas. An analyst, accountant or logistics specialist often understands the exceptions in their process better than a developer does. A prototype they create can make requirements concrete and accelerate mutual understanding. A company needs an accessible route from that prototype to a maintained solution, with a description of its purpose, validation of assumptions and a handover for ongoing support.
AI can also assist with review, but an additional automated assessment does not guarantee correctness. In its agent documentation, GitHub warns about missed problems, false positives and potentially insecure code suggestions. Its recommendations call for human review and testing of the results. GitHub Docs: capabilities, limitations and responsible use of Copilot agents.
Acceptance criteria should therefore be defined before generation begins. Calculations need examples with known correct answers. Data access needs tests confirming that a user cannot perform a prohibited action. Integrations need failure and recovery scenarios. This approach helps verify compliance with business requirements, including those that the model may have misunderstood.
For Ukrainian product and service companies, this creates a concrete opportunity. An offering to a customer can cover the entire journey from a rapid prototype to an integrated, verified system with defined support. The value of this work is easier to explain through customer outcomes, reliability and operating costs.
Customers, in turn, should clarify who reviews critical changes, which data agents can access, how their actions are recorded and who will maintain the solution after launch. The answers need to be specific: a responsible team, acceptance criteria, access rules and a recovery procedure. A formal assurance that a supplier uses “the latest AI” does not address these questions.
The training of junior specialists also needs attention. As AI takes on some entry-level tasks, companies must deliberately teach people to read other developers’ code, find errors, test assumptions and explain decisions. Access to a powerful tool creates more opportunities to practise, but developing professional judgement requires mentoring and feedback.
The Goldman Sachs story leaves Ukrainian IT with a useful question: are our processes ready for many more people to be able to create software solutions? The answer needs to include both freedom to experiment and a way to turn a successful experiment into a reliable product.
Access to code generation is becoming widespread. Accountability for software must remain specific.
The Association’s work in this area: Software Ukraine AI Commission.