Tampere University AI-native Software Master's Thesis Guide: 30 ECTS, Software Web & Cloud and Trepo

What this guide covers

Tampere University now markets this study option as AI-native Software, a 120 ECTS, two-year Master of Science specialisation in the Faculty of Information Technology and Communication Sciences. There is an important curriculum detail behind that new name: the current 2026–2027 Student’s Guide still presents the underlying MSc specialisation as Software, Web & Cloud inside the Master’s Programme in Computing Sciences and Electrical Engineering (CSEE). This guide therefore uses the current applicant-facing name while explaining the curriculum name that students will still encounter in the Student’s Guide and Sisu.

For the current MSc structure, the decisive curriculum object is CSEE-SWCY. It states that the 120 ECTS degree contains 50 ECTS of advanced studies in the specialisation, a 30 ECTS master’s thesis on a topic inside the specialisation, and 40 ECTS of other studies, including joint, free-choice and possible complementary studies. The thesis is therefore 30 ECTS. That does not make it a Technology diplomityö: this route awards Master of Science, not Master of Science (Technology), so the current non-technical master’s-thesis process is the relevant university-wide framework.

AI-native Software and Software, Web & Cloud are two names you must understand

The applicant-facing programme emphasises AI-supported software development, large and complex software systems, web and cloud technologies, and the ability to manage and improve software engineering with AI technologies. The 2026–2027 curriculum underneath that offer is still titled Software, Web & Cloud. Treat this as a naming transition, not as evidence that the older curriculum rules have vanished or that a separate set of thesis credits has appeared.

This matters when you search the Student’s Guide. A student who looks only for the phrase “AI-native Software” may miss the current CSEE-SWCY and COMP.SE-S20 curriculum records. Conversely, a student should not assume that every detail from an older Software, Web & Cloud curriculum remains unchanged. For each administrative or thesis decision, use the current academic-year record and your current Sisu study plan.

The 120 ECTS structure and the 30 ECTS thesis

CSEE-SWCY gives a clear MSc structure: 50 ECTS advanced studies + 30 ECTS master’s thesis + 40 ECTS other studies = 120 ECTS. The thesis topic must sit inside the specialisation. The advanced-studies curriculum, COMP.SE-S20, is current through 2026–2027 and covers software engineering rather broadly.

The curriculum is not divided into compulsory branches. It describes useful planning directions such as network solutions and large-scale software engineering/software production, but these are guiding groupings rather than mandatory thesis tracks. Current subject areas include web development, cloud technologies, data-intensive programming, Internet of Things, software testing, requirements engineering, DevOps, software architecture, secure programming and sustainable software engineering. Systems may also contain machine-learning components.

This means an appropriate thesis can be “AI-native” without being a thesis about training a new model. The academic fit comes from the research problem and its relationship to the specialisation, not from inserting generative AI into the title.

What a defensible thesis topic looks like

Start with a researchable software problem rather than a fashionable tool name. A strong topic should let you formulate a question that can be answered with evidence inside the time and access constraints of a 30 ECTS project. Examples of defensible directions include architecture trade-offs in AI-assisted services, evaluation of AI-supported development workflows, software testing for systems containing AI components, cloud deployment and observability, security of AI-integrated applications, data-intensive web systems, sustainable software engineering, requirements engineering, DevOps, code-quality interventions, or empirical study of development practices.

A title such as “Using ChatGPT in Software Engineering” is normally too broad. A stronger formulation identifies a context, intervention or phenomenon and an outcome that can be evaluated. For example, you might compare two code-review workflows on a defined repository set, investigate failure patterns in an AI-assisted test-generation pipeline, or evaluate an architectural decision against latency, cost, reliability and maintainability criteria.

If the topic comes from a company, distinguish the company problem from the academic research question. “Build this feature” is a project brief. A thesis needs a justified question, method, evidence and analysis that can be examined independently of whether the company deploys the feature.

Choose the method from the research question

Tampere’s non-technical master’s-thesis framework allows empirical research and literature-based research. In software and computer-science work, useful empirical approaches can include controlled experiments, benchmark studies, case studies, repository mining, architecture evaluation, surveys, interviews, mixed methods, design-science work and comparative prototype evaluation. A systematic or structured literature study can also be defensible when it answers a sufficiently specific question with a transparent search and synthesis method.

Do not begin by deciding that the thesis must contain a neural network, survey or prototype. First state the research question. Then ask what evidence would genuinely answer it. If the question concerns performance, you need a defensible workload, metrics, baseline and environment. If it concerns developer experience, you may need human-participant evidence. If it concerns architecture, you need explicit quality attributes and a method for comparing alternatives.

AI-assisted software research needs unusually clear validation

AI-native software can create attractive demos very quickly, but a demo is not validation. If you claim that an AI-assisted workflow is faster, safer, cheaper or more accurate, define what those terms mean and how they will be measured. Record the model/tool version where relevant, prompts or configuration needed for reproducibility, repository or dataset selection, hardware/cloud environment, baselines, randomisation conditions and exclusion criteria.

Separate tool output from research evidence. Generated code is an artefact. A generated explanation is not a scholarly source. An AI-produced test suite does not prove the system is correct. Your thesis should show how outputs were independently checked and how the evidence supports the conclusion.

For stochastic systems, one successful run is weak evidence. Repeated trials, uncertainty reporting, error analysis and sensitivity to prompts/configuration may be needed. If a proprietary model changes during the project, document that limitation instead of pretending the system is static.

For developer-productivity studies, decide what counts as productivity before collecting results. Completion time, accepted code changes, defect rate, review effort, task success and perceived workload are not interchangeable. If participants use different prior tools or have different experience levels, record that as a potential confounder. A claim that an AI assistant “improves productivity” should state exactly which outcome changed, under which tasks, compared with which baseline.

For software-quality studies, avoid relying on a single proxy. Passing unit tests does not prove maintainability or security; static-analysis findings do not automatically predict runtime failures; subjective code-quality ratings need a defensible rating procedure. COMP.SE-S20 explicitly spans testing, architecture, secure programming and sustainable software engineering, so your evaluation can draw on multiple quality dimensions when the research question requires it.

Security-sensitive AI integration also deserves threat modelling. Consider prompt injection, data leakage, dependency risk, insecure generated code, excessive permissions, model/API failure modes and logging of sensitive content where relevant. A thesis does not need to test every threat, but it should justify which threats are inside and outside the chosen scope.

Reproducibility and software-version control

Software results can depend on library versions, operating systems, hardware accelerators, cloud instances, compiler flags, API versions, database state and configuration. Record the conditions that materially affect your result. If the experiment uses a repository, identify the commit or release. If it uses a dataset, record provenance, version and preprocessing. If it uses an external API, document the relevant model/service version and date.

Keep an experiment log. A small table containing run identifier, code commit, configuration, input data, environment and output location can save days of reconstruction later. Store scripts and configuration separately from the prose so that you can rerun analyses when a bug is found.

Literature review and research grounding

AI-native software changes quickly, which makes research grounding more important rather than less important. Start with peer-reviewed research and authoritative technical sources appropriate to the claim. Use vendor documentation for product behaviour, not as the sole evidence for broad academic claims about effectiveness.

Your literature review should explain the research gap and the concepts needed to interpret the evidence. If your thesis is about AI-assisted software engineering, separate claims about model capability, developer productivity, software quality, security and organisational adoption. These are different constructs and may require different evidence.

Tampere recommends information-retrieval training during thesis work. Keep a search log for important literature searches, including databases, search strings, dates and inclusion decisions where a systematic approach is relevant.

Thesis seminar and supervision

Tampere’s general master’s-thesis process includes seminar work, oral presentation and acting as opponent. However, the current public 2026–2027 Software, Web & Cloud/AI-native curriculum sources used for this guide do not establish a separate current credit-bearing programme-specific seminar unit. Do not import the historic COMP.810 course merely because it existed in an earlier curriculum.

Use your current Sisu study plan, programme instructions and Moodle implementation to determine the exact seminar registration and schedule that applies to you. This is especially important during the AI-native naming transition.

The University appoints one or two thesis supervisors, including a primary supervisor. Supervision supports the work, but the student remains responsible for completing the thesis. For a company thesis, an external supervisor can support practical implementation, while academic supervision and examination remain with Tampere University.

Build a research plan before implementation expands

A useful software-thesis research plan should state the problem, research question, scope, related work, method, data or repositories, evaluation criteria, risks, ethics/data-protection issues and timetable. For an artefact-based thesis, separate the implementation plan from the evaluation plan. Otherwise implementation can consume the project while the research evidence remains underdeveloped.

Define success criteria early. If you will compare an AI-assisted method with a baseline, choose the baseline before seeing the final results. If you plan to evaluate quality, define the quality metrics and who or what assesses them. If human participants will judge outcomes, plan recruitment and analysis before collecting responses.

Company and proprietary projects

Tampere’s applicant-facing page highlights strong local IT-industry collaboration. That makes company topics realistic, but it also introduces evidence and publication constraints. Agree early on what data, source code, logs and architecture descriptions can appear in the examined thesis. A company may need confidential internal material to solve the practical problem, while the academic thesis must still contain enough public or examinable evidence for the University to evaluate your work.

Do not put credentials, customer data or proprietary code into public repositories merely for reproducibility. Reproducibility can often be supported through sanitised datasets, pseudocode, synthetic examples, configuration descriptions and clearly documented procedures.

If the company controls the production environment, agree on an evaluation plan that still allows academic scrutiny. For example, you may define metrics and analysis scripts in advance, run them inside the company environment, and export only approved aggregate results. Keep a record of what could not be independently reproduced outside the organisation and explain how that limitation affects the strength of the conclusions.

Personal data and research participants

If the thesis uses interviews, surveys, user studies, developer telemetry or other personal data, discuss processing with the supervisor before collection. An independently working student is normally the data controller for their thesis research; other controller arrangements can apply to University projects or commissioned work.

Document the purpose and scope of personal-data processing in the research plan. Prepare a privacy notice and participant information/consent materials where required. Minimise personal data, use University-designated tools where applicable, and anonymise data before analysis when identity is unnecessary. A public thesis should not identify an individual without an appropriate basis and consent.

Developer studies deserve the same care as other human-participant studies. Repository usernames, commit histories, chat logs and issue comments can contain personal data even when they are publicly visible.

Using AI under Tampere University rules

The fact that this programme is called AI-native Software does not suspend Tampere University’s academic-integrity rules. AI use in a thesis should be agreed with the primary supervisor when necessary and acknowledged according to current guidance. Students remain responsible for their own analysis and academic work.

Do not upload confidential information, personal data, credentials, unpublished company code or other protected material to external AI tools. AI-generated material must not be treated as a direct academic source. AI can support discussion, ideation or certain technical tasks when permitted, but it cannot replace the student’s analytical responsibility.

For code, verify correctness, licences, security and compatibility. For prose, verify every factual claim and citation. For data analysis, do not outsource the substantive analysis to AI and then present it as your own research reasoning.

Writing the thesis

Write while the technical work is progressing. Document the system context, research design and evaluation method before results accumulate. A software thesis often becomes difficult when implementation notes are excellent but the academic argument is reconstructed only at the end.

A useful structure is introduction and research questions, background/related work, method, system or intervention description where relevant, results, discussion, limitations and conclusions. The exact structure should follow your topic and supervisor/faculty instructions rather than a rigid universal template.

Keep results separate from interpretation where that improves clarity. Report negative or failed experiments when they materially affect the conclusion. Explain threats to validity: dataset bias, model drift, small samples, limited repositories, uncontrolled confounders, proprietary-tool opacity and measurement limitations are common examples in AI/software research.

Maturity test

A maturity test is part of the master’s-thesis process. When Finnish or Swedish language proficiency has already been demonstrated in an earlier degree as required, the thesis abstract normally functions as the maturity test and only content is assessed. When language checking is still required, the master-level maturity test is completed through the electronic EXAM route under Tampere’s current instructions.

When the maturity test does not demonstrate Finnish or Swedish proficiency, it is written in the thesis language. Maturity tests cannot be replaced through recognition of prior learning.

Turnitin, Trepo and final submission

Obtain the primary supervisor’s permission before final submission. The thesis first goes through Turnitin for originality checking. After the supervisor reviews the Similarity Report, the final thesis is deposited in Trepo, Tampere University’s institutional repository.

You must be registered as attending to submit the thesis for examination and receive credits. After Trepo deposit, the Library normally sends an access address within three working days; the student forwards that message to the examiner or examiners. Submit the final archival file in PDF/A format.

Do not confuse Turnitin with Trepo. Turnitin is the originality-check stage. Trepo is the repository and permanent electronic archive route.

Examination, grading and response rights

Master’s theses are approved by the dean based on a joint statement and grade proposal from two examiners. At least one examiner must be employed by Tampere University, and both examiners must hold at least a master-level degree. The general non-technical thesis scale is 0–5.

When the abstract functions as the maturity test, the normal combined assessment period is 21 days. When an electronic maturity exam with language checking is required, the period is 28 days. Summer submissions can follow a longer schedule, so do not build a graduation plan around the minimum assessment window without checking the current schedule.

The examiner statement and proposed grade are sent to the student’s tuni.fi email. If dissatisfied, the student may submit a written response within seven days. After the final grade is awarded, a written appeal to the Faculty Council is available within 14 days from access to the assessment result and criteria information.

After approval and graduation planning

Once a thesis has been approved, it is final and cannot simply be resubmitted as a new version. Check the archived file carefully before final deposit. All Tampere University master’s theses are archived electronically, and PDF/A is required for permanent archiving.

Thesis assessment is only one part of graduation readiness. Make sure the rest of the degree structure, study-plan approvals and required registrations are complete. The 21/28-day assessment period is not a promise that the entire graduation process will finish within that time.

A practical AI-native Software workflow

1. Confirm that your Sisu plan maps the applicant-facing AI-native Software option to the current Software, Web & Cloud MSc curriculum that applies to you.
2. Check that the proposed topic belongs inside the specialisation.
3. Convert the practical software problem into a researchable question.
4. Choose a method and define evidence, baselines and success criteria before major implementation.
5. Agree supervision and any company/confidentiality constraints.
6. Complete the current seminar/presentation requirements shown in your actual Sisu/Moodle implementation; do not rely on historic COMP.810 information.
7. Keep versioned code, experiment logs, data provenance and reproducible configurations.
8. Follow Tampere’s AI, data-protection and research-integrity rules throughout the project.
9. Write and revise alongside implementation and analysis.
10. Complete maturity requirements, Turnitin, Trepo PDF/A deposit and examiner communication.
11. Monitor the assessment and graduation schedule rather than assuming the thesis approval date alone determines graduation.

The central principle is that “AI-native” describes the current programme direction, not a lower evidentiary standard. A strong thesis still requires a precise problem, justified method, independently checked evidence, transparent limitations and conclusions that do not go beyond the data.