Founding Full Stack Engineer — Vyazen Onsite, Mumbai (Full-time)

Why Vyazen

Software systems have outgrown the humans who maintain them. Large codebases span millions of lines across thousands of files, with architecture that lives mostly in the heads of the few people who've been there longest. Understanding a system well enough to safely change it is now the hard part of engineering — writing the code is comparatively easy.

We think the answer isn't better autocomplete. It's giving both engineers and AI agents a genuine, shared understanding of a codebase — its structure, its intent, and how its parts actually relate — and then building an environment where agents can do real engineering work on top of that understanding: reading a problem, forming a plan, writing and verifying code, and handing back something a human can trust.

That's what we're building. Not a chat assistant that suggests snippets, but a system that does the work.

The role

Founding engineer means you own problems, not tickets.

You'll work across the platform — the systems that analyze and model large codebases, the infrastructure that runs agents against real repositories, and the product surface where engineers direct and review that work. The boundaries between those are deliberately loose. You'll go where the hardest open problem is.

Some of what that looks like: -

- Code understanding at scale - Parsing, resolving, and modelling relationships across huge repositories, then making that knowledge retrievable with precision.
- Agent execution infrastructure - Running autonomous agents in real development environments, reliably, and making their work observable end to end.
- Workflow design - Turning "an agent wrote some code" into a structured engineering process with specs, reviews, and verification gates.




- Product - Interfaces that make an autonomous system legible and directable rather than a black box. You will not be handed a spec for any of this.

You'll be handed the problem, the constraints, and access to whoever knows the most about it.

Who we're looking for

We care about what you've built and how you think, not years on a résumé. A strong second-year engineer and a solid final-year student look identical to us on the things that matter.

You're likely a fit if:

- You've built something substantial and unglamorous — a parser, an interpreter, a database, a scheduler, a game engine, a protocol implementation. Something where you made real design decisions and lived with them.
- You read source code to answer questions. When a library misbehaves, your instinct is to open its repo, not its issue tracker.
- You're comfortable being wrong in public and fast. Design here happens by argument, and the argument is won by better reasoning, not longer tenure.
- You can hold a system in your head across layers — as willing to reason about infrastructure behaviour as about a rendering bug.
- You write TypeScript a stranger can maintain, and you know when tests are load-bearing versus ceremonial.
- You use AI tools aggressively and have opinions about where they fail.

We especially want to hear from you if you've explored compilers, type checkers,



or language servers · static analysis · storage engines or database internals · distributed systems · graph databases and retrieval systems · developer tooling · Rust. One honest disqualifier - If your experience is mostly assembling UIs against existing APIs, or if you need well-specified work to be productive, you'll have a bad time here. That's not a judgement on that work — it's just not this job.

How we work

- Design before code - We resolve the open questions, write the spec, then build. Half-built implementations of unsettled designs are the expensive kind of mistake.
- Simple beats clever. We take the more debug option over the more optimal one, often at real cost, and we're deliberate about when to stop doing that.
- Profile before you split. No new service, database, or abstraction until the existing one is provably the bottleneck.
- We build with what we build. Our own platform ships meaningful parts of itself. If that idea makes you uncomfortable, this is the wrong role. If it makes you want to find where it breaks, we should talk.
- Small team, high bandwidth. Direct technical shorthand, no status theatre, no hand-holding.
- Onsite. Mumbai, five days a week. The conversations that matter happen at a whiteboard.

What you get

- Ownership and everything that comes with it.
- Direct authorship of the architecture — your decisions in production, not someone else's design to implement.
- Technical depth that's genuinely hard to find this early in a career.
- Competitive cash. We'll be transparent about the number in the first conversation.

Process

1. Short intro call — what you've built, what you want to build.
2. A technical conversation about a real problem we're currently working on. No Leet-Code.
3. Team conversation and offer.

📌 Full Stack Engineer (Mumbai)
🏢 Vyazen
📍 Mumbai