Infrastructure Engineer Intern / Co-op

About the role

About the role

Dedalus Labs builds persistent computers for AI agents. Our flagship product, Dedalus Machines, gives agents an isolated environment where they can run software, keep files and state, and work over time.

We're looking for someone who notices a slow build, a repeated manual step, or a service that fails in a way nobody can explain, and wants to make it better. You'll improve the team's development tools and workflows through focused fixes and speed improvements.

Explore our open-source tooling: Bessemer (BSMR), our build system, and Hollywood, which generates GitHub Actions from typed TypeScript definitions and runs actions locally.

About the internship

This is an evergreen opening. We review applications on an ongoing basis. Internships and co-ops last 3-9 months, depending on your school and co-op program.

We want evidence that you can learn something difficult, finish a working version, and improve it when the first approach fails. You do not need prior production ownership. You should already have a project you understand well enough to explain its hardest bug, its limits, and your personal contribution.

Work you might take on

• A build, test, or deployment improvement. Trace where the time goes, identify repeated work or a reliability problem, and verify the change against the same workload.

• A provisioning or developer-tooling workflow that another engineer can run and troubleshoot from its documentation.

• A small code change that eliminates repeated work, improves build or cache efficiency, or speeds up a developer workflow, with tests for the behavior it changes.

• Diagnostics that connect a failed operation to the relevant logs, metrics, and resource state, followed by a fix for the underlying problem.

Finish with tested code, documentation, and a clear account of the result and its limitations.

What we look for

You have completed a meaningful programming project in Python, TypeScript, Go, Rust, C, C++, or a similar language. You can explain its design, inspect its behavior on Linux, and investigate a failure. Experience with CI/CD, containers, Kubernetes, cloud infrastructure, networking, or infrastructure as code is useful.

Show us a tool someone used, a service you operated, a difficult bug you reproduced, or an experiment that led to a working improvement. Research and coursework are welcome too. Tell us what you personally implemented, including any decisions or extensions beyond the starting instructions.

You understand when to use unit, integration, end-to-end, and property-based tests, and what each can and cannot establish. You choose efficient ways to verify a change, test invariants and failure cases, and make failures reproducible. Experience with formal verification or model checking is a plus.

When you get stuck, you narrow the problem, read the relevant source or documentation, and try an experiment that can teach you something. You ask for help with the evidence you've collected and explain what you need to understand next. You act on feedback and keep ownership of the result.

You can use AI tools. You must understand, test, and correct the code you submit.

We evaluate the work relative to your experience and opportunities. A degree, a particular employer, or owning hardware is not a prerequisite. Be specific about what you have already learned and where you want to go deeper.

This internship may be a poor fit if

• You want to configure tools without understanding or investigating the software they run.

• You need every next step supplied before trying a small experiment or asking a focused question.

• You declare an improvement without checking whether another engineer can use it and whether the result is measurable.

Logistics

40 hours per week, five days onsite in San Francisco. Meals and office benefits included. Relocation and visa support may be considered individually. Strong interns may be considered for full-time roles.

Show us your work

Show us one thing you built and one difficult problem you investigated. They can come from the same project. Use existing work.

• Work: Show the code, demo, design, or result. Explain what you personally owned, what you reused, and one decision that made the result better or simpler.

• Investigation: Describe the symptom, your first explanation, the evidence that changed your thinking, and how you established the result. Include the workload or users involved and any important limitations.

• Engineering judgment: Link a public PR or commit, by you or anyone else, that you find interesting. Explain why it is an example of quality software engineering in the context in which it was written.

• Writing: Share one piece of writing you care about as a separate, required sample. Any medium or length is welcome. Tell us why you wrote it, who it was for, and what you wanted to communicate. Looking back, what works well and what would you change? We care about the quality of your thinking and writing, and your reflection on the work. Link it or paste a redacted excerpt. Explain your contribution and any coauthors or AI assistance.

Employment, open source, research, coursework, and independent projects all count. Links to your technical work or existing demos are optional but highly recommended so we can evaluate your body of work. Redacted excerpts are welcome for private work.

Tell us which problem in this role you want to own and why.