Insights
Research, observations and practical thinking on how people work with AI.
At universities of applied sciences, HBO-ICT teachers are preparing future developers for a profession where AI can produce working code before students understand the problem. What should educators protect?
A strategic guide for Dutch universities of applied sciences redesigning programming assessment around validity, AI literacy, portfolios, oral evidence, process, workload, and policy consistency.
What Npuls’ 2025 vision on AI-aware assessment says—and what programming educators must decide when applying it to local courses.
How to teach professional judgment in AI-assisted programming through decisions about data, security, verification, licensing, attribution and transparency.
A nuanced framework for deciding when agentic coding tools make educational sense in HBO-ICT, based on learning outcomes, student level, task type, evidence, and professional relevance.
How HBO-ICT programmes can review existing software-development outcomes and decide what to keep, update or add as AI changes the work.
How lecturers can assess an individual student’s outcome-relevant contribution to shared software work without treating commits, code volume, or AI records as proof.
Give feedback tied to an observable programming decision or check, then make the student’s next action clear without inferring hidden traits from AI use.
A nuanced description of healthy AI-assisted programming learning, focused on questioning, verification, reformulation, correction, and growing judgment rather than one ideal trajectory.
A conceptual case for treating the development journey—task, exploration, decisions, revision, verification, and result—as an educational object alongside final code.
A framework for distinguishing the submitted artifact, the AI contribution, student decisions, understanding, and demonstrated competence without pretending they can always be perfectly separated.
Concrete teaching decisions for helping programming students frame tasks, evaluate agent output, verify behavior and explain technical choices.
A vendor-aware but tool-neutral evidence checklist for HBO-ICT students using coding agents, focused on decisions, modifications, testing, verification, and understanding.
A practical comparison of AI-use declarations, screenshots, prompt logs, repository evidence, reflective forms, and selective process reconstruction.
How lecturers can select and interpret evidence across AI-assisted programming tasks when judging a learning outcome over time or across contexts.
When a short oral explanation can provide evidence for a programming learning outcome, how to ask a focused question, and what the response cannot establish.
A lecturer-focused guide to interpreting evidence of a student’s responsibility for AI-assisted code: what it supports, what remains uncertain, and when a fair follow-up may help.
How HBO-ICT programmes can turn institutional AI requirements into clear programming-education rules, responsibilities and exception routes.
How programming courses can align learning claims, AI conditions and evidence across assessments to support fair, defensible judgments about student learning.
A practical guide to disclosing material AI use in a programming assignment, with examples shaped by the task, permitted AI role and contribution.
A practical framework for assessing problem framing, exploration, design choices, iteration, testing, correction, explanation, and result in programming work.
How to design programming tasks that still require meaningful student decisions when AI is available, without claiming any task can be AI-proof.
A practical guide for examining student decisions, modifications, debugging, testing, integration, and explanation when an AI tool contributed to a programming submission.
How lecturers can select proportionate evidence from AI-assisted programming work and interpret it alongside the final artifact and learning outcomes.
How programming lecturers can interpret an AI-detection signal without treating it as proof of authorship, learning, rule violation or misconduct.
How Dutch HBO-ICT programmes can move from isolated assignment rules to a coherent programme-level approach to AI-aware programming assessment.
A practical HBO-ICT guide to aligning an AI-assisted programming assignment’s learning outcomes, task, AI conditions, evidence and assessment.
How to distinguish AI-agent activity and output from verification, accepted work, delivery, engineering outcomes and business outcomes.
Why the percentage of developers using an agent is only the beginning, and which workflow, quality, cost, and outcome signals should follow.
A taxonomy of adoption, usage, workflow, cost, quality, and outcome metrics, with guidance on the question each one can and cannot answer.
A nuanced look at how AI redistributes engineering effort across exploration, implementation, debugging, review, verification, and decision-making.
Why generated volume is an especially weak productivity signal in AI-assisted engineering, and what to observe instead.
A practical guide to cycle time, rework, throughput, review burden, quality, AI activity, complexity, time saved, and developer experience.
Evaluate whether AI-assisted development changes the wider developer-work system without treating activity, output or reported time savings as productivity.
Why a €0.70 session and a €2.00 session cannot be compared meaningfully without task, workflow, quality, and outcome context.
How to evaluate Claude Code, Codex, and GitHub Copilot against task fit, pricing model, workflow, review effort, scale, and measurable outcomes.
Evaluate AI coding tools economically by defining the alternative, incremental costs, attributable benefits, valuation and uncertainty before calculating ROI.
How engineering teams can verify an agent’s completion claim against the artifact, checks, review and acceptance conditions that matter for a change.
A bounded guide to distinguishing corrections, changed requirements and iteration—and why a change count is not a quality or productivity result.
How to evaluate an AI-assisted code change: choose the quality property, interpret tests and review in scope, and separate acceptance from later outcomes.
A practical outline for an internal AI coding policy covering tools, data, review, security, accountability, measurement, and exceptions.
Practical ways to balance control and developer usefulness through risk tiers, safe defaults, review boundaries, and learning loops.
A practical governance framework covering tools, data, access, traceability, review, security, accountability, measurement, and incidents.
A careful comparison method that normalizes for team responsibility, task type, project maturity, technology, complexity, and workflow.
A practical answer to “what belongs on the dashboard?” across adoption, usage, cost, workflow, quality, outcomes, and developer experience.
Design a useful way to measure AI coding agents: define the work unit, denominator and evidence before deciding what the metrics can show.
How engineering leaders can think about building an internal AI coding usage dashboard versus using a maintained specialist reporting product.
The evaluation questions a controlled TraceYield founding pilot should answer before broader enterprise validation.
How engineering organizations can manage AI coding expenditure without hidden surveillance or simplistic developer rankings.
Why AI coding spend, token totals, and model usage dashboards need engineering outcome context before they can support management decisions.
A practical guide for engineering managers who need AI coding governance, usage visibility, and developer trust without ranking engineers by raw token consumption.
A practical manager guide to reducing avoidable AI coding cost by improving prompts, context discipline, retries, verification, and model routing instead of cutting useful developer adoption.
A manager-focused guide to interpreting AI coding token variance without turning raw usage into a misleading developer KPI.
Why AI coding bills grow when retry loops, broad context, vague requirements, and poor model-routing decisions turn a simple task into an expensive trajectory.
A personal introduction to TraceYield, why it exists, how it helps engineering teams understand Codex, Claude Code, and GitHub Copilot usage, and why security and developer trust matter.
No insights found.
Try another search or category.