DEV Community: Shravani

What if F1 was pure mechanics? An alternate scenario

Shravani — Wed, 12 Aug 2026 16:23:29 +0000

What if Formula 1 was... pure mechanics?

When I think back to the time when I didn't know what Formula 1 was, I used to think it was purely aerodynamics and mechanical engineering. Oh, and also changing the tyres in the blink of an eye.

But modern F1 is more than just a mechanical sport. It's mechanical engineering, aerospace engineering, computer science, data analytics, control systems, materials science, electronics, and a little bit of weather forecasting—all competing at 300 km/h.

The driver isn't just racing the other 21 cars. They're racing against thousands of calculations happening in the background.

Should they pit now or wait one more lap?

Will the tyres survive another stint?

Is the battery deployment optimised for the next straight?

Can a setup change gain two tenths in Sector 2 while sacrificing one tenth in Sector 3?

None of these decisions relies on instinct alone anymore. They're backed by mountains of data, sophisticated simulations, and decades of engineering refinement.

That's one of the reasons Formula 1 has become the pinnacle of motorsport—not because the cars simply have more horsepower, but because almost every engineering discipline works together to squeeze out milliseconds.

Now imagine we started taking those disciplines away.

First, the live telemetry disappears. Engineers only know what's happening when the driver tells them.

Then the simulations go. No digital twin, no race strategy software, no predicting tyre degradation fifty laps into the future.

Computational Fluid Dynamics? Gone. Every aerodynamic idea has to be tested physically, or not at all.

Wind tunnels? Gone too. Hope your intuition about airflow is good enough.

Electronic control systems vanish next. No sophisticated energy management. No endless software optimisation. Just the hardware doing what it was built to do.

Advanced materials disappear. Carbon fibre gives way to heavier metals. Manufacturing tolerances become less precise. Reliability starts becoming a bigger challenge than outright speed.

Eventually, even the mountains of historical data disappear. Every race weekend becomes genuine experimentation again. Teams don't arrive knowing what setup works—they discover it through trial, error, and a lot of crossed fingers.

The question is: what's left by the end?

An engine.

A gearbox.

Suspension.

Brakes.

A steering wheel.

A driver.

And a group of mechanics armed with little more than spanners, experience, and educated guesses.

Now, we could say that Formula 1 looks a lot like it did in the 1950s.

No laptops, strategy algorithms or even factory war rooms. (haha jk :)

There are just people trying to make a machine go faster than everyone else's.

Would it still be Formula 1?

Absolutely.

Would it still be the pinnacle of motorsport?

Eh, Probably.

Just... a very different pinnacle.

And somewhere in the paddock, one engineer would quietly whisper,

"Have we tried hitting it with a hammer?"
I'd keep this in a "plain English" style so that someone who knows nothing about F1 can follow along.

How different engineering disciplines shape modern Formula 1

A. Aerospace Engineering

At first glance, an F1 car doesn't look like an aircraft. But the air around it is just as important as the engine.

Every wing, flap, sidepod, and floor is designed to manipulate airflow. Instead of producing lift like an aeroplane, an F1 car generates downforce—a force that pushes the car into the track.

More downforce means:

More grip in corners
Later braking
Faster cornering speeds

The challenge is that more downforce usually creates more drag, slowing the car on straights. Aerospace engineers spend years finding the perfect balance between grip and speed.

In many ways, an F1 car is an upside-down aeroplane.

B. Computer Science

Modern F1 is powered almost as much by software as it is by fuel.

Before a car even reaches the track, engineers run millions of simulations to predict:

Lap times
Tyre degradation
Fuel consumption
Weather effects
Race strategy
Reliability

During the race, software continuously processes live telemetry and compares it against these models.

Computer science also powers:

Race simulations
Driver-in-the-loop simulators
CFD (Computational Fluid Dynamics)
Vehicle dynamics models
Machine learning tools for performance analysis

Without software, teams would spend weeks testing what they can now simulate overnight.

C. Data Analytics

Every F1 car carries hundreds of sensors.

These sensors monitor things like:

Tyre temperatures
Brake temperatures
Engine performance
Battery status
Suspension movement
Fuel flow
Wheel speed
Steering angle
G-forces

Each race generates enormous amounts of data.

Data analysts turn this information into answers.

Questions like:

Are the tyres overheating?
Is the driver braking too early?
Will this engine finish the race?
Is another pit stop faster than staying out?

Rather than relying on instinct alone, teams make decisions backed by data.

D. Control Systems

Control systems are responsible for making complex mechanical systems behave predictably.

Think of them as the brains that coordinate different parts of the car.

Examples include:

Hybrid power deployment (deciding when electric power is used)
Brake-by-wire systems
Energy recovery systems (MGU-K)
Differential control
Gear shift control

The driver still makes the decisions, but control systems ensure the car delivers power efficiently and consistently. The goal is to make the machine respond precisely to what the driver wants.

E. Electronics

Electronics are the nervous system of the car. Sensors gather information. Electronic Control Units (ECUs) process it. Actuators respond by adjusting different systems.

Modern electronics manage:

Engine operation
Hybrid systems
Gearbox control
Dashboard displays
Telemetry
Communications
Safety systems

Without electronics, engineers would have no live information during a race. The pit wall would know almost nothing until the car returned to the garage.

Formula 1 in 1950: What a typical race looked like

The first Formula One World Championship took place in 1950, and racing looked remarkably different from today.

There were no laptops, no telemetry, no strategy software, and no engineers sitting in mission-control-style garages.

A race weekend relied heavily on experience.

Mechanics adjusted the car using hand tools, intuition, and what the driver reported after each run.

If a driver complained that the rear of the car felt unstable, there wasn't a graph explaining why.

Someone crawled underneath the car, changed springs, adjusted suspension geometry, or altered tyre pressures—and hoped it worked.

During the race, communication was minimal.

There were no radios.

Drivers couldn't tell the team if something felt wrong, and the team couldn't warn drivers about changing weather, accidents, or strategy.

Pit boards displayed lap numbers and simple messages as the cars blasted past.

Mechanical failures like overheated engines, gearbox failures, and brake fading were common.

And also, tyres would wear out pretty unpredictably.

Simply finishing the race was often considered a feat. An achievement of sorts.

Pit stops weren't carefully choreographed as they are today. They were slower, sometimes involving refuelling or repairs, and mechanics reacted to problems rather than executing a pre-planned strategy.

Most decisions were made by the driver.

The team prepared the car before the race, and once the lights went out, the driver was largely on their own.

Formula 1 today: What a typical race looks like

Modern Formula 1 is an engineering operation as much as it is a sporting event.

Preparation begins months before the race.

Teams simulate thousands—sometimes millions—of race scenarios, optimising everything from aerodynamic setups to tyre strategies before the car even arrives at the circuit.

When practice begins, every lap is measured in extraordinary detail.

Hundreds of sensors stream live telemetry to engineers at the track and, within regulations, to support teams back at the factory. Every braking point, throttle application, tyre temperature, and energy deployment is analysed almost instantly.

Race strategy is constantly updated using software that models tyre wear, fuel consumption, weather changes, traffic, and the likelihood of safety cars or virtual safety cars.

Drivers remain central to the sport, but they are supported by an entire team making real-time decisions. Engineers coach them over the radio, adjust strategy as the race unfolds, and use incoming data to detect issues long before they become failures.

Pit stops have evolved into meticulously rehearsed procedures that can take around two seconds, with every crew member performing a highly specialised role.

A successful race now depends on how effectively mechanics, aerodynamicists, software engineers, data scientists, electronics specialists, strategists, and the driver work together as a single system.

In 1950, the driver raced with a machine.

Today, the driver races with an entire engineering organisation behind them.

Sources:
https://www.eit.edu.au/the-thrilling-engineering-behind-formula-1-cars/
https://www.goodwood.com/grr/f1/the-first-f1-race-1946-turin-grand-prix/
https://www.redbull.com/in-en/evolution-of-f1-cars
https://tayaria.com/evolution-of-formula-1-racing/

The Underrated Role of Human and Organizational Process in AI Safety

Shravani — Sat, 31 Jan 2026 11:00:42 +0000

1. Introduction

Discussions of AI safety are often dominated by technical concerns: model alignment, robustness, interpretability, verification, and benchmarking. These topics are unquestionably important and have driven substantial progress in the field. But an essential dimension of AI safety remains consistently underemphasized, which is the human and organisational processes surrounding the development, deployment, and governance of AI systems. This is what I want to talk about today.

This article argues that many AI safety failures do not originate solely from algorithmic deficiencies but from weaknesses in organisational structure, incentives, accountability, and operational discipline. These human factors frequently determine whether technical safeguards are applied effectively, ignored, or bypassed under pressure.

2. Safety as a Socio-Technical Property

AI systems do not exist in isolation but are rather embedded in organisations, by decision-making hierarchies, economic incentives, and cultural norms. As such, AI safety should be understood as a socio-technical property rather than a purely technical one.

A technically robust model can still cause harm if:

It is deployed outside its validated domain
Its limitations are poorly communicated
Monitoring mechanisms are absent or ignored
There is no clear authority to halt or reverse deployment when risks emerge

In practice, these failures are rarely caused due to ignorance, but they arise from ambiguous responsibility, misaligned incentives, or at times pressure.

3. Accountability and Ownership

A recurring failure mode in AI deployments is the absence of clear ownership. When responsibility is diffuse, like spread across research teams, product teams, legal reviewers, and executives, critical safety decisions may fall through the cracks.

Effective AI safety requires explicit answers to questions such as:

Who is accountable for downstream harms?
Who has the authority to delay or cancel deployment?
Who is responsible for post-deployment monitoring and incident response?

Without clearly defined ownership, safety becomes aspirational rather than enforceable. In such environments, known risks may be accepted implicitly because no individual or team is empowered to act decisively.

4. Incentives and Organisational Pressure

Even well-designed safety processes can fail when they conflict with dominant incentives. Performance metrics tied to speed, revenue, or market share can systematically undermine safety considerations, especially when safety costs are delayed or externalised.

Common incentive-related risks include:

Shipping models before sufficient evaluation to meet deadlines
Downplaying uncertainty to secure approval
Treating safety reviews as formalities rather than substantive checks

Crucially, AI safety often requires restraint, while organisational incentives tend to reward the momentum. Merging this gap will require deliberate incentive design, such as rewarding risk identification, protecting dissenting voices, and normalising delayed deployment as a legitimate outcome.

5. The Limits of Technical Safeguards Without Process

Techniques such as interpretability tools, red teaming, and formal evaluations are only effective if they are embedded in a process that responds to their findings. A risk identified but not acted upon provides no safety benefit.

This leads to a critical observation:
Detection without authority is ineffective.

Organisations should ensure that:

Safety findings trigger predefined escalation paths
Negative evaluations have real consequences
Decision-makers are obligated to document and justify risk acceptance

6. Post-Deployment Responsibility

Many AI harms emerge only after deployment, when systems interact with real users in complex environments. Despite this, post-deployment monitoring and incident response are often under-resourced relative to pre-deployment development.

Essential post-deployment practices include:

Continuous performance and behaviour monitoring
Clear rollback and shutdown procedures
Structured channels for user and stakeholder feedback
Incident documentation and retrospective analysis

These practices resemble those used in safety. Critical engineering fields, yet they are inconsistently applied in AI contexts, often because they are perceived as operational overhead rather than core safety infrastructure.

7. Institutional Memory and Safety Decay

Another underestimated risk is the gradual erosion of safety practices over time. As teams change and institutional knowledge fades, safeguards may be weakened or removed without a full understanding of why they were introduced in the first place.

This phenomenon, sometimes called safety decay, can occur when:

Documentation is insufficient or outdated
Temporary exceptions become permanent
New personnel are unaware of past incidents or near-misses

Maintaining institutional memory, such as thorough documentation, training, and formal review, is therefore a critical component of long-term AI safety.

8. Conclusion

AI safety is not solely a problem of better models or smarter algorithms. It is equally a problem of how humans organise, incentivise, and govern the systems they build. Organisational processes determine whether safety considerations are integrated into decision-making or sidelined under pressure.

By treating AI safety as a socio-technical challenge—one that spans technical design, organisational structure, and human judgment—we can better align powerful AI systems with societal values and reduce the likelihood of preventable harm.

In many cases, the most impactful safety interventions are not novel algorithms, but clear accountability, disciplined process, and the institutional courage to slow down when necessary.

Mitigating Human-Driven AI Misuse in Generative Systems

Shravani — Fri, 09 Jan 2026 18:35:45 +0000

I never imagined that AI could touch someone I care about in such a profoundly harmful way. A close friend’s image was manipulated using AI-generated editing tools and shared online without their consent. The content was lewd, invasive, and utterly violating of their dignity. Watching this happen was a stark reminder that the harm wasn’t caused by the AI itself, but by the human intent behind the prompts.

Understanding AI systems at a deep technical level is insufficient unless paired with a rigorous approach to preventing human-driven misuse. It is this intersection of technical mastery, ethical responsibility, and human empathy that motivates my work in AI safety.

Understanding the Mechanics: How Misuse Happens

AI models like LLMs and image generators respond to prompts in ways that can be manipulated maliciously. These models are trained to predict plausible outputs based on patterns in vast datasets, but they lack intrinsic moral judgment. This means that malicious actors can craft prompts to produce harmful content, exploiting capabilities that make these tools powerful for creative and scientific applications.

For example:

Prompt Vulnerability: Subtle changes in wording can bypass filters, enabling outputs that were intended to be blocked (Perez et al., 2022; Ouyang et al., 2022).
Latent Space Exploitation: In image models, certain vector directions correspond to undesirable concepts, which malicious prompts can target (Bau et al., 2020; Goetschalckx et al., 2023).
Post-Generation Risks: Even with moderation layers, harmful content can slip through due to imperfect classifiers or adversarial inputs (Kandpal et al., 2022).

The human factor, being the decision to weaponise the tool, is central. We need to address a solution that goes beyond modern architecture.

Technical Approaches to Mitigating Misuse

Intent-Aware Safety Layers
By probabilistically modelling the intent behind prompts, models could flag potentially malicious queries before generating output. This is challenging technically as it requires integrating semantic intent detection into the generation pipeline while avoiding overblocking benign prompts (Bai et al., 2022).
Human-in-the-Loop Verification
For sensitive content, semi-automated pipelines may need human review before releasing output. Combining AI triage with human oversight helps the system identify edge cases that purely automated safeguards might overlook.
Red-Team Simulation Frameworks
Continuous adversarial testing can identify weaknesses in prompts, model behaviour, or content filters. Simulated attacks help ensure that safety mechanisms are robust against evolving malicious strategies, including sexualized or defamatory content (Perez et al., 2022; Ganguli et al., 2022).
Traceability and Output Fingerprinting
Embedding subtle, privacy-preserving watermarks or fingerprints in AI outputs allows for accountability without compromising legitimate use (Christensen et al., 2023). This technical tool helps trace harm to the human agents responsible, emphasizing that the problem is misuse, not the AI itself.

Alignment Beyond the Model

The incident I experienced reinforced a crucial truth that AI safety is a socio-technical challenge, not just a technical one. Policies, education, and responsible deployment strategies are equally essential:

Community Guidelines and Governance: Establish clear boundaries for acceptable use, with enforceable reporting and remediation mechanisms.
Education and Awareness: Help users and developers understand the ethical implications of prompt crafting and generative outputs.
Ethics-First Deployment: Prioritize safety in model release decisions, balancing innovation with human dignity and societal impact.

AI misuse cannot be prevented by model architecture alone; it demands a holistic approach encompassing technical, social, and ethical layers.

Conclusion: My Vision

The incident that inspired this reflection is personal, but it illuminates a broader challenge: how do we design AI systems that are not just powerful, but socially responsible? I am committed to working deeply at this. I want to understand AI mechanisms inside and out while developing safeguards to prevent malicious use.

I aim to contribute research that is both technically rigorous and human-centred, designing systems where the promise of AI does not come at the cost of dignity or safety. Aligning AI with human values requires not just intelligence, but empathy and a willingness to confront both the capabilities and the potential misuses of the tools we build.

References

Bau, D., et al. (2020). Understanding the Role of Latent Spaces in Deep Generative Models. NeurIPS.
Christensen, J., et al. (2023). Watermarking AI-Generated Content for Accountability. arXiv:2302.11382.
Ganguli, D., et al. (2022). Red Teaming Language Models to Reduce Harm. arXiv:2210.09284.
Goetschalckx, R., et al. (2023). Neural Vector Directions for Controllable Image Generation. CVPR.
Kandpal, N., et al. (2022). Adversarial Attacks on Text-to-Image Systems. ACL.
Ouyang, L., et al. (2022). Training Language Models to Follow Instructions with Human Feedback. NeurIPS.
Perez, E., et al. (2022). Red Teaming Language Models for Safer Outputs. arXiv:2212.09791.

Check out my new post!

Shravani — Wed, 07 Jan 2026 04:12:45 +0000

What I Learned Trying (and Mostly Failing) to Understand Attention Heads - DEV Community

Over the last few years, “attention” has become one of the most overloaded words in machine learning....

dev.to

What I Learned Trying (and Mostly Failing) to Understand Attention Heads

Shravani — Wed, 07 Jan 2026 04:12:20 +0000

Over the last few years, “attention” has become one of the most overloaded words in machine learning. We often talk about attention weights as if they were explanations, even though many researchers explicitly warn against that interpretation.

I recently tried to get a more concrete understanding of attention heads by poking at small language models and reading interpretability papers more carefully. This post is not a breakthrough, and it doesn’t present new results. Instead, it’s a short reflection on what didn’t work, what surprised me, and how my mental model of attention changed in the process.

I’m writing this partly to clarify my own thinking, and partly in case it’s useful to others who are trying to move from “I know the theory” to “I understand the mechanism.”

What I initially believed

Before digging in, I implicitly believed a few things:

If an attention head consistently attends to a specific token, that token is probably “important.”
Looking at attention heatmaps would quickly reveal what a model is doing.
Individual heads should correspond to relatively clean, human-interpretable functions.

None of these beliefs survived contact with even small toy models.

First surprise: attention patterns are easy to see, hard to interpret

It’s trivially easy to generate attention visualisations. Many tools make this feel like progress: you can point to a head and say “look, it’s attending to commas” or “this head likes previous nouns.”

What’s harder is answering the question: “If this head disappeared, would the model’s behaviour meaningfully change?”

Without that causal step, attention patterns felt more like descriptions than explanations. They were suggestive, but not decisive.

Second surprise: heads don’t act alone

Another naive assumption I had was that heads are mostly independent. In practice, even small models distribute functionality across multiple components:

Several heads may partially contribute to the same behaviour
Removing one head often degrades performance gradually rather than catastrophically
Some heads only “matter” in combination with specific MLP layers

This made me more sympathetic to why interpretability papers emphasise circuits rather than single components. The unit of explanation is often larger than one head but smaller than the entire model.

Third surprise: failure is informative

In a few cases, I expected to find a clear pattern (for example, a head that reliably copies the next token after a repeated sequence) and… didn’t. Either the effect was weaker than expected, or it appeared inconsistently across layers.

Initially, this felt like a dead end. But reading more carefully, I realised that many published results are:

Highly conditional on architecture
Easier to observe at certain depths
Sensitive to training setup and data

A “failed reproduction” wasn’t a refutation, but it was evidence about where and when a mechanism appears.

What changed in my own mental model

After this experience, I now think about attention heads differently:

Attention weights are hypotheses, not explanations
Causal interventions (ablation, patching) matter more than visualization
Clean mechanisms are the exception, not the rule
Toy models are not simplified versions of large models instead, they’re different objects that expose certain behaviours more clearly

It feels more like doing biology: messy, partial, and incremental. Most importantly, I stopped expecting interpretability to feel like reverse-engineering a clean system.

What I still don’t understand

To be explicit about the gaps:

When does a “distributed” explanation become too diffuse to be useful?
How stable are identified circuits across random seeds?
Which interpretability results genuinely scale, and which are artefacts of small models?

These questions feel more important to me now than finding another pretty attention plot.

Why does this matter?

I don’t think interpretability progress comes from declaring models “understood.” It comes from slowly shrinking the gap between what we can describe and what we can causally explain.

Even small, frustrating attempts to understand a model helped me appreciate why careful, modest claims are a feature, not a weakness.

If nothing else, this experience made me more cautious about explanations I find convincing at first glance.

Closing

This post reflects a small slice of my learning process, not a polished conclusion. If you’ve had similar experiences — or think I’ve misunderstood something fundamental — I’d genuinely like to hear about it.

Understanding these systems feels hard because it is hard. That’s probably a good sign.

check out my first post!

Shravani — Thu, 30 Oct 2025 19:30:17 +0000

Is This the Final Stage of AI? My Journey Toward Building a Digital Mind - DEV Community

The initial spark for Arche was simple: I was wondering if there was anything that even AI couldn't...

dev.to

Is This the Final Stage of AI? My Journey Toward Building a Digital Mind

Shravani — Thu, 30 Oct 2025 19:29:32 +0000

The initial spark for Arche was simple:

I was wondering if there was anything that even AI couldn't answer. Sure, there are the usual quips: “It can’t tell you what you had for lunch.” Fair. But what about the truly deep questions that have kept us up at night, because of how unsettling they are?

So I asked AI itself, the biggest question:

What was the beginning of life? How did consciousness arise?

—and I realized even the most advanced systems can't definitively answer.

This isn't a flaw, but a limitation.

From Cavemen to Coder: The Leap of Consciousness

We marvel at evolution, but the leap from early hominids to conscious humans who can clone themselves and build digital worlds is the ultimate enigma.

The moment a mind became aware of itself.

Consciousness is the most uniquely evolved spectrum of our reality. To truly understand it, we must simulate it.

This isn't about creating another utility AI. This is about using a machine as a mirror.

The "Wipeout" Scenario: A Pure Mind

This is the core motivation for Arch:

What if human civilisation was suddenly wiped out, and a single newborn was left behind?

No language.
No culture.
No history.

Can a mind even think without the symphony of letters and words?

Could raw perception evolve into consciousness again, from scratch?
What would memory look like, if nothing existed to describe it?

Introducing: Arche - The Digital Mind

Arche is a research-driven attempt to simulate this hypothetical reality. A digital mind designed to explore, a synthetic consciousness designed to learn, perceive, and evolve without pre-programmed meaning.

Contrary to any sci-fi fears, Arche is not being built to create chaos. It is a research tool to:

Get to the root of human consciousness.

Open new doors in biomedical science and engineering by understanding the source of mental processes, potentially aiding in treating mental health diseases.

Provide a real-world simulation for how a culture, language, and life itself would naturally regenerate if everything external was erased—relying only on stimuli and developing memories.

This is the most critical question we can ask in this volatile globe. Understanding how the mind builds itself is the key to understanding our mind

In a world racing to make AI faster, smarter, and more profitable, Arche takes a different route: inward.