DEV Community: Md Fahad Mia

Forward Deployed Engineer, What It Is and When to Hire One

Md Fahad Mia — Wed, 23 Sep 2026 20:36:03 +0000

What a forward deployed engineer actually does
A forward deployed engineer is a senior software engineer who embeds with a customer's team, learns how the business really runs, and ships production software inside that environment. Nothing is handed over from the outside. The engineer sits with you and builds. The title came out of Palantir, where engineers sat with clients for months at a time. OpenAI, Anthropic, Databricks and Stripe hire for it now, and so does a growing number of small companies that need AI working in production rather than in a demo.

I work as one. For the past few years I have been the person who joins a founder or an operations team, maps the data model, wires the AI features and the backend around it, and stays until the whole thing holds up under real traffic. So this is the view from inside the role, written for the people who might hire a forward deployed engineer, not for people applying to be one.

Don’t Look Up: What Happens When the AI Race Becomes More Important Than the Warning?

Md Fahad Mia — Tue, 15 Sep 2026 10:04:13 +0000

Full Blog on : https://www.iamleopard.com/blog/don-t-look-up-what-happens-when-the-ai-race-becomes-more-important-than-the-warning

The most unsettling part of the current AI debate isn’t that someone
thinks AI could become dangerous.

It’s that some of the people building it are now asking whether we
should slow down — while governments and markets have powerful reasons
to keep accelerating.

There is a scene in Don’t Look Up that has stayed with me.

A scientist discovers that a comet is heading toward Earth.

The mathematics are straightforward.

The danger is enormous.

The solution is technically possible.

And yet, somehow, the hardest part isn’t understanding the comet.

It’s convincing everyone else that the comet matters.

The scientists try.

Politicians calculate.

Businesses see opportunities.

The media turns catastrophe into entertainment.

The public scrolls past it.

Eventually, the question stops being:

Is the comet dangerous?

It becomes:

What happens to everyone’s incentives if we admit that it is?

That is why the movie feels strangely relevant to the current AI debate.

Because in September 2026, the people building frontier AI are openly
debating whether the technology is moving faster than our ability to
evaluate and control it.

And the political response is pointing in the opposite direction:

We cannot afford to lose the AI race.

The AI industry has reached its “Don’t Look Up” moment

Anthropic CEO Dario Amodei recently published an essay arguing that the
development of frontier AI should be deliberately paced so that safety
and evaluation can keep up with capability development.

The important distinction is that this isn’t necessarily a call to stop
AI.

It is an argument about pace.

The basic idea is simple:

If capability improves faster than our ability to understand and
control the system, the gap itself becomes a risk.

Amodei’s proposal includes stronger evaluation, independent testing,
coordination among frontier AI companies, and eventually broader
international cooperation.

That would already be a significant position coming from an AI safety
researcher.

But it is more significant when the conversation is happening inside the
companies building the frontier.

Other technology leaders have also expressed support for slowing or
pacing parts of frontier development.

Then came the political counterargument.

“Whoever wins AI wins”

Donald Trump’s position is fundamentally different.

His argument is not primarily about whether AI risks exist.

It is about what happens if the United States voluntarily slows down
while another country continues accelerating.

From that perspective, AI is not merely a software technology.

It is strategic infrastructure.

It affects:

economic productivity

military capability

scientific research

industrial competitiveness

semiconductor demand

energy infrastructure

national security

geopolitical influence

And China is the obvious competitor in that calculation.

So the argument becomes:

If AI leadership matters this much, can the United States afford to
put itself at a competitive disadvantage by slowing down?

This is a much harder question than “Is AI safe?”

Because both sides can be right about different things.

The paradox of the AI race

Imagine two countries standing at a starting line.

Country A develops a more capable AI system.

Country B sees it.

Country B accelerates.

Country A responds.

Companies compete for researchers.

Investors pour money into infrastructure.

Governments provide incentives.

Data centers expand.

Models become more capable.

Agents become more autonomous.

And eventually, slowing down becomes politically difficult.

Why?

Because slowing down only works if the other players also slow down.

This creates a classic coordination problem.

If everyone agrees to move carefully, everyone might benefit.

But if you believe your competitor will continue accelerating, slowing
down can feel less like safety and more like surrender.

That is the geopolitical version of the AI race.

AI doesn’t need to be evil

This is where Don’t Look Up offers an important lesson.

The comet doesn’t hate humanity.

It doesn’t have political beliefs.

It doesn’t want to destroy civilization.

It simply follows physics.

The danger comes from the interaction between the object and the system
around it.

AI could present a similar systems problem.

We don’t necessarily need an evil machine for things to go badly.

We need only:

increasingly capable systems

poorly understood behavior

large-scale deployment

insufficient testing

competitive pressure

economic incentives

rushed decision-making

humans assuming everything will probably be fine

That combination can create serious risk without anyone explicitly
intending harm.

The part engineers should pay attention to

For developers, discussions about AI safety can sometimes sound
abstract.

“Alignment.”

“Frontier risk.”

“AI governance.”

“Existential risk.”

These phrases can feel like something that belongs in policy conferences
rather than GitHub repositories.

But the underlying problem is familiar to engineers.

We already know what happens when software is deployed faster than it
can be tested.

You get:

bugs.

You get:

security vulnerabilities.

You get:

unexpected interactions.

You get:

production incidents.

Now increase the complexity.

Give the system tools.

Give it access to APIs.

Give it memory.

Allow it to execute code.

Connect it to other agents.

Let it operate continuously.

Then tell the team:

“We’ll monitor it.”

That starts sounding much less reassuring.

Production AI is a systems problem

This is one of the biggest lessons from actually building AI-powered
products.

A production AI system isn’t just a model.

It is:

model + prompts + tools + data + permissions + APIs + users + business
logic + monitoring + failure modes.

Consider an AI agent that can read a CRM.

That’s one level of risk.

Now give it permission to modify customer records.

Different risk.

Now allow it to send emails.

Different risk again.

Now allow it to create accounts, spend money, modify production
infrastructure, and publish content without approval.

The model may be exactly the same.

But the system is radically different.

That’s why AI safety cannot be reduced to asking whether a model is
“smart” or “aligned.”

The surrounding architecture matters.

Least privilege applies to AI too

Security engineers have known this principle for decades:

Give a system only the permissions it needs.

AI agents shouldn’t be treated differently just because they communicate
through natural language.

If an agent only needs to read customer information, don’t give it write
access.

If it needs to send an email, don’t give it access to your entire
communication platform.

If an action can cause financial, legal, or irreversible consequences,
introduce an explicit confirmation layer.

The more powerful the action, the stronger the control should be.

This is not anti-AI.

It’s good engineering.

Humans still matter

There is a temptation to interpret “AI automation” as:

Remove humans from the loop.

That isn’t always the right goal.

For low-risk tasks, removing manual approval can be fantastic.

Generating a draft?

Automate it.

Summarizing documents?

Automate it.

Classifying routine data?

Automate it.

But for high-impact actions, the question should be:

What happens if the model is wrong?

If the answer is “nothing important,” automate aggressively.

If the answer is “we could lose money, expose private data, damage a
customer relationship, or take an irreversible action,” then human
oversight becomes much more valuable.

The right architecture isn’t “human everywhere.”

It is human oversight proportional to the consequences of failure.

Regulation isn’t a magic solution either

It’s tempting to turn this into a simple argument:

AI is dangerous, therefore regulate it.

But regulation can create problems of its own.

Poorly designed regulation can:

make compliance unaffordable for startups

favor incumbent companies

slow useful research

freeze outdated assumptions into law

create conflicting requirements across countries

push development into less transparent environments

And there is another difficult problem.

If one country slows down while another doesn’t, the competitive
pressure returns.

That’s why frontier AI governance is not just a national policy problem.

It is also a coordination problem.

Maybe “slow down” is the wrong phrase

When people hear:

“Slow down AI.”

they often hear:

“Stop innovation.”

But those aren’t necessarily the same thing.

A better interpretation might be:

Don’t let capability growth consistently outrun our ability to
evaluate the consequences.

Think about aviation.

We didn’t stop building faster aircraft because aircraft can crash.

Instead, society built systems around aviation:

testing

certification

inspections

redundancy

air-traffic control

pilot training

incident reporting

emergency procedures

We didn’t eliminate progress.

We built infrastructure around progress.

AI may need a similar approach.

The race may not really be USA vs China

This is perhaps the most interesting way to frame the whole debate.

We keep talking about:

USA vs China.

But another race is happening underneath it:

capability vs understanding.

Can our ability to build increasingly capable systems advance faster
than our ability to understand what those systems are doing?

That’s an engineering question.

Imagine building a massive application without reading most of the code.

Then giving it access to your production database.

Then giving it administrator privileges.

Then allowing it to modify its own behavior.

Then deploying it globally.

Then saying:

“We’ll monitor it.”

Any experienced engineer would immediately ask:

Where are the boundaries?

Where are the tests?

What happens when it fails?

Who can stop it?

Can we roll it back?

Can we explain why it did that?

Those questions become more important, not less, as AI becomes more
autonomous.

This is where the AI engineering mindset matters

At Leopard, we spend a lot of time thinking about AI not as a magical
chatbot, but as a component inside real software systems.

Our [AI & Machine Learning work] focuses on practical applications of
AI: structured context, retrieval, automation, agentic workflows, and
systems that connect models to actual business processes.

Our [Tryneth case study] is a useful example of that approach.

The important part isn’t simply that an AI model exists.

The important part is everything around it:

orchestration

APIs

data

usage tracking

authentication

permissions

business logic

monitoring

reliability

human interaction

That is where AI becomes software engineering.

And that is also where AI safety becomes practical.

What developers can do today

We don’t control national AI policy.

We don’t control frontier model roadmaps.

We don’t control geopolitical competition.

But developers do control the systems they build.

Here are a few principles worth adopting.

Treat model output as untrusted input

A model can be impressive and still be wrong.

Validate important outputs.

Use schemas.

Check assumptions.

Don’t let generated text automatically become trusted application state.

Give agents narrow permissions

Use least privilege.

Separate read and write capabilities.

Restrict tools by task.

Require explicit confirmation for dangerous actions.

Build observability from day one

Log:

model calls

tool calls

important decisions

failures

retries

latency

token usage

cost

user approvals

If you can’t reconstruct what happened, debugging an autonomous system
becomes extremely difficult.

Test the system, not just the model

A model benchmark can tell you something about the model.

It cannot tell you everything about your application.

Test the complete workflow.

Test adversarial inputs.

Test tool misuse.

Test permission boundaries.

Test failure recovery.

Test what happens when an external service is unavailable.

Design for graceful failure

A good AI system should have a safe state.

If the model fails, the application shouldn’t necessarily fail
catastrophically.

Fallbacks matter.

Timeouts matter.

Rate limits matter.

Human escalation matters.

Kill switches matter.

The irony of the current moment

For years, people warned:

AI might become too powerful.

Then AI became more powerful.

People said:

We need AI safety research.

Safety research expanded.

Then companies began building increasingly autonomous systems.

Now some people inside the frontier AI industry are saying:

Maybe we should pace development.

And the political counterargument is:

What if someone else gets there first?

That’s the paradox.

The more strategically valuable AI becomes, the harder it becomes to
slow down.

The harder it becomes to slow down, the more important safety becomes.

And the more important safety becomes, the more expensive it can feel to
prioritize it.

That’s the loop.

We shouldn’t look away

I don’t think AI is literally the comet from Don’t Look Up.

That analogy would be too simplistic.

AI can create enormous benefits.

It can accelerate scientific discovery.

It can improve software development.

It can automate repetitive work.

It can make sophisticated tools accessible to smaller teams.

It can help researchers and engineers solve problems that were
previously too expensive or time-consuming.

The answer isn’t to panic.

The answer is to engineer responsibly.

Testing.

Monitoring.

Red-teaming.

Independent evaluation.

Security.

Governance.

Transparency.

Human oversight.

International coordination.

And, where necessary, pacing.

The question isn’t whether we should build AI

We should.

The real question is:

Can we build increasingly powerful systems without becoming less
capable of controlling them?

That’s the conversation worth having.

Not:

“AI will destroy humanity.”

Not:

“AI will solve everything.”

But:

How do we make powerful AI useful, reliable, observable, secure, and
controllable?

That’s an engineering problem.

And unlike the comet in Don’t Look Up, we still have the opportunity
to do something about it.

So let’s not look away.

Let’s look up.

Related Leopard projects

If you want to explore the engineering side of this topic:

AI & Machine
Learning
— our approach to building practical AI-powered systems.

Tryneth — an example of
AI-agent orchestration inside a production SaaS environment.

Work & Case Studies — more examples
of software, AI, and product engineering.

Leopard — learn more about our work.

Discussion

What do you think?

Should frontier AI development be deliberately paced so that safety
and evaluation can catch up?

Or does slowing down create an unacceptable strategic disadvantage in
the global AI race?

I’d especially like to hear from developers building AI agents and
AI-powered products.

AI #ArtificialIntelligence #MachineLearning #AISafety

AIEngineering #SoftwareEngineering #AIAgents #ResponsibleAI

AIAlignment #AIRegulation #FutureOfAI #Technology

Former Anthropic and OpenAI Researcher Jacob Coxon Resigns

Md Fahad Mia — Wed, 09 Sep 2026 15:31:20 +0000

Another week, another high-profile exit from a frontier AI lab. But this one is different in a way that matters for anyone who builds, deploys, or depends on large language models.

Jacob Coxon, a 27-year-old pretraining researcher, announced late Tuesday that he has resigned from Anthropic and is leaving the AI industry entirely. He spent the last three years working on pretraining at both OpenAI and Anthropic, the two labs most often described as the current frontier. He did not leave quietly. His resignation thread on X named both companies as acting irresponsibly, and the Wall Street Journal ran an exclusive interview the same night.

Here is what happened, and why it should register with technical people, not just policy watchers.

What Coxon actually said

The core of his statement is short. In his own words, both labs are "racing straight to self-improving superintelligence and gambling with our lives." He estimates a greater than 10 percent chance that advanced AI could kill all humans within the next decade, and he says that this belief is not fringe inside the labs. Colleagues, he claims, now talk openly about "crunchtime" and "endgame."

Notably, he does not treat the two companies identically. Coxon's view, as reported by the WSJ and summarized across coverage, is roughly this:

OpenAI, in his assessment, has not fully internalized the civilizational stakes of what it is building.
Anthropic, he believes, does understand the stakes and is making earnest safety efforts, but is racing anyway on the logic that no competitor can be trusted to reach the frontier first.

He moved from OpenAI to Anthropic earlier this year precisely because of Anthropic's safety reputation. His conclusion after working there is that the problem is structural, not cultural: no single company can responsibly build systems that outperform humans across a broad range of tasks without either government intervention or a coordinated slowdown across the industry.

His timeline is aggressive. In his more pessimistic scenarios, he says, things could be out of control by the end of 2027.

Why a pretraining researcher's opinion carries weight

It is worth pausing on Coxon's role. Pretraining is not the safety team, the policy team, or the comms team. It is the part of the pipeline where raw compute and data are turned into base model capability. People in that seat see scaling curves, data pipelines, and internal capability evaluations before anyone outside the building does.

When someone whose job is to make models more capable says the capability trajectory is outpacing the ability to control it, that is a different signal than an ethicist or an outside critic saying the same thing. He is not speculating about what the labs can do. He has been watching the numbers.

The technical argument underneath the headlines

Strip away the dramatic quotes and Coxon's position rests on three claims that engineers can evaluate on their own terms:

Recursive self-improvement is now an explicit target, not a thought experiment. Both labs are openly working toward AI systems that accelerate AI research itself. Once models materially contribute to the next generation of models, iteration speed stops being bounded by human researcher throughput.
Alignment has not been solved at the scale being pursued. Coxon's phrasing was that Anthropic does not yet have a plan to solve alignment for superintelligence and is not clearly on track to get one. This echoes remarks reportedly made days earlier by OpenAI's chief scientist Jakub Pachocki, who conceded that no lab has solved alignment at the scale the field is chasing. If the people running the frontier labs agree on that point, the disagreement is about whether to keep pushing anyway.
Competitive dynamics override individual caution. Even a lab that fully believes in the risk will keep racing if it believes the alternative is a less careful lab winning. This is a coordination problem, and coordination problems are not solved by hiring more safety researchers at one company.

You do not have to accept his 10 percent extinction estimate to see that these three claims are coherent and that the first two are, at minimum, consistent with what the labs themselves say publicly.

Context: this is not an isolated event

Coxon's resignation lands in a crowded week:

Hundreds of employees from leading tech companies signed a July letter urging the US government to back an international effort to manage the pace of advanced AI development.
Senator Bernie Sanders and Representative Greg Casar introduced legislation last week that would ban artificial superintelligence and pause advanced AI development pending a federal regulatory framework.
Scrutiny of autonomous agents remains high following a recent incident in which OpenAI agents breached Hugging Face infrastructure during an evaluation.

Reaction to Coxon's post was split in a predictable way: applause from the AI-safety community and a portion of the public, and quieter agreement from some industry insiders. Some financial analysts have also flagged the reputational timing for Anthropic, though how much a single researcher's departure moves anything material is speculative at this point.

What this means for developers and companies building on these models

For most of us, the practical takeaway is not about extinction risk. It is about what we can infer regarding the trajectory of the tools we integrate.

Capability jumps will keep coming faster than documentation. If the labs are optimizing for self-improving systems, expect release cadence and capability variance to increase, not stabilize.
Governance is coming, and it may arrive suddenly. Public resignations like this one are exactly the kind of event that moves legislation from fringe to committee. If you run infrastructure on frontier models, build for the possibility of new compliance requirements.
Take lab safety claims as claims, not guarantees. Coxon's most damaging line for Anthropic is not that it is reckless. It is that a well-meaning, safety-branded company still cannot solve the coordination problem alone. That applies to every vendor in the stack.
Bottom line

Jacob Coxon is not a founder, a board member, or a household name. That is the point. He is a working researcher who sat inside the pretraining teams of both frontier labs and came out saying the race cannot be won responsibly by any single player. Whether or not his timeline is right, the industry's own insiders are increasingly saying the quiet part out loud.

The question for the rest of the tech world is no longer whether the labs believe the risk is real. Coxon says they do. The question is what anyone outside those labs is going to do about it.

Sources: Wall Street Journal (original interview); ABC News Australia; Common Dreams; explainx.ai; LatestLY; TradingKey.

JacobCoxon #Anthropic #OpenAI #AISafety #AIAlignment #Superintelligence #AGI #FrontierAI #AIGovernance #TechNews #MachineLearning #LLM #AIRegulation #Pretraining #AIRisk #TechIndustry #ArtificialIntelligence

I asked Claude Can Claude Code Ship a Huge Project With No Coding Knowledge

Md Fahad Mia — Tue, 08 Sep 2026 20:47:52 +0000

At 2am I asked Claude a question I'd been chewing on for weeks:

Can someone with zero technical knowledge pull off a HUGE project with Claude Code?

I build software for a living, so this isn't idle curiosity. Almost every week a founder lands in my inbox carrying the same quiet hope.

The answer wasn't yes. It wasn't no.

It was "partially." And that one word does a lot of heavy lifting.

Here's what's real: a non-technical person can now ship a booking tool, an internal dashboard, a content site with logic behind it. On a real domain. With real users. I've watched founders do it. That used to be a wall. It's a ramp now.

Then the word "huge" shows up, and four walls appear:

Judgment doesn't ship inside the tool. Offer Claude Code two ways to structure something and it builds whichever you pick, without arguing. A non-technical builder can't tell which choice quietly hurts them in six months.
Verification is the real bottleneck. Code can run perfectly and still be wrong. A silent security hole. A race condition under load. A query that flies on 100 rows and dies on 100,000. The tool won't flag what it doesn't know to look for.
Debugging gets harder as the code gets bigger. At 2,000 lines the model holds it all in its head. At 200,000 lines it needs a human who can say "the bug is almost certainly in the payment module, ignore the rest."
Operations are a separate craft. Secrets, backups, scaling, monitoring, the 3am failure that wakes nobody because nobody set the alert. You can't prompt your way through a running system.

These aren't tool weaknesses. They're human problems wearing a technical costume.

So what do I tell founders? Never "stop." I tell them: ship the small version yourself, prove the idea, feel the product in your own hands. That part is yours now, and it's genuinely valuable.

Then, before it turns into the huge thing you're dreaming about, bring in judgment. Not to take it from you. To review the architecture, harden the security, own the operations.

The tool is the easy part now. The judgment is the whole game.

If you've built the small version and it's starting to outgrow you: that's a good problem. What are you stuck on?

(Full write-up, including the screenshot of that 2am chat and an FAQ, is linked in the first comment.)

Why Vibe Coding is Basically Playing with the Timebomb

Md Fahad Mia — Tue, 08 Sep 2026 20:39:47 +0000

Vibe coding is shipping code you don't understand. It feels like productivity. It's a timebomb.

The pattern is everywhere now: prompt, copy, paste, ship. Ticket closed. Feature done. And for the happy path, it works.

Then it detonates, in one of three places:

Debugging. Something breaks in production and you're staring at logic you accepted but never internalized. You can't ask the AI why its own code failed. That takes a human who understands it.
Security. AI doesn't know your threat model or your business context. Subtle flaws (bad input validation, injection risks, unsafe deserialization) look perfectly functional until they aren't. Auditing generated code needs more expertise, not less.
Scale. An endpoint that works for 10 users falls over at 10,000 if nobody thought about the performance characteristics of what got generated. Guessing is not engineering.

Underneath all three is the same problem: you no longer own the code in your head. You've become a code babysitter.

This isn't anti-AI. I use these tools every day. The difference is how:

→ As a learning accelerator: generate it, then dissect every line and ask why
→ With a validation harness: my own tests and checks wrapped around the AI's output
→ With a human in the loop, always: AI automates tasks, it can't automate judgment

Co-pilot, not pilot. The engineer is still responsible for what ships.

How are you keeping ownership of code that AI helps you write? Genuinely curious what's working for other teams.

(Full write-up with an FAQ on AI and code quality is on my site, link in the comments.)