HomeSomewhere in the last stretch of big tech's public commentary on AI-assisted engineering, a genre of internal memo has become recognisable: leadership stating, in terms considerably blunter than the usual corporate hedging, that AI coding tools are no longer optional accelerants for engineers who feel like using them, but a baseline expectation woven into how the organisation ships software. Coinbase's leadership has been among the more publicly direct voices in this genre, framing the choice starkly: build with the available agentic tooling, or don't expect the same throughput to be tolerated without it.
For a Singapore tech team reading this from a considerable distance, both geographically and in terms of the resourcing available to a crypto-exchange-scale engineering organisation, the honest question is not "should we copy this exactly" but "what is the actual discipline underneath the headline, and how much of it transfers to our scale." That is the question this piece works through.
Related reading in our Insights hub covers what engineering looks like after Copilot, when engineers become architects rather than typists, and how Microsoft's copilot-in-every-job playbook translates to Singapore SMEs.
What the Mandate Actually Says, Stripped of Rhetoric
Strip away the deliberately blunt framing and the underlying claim is more precise and more defensible than the headline suggests. It is not "AI should write all your code" or "engineers are being replaced." It is closer to: for the categories of engineering work that AI coding assistants now handle reliably, boilerplate generation, test scaffolding, well-specified integrations, routine refactoring, an engineer who isn't using that tooling as the default first pass is working at an artificially slower pace than the tooling now makes available, and that gap is no longer acceptable to carry silently.
The mandate is a floor on baseline tool adoption for well-understood categories of work, not a ceiling on human judgment for the harder categories. Architecture decisions, security-sensitive logic, ambiguous requirements that need genuine interpretation, and anything where a mistake is expensive to discover late, these remain squarely human-judgment territory, and no serious version of this mandate claims otherwise. The mandate's actual target is the software engineering equivalent of what we've called bucket-one work elsewhere: high-volume, well-specified, machine-suitable tasks that some engineers, out of habit or discomfort with new tooling, were still doing by hand at the old pace.
Why the Framing Is Deliberately Uncomfortable
Leadership choosing blunt, almost confrontational language for this kind of mandate is itself a signal worth reading correctly. Softer internal messaging, "we encourage the use of AI tools where appropriate", tends to produce patchy, inconsistent adoption, because it leaves the decision to individual comfort levels, and comfort with new tooling varies enormously across an engineering organisation regardless of actual skill. Blunt, close-to-non-negotiable framing forces the adoption curve to compress faster than it otherwise would, at the real cost of some discomfort and some genuine resistance from engineers who have legitimate concerns about code quality or over-reliance.
Whether that trade-off is the right one depends heavily on context that a memo alone can't convey: how mature the company's code review discipline is, whether security scanning catches AI-introduced vulnerabilities before they ship, and whether junior engineers are given a genuine path to still develop fundamental skills rather than becoming purely AI-output reviewers before they've built the judgment to review well. A mandate without those safeguards in place is a different, riskier proposition than a mandate layered on top of them.
The Singapore Engineering Team's Honest Starting Point
Singapore's tech sector, spanning everything from fintech and gaming to the SME digitalisation work that makes up much of the market our own clients operate in, is engaging with agentic coding tools at wildly varying maturity levels. Some teams have genuinely integrated AI-assisted development into daily practice; many others are still treating it as an individual engineer's personal choice, unevenly adopted, informally used, with no organisational visibility into how much of the team's actual output now depends on it.
The honest first step for most Singapore engineering teams is not adopting a Coinbase-style hard mandate. It is closing the visibility gap: understanding, with actual data rather than assumption, how much of the team's current output already involves AI-assisted coding, and where the remaining gaps are. A team that doesn't know this baseline cannot make an informed decision about whether a stronger mandate would meaningfully change throughput, or whether the team has already effectively adopted the discipline informally and the real gap lies elsewhere, in code review practices, in deployment pipeline speed, or in how requirements are specified before engineering work begins.
The Governance Layer Most Memos Skip
What is conspicuously absent from most public commentary on these mandates, understandably, since companies rarely publish their internal quality-control playbook alongside a punchy leadership memo, is the governance layer that makes aggressive AI adoption survivable rather than reckless. Three components matter most for a Singapore team considering a similar push.
Code review discipline has to scale with adoption, not lag behind it. AI-generated code that passes a cursory glance can carry subtle logic errors or security issues that a rushed reviewer, under pressure to match the new, faster pace of AI-assisted output, might miss. Teams that push AI adoption without proportionally strengthening review discipline are trading a slower, safer pace for a faster, riskier one, often without deciding to make that trade consciously.
Security scanning needs to specifically account for AI-introduced patterns. AI coding assistants have documented tendencies toward specific classes of vulnerability, insecure default configurations suggested because they're common in training data, dependency suggestions that aren't properly vetted. A Singapore fintech or any business handling PDPA-covered personal data needs security tooling and review practices that specifically account for this, not a generic code review process assumed to catch AI-specific failure modes it wasn't designed for.
Junior engineer development needs deliberate protection. The engineers who will supervise, direct, and catch the errors of AI-assisted development in five years are being trained today, and if today's junior engineers are only ever reviewing AI output rather than building the foundational skill of writing and reasoning about code themselves, the pipeline of engineers capable of exercising that judgment eventually runs dry. This is a genuine, under-discussed risk in the industry's rush toward AI-first engineering mandates, and a Singapore team adopting this discipline should build an explicit answer for how junior development still happens.
What a Realistic Singapore Version Looks Like
A realistic, appropriately scaled version of this mandate for a Singapore engineering team, whether inside a larger enterprise or a growing SME's in-house team, has several concrete components. A clear, written expectation that AI-assisted tooling is the default first pass for well-specified, routine implementation work, communicated as a baseline expectation rather than an optional accelerant. A code review process explicitly updated to account for AI-generated code's specific failure modes, not just a generic review checklist inherited from before AI tools were in daily use. A defined path for junior engineers that preserves genuine skill-building alongside AI-assisted work, rather than skipping straight to AI-output review. And honest, periodic measurement of whether the adoption is actually improving throughput and quality together, not just throughput, since a throughput gain purchased with a quality decline is not the gain it appears to be on a sprint velocity chart.
Workforce Singapore's job-redesign consultancy support and SkillsFuture's enterprise training credits can meaningfully lower the cost of building this properly, training an engineering team in genuine AI-tool literacy and updated review discipline, rather than leaving adoption to happen unevenly and informally across individual engineers' personal initiative.
How to Measure Whether the Mandate Is Actually Working
A Singapore engineering leader considering this kind of mandate should decide, before rolling it out, exactly how success will be measured, because "did throughput go up" is an incomplete and potentially misleading measure on its own. A more complete measurement set tracks throughput alongside defect rate in production, the proportion of pull requests requiring significant rework after initial review, and, where feasible, a periodic security audit specifically checking for the vulnerability patterns AI coding assistants are known to introduce. A team that sees throughput rise while these quality indicators hold steady or improve has genuinely captured the benefit the mandate was meant to produce. A team that sees throughput rise while defect rates or security findings creep upward has, in effect, borrowed against future engineering time to hit a short-term velocity number, and the bill for that borrowing arrives later, usually at a less convenient moment than a planned investment would have been.
The Uncomfortable Conversation About Engineer Identity
There is a dimension to this shift that pure productivity metrics don't capture, and Singapore engineering leaders considering a strong AI-adoption mandate should be prepared to have the conversation directly rather than let it fester unaddressed. For many engineers, a meaningful part of professional identity and satisfaction has historically been built around the craft of writing code itself, not just the outcome of shipped software. A mandate that reframes an engineer's primary value as directing and reviewing AI output, rather than personally writing the implementation, is not merely a workflow change; for some engineers, it touches something closer to how they understand their own professional worth.
Leaders who acknowledge this directly, rather than dismissing the discomfort as simple resistance to change, tend to navigate the transition with considerably less attrition of their strongest people. The engineers most worth retaining through this shift are often the ones who can articulate, once given the space to think it through, that architecture judgment, system design, and the ability to direct AI tooling effectively toward a well-conceived solution are a more advanced and more scarce skill than the manual implementation work the tooling now handles, not a lesser version of the job. Making that reframing land authentically, rather than as a corporate talking point, is genuine leadership work that a memo alone cannot accomplish.
The Broader Point for Singapore's Tech Sector
Coinbase's blunt memo is a useful provocation precisely because it forces a question most Singapore engineering leaders have been able to defer: not whether AI coding tools work, that question is largely settled, but whether the organisation has actually built the governance, review, and training discipline to adopt them at the pace the tools now make possible, safely. The companies that get this right in Singapore's own tech sector will be the ones that read past the provocative headline to the underlying discipline, and build the governance layer deliberately, rather than either ignoring the shift entirely or adopting it recklessly because a global company's memo made it feel urgent.
The practical starting point for a Singapore engineering leader reading this and wanting to act on it, rather than simply nodding along, is small and specific: pick one team, one sprint, and measure the three things that matter, throughput, defect rate, and review time, before and after deliberately raising the expectation around AI-assisted tooling for that team's routine work. That single, bounded experiment produces more genuine, locally relevant evidence about whether a stronger mandate would help this specific organisation than any amount of reading about how a much larger, differently resourced company has handled the same question.