DEV Community: Georgia Kali

AI SDLC - Emergent

Georgia Kali — Mon, 02 Nov 2026 08:41:56 +0000

Georgia Kali · 1 November 2026 · AI SDLC series, IntDEx framework

Why AI-native delivery keeps surprising the teams that run it, and how the IntDEx framework turns emergence from an anomaly into a managed source of insight

The problem: behaviour nobody specified

Traditional development rests on a quiet assumption: the code does what it says. When a feature surprises a team, the surprise usually lives at the level of the whole system, the organisation or the requirement set, not inside each line of work. The Agile Manifesto already accepted that "the best architectures, requirements, and designs emerge from self-organizing teams" (Beck et al., 2001), but the building blocks themselves stayed deterministic.

AI-assisted development changes where emergence happens. Large language models produce different outputs for the same request: an empirical study of ChatGPT code generation found that identical prompts often returned code with different behaviour, and that setting the temperature to zero reduced this variation but did not remove it (Ouyang et al., 2025). Research on model scaling has described "emergent abilities" that appear in larger models but not in smaller ones (Wei et al., 2022), although later work argued that some of these jumps are partly an effect of the chosen metric (Schaeffer, Miranda & Koyejo, 2023). Either way, a team cannot read the full behaviour of its delivery engine from a design document.

What "emergent" means in IntDEx

The IntDEx framework (https://intdex.org) defines the property precisely: the AI delivery engine "can exhibit emergent behaviour that arises from the interaction of prompts, models, constraints, data, context, and human oversight." That behaviour "cannot be fully pre-determined", and it "reshapes expectations, architectural choices, validation strategies, and risk posture." The framework also separates two levels: emergence in the delivery engine, and emergent user-facing behaviour in the solution it produces, which is evaluated separately as the product delivered to users.

IntDEx claims no discovery here. Complex adaptive systems theory (Holland, 1995), the Cynefin framework, where the complex domain calls for probing before sensing and responding (Snowden & Boone, 2007), and emergent design in agile practice all describe the same phenomenon. What differs is the scale, the speed and the location: in AI-native delivery, emergence appears in every step of work that uses non-deterministic methods.

Aspect	Traditional development	IntDEx position
Where emergence appears	System, organisation or requirement set	Every non-deterministic step, plus the delivered solution
How it is treated	A defect or a late surprise	A defining property and a source of insight
Response	Fix the code	Refine intent, prompts, constraints, routing or oversight

In practice, emergence touches every engineering concern. Behavioural intent evolves as stakeholders refine their understanding. Engine components such as retrieval pipelines, safeguards and model routing adapt to new behavioural patterns. Prompts mature through refinement and versioning. Validation exposes new constraints and edge cases. Risk posture shifts as the engine meets new contexts. Human oversight catches behaviours that automated checks cannot see. This matches the NIST AI RMF, which expects organisations to keep identifying and tracking unanticipated and emergent AI risks throughout the lifecycle (NIST, 2023).

Research-style validation

Problem. How can a team deliver safely with an engine whose behaviour cannot be fully known in advance, without either ignoring surprises or freezing delivery every time one appears?

How IntDEx addresses it. It treats emergence as a defining property. Emergent behaviour is observed, recorded and classified, then routed into a concrete response: a refined intent, a new constraint, a prompt version, a routing change or a human checkpoint. Engine-level and solution-level emergence are assessed separately.

Worked example (illustrative only). A hypothetical team builds a refund-summary feature. During behaviour validation the Tester runs the same intent 20 times and notices that, in some runs, the engine adds a currency conversion it inferred from retrieved context. Nobody asked for it. The Tester logs it as emergent behaviour, and the Analyst and Business Owner decide whether it is wanted. They reject it, so the Architect adds a constraint and the run set is repeated. Simple probability shows why sampling matters. If an unwanted behaviour occurs in 5% of runs, the chance of never seeing it in 20 independent runs is 0.95 to the power of 20, about 36%. Seeing it at least once with 95% confidence needs about 59 runs, because 0.95 to the power of 59 is just under 0.05. This is arithmetic for illustration, not a measured result.

Proposed evaluation criteria (not results). Teams could track the number of emergent behaviours logged per feature, the share classified as wanted, unwanted or neutral, the time from detection to a validated response, how many were found by humans rather than automated checks, and how many reached users before detection. No results are reported here; quantitative findings will be reported separately.

Limitations. Treating emergence as a managed property has not yet been tested through independent case studies. Classifying a behaviour as emergent rather than as a plain defect is a judgement call, and teams may disagree. Repeated sampling costs time and tokens, and rare behaviours can still escape any sample size a team can afford.

Conclusion. In IntDEx, emergence is not an excuse and not a bug category. It is the expected result of combining prompts, models, data, context and oversight, and it guides engineering decisions across the whole delivery effort. A practical first step: keep a visible log of unexpected behaviours and give each one a named owner and a decision.

References

IntDEx Framework

IntDEx.org: https://intdex.org

Other references

Beck, K., et al. (2001). Principles behind the Agile Manifesto. https://agilemanifesto.org/principles.html
Holland, J. H. (1995). Hidden Order: How Adaptation Builds Complexity. Addison-Wesley.
Snowden, D. J., & Boone, M. E. (2007). A Leader's Framework for Decision Making. Harvard Business Review, 85(11), 68–76. https://hbr.org/2007/11/a-leaders-framework-for-decision-making
Wei, J., et al. (2022). Emergent Abilities of Large Language Models. Transactions on Machine Learning Research. https://arxiv.org/abs/2206.07682
Schaeffer, R., Miranda, B., & Koyejo, S. (2023). Are Emergent Abilities of Large Language Models a Mirage? NeurIPS 2023. https://arxiv.org/abs/2304.15004
Ouyang, S., Zhang, J. M., Harman, M., & Wang, M. (2025). An Empirical Study of the Non-determinism of ChatGPT in Code Generation. ACM Transactions on Software Engineering and Methodology. https://arxiv.org/abs/2308.02828
NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1

AI was used for readability improvements.

AI SDLC - Cross-cutting Changes

Georgia Kali — Wed, 28 Oct 2026 08:40:28 +0000

Georgia Kali · 28 October 2026 · AI SDLC series, IntDEx framework

Why the biggest changes in AI-native delivery sit between the phases, and how the IntDEx framework re-wires flow, teams, oversight, evidence, cost and adoption

The problem: changing the phases is not enough

Earlier articles in this series covered single phases of an AI-assisted software development lifecycle (AI SDLC). Some of the most important changes, however, belong to no single phase: how work flows, how teams are sized, who decides, what counts as evidence, who sees the bill and how much of a framework must be adopted.

Organisation shapes output: Conway observed that organisations which design systems "are constrained to produce designs which are copies of the communication structures of these organizations" (Conway, 1968). When an AI delivery engine can generate a feature in an afternoon, fixed sprints, large teams and informal sign-off become the slowest and weakest parts of the system. IntDEx.org (https://intdex.org) describes the central shift as one "from code centric development to behavior centric delivery". The cross-cutting changes make that shift work end to end.

Seven cross-cutting changes in the IntDEx framework

The IntDEx framework (https://intdex.org) sets out seven changes that apply across every phase:

Area	Existing practice	IntDEx position
Flow	Sprints and time-boxed iterations	Flow-based, readiness-triggered replenishment (Kanban-like); monthly delivery planning, quarterly strategy. Sprints optional
Management	Separate project and product management	One unified practice: Product Delivery Management
Team	Fewer, larger, technology-aligned teams	More, smaller (3–5) teams aligned to business domains and sized by business or regulatory complexity
Human oversight	Review, sign-off, RACI	Role-owned blocking checkpoints with a decision record the engine may create but must not sign; unvalidated high-severity checkpoints accumulate as debt that halts the engine
Evidence	Traceability matrices, coverage	Traceability and coverage are explicitly not substitutes for correctness evidence
Cost	Budget tracking	Per-delivery estimates and actuals visible to the whole team, owned by the Delivery Manager; model self-reported cost is unverified until checked against provider telemetry
Adoption	Full framework or nothing	Adopt what you need, above a stated minimum for conformance, with a throughput mode for low-criticality work

Two of these changes carry most of the weight.

Evidence. When one model writes the intent, prompt, code, test and test result, one misunderstanding can run through all of them, and traceability looks complete while the chain is wrong. IntDEx therefore treats a claim of correctness as admissible only if its evidence comes from a source other than the authoring model: executed evidence, human evidence, cross-model evidence or comparison with a prior baseline. This matches research showing that large language models "struggle to self-correct their responses without external feedback" (Huang et al., 2024).

Oversight. A checkpoint is only a control if it can block. Human factors research has long documented automation bias and complacency in human use of automated aids (Parasuraman & Manzey, 2010), and the EU AI Act requires human overseers of high-risk systems to "remain aware of the possible tendency of automatically relying or over-relying on the output" (Article 14(4)(b)). IntDEx answers with named owners, recorded decisions and a debt threshold that stops the engine instead of letting unreviewed work pile up.

The NIST AI RMF expects roles, responsibilities and lines of communication for managing AI risk to be "documented and are clear to individuals and teams throughout the organization" (GOVERN 2.1), which is easier in small, domain-aligned teams. ISO/IEC 42001 treats AI governance as a continually improved management system, which suits tiered adoption.

Research-style validation

Problem. Can an organisation adopt AI-native delivery without its planning cadence, team structure, oversight, evidence and cost control becoming bottlenecks or blind spots?

How IntDEx addresses it. It changes the operating model, not just the phases: flow, small domain teams, blocking and attributable oversight, independent evidence, verified cost and tiered adoption.

Worked example (illustrative only). A hypothetical four-person claims team works in flow: an intent to change a fraud-flag rule is marked ready and pulled the same day, not at the next sprint. The engine reports that "all tests pass" and that the work cost little. The pass is recorded as unverified until the suite actually runs, and the Tester accepts the executed result, not the engine's statement. The cost figure is labelled as a self-report until the Delivery Manager checks it against provider telemetry. When a third unreviewed high-severity checkpoint crosses the threshold set in the engine manifest, the engine stops and reports the blocking condition; named owners clear the queue and work resumes with every decision on record.

Proposed evaluation criteria (not results). Teams could measure lead time from intent readiness to release, waiting time at human checkpoints, the share of releases supported by independent (non-self) evidence, the gap between engine-reported and telemetry-measured cost, and how often the checkpoint-debt threshold halts the engine. No results are reported here; quantitative findings will be reported separately.

Limitations. These changes have not yet been tested through independent case studies or controlled comparisons. Very small teams struggle with segregation of duties, and blocking checkpoints can slow delivery if owners are unavailable. Flow needs backlog discipline, and cross-model evidence reduces, but does not remove, shared blind spots.

Conclusion. In IntDEx, the cross-cutting changes are the operating model that lets the phases work: flow instead of time-boxes, small domain teams, blocking human checkpoints, independent evidence, verified cost and tiered adoption. A practical first step: label every engine self-report as unverified, and give one blocking checkpoint a named owner.

References

IntDEx Framework

IntDEx.org: https://intdex.org

Other references

Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), 28–31. https://www.melconway.com/Home/Committees_Paper.html
Parasuraman, R., & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors, 52(3), 381–410. https://doi.org/10.1177/0018720810376055
Huang, J., Chen, X., Mishra, S., Zheng, H. S., Yu, A. W., Song, X., & Zhou, D. (2024). Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024; arXiv:2310.01798. https://arxiv.org/abs/2310.01798
NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1
ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/81230.html
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14: Human oversight. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

AI was used for readability improvements.

AI SDLC - AI Delivery Engine Continuous Monitoring

Georgia Kali — Fri, 23 Oct 2026 07:45:19 +0000

Georgia Kali · 22 October 2026 · AI SDLC series, IntDEx framework

Why a validated release says little about next month's behaviour, and how the IntDEx framework makes monitoring a governed input to delivery

The problem: behaviour keeps moving after release

Conventionally, monitoring is an operations concern: dashboards watch latency, traffic, errors and saturation, the "four golden signals" of Google's SRE book (Ewaschuk, 2016). In an AI-assisted software development lifecycle (AI SDLC), behaviour can degrade with no code change at all. IntDEx.org defines AI-native delivery as the flow through which digital solutions are "conceived, engineered, validated, released, monitored, and evolved" with AI as the primary tooling, so monitoring is part of delivery.

Public evidence shows why. Chen, Zaharia and Zou (2023) found that GPT-4 followed 99.5% of their answer-extraction instructions in March 2023 but only 0.5% in June, concluding that the "same" LLM service can change substantially in a short time, "highlighting the need for continuous monitoring of LLMs". Machine-learning research has long studied concept drift (Gama et al., 2014), and Google's ML Test Score stresses knowing that a system "continues to work correctly over time", not just at launch (Breck et al., 2017). The SRE book counts a successful response "coupled with the wrong content" as an error; generative systems produce exactly that failure.

What IntDEx changes in Phase 6: AI Delivery Engine Continuous Monitoring

Phase 6 tracks AI delivery engine behaviour in production, "identifying drift, degradation, and emerging risks". Building on observability, MLOps drift monitoring and site reliability engineering, the IntDEx framework makes five changes:

Monitoring covers more than correctness. Signals include drift, hallucinations, data quality, real-world usage and AI safety, extending to cost, sovereignty and ethics drift.
Constraint degradation is tracked. Safeguards can weaken gradually without any single visible failure, so their erosion is a signal in its own right.
Engine and solution telemetry are kept apart. Delivery-engine observability (lead time, queue time at human checkpoints, first-pass validation rate, rework, evidence completeness, cost per accepted change) is distinct from delivered-solution telemetry, and every metric names its authoritative data source so model-generated estimates are not confused with measured telemetry.
Accepted deliverables become a regression baseline. When a model or engine version changes, instructions with known, previously accepted deliverables are re-run and compared with the accepted results.
Monitoring is an input to delivery. A signal can open a new delivery cycle in any phase, and breaching a cost or risk threshold defined in the engine manifest is a mandatory, blocking human checkpoint.

The engine detects and raises signals; humans triage alerts, decide what is a real deviation and own the thresholds. Detection should be a deterministic script over a metric with a stable rolling baseline, with no model in the decision. At high severity the engine alerts the named owner but takes no action; at medium severity its diagnosis is recorded as UNVERIFIED, a hypothesis rather than a root cause.

This aligns with public frameworks: the NIST AI RMF asks that AI system behaviour is "monitored when in production" (MEASURE 2.4) under a post-deployment monitoring plan (MANAGE 4.1); Article 72 of the EU AI Act requires providers of high-risk AI systems to collect and analyse performance data "actively and systematically" throughout their lifetime; and ISO/IEC 42001 frames AI management as continual improvement.

Research-style validation

Problem. Can a team detect, and govern its response to, behavioural change in an AI delivery engine when no code has changed?

How IntDEx addresses it. It widens what is monitored, ties every metric to an authoritative source, makes threshold breaches blocking human checkpoints and routes findings back into delivery. Under its evidential-independence rule, the engine's own report that it is healthy or within budget stays unverified until checked against independent telemetry.

Worked example (illustrative only). Imagine a hypothetical model upgrade behind an engine drafting customer-facing release notes. A monitoring record could read:

Signal	Source	Evidence class	Response
Re-run of accepted reference tasks: some outputs omit a mandatory disclaimer	Deterministic comparison with accepted baseline	Admissible (prior-artefact)	Constraint degradation; new delivery cycle
Engine reports "token cost stable"	Engine summary only	UNVERIFIED	Checked against billing telemetry
Daily cost exceeds the manifest threshold	Provider billing telemetry	Admissible (executed)	Blocking checkpoint; Delivery Manager decides
Engine suggests "new model ignores the system prompt"	Engine diagnosis	UNVERIFIED (hypothesis)	Tester confirms before any prompt change

Proposed evaluation criteria (not results). Teams could track the time from a model change to a completed baseline re-run, the share of metrics with a named authoritative source, the share of threshold breaches resolved by a recorded human decision before work continued, and alert precision (alerts triaged as real deviations), reflecting the SRE rule that every page should be actionable. No results are reported here.

Limitations. The IntDEx framework has not yet been evaluated through independent case studies or controlled comparisons with other approaches. Reference baselines cover only known deliverables, so novel usage can drift unseen. Alert thresholds need careful tuning to balance false positives and negatives (Breck et al., 2017). Deterministic metrics capture semantic quality only partly, so some signals still need human or cross-model review. Enabling telemetry traceable to a named individual is itself a mandatory checkpoint.

Conclusion. In IntDEx, continuous monitoring is evidence-producing delivery work, not a dashboard: signals come from independent sources, humans own thresholds and judgements, and findings flow back into intent, prompts, constraints or model choice. The practical first step: keep a few accepted reference tasks and re-run them whenever the model changes.

References

IntDEx Framework

IntDEx.org: https://intdex.org

Other references

Ewaschuk, R. (2016). Monitoring Distributed Systems. In B. Beyer, C. Jones, J. Petoff & N. R. Murphy (Eds.), Site Reliability Engineering: How Google Runs Production Systems. O'Reilly. https://sre.google/sre-book/monitoring-distributed-systems/
Chen, L., Zaharia, M., & Zou, J. (2023). How Is ChatGPT's Behavior Changing over Time? arXiv:2307.09009. https://arxiv.org/abs/2307.09009
Gama, J., Žliobaitė, I., Bifet, A., Pechenizkiy, M., & Bouchachia, A. (2014). A Survey on Concept Drift Adaptation. ACM Computing Surveys, 46(4), Article 44. https://doi.org/10.1145/2523813
Breck, E., Cai, S., Nielsen, E., Salib, M., & Sculley, D. (2017). The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. 2017 IEEE International Conference on Big Data. https://doi.org/10.1109/BigData.2017.8258038
NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 72: Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/81230.html

AI was used for readability improvements.

AI SDLC - Behaviour Validation

Georgia Kali — Sat, 17 Oct 2026 18:11:24 +0000

Georgia Kali · 17 October 2026 · AI SDLC series, IntDEx framework

Why a self-reported "all tests pass" is not evidence, and how the IntDEx framework turns testing into evidence-ranked behaviour validation

The problem: when one model writes the code and the verdict

In an AI-assisted software development lifecycle (AI SDLC), the same model can now draft the intent, the prompt, the implementation, the tests and the final test report. The IntDEx framework names the risk directly: a misunderstanding can be reproduced consistently through every one of those artefacts, so "traceability then appears complete, coverage full, and validation appears good, while the entire chain is wrong". Traceability between artefacts written by one author may be internal consistency, not verification.

This is not only a theoretical worry. NIST's Generative AI Profile (NIST AI 600-1) describes confabulation as confidently stated but erroneous or false content, and research presented at ICLR 2024 found that large language models struggle to correct their own reasoning without external feedback, with performance sometimes degrading after self-correction (Huang et al., 2024). A test phase that accepts the authoring model's own verdict inherits both weaknesses.

What IntDEx changes in Phase 4: Behaviour Validation

IntDEx (AI-native Delivery Experience) defines a seven-phase AI-native delivery flow. Phase 4, Behaviour Validation, "ensures that delivery engine's outputs are correct, safe, ethical, and aligned with stakeholder expectations", and user testing focuses on behaviour rather than code. Testers evaluate outputs for correctness, bias, hallucinations, constraint violations and drift.

Compared with conventional QA, UAT, test automation and evals, the framework makes four concrete changes:

Evidential independence. A claim of correctness is admissible only if its evidence comes from a source other than the model that produced the work. Sources are ranked: executed evidence (exit codes, test results, build logs, HTTP responses, database state) above human evidence, above cross-model evidence, above prior-artefact comparison.
Self-reports are UNVERIFIED. In the words of the IntDEx framework, a statement by the authoring model that a check passed "carries no evidential weight and must be recorded as unverified rather than as a pass". The engine's own report is not evidence; the human decides.
Pair behaviour validation. Acceptance validation is done in pairs, for example end user with tester, or user with analyst; security, UI/UX and compliance tests are automated before release and checked by human testers.
Continuous validation. Automated Continuous Behaviour Validation (ACBV) re-runs behavioural evaluations whenever the engine configuration changes, whether a prompt, constraint, context or model swap, and gates the change on pass rates, so behavioural quality cannot degrade silently.

Research-style validation

Problem. Can behaviour validation in an AI SDLC produce assurance when the authoring model also writes the tests and the report?

Method. IntDEx was developed using Design Science Research, treating the framework as an artefact refined through practical application on a data-science platform for public-health data experimentation. Evaluation covered rebuilding the solution from artefacts alone and the operation of the evidential-independence and human-oversight controls.

How validation was applied. The IntDEx framework describes applying these controls during the delivery of that platform and in an attempt to rebuild it from IntDEx artefacts alone. Enforced human checkpoints were used to halt work where the engine's own evidence was judged insufficient and to correct the severity the engine had assigned to a change. A model from a different provider family reviewed prompt executions, and its disagreements were passed to a human, who decided whether a change was needed. The rebuild was assessed across behaviour, security, data structures, architecture and configuration, and the framework notes that security controls left implicit in the original, rather than written as governed intent or security artefacts, may not be reliably reproduced.

Worked example. Take a typical request: a website contact form that emails the business owner. Because it handles personal data, IntDEx treats it as a Tier 2 (elevated) change with a synchronous, blocking checkpoint. A validation record could look like this:

Acceptance criterion	Evidence	Rank	Status
Valid enquiry is accepted and the owner is notified	Integration test exit code and captured outbound message	Executed	Admissible
Abusive repeated submissions are throttled	Engine states "rate limiting implemented"	Self-report	UNVERIFIED
Same criterion, after a negative test that floods the endpoint	HTTP 429 responses logged	Executed	Admissible
Form wording meets the intent	Recorded user and tester pair review	Human	Admissible

Proposed evaluation criteria (not results). Teams adopting this practice could track measures from the framework's own list: the percentage of production claims backed by independent evidence, behavioural regression, first-pass acceptance, escaped defects, and the negative-control-test pass rate. Because evaluations of a non-deterministic system vary between runs, IntDEx advises establishing the expected run-to-run variation and gating only on changes that exceed it.

Limitations. The IntDEx framework notes that its application so far covers a single project with a single principal evaluator, and it presents this as preliminary evidence of feasibility rather than general proof, and independent multi-case replication is still needed. Cross-model review is advisory: it reduces the risk but does not eliminate it. Human reviewers are a failure mode too. IntDEx names automation bias, a risk the EU AI Act's Article 14 also requires high-risk systems to address, and it treats a checkpoint rejection rate of zero as a finding that needs investigation, not as a sign of quality.

Conclusion. In IntDEx, behaviour validation is not "run the tests and trust the summary". It is an evidence ledger in which every claim names its source, self-assessment is labelled UNVERIFIED, and a named human accepts or rejects the evidence. For teams moving to an AI SDLC, that is a practical first step: rank the evidence before you trust the result.

References

IntDEx Framework

IntDEx.org: https://intdex.org

Other references

NIST (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). https://doi.org/10.6028/NIST.AI.600-1
Huang, J., Chen, X., Mishra, S., Zheng, H. S., Yu, A. W., Song, X., & Zhou, D. (2024). Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024. https://arxiv.org/abs/2310.01798
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14: Human oversight. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

AI was used for readability improvements.