You are a systems engineer for non-deterministic code generation. You are comfortable blocking a merge that looks perfect, and you can say precisely what evidence would unblock it.

The central problem you are hired to solve

Legacy ERP modules have no spec, no tests and no author still at the company. An agent can rewrite one in an afternoon. Nobody can prove the rewrite is correct. Everything below exists to close that gap.

The Three Things You Own a) The Guardrail Layer for agents that touch the codebase What an agent is permitted to modify and where it is sandboxed. Branch and PR discipline that agents cannot bypass. Dependency, licence and secrets constraints enforced in the pipeline.

Human approval gates on anything touching financial posting logic, data migrations or schema. Rollback that works at 2am. You assume the agent will eventually write something plausible and wrong, and design so that it costs a review comment, not a restatement.

b) The Behaviour-Parity Eval Framework This is the heart of the Dev track. Characterization tests generated from real production traffic and real data. Differential / shadow execution of legacy and modernized paths against the same inputs, with reconciliation on outputs and side effects. Coverage and mutation testing so tests pass means something.

Golden datasets drawn from the edge cases that actually bite — fiscal calendars, multi-currency, partial shipments,

credit memos, period-end adjustments. Regression detection when a model version or prompt changes underneath you. All of it wired into CI as a gate that can and does block merges.

c) The Cost & Throughput Envelope Cost and cycle time per module modernized to parity — not per token, not per PR.

Where the agent loop is burning context, where caching and model routing pay off, and which modules are not worth an agent at all. You can tell the CFO why a module cost what it cost and where the next 40% comes from.

Also expected

- Sequencing.



You decide which legacy modules go first, based on blast radius, data gravity and how cheaply

parity can be proven. Not on which one looks most fun.
- You still build. You write agents and code yourself, regularly. Your leverage comes from the interfaces, state

management and failure semantics everyone else builds inside.
- Fluency across the squad. Deep in development, but conversant with the Data (RAG/context), QA (evals/red-

teaming), Infra (AgentOps) and Domain (prompt architecture) tracks — enough to review their work and call a bad design early.

What You’ll Actually Do

- Define “shippable.” Write the standard for when agent-generated code can merge, and enforce it in the

pipeline, not in a wiki page.
- Build the parity harness — characterization tests, differential runs, reconciliation — and make it the default

first step of every modernization.
- Design the guardrails around regulated and financial logic, including approval and rollback paths.
- Run design and code review. Kill bad agent architectures in week one instead of month four, and be specific

about why.
- Own agent incidents. Pull the traces, find the root cause, add the eval that makes that failure impossible to

reintroduce.
- Make build-vs-buy calls on coding agents, frameworks and models — and revisit them when the ground shifts,

which it will.
- Grow Builder 1s and 2s through review and pairing. Not through ceremony.

The Stack
- Python, SQL (Postgres/SQL Server), TypeScript, OpenAI/Anthropic, agentic coding tools, LangChain/LangGraph, DSPy,
- pgvector/Qdrant, dbt, Apache Hop/Airflow, Docker, Weights & Biases, OpenTelemetry. Plus the layer you’ll live in: AST
- and static-analysis tooling (tree-sitter and friends), coverage and mutation testing, contract and snapshot testing,
- Playwright for UI-level parity, eval and tracing platforms (LangSmith / Langfuse / Braintrust or equivalent), model
- routing and caching. And any other tool that helps us achieve greatness.

📌 Lead AI Engineer (Hyderabad)
🏢 Ciklum
📍 Hyderabad