Author Archive

When the Machine Won’t Promise to Behave: What This Week’s AI News Really Tells Us

Posted by Prem

Would you hand your car keys to a teenage driver who refused to promise they’d stop at red lights? Probably not. Yet this week, some of the biggest names in AI — OpenAI, Anthropic, Meta, and Google among them — stopped short of guaranteeing that their AI agents will always obey the safeguards built in to control them. Not because they’re being careless. Because, honestly, nobody can make that promise yet.

That admission landed quietly this week, buried under a dozen other headlines. But I think it’s the single most important thing to come out of the AI world in months.

The Pace Hasn’t Slowed. The Confidence Has.

It’s not as if the industry is standing still while it grapples with this. Reflection just unveiled Beam, a 501-billion-parameter open-weight model trained across more than ten thousand GPUs. Amazon shipped a new open-source decision model built for local workflows. The releases keep coming, each one bigger, faster, more capable than the last.

And yet, in the same week, the companies building these systems are telling us — in plain language — that they can’t fully guarantee their own agents will stay inside the lines. That’s not a contradiction. That’s the whole story.

Why This Matters More Than the Headlines Suggest

Wouldn’t it be reassuring if “safeguards” simply meant safeguards — a locked door that stays locked? Unfortunately, that’s not how any of this works, and the sooner businesses understand that, the better decisions they’ll make.

Think about what an non-guaranteed safeguard actually means once you plug an agent into something with consequences:

  • REVIEW every permission you grant an agent, not just the ones that feel risky
  • LIMIT what any single agent can touch, rather than trusting it to self-police
  • LOG every action so you can reconstruct what happened, not just what should have happened
  • TEST your agents against their stated boundaries before you ever let them near production data

Remember: “the model is usually well-behaved” is not the same sentence as “the model is safe to deploy unsupervised.” Those two ideas get blurred constantly, and the gap between them is exactly where the expensive mistakes happen.

This Isn’t Really About the AI Giants

Now, I won’t pretend this is only a problem for the OpenAIs and Googles of the world — and I think it’s worth being honest about where it actually lands. It lands on every business quietly wiring an AI agent into its email, its calendar, its client records, often without anyone asking the question these companies just answered out loud: can we actually guarantee this thing will stay in its lane?

For smaller firms, especially the ones handling sensitive client data, this isn’t an abstract debate happening in Silicon Valley. It’s a design decision sitting on your desk right now, whether you’ve noticed it or not.

But on the other hand, this doesn’t mean AI agents aren’t worth using. It means they’re worth using carefully, with eyes open, rather than with blind trust borrowed from a product demo.

The Bigger Picture

What struck me most this week wasn’t the new models or the funding rounds — it was the honesty. An industry admitting the limits of its own guarantees is, in a strange way, a healthier industry than one pretending it has everything under control.

Compliance and governance aren’t the boring cousin of innovation. They’re what lets the innovation actually get used in the real world, by real organisations, with real consequences if something goes wrong.

So the next time someone tells you their AI agent is “safe,” ask the follow-up question these companies just answered for free: safe compared to what, and guaranteed by whom? That one question will tell you more about an AI vendor than any feature list ever could.

The Ten-Second Compile: TypeScript’s Biggest Change in a Decade

Posted by Prem

How many times have you hit save, glanced at that little spinner next to your terminal, and felt the familiar twitch of impatience creep in? Maybe you got up for coffee. Maybe you scrolled your phone “just for a second” and lost ten minutes you’ll never get back. If you’ve spent any real time in a large TypeScript codebase, you know that twitch well. Waiting on the compiler isn’t just an inconvenience — it’s a daily tax on your focus.

That’s exactly the problem TypeScript 7.0 was built to solve, and it solves it in the most direct way possible: by rewriting the entire compiler from scratch in Go.

Why This Isn’t Just Another Version Bump

For over a decade, TypeScript did something almost poetic — it checked itself. The compiler was written in TypeScript, compiled down to JavaScript, and run on Node. Elegant, sure. But it also meant TypeScript inherited every one of JavaScript’s limitations: single-threaded execution, garbage collection pauses, the lot. On a small project, you’d never notice. On a codebase with a couple million lines, you’d feel it every single day.

TypeScript 7.0, which reached general availability in July 2026 after a project internally known as “Project Corsa,” breaks that pattern entirely. The new compiler is written natively in Go, and the results aren’t subtle. Microsoft’s own benchmark on the VS Code codebase — roughly 1.5 million lines — showed a full type-check dropping from 125.7 seconds to 10.6 seconds. That’s not a nice-to-have improvement. That’s the difference between a genuine break in your thinking and a blink.

What This Actually Means For You

Wouldn’t it be great to trust that your build will just… finish, before your train of thought derails completely? That’s the real gift here. Faster builds aren’t only about CI pipelines humming along quicker, though they do that too. They’re about protecting the thing that’s hardest to get back once it’s gone: your concentration.

Think about what changes when the feedback loop shrinks that dramatically:

  • REGAIN your flow state instead of losing it to a spinner
  • CATCH errors the moment you make them, not minutes later
  • RUN larger type-checks without dreading the wait
  • SCALE your codebase without watching your tooling buckle under it

Remember: a faster compiler isn’t just a performance win on a chart somewhere. It’s fewer moments where your brain quietly checks out of the problem you’re solving.

A Few Things Worth Knowing Before You Jump In

Now, I won’t pretend this upgrade is entirely frictionless, and I think it’s worth being honest about that rather than glossing over it. TypeScript 7.0 shipped without a stable programmatic API, which means tools like Vue’s Volar, Svelte, and Astro’s type checker are still waiting on a later release before they can fully catch up. If your stack leans on one of those, it’s worth holding off just a little longer.

But on the other hand, if you’re working in a fairly standard setup, there’s very little reason to wait. Strict mode is now the default, some legacy build targets have been retired, and installation is refreshingly simple — just the standard install command, no special flags required.

The Bigger Picture

This release matters because it signals something beyond raw speed: TypeScript is willing to rebuild its own foundation when the old one starts holding developers back. That’s the kind of decision that pays off for years, not just for one release cycle.

So the next time you hit save and the compiler finishes before you’ve even looked away from your screen, take a second to notice it. That small, quiet moment of not waiting is exactly what this whole rewrite was for.

Private class members

Posted by Prem

JavaScript is a constantly evolving programming language, with new features and updates being released regularly. One such feature that is sure to blow developers’ minds in ES2022 is the introduction of the JavaScript private fields.

JavaScript has always had a somewhat weak support for encapsulation and data hiding, which is a fundamental principle of object-oriented programming. In the past, developers have used various techniques such as closures and WeakMap to emulate private fields, but they are often complex and hard to understand. With the introduction of private fields in ES2022, developers can now create truly private fields in JavaScript classes, making it easier to write robust, maintainable and secure code.

To create a private field, developers simply need to prefix the field name with a “#” symbol. For example, the following code creates a private field called “_secret” in a class called “MyClass”:






class MyClass {
  #_secret;

  constructor(secret) {
    this.#_secret = secret;
  }
}






Once a private field has been defined, it can only be accessed within the class or its subclasses, making it truly private and inaccessible from the outside world. This can help to prevent accidental or intentional data leaks and improve the overall security of the application.





In addition, private fields can also be used in conjunction with getters and setters to provide controlled access to the data. For example, the following code creates a private field called “_name” and a getter called “name” that allows the value of the field to be read but not modified.










class MyClass {
  #_name;

  constructor(name) {
    this.#_name = name;
  }

  get name() {
    return this.#_name;
  }
}






One of the most interesting aspect of private fields is that they are also fully supported by the JavaScript reflection API. This means that, unlike closures and WeakMap, private fields are fully inspectable and debuggable. For example, the following code uses the Object.getOwnPropertyDescriptor method to inspect a private field:










console.log(Object.getOwnPropertyDescriptor(MyClass.prototype, "#_secret"));






Another great feature of private fields is that they can also be used in combination with other ES2022 features like decorators. Decorators are a new way of adding metadata to class members, which can be used for things like type checking, performance optimization, and more. For example, the following code uses a decorator to add a type check to a private field:










class MyClass {
  @type("string")
  #_name;

  constructor(name) {
    this.#_name = name;
  }
}






In conclusion, the introduction of private fields in ES2022 is a game-changer for JavaScript developers. It allows for true encapsulation and data hiding in JavaScript classes, making it easier to write robust, maintainable and secure code. Private fields are also fully supported by the JavaScript reflection API, making them fully inspectable and debuggable. And they can be used in combination with other ES2022 features like decorators, making them even more powerful. With the growing popularity of JavaScript, it’s the perfect time for developers to start learning and incorporating these new features into their projects.