AI Engineer

Job Summary

Required Qualifications

• •Python – primary development language for AI/ML systems
• •LLM orchestration (LangChain, LlamaIndex)
• •data pipelines
• •embedding generation
• •vector operations
• •rapid prototyping
• •Prompt engineering – crafting precise, constraint-rich prompts and AI constitutions (CLAUDE.md-style rule files) that direct AI behaviour reliably
• •LLM integration – Claude, GPT models, GitHub Copilot
• •building AI-augmented workflows and agentic systems for enterprise applications
• •MCP (Model Context Protocol) – building tool-use interfaces and AI skill development that give LLMs structured access to our current CPQ tool's services and databases
• •Vector databases – embedding-based retrieval (Pinecone, Weaviate, pgvector) for knowledge management, documentation search, and institutional memory
• •JSON – schema design for AI tool definitions, MCP interfaces, LLM function calling specifications, structured output parsing, and agent configuration
• •Markdown – AI constitution authoring (CLAUDE.md files), prompt templates, knowledge base structuring, and documentation-as-code
• •Data modelling for AI – designing data structures and schemas that LLMs can reason over effectively
• •understanding complex existing relationships (costing WBS trees, commodities, elements, financial factors, bid history)
• •Data quality for AI – assessing, profiling, and improving data quality upstream of AI systems
• •understanding that poor data quality produces confidently wrong AI outputs
• •Analytical data design – structuring analytical datasets and knowledge bases from Oracle / MSSQL / ClickHouse sources for AI consumption
• •GitHub Copilot and Claude Code – not just using them, but designing how the broader team uses them
• •the AI toolchain is part of your architecture responsibility
• •C# / .NET Core – understanding existing backend for integration and migration planning
• •JavaScript / TypeScript – for AI-powered frontend features or Node.js-based AI middleware
• •SQL (Oracle, MSSQL, PostgreSQL, ClickHouse) – for building AI context from existing databases and designing analytical schemas
• •Docker / Kubernetes – containerising AI services for deployment on EKS
• •Grafana / observability tooling – for AI performance monitoring and anomaly detection pipelines
• •RAG (Retrieval-Augmented Generation) – architecture patterns at scale
• •experience with enterprise RAG deployments
• •Fine-tuning, RLHF, evaluation frameworks – RAGAS, DeepEval for systematic AI output quality measurement
• •Event-driven architectures – designing AI agents that respond to system events from our existing message bus
• •Salesforce Einstein AI or similar enterprise AI platforms
• •dbt, Great Expectations or similar data quality tooling – for building systematic data quality checks upstream of AI models
• •Evaluative cognition shift – deep understanding that this role exists to help the team transition from generative to evaluative work modes
• •you design the systems that make evaluation possible
• •Sycophancy detection – understanding when AI agrees with framing because you're the prompter, not because you're right
• •designing systems that resist circular validation
• •Constitution design expertise – the highest-leverage artefact in AI-first development
• •a garbage constitution means a confidently wrong system
• •Adversarial verification design – creating structured exercises and automated checks that train evaluative instincts across the team
• •Data-chain awareness – the ability to trace an AI output back through its data sources, embeddings, and context to diagnose why it went wrong
• •never accepting 'the AI said so' without understanding the data path
• •modelling existing costing structures, bid history, and financial factors into AI-consumable schemas
• •data quality is the prerequisite for every AI output
• •Build data profiling and quality assessment pipelines
• •understanding what data we currently have, what is reliable, and what must be cleaned or restructured before AI can use it
• •Design LLM-based replacements for rigid legacy business logic
• •costing rules, allocation algorithms, and financial calculations expressed as AI-driven decision systems
• •MCP-based AI skills that give LLMs structured access to current services, databases, and business logic
• •creating the foundation for an AI-native platform
• •Design and implement AI constitutions and guardrails encoding domain rules, pricing logic constraints, audit requirements, and data quality checks
• •vector-based knowledge retrieval systems for documentation, architecture decisions, bid history, and institutional knowledge
• •Create AI-augmented developer tooling – specification templates, automated verification pipelines, and AI-assisted code review that catches 'looks right vs. is right' failures
• •Design and build an AI-driven workflow engine to replace complex legacy orchestration patterns (125+ rigid service chains) with intelligent, self-adapting agents
• •Establish metrics and measurement for AI-first adoption and platform modernisation progress
• •Support the team's transition to the Intent → Generate → Verify → Decide → Document workflow loop
• •Prototype and validate next-generation architecture patterns
• •proving that AI-native approaches can replace current complexity
• •Run regular AI literacy sessions with the whole team
• •including the two testers who are natural candidates for AI verification and prompt engineering backup roles
• •Train both testers on AI constitution design and adversarial verification techniques
• •so that AI guardrail maintenance does not depend on a single person
• •Document all data models, embedding schemas, MCP tool definitions, and vector retrieval configurations in version-controlled Markdown
• •every AI skill must have a corresponding specification document
• •Pair with Position 1 (backend) to jointly own the data modelling decisions for the replacement platform
• •data architecture knowledge must overlap with at least one backend developer
• •Establish a 'AI knowledge base' in the team's wiki covering prompt patterns, constitution templates, and data quality rules
• •accessible and maintainable by the whole team within 6 months