--- title: Introduction Slides type: slides order: 1 --- # Generative AI ### A Pilot === # Overview == ## A Brief History of AI

- **1940s–1950s**: neural computation, Turing’s questions and early machine intelligence - **1956 onward**: AI becomes a named research field, initially dominated by symbolic reasoning - **1960s–1970s**: strong optimism, expert systems and public investment - **AI winters**: limited computing, brittle systems, theoretical limits and unmet promises reduce confidence - **1980s–2000s**: expert systems, statistical learning, better data and larger computation - **2010s onward**: deep learning and foundation models enable broad generative capabilities - **2022+**: Chat LLM's (OpenAI launches public ChatGPT)

== ## From AI to genAI

Artificial Intelligence

Machine Learning

Deep Learning

Generative AI

Language models

Image models

Audio models

Video models

Note: - Most AI is not generative - AI: expert systems, rule-based reasoning, search and planning, **and machine learning** - Machine learning: linear regression, random forests, clustering, **and deep learning** - Deep learning: image classifiers, speech recognition, anomaly detection, and **genAI** - genAI: Many current models are multimodal and span several of the four types - Simplifications: - Generative AI sits inside deep learning in practice today, not by definition (earlier generative methods such as Markov chains were not deep learning) - Not every language model is generative: encoder models such as BERT are used to classify and embed - Language models are the focus of this module == ## AI Capabilities

Create Generate Summarize Translate

e.g. Draft text, code, images, slides Papers, meeting notes, transcripts Languages, programming languages

Understand Classify Extract Detect

e.g. Publications, species, images, emails Metadata, entities, keywords Anomalies, fraud, tumors

Find Search Recommend Predict

e.g. Semantic search over documents Papers, resources Forecast outcomes with data

Interact Converse Reason Act

e.g. Chat assistants Solve problems, infer conclusions Use tools, execute workflows, control robots

== ## Four roles for AI in research 1. Research object: study AI systems, data, behaviour or impacts 2. Research instrument: use AI to measure, classify, generate or analyse 3. Research co-creator: use AI during ideation, drafting or interpretation 4. Research infrastructure: embed AI in services, repositories, portals or workflows == ## What is an LLM? - Predicts the next token, one at a time: fluent ≠ true - Non-deterministic: same prompt, different answers - Frozen at a training cutoff: doesn't know the latest library versions - No separation between instructions and data: everything is just text in the context - Context window: everything the model "sees" — fills up, degrades, gets compacted == ## Agent = Model + Harness - **Model**: the LLM, stateless, only produces text - **Harness**: the loop around it — runs tools, enforces permissions, manages context - Tools: file edits, shell, web search, MCP servers - Skills and instruction files `AGENTS.md` - "Memory" is just files fed back into the context == ## How GenAI fits in your workflow

💬 Planning / Sparring

Discuss architecture, talk through trade-offs, get a second opinion on your design

⌨️ Tab Completion

Inline suggestions as you type — low risk, high daily value

🧱 Code Block Generation

Ask for a function, a regex, a test — review and integrate manually

🤖 Agentic Coding

Model reads/writes files, runs tests, operates autonomously — our focus today

🌟 Autonomous Agents

Execute scheduled tasks, react to web hooks, no or little user interaction

Note: - Different risk profiles per use-case == ## What You Can Use It For Today

🔍 Code Explanation

Paste unfamiliar code and ask for a walkthrough — useful for legacy scripts or inherited projects

♻️ Refactoring

Restructure working code for readability, performance, or style — with tests in place first

🧪 Tests & Docs

Generate unit tests and docstrings — read the tests, they reveal the model's assumptions

🚀 DevOps

CI config, Dockerfiles, environment files — well-covered territory with high AI reliability

=== # Strengths & Weaknesses == ## Well Suited - 🧑‍💻 Sparring partner / pair programmer / junior dev - ⚗️ Prototyping and exploring unfamiliar territory - 🤖 Automating repetitive or tedious tasks - 🌐 Popular frameworks and languages (Python, tidyverse, SQL…) - 🔍 Sifting through log files and stack traces - 📚 Learning about new-to-you technologies - 🔣 Regex (genuinely very good at this) == ## Dangerous Territory - 📜 Gigantic inputs — clobbers the context window - 🔮 Used as an oracle or on autopilot - 📈 Feature creep — it will enthusiastically build things you didn't ask for - 🧩 Niche frameworks and languages - 🧮 Statistical reasoning — wrong tools/types, silent NA drops, off-by-one errors - ✨ Looks correct ≠ works correctly

The output reads like it was written by a competent analyst. That is exactly the danger.

== > "LLMs doesn't know they are wrong. They don't know anything. They are very good at sounding right." > > – Claude.ai, asked about LLMs Note: Who said this quote? LLMs are a **pattern matcher**, not reasoner: - Hallucinations - Overconfidence - Domain Weakness == ## Up-Skill rather than De-Skill

Locate technical information quickly
- Instead of reading through multiple documentation pages, you can ask AI to find the relevant function, argument, or method for your task.
Summarise key concepts
- AI can condense long documentation into concise, understandable explanations. You can even ask AI to tailor explanations to your code and dataset.
Clarify ambiguous points
- You can follow up iteratively, asking AI to rephrase explanations or provide examples.
Code comprehension
- Paste code generated by AI or colleagues and ask for line-by-line explanations.
Contextual learning
- Ask why certain functions or methods are used, what alternatives exist, and best practices.

== ## Exercise 1: AI Battle (15 min) === # Access & Deployment == ## Hosting

RouteUseful when …

Commercial hosted service Fast access and broad capability matter

Ask: What data is retained, where, for how long and under which terms?

EU-hosted service Jurisdiction, procurement or institutional policy matters

Ask: Which legal entity, subprocessors and service commitments apply?

Institution-hosted service Sensitive data or local integration matters

Ask: Who operates it, who can access logs and how is it maintained?

Local model Data must remain within a controlled environment

Ask: What quality, update, support and security trade-offs follow?

Note: - The routes run from most convenient (commercial) to most control (local) - Open-weight models are a property of the model, not a hosting route: they can run on any of these routes - Useful when inspectability, adaptation or local execution matters - Ask: What do the licence, training-data disclosures and hardware needs permit? == ## Residency vs Jurisdiction - **Residency**: where the data is stored and processed - **Jurisdiction**: whose law applies to the provider - An EU datacenter run by a US company is still subject to the US CLOUD Act - Also check: Data Processing Addendum (DPA), Zero Data Retention (ZDR), subprocessors, no training on your data Note: - DPA, ZDR - see Exercise 2 "Client Settings" - Some LLM "vendors" offer models themselves, others are _routers_ that broker between you and other vendors - Now you have _two_ companies to check == ## Cost Model - **Subscription**: flat fee, usage limits - **API**: pay per token, input and output priced separately - Agentic use consumes far more tokens than chat — the whole context is re-sent every turn - Cache hits are cheaper, but cost still piles up - Larger models cost more: match model size to the task Note: - Input tokens: what you type - Output tokens: what the LLM returns - Cache: input + output of previous turns - The agent processes _the entire conversation_ every turn - Tips - Start a new conversation for a new topic - Use cheaper models for simpler tasks - Play with the "thinking" level of models == ## A Framework for Tool Assessment

- **Purpose** What research task is being supported, and what would count as success? - **Data** What information enters the system, and is it sensitive, personal, confidential or unpublished? - **Control** Who can inspect, correct, stop and reproduce the workflow? - **Evidence** How will quality, bias, uncertainty and failure be checked? - **Governance** Which policies, licences, contracts and responsibilities apply? - **Continuity** Can the work be rerun if the model, provider or interface changes?

=== # Security, Biases & Ethics == ## A Risk Map for Research Support

🎯 Reliability

🔒 Privacy

🛡️ Security

⚖️ Bias

🔁 Reproducibility

🌱 Sustainability

Typical failure
Plausible but false claims, fabricated references or buggy code

Support response
Require source checking, tests, domain review and uncertainty labels

Typical failure
Sensitive prompts or files reach an external provider

Support response
Classify data, use approved environments and minimise inputs

Typical failure
Prompt injection, malicious content, unsafe tool calls or leaked secrets

Support response
Limit permissions, sandbox actions and review connected tools

Typical failure
Training data or evaluation gaps shape outputs

Support response
Examine affected groups, document limitations and seek domain expertise

Typical failure
Outputs or training data create unclear reuse conditions

Support response
Check licences, provenance, attribution and institutional guidance

Typical failure
Model, prompt, retrieval context or interface changes

Support response
Record versions, inputs, settings, outputs and review decisions

Typical failure
Resource-intensive computation or duplicated infrastructure

Support response
Match model size and frequency to the task; prefer proportionate use

Note: - Privacy includes confidentiality - Bias includes representativeness - Copyright includes licensing == ## The Lethal Trifecta Dangerous when an agent has **all three**: 1. Access to private data 🔐 2. Exposure to untrusted content (web pages, issues, emails, files) 🌐 3. A way to communicate externally 📤

Remove one leg, and prompt injection loses most of its teeth.
Sandboxing can help protecting against injection and mistakes.

== ## Licensing - Purely AI-generated output is likely not copyrightable (US and EU) - Open-source licences rely on copyright, so licensing purely AI-written code is shaky - Generated code may reproduce licensed code verbatim - Snippet scanners exist (e.g. SCANOSS), but tooling is immature - Vendor "public code" filters and indemnities shift liability, but don't guarantee clean code - Some open-source projects restrict or ban AI-generated contributions == ## Exercise 2: Checking AI Client Settings (15 mins) === # Practice == ## Good Practices 1. Before touching code, discuss the architecture with the AI — it's a good sparring partner 2. Ask it to review your plan and surface edge cases you haven't considered 3. Supply links to relevant documentation in your prompt 4. Write the agreed plan to a file — this becomes compact context for future sessions Note: - Also see tab "Prompt Engineering" == ## The Prompt Framework **Role + Context + Task + Constraints + References**

Role	"You are helping an RSE writing a data analysis pipeline in Python…"
Context	Hardware, data format, scale, existing codebase, language/version
Task	Specific, measurable outcome — not "make it faster", but "reduce runtime below 30s on 10GB input"
Constraints	Memory limits, coding conventions, libraries allowed, what must not change
References	Package docs, similar code, API specs — especially for niche libraries

Note: - The better models get, the less important the "Role" becomes == ## Prompt Engineering Tips

- Start broad ➜ discuss ➜ refine ➜ add constraints before implementation - Ambiguity during implementation is dangerous — be precise about signatures, types, return values - Ask for options: "Give me three approaches and their trade-offs" - Ask for steps: "Walk me through this optimisation step by step" - Provide examples: "This R function does X — implement the equivalent in Python" - Explaining the problem clearly helps you understand it better too

Note: - Writing a good prompt _requires the same clarity as writing a good specification_. - If you can't write a good specification, you have not fully defined the problem yet. == ## Transparency about AI Record, where relevant: - purpose and research activity - tool, provider, model and access route - date or version information - data or context supplied - material generated, transformed or evaluated - human review and verification performed - limitations, uncertainty and unresolved concerns - how the use affected authorship, attribution or interpretation == ## Exercise 3: AI Declaration Tool (15 min) === # Wrap-Up == ## Key Takeaways - Generative AI is a changing capability family. - Good advice starts with purpose, data, control, evidence, governance and continuity. - Human review, domain knowledge and reproducible records remain central. - Tool choice should follow the research workflow and institutional context. - Research support professionals can turn broad principles into practical routes for safe, FAIR and sustainable use. == [www.esciencecenter.nl](https://www.esciencecenter.nl) info@esciencecenter.nl 020 - 460 47 70

Generative AI

Resources and further reading: