How We Onboard Engineers at KodeCraft
Week One: Ship Something
Your first day starts with a working development environment. We’ve invested heavily in making this frictionless—a single script that sets up the Rust toolchain, pulls the relevant repositories, configures Vault credentials, and runs the test suite. By lunch, you should be able to build and run the services you’ll be working on.
By Wednesday, you’ll have a pairing session with the engineer closest to whatever you’re working on first. Not a walkthrough of the architecture docs—actual pairing on a real task. We find that reading code together beats reading documentation alone.
By Friday, you should have your first pull request merged. It doesn’t need to be large. It needs to be real. A bug fix, a small feature, a test improvement, an observability addition. The goal is to close the loop between writing code and seeing it run in a staging environment within your first week.
Week Two: Understand the Agent Layer
Most engineers joining KodeCraft have strong backend or systems experience but haven’t built agent-native systems before. That’s expected—this is a new domain and there isn’t a textbook for it.
In week two, you’ll work through our internal guide to MCP server design. You’ll read the code for one of our simpler MCP servers, understand how tool schemas are defined, and see how agents discover and call tools at runtime. Then you’ll build a small tool interface yourself—something simple enough to finish in a day, complex enough to teach you the patterns.
The key insight most engineers get in this week: agent-native architecture isn’t about AI. It’s about designing systems where the primary operators aren’t humans. The AI is just the agent’s brain—the architecture is everything around it.
Week Three: Own a Piece
By week three, you’ll be assigned to a specific product or project team. At our size, “team” usually means 2-4 engineers working on a shared problem. You’ll have a defined area of responsibility—not just tasks assigned to you, but a piece of the system that you’re expected to understand deeply and improve.
This is where the learning curve steepens. You’ll encounter patterns specific to agent workloads: how to handle cascading tool calls, how to design guardrails that don’t add latency, how to build observability into agent orchestration pipelines. Your team lead will be available, but we expect you to drive your own understanding.
Week Four: Write About It
Every new engineer writes a blog post or internal document in their first month. This isn’t optional and it isn’t busywork. Writing forces you to organize what you’ve learned, and it creates artifacts that help the next person who joins.
The topic is up to you. Past examples include a deep dive on a Rust pattern that was new to the author, a comparison of approaches to agent guardrail validation, and an architecture decision record for a technical choice made during onboarding.
Some of these become public blog posts. Some stay internal. The format matters less than the habit of turning experience into shared knowledge.
What We Expect
After 30 days, you should be able to independently ship features in your area of responsibility, understand how MCP servers and agent orchestration work in our architecture, have opinions about how things should be improved, and feel comfortable asking hard questions in architecture discussions.
We don’t expect you to have mastered everything. Mastery takes months to years, especially in a domain this new. We expect you to be dangerous enough to contribute independently and curious enough to keep going deeper.
What You Can Expect From Us
A working development environment on day one. A real task in your first week. A team that answers questions honestly and reviews code thoughtfully. Direct access to every piece of the architecture—no layers of abstraction between you and the systems you’re building.
And a culture where the people who write the code make the decisions about the code. That’s the part that takes longest to believe and shortest to experience.