Abstract:

Introduction:
Large language models (LLMs) now make it feasible to deploy conversational assistants that support explanation, feedback, and problem-solving in engineering education. Educators face a mix of no-code tools, lightweight web solutions, and full software stacks, each with different implications for cost, data governance, and curricular alignment. Existing work often reports individual pilots or single-platform case studies. This paper addresses that gap by analysing three development pathways for educational AI assistants and relating them to deployment at course, programme, and institutional level.

Methodology:
The study uses a comparative design analysis. It focuses on three approaches:
(1) no-code platforms such as OpenAI GPTs and Poe, where assistants are configured through graphical interfaces;
(2) low-code solutions with HTML and JavaScript front-ends calling LLM APIs; and
(3) full developer pipelines with Python backends, Retrieval-Augmented Generation (RAG), vector databases, and Learning Tools Interoperability (LTI) integration.
Each approach is examined against criteria including development effort, pedagogical flexibility, maintainability, cost, data governance, scalability, and LMS integration. The comparison is grounded in realistic scenarios in engineering education, such as a course-level tutor, a domain-specific assistant for laboratory or design work, and an institution-wide assistant with analytics.

Results:
The analysis shows that no-code platforms are well suited for rapid prototyping and early experimentation. They allow educators to design assistants with minimal technical skills, but offer limited control over model configuration, data routing, and authentication, and only basic LMS integration. Low-code solutions require modest technical skills but provide a customisable user interface and straightforward embedding into existing learning environments. Their main limitations are the lack of built-in memory or RAG and the need for careful handling of API keys and privacy. Full developer pipelines demand the highest expertise and maintenance effort, but they enable domain-specific retrieval, detailed logging and analytics, fine-grained access control, and close alignment with institutional data policies.

Discussion:
Taken together, the three approaches form a spectrum rather than a ranking. No-code tools are appropriate when resources are limited and the goal is to explore use cases, involve students quickly, or run pilots. Low-code assistants are suitable for stable courses that require consistent interfaces and moderate customisation. Developer pipelines are most appropriate when institutions aim for long-term integration of AI assistants with strong requirements on reliability, traceability, and governance. Across all approaches, the study underlines the importance of LLM literacy among educators, including awareness of model limitations and the risk of over-reliance by students.

Conclusion:
Choosing a design approach for educational AI assistants in engineering education is a strategic decision that must balance accessibility, control, integration, and sustainability. Based on the comparative analysis, the paper proposes a decision framework and practical guidelines that help educators and institutional leaders match development pathways to their technical readiness and pedagogical aims. Future work should include empirical evaluation of learning outcomes and longer-term adoption.

Keywords:

AI in education, Large Language Models, no-code platforms, low-code development, RAG, educational chatbots, engineering education.