DEV Community: Aswin M Rajeev

Should Every Application Really Run Its Own AI for Resource Management?

Aswin M Rajeev — Mon, 31 Aug 2026 16:05:20 +0000

Imagine five applications running on a computer, and each has a small AI model trying to optimize how that application uses the system.

Capable hardware can easily carry that extra weight.

But those models are still spending the user's computation.

That is what makes me question the architecture. If every application starts carrying a model to observe its resource usage, predict what it will need and make its own optimization decisions, we haven't removed resource management from the operating system. The OS is still there doing the actual scheduling. We have just added several smaller decision-making systems around it.

The OS Already Knows a Lot

It knows memory pressure. It knows which processes are waiting for CPU time, which ones are active, what is being allocated and where contention is happening. More importantly, it sees all applications at once. An application optimizing itself doesn't have that same view.

Still, the OS has a blind spot.

It can know what an application needs without completely knowing what the user wants from it.

It can know that a program wants 4 GB of RAM and several busy threads. That doesn't mean it knows what the user actually wants from that program.

Maybe an application doing almost nothing in the background is the one I expect to respond instantly in the next few seconds. Meanwhile another process can be consuming a large amount of CPU for something I don't currently care about. Looking at resource demand alone doesn't completely reveal that difference.

This is where I think AI becomes interesting—but not as a replacement for the scheduler.

Not Every Decision Needs AI

If a deterministic rule already gives the OS an answer, use it. There is little reason to run an inference just to rediscover a decision we could calculate directly.

Sometimes there isn't even time to ask.

Some OS operations happen on extremely short timescales. Put model inference in that path and the thing supposedly optimizing the system can become the reason it is slower. Input preparation costs something. Inference costs something. Monitoring the result costs something too.

You could eventually spend more computation deciding how to save computation than you actually save.

That would be a strange optimization.

So I wouldn't put AI in every decision path. I see it being useful in the less obvious cases, where several system signals exist but they don't translate cleanly into a deterministic decision.

Let AI Handle the Uncertainty

A model trained specifically for this domain could receive things such as RAM pressure, CPU utilization, queue states and process behaviour. Historical user behaviour might be useful too, but I would treat that as secondary data rather than letting the whole system reshape itself around one person's habits.

The model's job wouldn't be to control the machine.

It would take a situation containing uncertainty and turn it into useful information that the OS can evaluate.

The operating system remains the authority because, in the end, it is the component actually controlling the resources.

Reversibility Matters

I would put another restriction on it.

Before the OS performs an AI-influenced optimization, there should already be a deterministic condition for reversing that action. If the change pushes the system somewhere it shouldn't, recovery shouldn't depend on asking the same model whether its previous prediction was a mistake.

Rollback is already defined.

This doesn't mean every application-level AI should disappear. If an IDE needs a model to understand code, that model belongs there. The same applies to an image editor using a model for image processing. Those are features of the application itself.

I am talking specifically about AI being added to applications to manage shared system resources.

Hardware resources don't belong to individual applications. Every application ultimately asks the same operating system for those resources anyway.
Having several independent models reason about their individual pieces of the machine while the OS remains responsible for the whole machine creates unnecessary system friction.

Let applications keep the AI they need for their actual work.

For resource optimization, I would rather give the intelligence to the component that already holds the authority—and make sure that intelligence knows when not to get involved.

When Should Software Refuse to Continue?

Aswin M Rajeev — Sat, 29 Aug 2026 14:56:55 +0000

A program reaches a state it did not expect. It can still execute instructions. Nothing has crashed yet. Should it continue?

I don't think there is a single answer.

If software knows it is making an assumption, silently guessing what the user intended is questionable. For a reversible operation, continuing may be reasonable if the uncertainty and its cause are clearly shown. Irreversible actions deserve a different threshold. Sometimes confirmation makes sense; sometimes the operation should simply be rejected.

That logic changes once the system itself becomes unreliable. Memory corruption, a security compromise, or an undefined internal state creates a different problem. A system in an undefined state cannot confidently decide that an action is reversible, because the mechanism making that judgment may itself be affected. Returning to a known-good state is preferable whenever possible. Otherwise, stopping may prevent corrupted execution from travelling further.

But stopping is not automatically the safe option either. In safety-critical systems such as avionics or medical equipment, suddenly removing a function can itself create danger. The design may need redundancy, isolation, degraded operation, failover, or another predefined recovery path that keeps essential functions available rather than simply terminating everything.

Asking the user isn't an escape from every decision. Waiting for an answer can leave an application blocked or preserve a dangerous state. Some decisions must happen before a user could reasonably intervene. Even an application that wants to continue exists under a larger authority; if the operating system terminates it to protect the machine, it cannot simply override that decision.

So I don't see "always continue" or "always stop" as useful absolute rules. Predicting the next state is itself a probability problem.

The harder engineering question is deciding what we are protecting—the current work, the data, the application, the wider system, or continued operation itself—and whether the system is still trustworthy enough to make that choice.

Engineering Isn’t About Building More. It’s About Finding the Best Path.

Aswin M Rajeev — Wed, 26 Aug 2026 16:59:55 +0000

Engineering, in my view, is not simply about building a solution. It is about finding the best path to accomplish a task while thinking about what that solution will cause in the long term.

A good product should be highly reliable without unnecessarily consuming the customer's resources. If two solutions achieve the same purpose, I would choose the one that saves resources rather than choosing something simply because it uses more sophisticated technology.

But reliability alone cannot define a good product. A combustion engine might run throughout its entire life, but if it continuously produces harmful emissions, what meaning does reliability have? Engineering should always uphold sustainable development and give importance to the environment.

I also believe an engineer's vision should extend beyond a small request from a user. The responsibility begins when the product is created, while different engineering fields and services take responsibility for other parts of its life.

Engineering is also not a journey without failure. Failure can be part of the engineering journey, because it can expand what we discover. Even solving a problem that wasn't originally intended can open a completely different direction.

Ultimately, engineering is not about asking "Can we build this?"

It is about asking:

"What will happen because we built it?"

Beyond Syntax: What Really Makes a Programming Language?

Aswin M Rajeev — Sat, 01 Aug 2026 18:28:52 +0000

In this post, I want to explain how I approached the design of my own programming language, Light, and why some of its rules were designed the way they are.

When designing Light, I was not only deciding how programs should be written. I also had to define how those programs should behave, how different features should interact, and what rules should remain consistent throughout the language.

One question guided many of these decisions:

What rule should govern this, and how should it interact with the rest of the language?

This led to a design centered around explicit structure and dynamic flexibility.

Light defines structural rules for program entry, control flow, data access, and reusable program units. At runtime, variables remain dynamically typed while operations such as array access, expression evaluation, and type conversion follow defined rules.

The same principle applies to Purpose blocks and libraries. They are not isolated features; their behavior is designed to fit into the language's existing execution and data model.

A feature is not complete simply because its syntax works. Its behavior must remain predictable when combined with everything around it.

That is why I focus not only on what a feature can do, but also on where it belongs, what rules govern it, and how it interacts with existing constructs.

For me, this is the foundation of Light's design philosophy:

explicit rules, structured execution, and dynamic flexibility without sacrificing consistency.

Light is still under active development, including its standard libraries, so its design will continue to evolve as the language grows.

Your thoughts and feedback are appreciated.

Explore Light on GitHub: GitHub Repository

Building the Light Programming Language: What I Learned After 9 Months

Aswin M Rajeev — Sun, 26 Jul 2026 07:45:28 +0000

A few days ago, I shared the first public release of Light, a programming language I've been designing and developing over the past nine months.

Rather than introducing the language again, I wanted to share one of the biggest lessons I learned while building it.

Before diving into that, here's a small example written in Light.

user

Purpose Add[a,b]
{
    sum = a + b
    out:sum
    stop
}

x = 23
y = 34

out="'Add{x,y}'"

Before implementing the first working version of Light, I documented the core concepts, language rules, and the initial specification. At that stage, I believed the primary challenge would be transforming those ideas into a working implementation.

Development reinforced just how inherently iterative language design is.

As implementation progressed, practical experimentation exposed interactions that weren't immediately apparent during the initial design. Some features evolved, certain language rules were refined, and additional capabilities were introduced as the language matured. At the same time, performance, error reporting, and the implementation itself were continuously improved through repeated testing and refinement.

One observation became increasingly clear throughout the project:

The specification shapes the implementation, but the implementation also helps refine the specification.

Looking back, building a programming language has been as much about evaluating and refining design decisions as it has been about writing code. Every iteration strengthened the language, improved its consistency, and reinforced the foundation established by the current public release.

This release represents an important milestone in the development of Light. While there is still much to explore and refine, it establishes the foundation on which the language will continue to evolve.

Your feedback and insights are always appreciated.

If you're new to Light, you can read the introduction to the project here:
Introducing Light — A New Programming Language:

https://dev.to/aswinmrajeev/introducing-light-a-new-programming-language-ghd

To learn more about Light and explore its documentation, visit the official GitHub repository.

Official GitHub Repository:

https://github.com/aswinmrajeev/light

Introducing Light — A New Programming Language

Aswin M Rajeev — Sat, 18 Jul 2026 16:39:04 +0000

Over the past 9 months, I've been designing and developing Light, a programming language with the long-term vision of making script automation more structured, consistent, and easier to build and maintain.

The idea behind Light began with a simple question: what would a programming language designed around structured program organization and predictable execution look like? That question evolved into designing the language specification, defining its syntax and execution model, implementing the interpreter, and building the foundation of its ecosystem.

This first public release marks an important milestone. It includes the core language and two standard libraries, establishing the initial foundation of the project. Light is under active development, with additional language features, standard libraries, and developer tooling planned for future releases.

I'm sharing this first public release to introduce the project and gather feedback from the developer community. I'd appreciate your thoughts on the language design, syntax, documentation, and overall developer experience.

Hello Light

user

name = _Light_

out="Hello 'name'"

GitHub

https://github.com/aswinmrajeev/light