Hello Reader,
This week, I want to talk about Keppel's floating data centre and Racks Central's 510MW data centre campus in Johor. Also, is there such a thing as going too fast with AI? (Spoiler: I think so.)
Floating data centres
After years in the pipeline, Keppel's floating data centre in Singapore is finally under construction. This was quietly confirmed in the firm's Q1 business update released on Thursday morning.
I was the first to write about it; DCD wrote a report the very next day. Interestingly, a contact from a government agency actually texted me to clarify, so surprised was he by the revelation. He followed up soon after to confirm: yes, JTC has apparently given the go-ahead.
No details were offered by Keppel beyond a single mention in its presentation deck and press release, which came with an artist's impression. But Keppel's Wong Wai Meng has talked about its floating data centre for almost a decade now, so it won't be much trouble to piece together what's coming.
Here are some nuggets of information that have since trickled in. For a start, the floating data centre will be 20MW with shoreside infrastructure. If plans shared in 2025 come to pass, it will be cooled by seawater. And it's located at Loyang Crescent, targeted to be ready by 2027.
I hope I'll have the chance to visit when it launches.
Going big in Johor
In other news, Singapore firm Racks Central wants to build really big in Johor. 510MW big. When I read the interview by Jan Yong, what surprised me wasn't so much the 510MW, but the fact that Racks Central plans to eventually deploy Rubin Ultra, Nvidia's 600kW per rack AI behemoth.
The plan calls for four data centres within a single campus, built solely to support AI workloads and specifically for Nvidia GPUs. A rapid build-out is expected through 2028, with phase two already slated for 2027 completion.
This is quite different from my conversations with another mega player in Johor. In informal chats, they indicated that perhaps 160kW racks would be adequate to scale up to the next generation of Vera Rubin (~300kW) by spacing things out.
Whose approach will prove right? I don't know. Of course, I'm hearing of at least one data centre operator having to slow down initial plans due to factors outside their control: namely, a delay in their ability to access sufficient electricity.
Too fast, too furious?
Is it possible to do AI too quickly? I am starting to think it might not always be desirable to move too fast. And no, I'm not saying this because I'm cheap. I just upgraded to the most expensive Claude Max plan. This week, I spoke with two individuals about AI. And while they have found varying levels of success, it gave me pause.
The first recently conducted a successful paid class where he showed learners how to build websites and apps using an AI tool. As we chatted, he walked me through some of these apps, including B2B ones that still had bugs because they were "rushed out."
Separately, I spoke with a friend at a large local organisation who shared how his department was given a remit to complete and roll out an internal app. Why? Because a new hire showed off a Claude Code-produced prototype, and now the bosses absolutely had to have it, in order to retire an older vendor-created system.
This isn't a trivial service either, given that it will have over a thousand users. And mobile apps are expected too. But while my friend was supportive of the new hire, the problem, as he explained, is that "he doesn't know what he doesn't know." I can empathise.
After all, even though I am familiar with coding, there is a lot I don't know. And I have the scars to show for it. I've been bitten countless times by bugs that should have been easily solved if only I'd known certain concepts; I've also pushed back against bad design decisions that I caught and stopped Claude Code from making.
So while an AI tool can deliver an initial superlative boost to do things possible only with far larger teams, the accrued tech debt does not disappear. It grows quickly, and could well reach a point where even AI-assisted coding will slow to a crawl.
Sometimes the fastest path forward is the one that slows you down later.
As usual, you can reply to this email to reach me.
Regards,
Paul Mah
