8  Future Trajectory and Vision

My vision for the coming years is structured around three horizons: consolidating the support ecosystem, creating a new advanced course offering, and formalizing my pedagogical research (SoTL).

8.1 Horizon 1: GPT-CDA Next Step (Phase 2, 2026-2027)

8.1.1 Why a Phase 2

Phase 1 made it possible to develop the agent, integrate it into CDA facilities, train staff, test in real conditions, and progressively deploy the tool.

Phase 2 now targets sustainability and service expansion: instead of depending on an external interface, the objective is to build an institutional in-house web platform that accesses the model via an API and enables a controlled, scalable experience integrated with CDA needs.

8.1.2 Vision: Hybrid Online Platform (AI + Teaching Assistants)

The core of Phase 2 is native integration of a hybrid online pathway:

  • students use GPT-CDA in self-service mode
  • during opening hours, they can be transferred to an online teaching assistant (chat)
  • transfer preserves relevant history and context to make human intervention more effective

This step is also a direct response to accessibility challenges: supporting students who cannot physically come to the CDA and better covering needs beyond in-person support.

Note

Pedagogical positioning Phase 2 does not aim to replace human support. It organizes help into two layers: handling simple or recurrent requests through the agent, then human intervention when needed, with continuity of context.

8.1.3 Operational Objectives of Phase 2

  1. Design and deploy an in-house API-based web platform, including UL authentication, access control, logging, and administration tools.

  2. Integrate a hybrid pathway: interaction with GPT-CDA, then transfer to an online teaching assistant with context preservation during opening hours.

  3. Implement and document a fully remote version of the service (agent + human interaction) in one course, then extend to all courses supported by the CDA.

  4. Evaluate acceptability and large-scale adoption conditions: preferences (human, AI, mixed), barriers, user and non-user profiles, usage trace analysis.

  5. Produce reusable deliverables: responsible-use guide, technical documentation, implementation recommendations.

8.1.4 Implementation Plan (May 2026 to April 2027)

Phase 2 is planned from May 1, 2026 to April 30, 2027.

  1. Analysis and specifications (May to June 2026)
    • consolidate Phase 1 feedback, clarify student pathway
    • confidentiality requirements, monitoring needs, transfer modalities to teaching assistants
  2. In-house platform development (June to September 2026)
    • authenticated web interface (UL account)
    • conversational model integration via API
    • access management, minimal logging, admin dashboard
  3. Online human support module (September to October 2026)
    • teaching assistant chat with queue management
    • transfer mechanism from GPT-CDA preserving relevant context
  4. Operational pilot and testing (October to December 2026)
    • controlled deployment in one fully remote course
    • student and assistant feedback, fixes, stabilization
  5. Expanded deployment and evaluation (January to April 2027)
    • extension to all CDA-supported courses
    • training and documentation
    • acceptability study (survey, focus groups, usage analysis)

8.1.5 Evaluation: What Will Be Measured and Why

Phase 2 explicitly documents adoption conditions to guide deployment decisions and continuous improvement.

Indicators and typical questions:

  • platform usage volume and recurrence
  • rate of transfer to teaching assistants and when transfer occurs
  • satisfaction, perceived utility, preferences (human, AI, mixed)
  • profiles of students who adopt or do not adopt, reported barriers

8.1.6 Risk Management and Responsible Implementation

Phase 2 includes explicit attention to:

  • limiting out-of-scope responses (guidance toward course concepts and methods, pedagogical framing, redirection in case of uncertainty)
  • confidentiality and data minimization (clear student information, validation of retention parameters)
  • academic integrity: support for process rather than generation of final answers when inappropriate
  • data collection under required authorizations, including ethics process when needed
Warning

Watch point The added value of Phase 2 depends on two difficult but essential elements: governance (access, logging, confidentiality) and context transfer to humans. The in-house platform is precisely the lever that makes these elements controllable.

8.1.7 Expected Outcomes and Sustainability

Expected outcomes:

  • increased accessibility to support (including for remote students)
  • reduced waiting times and better support continuity
  • better use of teaching assistants’ time (higher-value interventions)
  • reusable model adaptable to other contexts

Sustainability:

  • the in-house platform reduces dependency on an external interface and facilitates maintenance
  • technical documentation and user guide support continuity beyond grant funding

8.2 Horizon 2: STT-4230 / STT-6230 - Programming for Data Science: Development of the New Course (Summer 2026)

8.2.1 Context and Pedagogical Intent

In summer 2026, I am developing a new version of STT-4230/6230 Programming for Data Science. This redesign aims to align the course with current practice: students should not only write code that runs, but learn to design, structure, test, optimize, document, and deliver reproducible artifacts in a collaborative setting. The course is explicitly designed for students who already have R experience, so class time can focus on intermediate-to-advanced competencies: project engineering, performance, software architecture, and full model lifecycle.

8.2.2 Course Vision: Moving from “Script” to “Product”

The redesign is guided by a progressive transition:

  • from one-off scripts to structured projects
  • from local results to shareable deliverables (reports, dashboards, web apps)
  • from individual code to collaborative code (versioning, review, documentation)
  • from “I can run something” to “I can deploy and maintain a pipeline”

The objective is that students leave the course able to deliver a mini data-science product: a clean repository, a clear pipeline, reproducible analyses, and the ability to diagnose, maintain, and evolve the project.

8.2.3 Modular Architecture (Planned Progression)

The course is organized in modules following a real production logic, where each block enables the next.

  1. Structuring data-science projects
    • directory conventions, file organization, reproducibility principles
    • dependency and environment management
    • versioning best practices and commit strategy
  2. Data handling and management
    • import, validation, cleaning
    • robust and traceable transformations
    • output structuring (clean tables, exchange formats)
  3. Visualization
    • exploratory visualization and communication
    • principles of readability, coherence, and graphical honesty
    • graphics as components of a reproducible pipeline
  4. Reports, web apps, and dashboards
    • reproducible reports (generation, parameters, templates)
    • decision-oriented dashboards
    • web apps for interaction and dissemination
  5. Object-oriented programming
    • motivation in data science (stable interfaces, rich objects, methods)
    • object design for analytical workflows
    • user-oriented design: prints, summaries, diagnostics
  6. Functional programming with tidyverse and pipelines
    • transformation composition
    • readable, testable, reusable pipelines
    • “data in, data out” principles and pure functions when possible
  7. Profiling, optimization, and performance management
    • identify bottlenecks
    • optimize without harming readability
    • tradeoffs: performance, maintainability, reproducibility
  8. Asynchronous and parallel programming
    • when parallelization is relevant
    • structuring parallelizable tasks, avoiding common errors
    • robustness: error handling, logs, result reproducibility
  9. End-to-end model pipeline and hyperparameters
    • structuring full machine-learning pipelines
    • train/validation/test separation
    • hyperparameter tuning and data-leakage prevention
  10. Model deployment and production
  • turning a model into a service or reusable component
  • producing consumable outputs (API, report, app)
  • minimum requirements: documentation, tests, versioning
  1. Model lifecycle
  • continuous monitoring: drift, degradation, updates
  • logging, monitoring, and quality maintenance
  • reflection on model governance and responsibility
  1. Collaboration and documentation: package
  • turning a project into a reusable package
  • user and developer documentation
  • team collaboration: issues, code review, conventions, continuous integration

8.2.4 Assessments and Deliverables (Orientation)

Assessments will be aligned with delivery competencies:

  • recurring deliverables as structured, reproducible repositories
  • artifact production: report, dashboard, or web app
  • software components: objects, functions, pipeline, tests, documentation
  • final integrative project: a complete mini-product (data -> pipeline -> deliverable -> lightweight deployment), with collaboration and traceability requirements

8.2.5 Expected Outcomes

This redesign aims to produce a clear increase in autonomy and programming maturity: less trial-and-error, more intentional design; fewer fragile scripts, more maintainable projects; and a concrete understanding of what it means to put analysis, models, and code into production in real environments.

8.3 Horizon 3: Pedagogical Research (SoTL)

I plan to formalize my approach through academic publication on university pedagogy.

  • STT-1100 analysis: an article documenting course design is in preparation. A longitudinal study on skill retention is also envisioned to evaluate whether students immersed in the STT-1100 narrative retain better programming habits throughout their program.

  • Competition club: launch of a student club for Kaggle/hackathon competitions, which will also serve as an observation site for informal and peer-based learning dynamics.

8.4 Conclusion: A Pedagogy of “Doing Together”

Across these projects, my trajectory remains guided by one conviction: teaching statistics is not the transmission of inert knowledge, but an invitation to join a living, tool-enabled, and ethical community of practice.