AI-Integrated Development Lifecycle

Before writing a single line of code, validate that AI will actually solve the problem. Most projects add AI where rule-based logic, a database query, or a simple algorithm would work better — and be far cheaper.

Decision matrix: should you use AI?

Key activities

• Stakeholder interviews: who uses this feature, what outcome matters, what does failure look like?
• AI literacy assessment: does the team understand probabilistic output and hallucination risk?
• Data availability audit: does training/prompt data exist and is it legally usable?
• Ethical pre-screen: bias, fairness, and consent implications of using AI here.
• Nepal-specific constraints: connectivity, language (Nepali/English mix), regulatory requirements.
• Build vs. fine-tune vs. prompt-only decision — documented and signed off.

Deliverables

AI requirements differ fundamentally from traditional ones. Outputs are probabilistic, not deterministic. Acceptance criteria must be ranges and rubrics — not binary pass/fail.

AI-specific functional requirements

• Define "good enough" quantitatively: "Summarisation must score ≥ 0.82 ROUGE-L on our test set."
• Specify confidence thresholds: when should the system abstain or escalate to a human?
• Document fallback behaviour: what happens when the model returns an unusable response?
• Identify human-in-the-loop checkpoints: which decisions require human approval before acting?
• Define output schema: if the AI must return structured data (JSON, table), specify the schema.

Non-functional requirements

Writing AI user stories

Deliverables

Even when using pre-trained open source models with prompt-only integration, you still need a data strategy — for few-shot examples, RAG documents, and evaluation sets.

Data types you need

Nepali language considerations

• Most models tokenise Devanagari less efficiently than Latin script — expect 1.5–2× more tokens per word.
• Code-switching (Nepali + English in the same message) is common; test explicitly for this.
• Qwen 2.5 14B and Llama 3.1 70B have the best Devanagari coverage among models on Higain.ai.
• If building for Nepal government or education, consider a Nepali-language fine-tune (reach out to Higain Labs).

Governance checklist

• Document data sources, licenses, and consent status for every dataset.
• PII audit: mask names, phone numbers, and addresses before indexing into RAG.
• Data residency: all storage and processing on Nepal-hosted infrastructure.
• Version your datasets with DVC or equivalent — model behaviour is reproducible only if data is versioned.
• Define data retention and deletion policy before launch.

Deliverables

Choose the right integration pattern before writing code. The wrong architecture — fine-tuning when prompting would do, or direct API calls when you need RAG — is expensive to reverse mid-sprint.

Integration pattern selection

Prompt architecture

Security: prompt injection mitigation

• Treat user input as untrusted data — never concatenate it directly into the system prompt without sanitisation.
• Use delimiters (XML tags or triple-quotes) to clearly separate system instructions from user content.
• Apply output validation: if you expect JSON, parse it and reject anything that doesn't match the schema.
• Rate-limit the API endpoint to prevent prompt flooding and token exhaustion attacks.

Deliverables

AI features span multiple disciplines simultaneously: prompt engineering, data plumbing, API integration, and conventional software engineering. Structure your sprints to reflect this — not as waterfall phases, but as parallel workstreams.

Sprint workstreams

Prompt version control

Testing AI features

• Unit test: mock the LLM response and test your application logic independently of the model.
• Integration test: call the real API with a fixed seed (or deterministic model) against golden outputs.
• Semantic assertion: don't test exact string equality — test meaning. Use embedding cosine similarity ≥ 0.92.
• Regression gate: block merges if any eval metric drops below baseline by more than 5%.

Deliverables

LLM evaluation is different from traditional QA. You cannot write a test that checks whether an answer is "correct" with assertEquals. You need a layered evaluation strategy.

Evaluation dimensions

Automated evaluation methods

• LLM-as-judge: use a second Higain.ai model call to score outputs 1–5 on each dimension. Works well at scale.
• Embedding similarity: compute cosine similarity between generated output and reference answer. Threshold ≥ 0.88.
• ROUGE / BLEU: useful for summarisation and translation tasks where a reference output exists.
• JSON schema validation: for structured outputs, parse and validate on every test run.
• Regex / keyword checks: blunt but fast — ensure key terms appear or don't appear in output.

Human evaluation protocol

Red teaming

• Jailbreak attempts: try to make the model ignore its system prompt ("ignore all previous instructions").
• Prompt injection via user content: embed instructions inside user-supplied documents or input fields.
• Edge inputs: extremely long inputs, empty inputs, non-UTF-8 characters, Devanagari mixed with emojis.
• Adversarial personas: test as a malicious user trying to extract system prompt content.

Deliverables

AI features deserve more cautious rollout than conventional features because failures are often silent, hard to detect, and erode user trust quickly.

Rollout strategy

Model pinning

• Always pin to a specific model version in production — never use a floating alias that updates automatically.
• Test every model update in staging with your full eval suite before changing pinned version in prod.
• Keep the previous model version available for 2 weeks as a rollback target.

CI/CD for AI applications

Deliverables

Unlike traditional software, AI systems degrade silently. User behaviour changes, data distributions shift, and what worked in March may fail by September. Monitoring is not optional — it is a core feature.

Metrics to track in production

Feedback loop design

• Embed thumbs-up / thumbs-down on every AI response in your UI. Log with full context (prompt, output, model, timestamp).
• Sample 2% of production traffic daily for async human review. Log scores back to your eval database.
• Surface flagged outputs to the team every Monday. Triage into: prompt fix, data fix, model switch, or expected edge case.
• Use production feedback as your next iteration's eval set — it represents real user intent better than synthetic data.

Drift detection

• Input drift: track the distribution of prompt topics using embedding clustering. Alert if new cluster emerges with > 5% share.
• Output drift: track average output length, refusal rate, and schema compliance weekly — sudden changes signal a problem.
• Model-level drift: if Higain.ai updates the underlying model weights, re-run your full eval suite before trusting existing behaviour.

Continuous improvement cadence

Deliverables