AI Engineer

Who we are

RedCarbon builds AI agents for cybersecurity. Think of them as virtual colleagues that join a Security Operations Center and take on the work that burns analysts out: triaging the endless stream of alerts, investigating incidents, hunting for threats, writing the report at the end. The humans keep what needs a human: judgement, decisions, the call to the customer at 2am.

We are an Italian company with our HQ in Turin, remote since day one, and we closed a €3M Series A in 2025. Our customers trust us with their security, which is a polite way of saying that "it works on my machine" is not an option here.

We are a bit crazy. We put a hacking challenge in front of our application form, and a pixel-art mascot in our job posts. You are about to meet him.

But we are dead serious about the engineering. We aim for a technical bar that is very, very high, and we are AI-first: we build AI products, and we build them with AI, every day, on purpose.

So we don't hire people to turn detailed requirements into code. We hire engineers who start from a problem, understand it, question the assumptions, pick a reasonable solution, ship it, and check that it actually solved the problem. You don't need to know our whole stack on day one. You need solid fundamentals, and to learn fast.

The role

We're looking for an AI engineer who trusts a number over a good-looking transcript.

Our agents investigate security incidents for real customers. When an agent is wrong, an analyst wastes an hour, or misses an attack. As an AI Engineer you make sure that happens less every week: you build the harnesses our agents run in, you fine-tune the models they think with, and you prove with numbers that they got better.

What you'll do

Build agent harnesses: tools, structured outputs, sub-agents, context management, caching and replay. The engineering that turns a model that sounds right into an agent that is right, run after run.
Fine-tune open-weight models for focused security tasks, from dataset curation to a model serving in production.
Write the evals. Benchmarks and regression suites that tell us whether a change made the agents better or just different. Nothing ships on vibes.
Run models in production: self-hosted inference, latency, cost, and what happens when a provider has a bad day.
Keep the agents safe: guardrails on what an agent is allowed to do, and one customer's data never in another's context.
Work with our threat analysts to turn how a senior analyst reasons into something an agent can do.

The problems you'll solve

An agent is right nine times out of ten. You find the tenth, fix it, and prove the fix didn't break the other nine.
The attacker writes part of the prompt. Alerts and logs carry text an attacker controls, and the agent reads all of it.
An investigation needs more data than fits in a context window. You decide what the agent sees, when, and what it fetches on its own.
Fine-tune a small model or prompt a large one? You answer with numbers on quality, latency and cost, not with opinions.

What we're looking for

Must have

Python and TypeScript in production. One very well, the other well enough to ship in it.
You know how LLMs actually work: attention, context windows, tokenization, sampling, why they hallucinate and what you can do about it.
You have built LLM-based systems that real users depend on, not only demos: agents, tool-using pipelines, or something we haven't thought of.
Software engineering fundamentals. An agent is a distributed system that sometimes improvises: retries, timeouts, idempotency and observability still apply.
An evaluation mindset. You have built evals before, and you trust a number over a good-looking transcript.
Strong on tests. You test the deterministic parts like any other software, and you have a strategy for the parts that aren't.
You have dropped an approach because the evals said so, and you can tell us what you learned.

Nice to have

We use these every day. You'll learn the ones you don't know yet.

Hands-on fine-tuning: LoRA/QLoRA, PEFT, Unsloth, dataset curation.
Serving open-weight models: vLLM or similar, quantization.
MCP and multi-agent orchestration.
Classical ML, when an LLM is the wrong tool.

Your first months

First week: run the eval suite locally, read some real agent transcripts, and fix one case where the agent gets it wrong.
First month: add a new eval for a task the agents get wrong today, then ship a change that moves that number.
First three months: own an agent capability end to end (for example, phishing triage): its harness, its evals, its behaviour in production.
After one year: you are better at something that matters to you, technical or not, and you can prove it. That's what the growth budget is for, and we'll look at it together.

For every role

You live in Italy. We hire in Italy only, for now.
Fluent Italian and good English. Code and docs are in English; calls are usually in Italian.
You take tests seriously. A feature without tests is a draft. Code reaches review when its author is convinced it works, not so that someone else can find out whether it does.
You use AI to think better, not to stop thinking. AI raises the floor; it doesn't raise the ceiling for you. Use it a lot, challenge its output, and own what you ship: "Claude wrote it" is never an excuse.
Big plus: you are visible. Interesting things on GitHub, talks at conferences or meetups, posts people actually read. Put the links in your CV.
Plus: a degree in Computer Science or a related field. Nice, not required: show us what you built.
Plus: you know some security. If you don't, we'll teach you; it's contagious.

Mid or senior?

Both, and we don't count years. A mid-level engineer ships features end to end in their area, with little guidance, and asks for help before being stuck becomes a habit. A senior engineer has owned a system in production and lived with their own decisions, sees problems before they become tickets, and makes the people around them better.

At every level we expect the same two things: you learn fast, and you take responsibility for your work. The autonomy grows with experience; the initiative has to be there from day one.

Is this for you?

If you have the fundamentals but not every nice-to-have, apply anyway: tools are learnable, and we'll teach you ours. If you'd rather get detailed tickets and someone to tell you when you're done, we're probably not the right place. No hard feelings.

How we think about engineering

Writing code is only part of the job, and with AI writing more of it every day, it's less and less what sets an engineer apart. What does: understanding the problem you're solving, questioning assumptions, exploring alternatives, and taking responsibility for the outcome.

We value curiosity over certainty, evidence over ego, and impact over activity.

Ownership means owning the problem, not falling in love with your solution. Sometimes the right thing is to push through a difficult problem. Sometimes it's to admit that the original decision was wrong and change direction. Knowing the difference matters, and changing your mind when the evidence changes is a strength here, not a loss of face.

We give people context, trust, and room to make decisions. We don't expect you to get everything right; we expect you to learn, take initiative, and grow. The team will help you, a lot, but it won't do your thinking for you.

We care about what you achieve, not how many hours you spend looking busy.

And we want to enjoy building things together. Great engineering and having fun aren't mutually exclusive.

How we work

We are agile, in the original sense of the manifesto, with security by design and by default on top. As an engineering team, we value:

people and trust over processes and controls;
real impact over plans and documentation;
understanding the customer's problem over executing the spec;
learning and adapting over following the original plan;
security as a design choice over checking it at the end;
growing together over excelling alone.

The things on the right matter. When we have to choose, we choose the ones on the left.

In practice:

Simplicity over virtuosity. Complexity is a debt, clarity is an asset. When in doubt, the simplest thing.
Ownership, not hand-offs. Shipping is not passing the ball. You follow your work until it really works in production, and you fix it if it doesn't.
Decide, write it down, revisit it. The people closest to the problem make the call, and write down why: that's what the ADRs are for. When the evidence changes, the decision changes too. A superseded ADR means we learned something, not that someone failed.
Remote, not isolated. Writing well is part of the job: we don't have a hallway, we have text. And we meet in person regularly, because some things remote can't give you.
Mistakes are fine, repeating them isn't. A deploy that breaks something happens. The same deploy breaking the same thing three times is not "iterating".
Cross the borders. Backend people touch the frontend, AI people learn the security domain, everyone cares about the analyst on the other side of the screen.

What we offer

A competitive salary: €45k–70k gross a year (RAL), depending on your level. The range is indicative: if you are truly exceptional, we'll talk numbers above it.
Full-time, permanent contract, CCNL Commercio, with health insurance.
Full remote from anywhere in Italy. We do about 95% of the work remotely; the rest is alignment days and company retreats.

A MacBook Pro. It's what we all work on.
An AI subscription for everyone. Use it, a lot.
Flexible hours, holidays managed on trust, zero micro-management.
Growth budget: time for learning, courses and certifications, internal tech talks, and conferences paid for, even more so if you are the one on stage.
Meal vouchers.

How to apply

There is no "send us your CV" form here. To apply, you have to hack the site.

The application form is behind a short challenge: a few puzzles that a curious developer solves with the browser devtools, a terminal and some patience. It's the same for every role. Solve it, then send us your CV and your GitHub profile. If you like the challenge, you'll probably like the job.

What happens next

An intro call with your future manager and our Product Manager: who we are, who you are, what you are looking for.
One or two technical interviews with the engineers you would work with.
A final interview with our CTO, and then an offer.