Software Product Engineer

AI-Native Enterprise Platform Engineering

Role Description + Assessment Playbook

Built for the era where AI writes code and judgment ships products

1. The mission

We are building an AI-native enterprise platform that operates inside regulated workflows. The platform deploys as a multi-tenant or a dedicated single-tenant environment on Microsoft Azure (platform agnostic), inside each customer's compliance boundary, with specialized AI agents that execute narrowly scoped tasks, a dual-validation layer where one AI verifies another before any output reaches a human, a versioned Prompt Registry, and a complete audit trail at session, field, workflow, and user level.

The product itself is the hard part. What makes the hiring decision hard is a different problem: in 2026, any competent engineer can produce a working prototype with AI assistance in an afternoon. That is not the bar. The bar is shipping software that a security review can clear, an auditor can trace, and a senior operator can trust for decisions that matter.

We are hiring the engineer who can meet that bar, and we do not care what domain they come from.

The one non-negotiable

You must be fluent with AI coding tools and ruthless about their output. Engineers who refuse to use AI are too slow for this environment. Engineers who accept whatever AI produces are too dangerous. We want the third kind: engineers who use AI to move rapid and still ship code that holds up months and years later.

2. What you will be building

You will contribute across four layers of the platform. The domain is regulated enterprise software; the craft is general-purpose product engineering at a high bar.

Application layer

A suite of specialized AI agents that each own one narrowly scoped task. Each agent is independently enableable or disableable by the customer at every workflow step, operates against a documented input-output contract, and can be swapped, versioned, or retired without breaking the ones around it. You will design, build, and evolve these agents and the workflows that compose them.

AI engine layer

Multi-LLM orchestration across several model providers, all inside the customer's cloud compliance boundary. A versioned, auditable Prompt Registry where every prompt change goes through formal change control. Deterministic, rule-bounded execution so identical inputs produce identical outputs. An LLM-as-a-Judge verification pattern where a primary agent performs a task and an independent agent verifies the output, with auto-escalation to a human on disagreement. You will build the plumbing, the guardrails, and the controls that make this layer reviewable.

Data and security layer

End-to-end encryption, full data lineage, complete audit trails with timestamps, strict de-identification before any data reaches an AI model, and zero data exfiltration outside the customer boundary. This layer is the foundation of enterprise trust. You will not compromise it, even under time pressure.

Cloud infrastructure layer

Dedicated per-customer Azure subscriptions, customer-managed encryption keys, network isolation via dedicated virtual networks and private endpoints, geo-redundant backups, a 99.9 percent uptime SLA. You will own the Infrastructure-as-Code that makes every new tenancy reproducible, inspectable, and handoff-clean.

3. How we work

- Repo is the source of truth. Every decision, every rule, every handoff is committed. Conversations, memory, and verbal context are not evidence; git is.
- Determinism over cleverness. Identical inputs must produce identical outputs. Non-deterministic, generative, or probabilistic outputs are unacceptable in the workflows we serve. We design for that constraint from the first line of code.
- Dual validation, not single output. Every high-stakes AI action is followed by an independent verification step. Disagreement auto-escalates to a human.



You will build this pattern in from the start, not bolt it on later.
- Human governs, AI executes. No autonomous actions in any customer workflow. Comment-driven sign-off is mandatory at every critical step. Every AI action logs its rationale, source references, and timestamps. This is a product contract, not a feature.
- Contract-first development. Every API endpoint publishes a versioned TypeScript contract before any consumer is written. Frontends import the contract; they do not redeclare shapes. Breaking changes bump the version.
- Targeted edits over rewrites. Small, reviewable commits. Full rewrites of files over 50 lines require explicit approval. Every change shows a clear before-and-after.
- Prompts are code. Every prompt lives in the versioned Prompt Registry. Prompt changes go through the same change control as code: impact assessment, test, approve, deploy, traceability. Every prompt execution is logged with input-output pairs.
- Standing rules grow with the product. When a bug exposes a new failure mode, we write a rule that prevents the entire class. The rule file is law, not guidance. Engineers add to it.

4. What you will actually do (by weight)

Build production-grade features across the stack (about 35 percent)

You are a full-stack product engineer first. You will design APIs and their contracts, write the serverless or containerized backends, build the React front ends, design the Postgres and Azure SQL schemas, and wire it all together. Most weeks, shipping features is the primary thing you do. You should enjoy that.

Design and evolve AI agents and their verifiers (about 20 percent)

Specify what an agent is supposed to do, what it is not allowed to do, what evidence it returns, and how an independent verifier would catch it if it were wrong. Integrate new agents into orchestration without destabilizing existing ones. Qualify each agent against defined acceptance criteria before it goes live.

Review and correct AI-generated code (about 20 percent)

A meaningful share of code across the platform is produced with AI assistance. You will read AI-generated pull requests and find the load-bearing defects that pass TypeScript and unit tests but violate the product contract a schema column that drifted, a filter applied to the wrong join, a helper unsafe at the leaf, an audit log that records nothing. You will own the discipline of not letting this class of bug ship.

Root-cause debugging of production (about 15 percent)

Reproduce the bug in your own hands before touching code. Diagnose to a single line. Fix the root cause, not the symptom. File the neighboring debt items you chose not to fix. Write the rule that prevents the next instance. Hand off cleanly so a different engineer can pick it up cold.

Raise the bar of the team itself (about 10 percent)

Write the rule additions. Propose the pre-commit hooks. Improve the contract tooling. Mentor teammates on using AI fluently without outsourcing their judgment. Make the next engineer's job easier than yours was.

5. What you must bring

Hard requirements

- Five or more years of production software engineering experience. Full-stack comfort. TypeScript and modern React on the frontend; Node or Python on the backend. If you have only done one side of the stack, this role will stretch you too thin.
- Real production Postgres or comparable relational database experience. You have written queries against tables with millions of rows. You know why COUNT(*) on a large join is a bad idea.



You have debugged a timeout that turned out to be a missing index.
- Demonstrable fluency with AI coding tools. Claude Code, Cursor, Copilot, or equivalent, used daily. You must be able to describe, from your own projects, a specific case where the AI produced convincing code that you rejected or corrected, and what your rejection criterion was. If you cannot tell that story, this role is not right for you.
- Cloud platform experience. AWS, Azure, or GCP in production. You have deployed, monitored, and debugged services running on managed cloud infrastructure. You understand IAM, networking, secrets, and observability as first-class concerns, not afterthoughts.
- Written clarity. Your PR descriptions, handoff docs, and design proposals should hold up six months later when a new engineer reads them cold. We will test for this.
- Comfort with ambiguity. You will often receive product intent, not spec. You will be expected to draft the spec, surface the tradeoffs, flag the unknowns, and commit it before writing code.

Strongly preferred (in this order)

- Experience building multi-tenant SaaS in production, especially deployments where each customer gets isolated infrastructure.
- Experience with Azure specifically: Azure AI Services or Azure OpenAI, Azure AD and SSO, Azure Key Vault, Azure SQL, Azure Monitor. If not Azure, equivalent depth on AWS or GCP is fine.
- Prior work in any regulated or high-trust domain where audit trails, change control, and reproducibility were real constraints: fintech, healthtech, legaltech, aviation, industrial controls, insurance, government. We do not need pharma specifically. We need the engineering discipline that regulation forces.
- Experience building or operating LLM-based systems in production: prompt versioning, eval harnesses, guardrails, fallback providers, cost and latency budgets. Hobbyist chatbots do not count; production systems with real users do.
- Strong schema design instincts. You think in entities and relationships before you think in components.

Domain note

We are not looking for domain expertise. Most of the team did not come from this domain either. A curious generalist who can read a 20-page regulatory guidance document and extract the three constraints that matter for software will outperform a narrow specialist. What we want is engineering craft plus the humility to learn the domain fast.

Will not work out

- Engineers who accept AI output without reading it, and engineers who refuse to use AI at all. Both are failure modes for this role.
- Engineers whose definition of 'done' stops at 'tests pass.' Ours stops at 'the deployed behavior matches the contract and the audit log proves it.'
- Engineers who cannot explain their code to someone who is not an engineer. You will often talk, through the team, to senior operators who are personally accountable for what the software does. Your thinking has to survive that translation.
- Engineers who treat prompts as throwaway strings. In this environment, prompts are versioned, reviewed, tested, and logged just like code. If that sounds like overhead, this role is not the right fit.

6. What we offer

- Competitive base compensation benchmarked to senior engineering roles, plus equity participation.
- Direct ownership of a production platform, not a sliver of one. Your name will be on architecture decisions, not buried three levels down.
- A compressed path to senior and staff-level scope. If you can operate this role as written, you are already doing the work of a staff engineer at most companies.
- An AI-augmented workflow that respects your time. You will not rewrite boilerplate. You will make the hard calls that AI cannot.
- Enterprise customer exposure. You will watch your code run in production for customers whose security teams and auditors push back hard, and you will get better because of it.

📌 Software Product Engineer (Telangana)
🏢 Theragenx
📍 Telangana