Design laboratory

Edition: Winter semester 2026/2027.

The Design Laboratory is a course where you will form a team to propose and execute a design idea. While the design is important, the primary focus is on the effort and processes required to build and manage the project. The objectives of this course include fostering teamwork skills, enhancing project management abilities, and developing proficiency in software development tools. You will be responsible for planning, organizing, and dividing the workload within your team, maintaining a log of your tasks, and documenting your work progress using software development tools. Throughout the course, you will enhance your problem-solving skills, improve your ability to collaborate effectively in a team setting, and gain hands-on experience with industry-standard tools. A wise design choice and reliable plan are crucial for a smooth journey through the semester.

During the course, you will be required to utilize the following software development tools as part of your workflow:

git for source code management,
Forgejo, a web based collaborative software development platform (software forge) tightly integrated with git,
Pixi, a fast, modern, and reproducible package management tool for developers of all backgrounds.

If you are attending this course, please read this whole page carefully. In the case of any ambiguity in the content, you will have a chance to ask questions on dedicated Forgejo's issue board or in-person meetings.

Table of content

Staff

The laboratory staff consists of one instructor, Szymon Woźniak, that will supervise you during this course. Click for information about office hours or contact details.

Prerequisites

This course does not have a strict prerequisites. However, a fundamental knowledge and skills obtained in the previous courses are essential for smoothly completing this course. The most important abilities you should have are the following:

self-study,
search for the information in the books, literature, and internet,
good programming and algorithmic skills.

Laboratory organization

In this section, you will find some details about laboratory organization throughout the semester. There will be 14 laboratory meetings, which are divided into three meeting types. Types are as follows:

Proposal meeting (3 meetings),
Project meeting (10 meetings),
Evaluation meeting (1 meeting).

Most of meetings are in the form of not obligatory consultations, where you can come to discuss or consult your project development with me. Although, sometimes I might invite you to review and discuss your work as a part of grading system. In the following parts of this section, there is a short description of each meeting type. Finally, the procedure for signing up for a meeting is described.

All meetings will take place at the room 310/C-3, each Thursday between 08:00 - 09:30. The detailed schedule of the laboratory meetings is available in the section Schedule.

Proposal meeting

These three meetings are in the individual or team consultation form where you can discuss anything related to your design idea with me. The purpose of the meetings is to help you prepare a suitable project proposal.

You should come to this meeting at least with preliminary design ideas, that you would like to develop in this course. In section Design expectations you can read more about expectations put on design ideas. It is recommended for preformed teams to prepare a draft version of the proposal.

If you plan to attend meeting, you are required to register in advance for each one. Check section Signing up for a meeting for details.

Project meeting

Project meetings are weekly meetings where you can meet with me to discuss progress or encountered difficulties, obtain assistance in planning the immediate steps, or consult whatever you like. Since the meeting duration might be relatively short, you should be well-prepared.

If you plan to attend the meeting, you are required to register in advance for each one. Check the section Sign up for a meeting for details.

Some Project meetings will also include the review. You will be notified about it beforehand via e-mail. So keep in mind that I can register you for a meeting for the purpose of the project review, even if you didn't plan to come.

Evaluation meeting

The evaluation meetings is a final review of the project, where you will have to demonstrate your proficiency in the project code base and what have you achieved through semester.

Signing up for a meeting

If you are interested in attending a particular meeting, the signing up procedure for each meeting is as follows:

Send me a message via e-mail stating that you would like to schedule an appointment. You should send your message before 17:00 o'clock the day before the day on which the meetings take place. According to current schedule the deadline for sign up is 17:00 Wednesday. The title of the message should be something like that: [design-lab] Signing up for a meeting. The message should at least briefly explain the aim of our meeting, however if you do it in more detail, I will probably be in a better position to help you. If you plan to come with other team members, state who is coming with you, and add them to correspondence as carbon copy (CC) receivers of this message.
After 17:00 o'clock, I will prepare a detailed schedule of the meetings for the next day based on the messages received. In response to your message, I will send you the exact time slot of our meeting so that you do not have to wait in line. You can expect the reply from me between 17:00 and 18:00.

Very important remark

Don't forget to check the e-mail even if you didn't sign up for a particular meeting, since you can be invited for project review!

Schedule

The winter semester spans 18 weeks, providing ample time to accommodate all 14 scheduled meetings. The first three meetings will focus on project proposal discussions. The next 10 meetings are reserved for consultations on project development and reviews. The remaining meeting will be used for the final evaluation of your project.

Additionally, the following notation was applied for dates:

Strike-through ~~dates~~ indicate canceled meetings due to various reasons,
- indicates that no update is expected for given cell.

week	lab nr	date	description
01	01	2026.10.01	Proposal meeting#01.
02	02	2026.10.08	Proposal meeting#02.
03	03	2026.10.15	Proposal meeting#03.
04	04	2026.10.22	Project meeting#01.
05	05	2026.10.29	Project meeting#02.
06	06	2026.11.05	Project meeting#03.
07	07	2026.11.12	Project meeting#04.
08	08	2026.11.19	Project meeting#05.
09	09	2026.11.26	Project meeting#06.
10	10	2026.12.03	Project meeting#07.
11	11	2026.12.10	Project meeting#08.
12	12	2026.12.17	Project meeting#09.
13	-	~~2026.12.24~~	Winter break.
14	-	~~2026.12.31~~	Winter break.
15	-	~~2027.01.07~~	Wednesday schedule.
16	13	2027.01.14	Project meeting#10.
17	14	2027.01.21	Evaluation meeting.
18	-	~~2027.01.28~~	-

Grading policy

The laboratory uses a standard university grading scale, beginning with 2.0 as a failing grade and passing grades from 3.0 to 5.0 with a progression of 0.5. It progressively denotes students’ performance from satisfactory to very good. The final laboratory grade is calculated based on the grade coefficient $\sigma$ . In the following paragraphs, you will learn how to calculate this coefficient and the final laboratory grade.

During the semester, you will acquire points for performing graded tasks. The table below lists grade segments, their scopes and weights.

$i$	Grade segment	Segment scope	$\psi_i$
1	The proposal	Team	$0.10$
2	The review	Individual	$0.50$
3	The log	Individual	$0.25$
4	The report	Team	$0.15$

The assessment of the whole project is divided into four separate segments. Each segment is either in individual or team scope. The points within individual segments are assigned to each student and are based on individual performance. So as a result, each person within a team can obtain a different amount of points in those segments. On the other hand, points within team segments should be a result of collaborative effort and therefore each person within the team will receive the same amount of points. The laboratory grade coefficient $\sigma$ is calculated as weighted arithmetic mean using the following formula

\sigma = \left\lfloor P \cdot \left( \sum_{i=1}^{4} \frac{\omega_i}{\Omega_i} \cdot{} \psi_i \right) \cdot \left( \sum_{i=1}^{4} \psi_i \right)^{-1} \right\rfloor ,

where $\lfloor x \rfloor = \max \{ k \in \mathbb{Z} : k \leq x \}$ , $0 < P \le 100$ is a project coefficient, $\omega_i$ denotes the number of points that the student got from $i^{\mathrm{th}}$ segment, $\Omega_i$ denotes the maximal amount of points within the $i^{\text{th}}$ segment, while the contribution of the $i^{\text{th}}$ segment to the grade coefficient $\sigma$ is given by weight $\psi_i$ .

The project coefficient $P$ reflects the overall quality of the design idea, its engineering advancement, and how well the project's required work hours correspond to the size of the team. The initial value of $P$ is estimated based on the proposal, so you will know where you stand. The final value of project coefficient $P$ is set during the evaluation meeting. By the rules, final value of the project coefficient can't be lower than its initial estimation.

In summary, the project coefficient depends solely on the design, all the other points you can collect during the semester depend on how you deliver and develop that design.

Note that the team must submit the proposal and the report to be eligible for a passing grade.

The final laboratory grade is strictly determined by a grade coefficient $\sigma$ and the table below presents the dependency between the final laboratory grade and a grade coefficient.

Final Grade	Interval
2.0	$\sigma \in (-\infty, 50)$
3.0	$\sigma \in [50, 60)$
3.5	$\sigma \in [60, 70)$
4.0	$\sigma \in [70, 80)$
4.5	$\sigma \in [80, 90)$
5.0	$\sigma \in [90, +\infty)$

The grading scale is set according to § 13. GRADING SCALE from the AGH University of Kraków study regulations, applicable from 1st of October 2023.

Honor code

You can use any books, papers, references, and publicly available implementations for ideas and code that you may want to incorporate into your project. However, you must clearly cite all your sources in your write up and source code. The project must be a result of work done by the team. Contributions of third-party are strictly forbidden.

If you are combining your project with the project from another course, you must receive permission from the laboratory instructor. In addition, you must provide:

Clear explanation in the proposal and report the exact contributions carried out as a part of this course.
Separate reports for each course (include them in final submission as well).

Team formation

The project must be realized as a collaborative effort within a group of students. The permissible number of students in a team is up to four people, while the recommended number of students in a team is two people. The team should be formed by students with similar knowledge, technical skills, and coinciding design ideas.

The number of students in a team should be appropriately matched to the workload that design of choice requires since it is expected that each team member commit similar work hours towards developing the project. Keep in mind that the larger the team, the more time will be needed to organize its work. Also, it will be more difficult to organize work within the team well and efficiently.

The official team formation is done by submitting your proposal.

Technology stack

To ensure that all projects developed in this class can be installed, configured, and executed in a consistent manner, Pixi must be used as the primary package and environment manager. The project should be reproducible on another computer by cloning the repository and using the Pixi configuration included in the project directory to prepare build/runtime environment. All dependencies, development tools, theirs versions, and commands for common project tasks like building, running test, or running the project itself should be defined in pixi.toml as a Pixi's tasks. The project should be runnable using only Pixi without requiring user to manually install any other runtimes or dependencies other than pixi.toml file specifies. The goal of this requirement is not to prescribe a particular programming language or framework, as Pixi can provide binaries for various programming languages, but to provide a common and reproducible way of managing and running projects across various people's computers.

You, as a team, may choose in general any programming languages, packages, and development tools that are appropriate for your project as long as they are available via Pixi and are support by operating systems based on modern Linux kernel and Microsoft Windows 11. You should avoid technologies or dependencies that require a specific operating system unless there is a clear project-related justification and you obtained prior approval from the instructor. It is prohibited to use a technologies that require an access to external services during runtime unless there is a clear project-related justification and you obtained prior approval from the instructor.

It is recommended, but not limited, to use one of the following programming languages as main language for your project:

The technical support of the instructor during consultations might be limited when you choose other programming language than recommended.

On the use of artificial intelligence tools

The AGH University has elaborated and published guidelines on the responsible use of artificial intelligence in the educational process within the AGH academic community (only Polish version of this document is available). For this class, the use of AI tools is allowed only after appropriate documentation has been provided (pol. poziom Korzystanie tylko po odpowiednim udokumentowaniu) in accordance with AGH’s scale for the use of AI in academic education (only Polish version of this document is available).

So, you are permitted to use AI tools to support and assist you in your software projects. However, you remain fully responsible for all code included in your project, regardless of whether it was written by you or generated with the assistance of AI tools. If you are using the AI tools, then you are expected as well to be proficient in reading, understanding, reviewing, debugging, and modifying code contributed by AI tools. Using AI tools does not replace your responsibility to understand the software you submit. You should be able to explain the purpose, behavior, and relevant design decisions of the code you submit, and you should not include AI-generated code that you cannot understand or maintain. Failing to comply with those requirements, might cause you to fail the class.

Disclosure of AI contributions

The changes of the project contributed by AI tools must be documented clearly in the project repository by labeling committed changes with [AI] tag at the beginning of the commit message.

Any commit whose message starts with [AI] must contain only changes contributed by AI tools. Such a commit must also include a file with the corresponding AI session data in human readable form, containing AI models metadata, the complete prompts and responses exchanged with the LLMs that generated changes you are committing.

In other words, an [AI] labeled commits must be fully traceable to the AI-assisted session that produced its changes.

A great example of documenting the AI session data in a human readable form is session feature of pi.dev harness for AI agents. Example session export in HTML form from this agent harness is available here for inspection, and it is set as a gold standard for documenting your work with AI. You are expected to include similar files for documenting your AI assisted sessions.

The changes to the code generated by AI tools that you introduces personally (manually) must be committed to the repository in a separate commit whose message do not start with [AI] tag. Do not mix changes generated with AI with your changes.

Project details

Design expectations

The expectation for the design is that it must be implemented as software. This means that all functionalities and processes must be developed with a programming language in the form of a source code, that can be compiled or interpreted, and in the end, executed on a computing unit.

You are free to choose any subject of your design. However, some constraints must be followed.

Each design must address a problem using engineering techniques.
The outcome of the design must be evaluable in a well-defined, repeatable, and deterministic way.
Any two teams must not carry out the same design.

The problem you choose to solve does not necessarily need to be practical. It can be abstract, unconventional, or even far from practical. The key requirement is that your design applies engineering techniques to provide a solution. However, it is recommended that the design is both practical and useful.

The design should be simple since you as the team must complete it within one semester. Note that this does not imply that the design or its realization can be trivial. It should possess some challenges that you will have to face. It is recommended to use or combine at least a few engineering techniques in your project. The total workload per team member to complete assigned work is expected to be about 90 working hours.

The proposal

The project proposal is a document that tells what you are planning to do for the project. It introduces and discusses the design idea, formalizes the subject of your project, sets your goals, and plans your work. The potential reader of the proposal should grasp a good understanding of your design idea and the plan for its realization. The proposal must be no longer than eight double-column pages with a font size of 10pt and must be written in the English language. You must use a specific template for the document.

A well-written proposal should include the information listed below, but is not necessarily limited to:

Project title.
List of team members.
Good introduction and background material on a problem you are solving with your design. Make a short discussion about why the problem is important and/or challenging in general but wider context.
Clear and precise problem formulation (or specification) with objectives.
A brief description of how you plan to solve it.
An approximate timeline of work (please refer to weeks from the laboratory schedule).
Exactly three project milestones. The milestone is a feature list you state to complete due to a date. The feature list should state, as clear as possible, of what you want to accomplish by the milestone. The milestones must have following deadlines respectively: 2026.11.14, 2026.12.12, 2027.01.19.
Preliminary division of labor between the team members.
Technology stack with a short discussion about the choice.
References.

The organization of this document is at the discretion of the team and does not need to be done in the above order. However, the specified pieces of information are requested and should be included.

You should send complete proposal to me (laboratory instructor) via e-mail. The file format of the document must be Portable Document Format (PDF). Other formats are not accepted and will be automatically rejected. Only one team member should send a proposal, but do not forget to carbon copy (CC) the message to the other team members.

The deadline for sending proposal is end of the day 2026.10.17. Proposals submitted after the deadline are subject to a 20% penalty for each day of delay.

In the reply to the message, the team will obtain the proposal coefficient $\omega_1$ and the proposed project coefficient $P$ . The proposal will be graded according to the following criteria:

Introduction, topic review, discussion (10%)
Clear problem statement (15%)
Preliminary approach description (10%)
Project plan, milestones, division of labour (40%)
Technology stack discussion (10%)
Writing and formatting (15%)

The log

The log corresponds to the overall realization of the project plan, keeping the log, and consistency of the work throughout the semester. The main aspect of this segment is the log. The basic buildings blocks of The log are git commits and Forgejo's issues, pull request, and milestones. It should document your work progress and present how you organize your work. In other words, you should document what you are currently doing and what are you going to do in the near future by planning minor (incremental) tasks. The log should be maintained in such a way that a bystander reading the log can figure out more or less what is going on part of the project you are implementing. It is expected that on average you have at least a few minor contributions each week. Systematic inactivity will be penalized and will result in a deduction of points from the log grade.

To keep your log in good condition, you are requested to use the following features of Forgejo:

issue tracker,
issue labels,
issue time tracking,
pull requests,
milestones,
each commit must be bound to the issues,
each commit must have a meaningful commit message,
each feature must be developed in separate branch,
each feature branch must be merged into main branch via pull request,
each pull request must be reviewed and approved by other team member.

It is very important to keep the log up to date in the context of the review. It is also recommended that all communication and discussions related to the development of the project be conducted through the issue tracker provided by the Forgejo.

Remarks

Pay particular attention to handle correctly authorship of commits, since only the code committed by you will be considered as your contributions. The value of

git config user.email

in the repository should be the same as the e-mail address for you account on Forgejo.

If at some point the code you commit to the repository is generated by other program, e.g. files generated by framework for a new project, you must prepare a separate commit that include generated code, with a clear statement in commit's message that the code is generated by program. The message should also include all commands that generated the code. In the case of AI tools, read section Disclosure of AI contributions.

The review

The project review is a oral colloquium in which the main topic is the contributions you have made. You should be able to smoothly present details of your already contributed work. It includes the ability to explain, modify, compile and run the code from your branches, branches you reviewed, and from the main branch. In general, you must present a proficiency in your contributed work, to get positive grade from a given review. You might be required to run the project on the computer available in the class (Pixi will be already installed).

It is highly recommended that you maintain the quality and clarity of your contributions. Plan the structure of the project so that it makes logical sense. Use meaningful names in your project so that a bystander doesn't have to guess too much about what a particular element or variable is used for. Provide short auxiliary comments in your code so that one can deduce more quickly what a given block implements. It will help you not only during the review but also during the development of the project.

Failure to attend a project review for which one has been invited will result in a zero point for that review.

The report

The report is a summary of your design idea and a description of the result that the team produced. The main aim of the article is to introduce the potential reader to the problem, approaches to solve it, and evaluation of those approaches. It should also be a kind of own work review. Remember that the report should be neutral about the project. Reject the idea that you did the project and don't be afraid to criticize things that you think require it. Keep in mind that the report is not detailed documentation of the project describing every functionality. The write up should be self-contained and be structured similarly to a conference or journal paper. The report must be no longer than 10 double-column pages with a font size of 10pt, and it must be written in the English language. It is required to use a specific template for the document.

The following is just a suggestion for the scheme of the report, but it should be a good starting point for most projects:

Header: It should contain the project title and author’s names.
Abstract: It should briefly describe the content of the report, i.e., problem, approaches, and main results. There should be no more than 300 words.
Introduction: Good introduction and background material on the problem and the design. Discussion and try to refer to literature related to the problem. It should extend the introduction from the project proposal.
Problem formulation: A clear and precise formulation of the problem.
Methods, approaches, solutions: Describe and discuss approaches you decided to implement. Explain the reasons why you selected those particular methods. Compare pros and cons.
Evaluation: Describe and discuss the evaluation you performed to demonstrate the effectiveness of the employed methods. Define and explain evaluation metrics. Determine the impact of various components of your system.
Conclusions: Summarize your project. Distinguish key results.
Changes: Describe differences and changes between the initial design from the proposal and final result.
References: References to the literature.

The description of each bullet point is a suggestion of what is expected, but it should not limit the content of the article. Since it's the team's burden to write a report up, the team has the right to compose the article in another more suitable manner for the project. Keep in mind that a well-written proposal is a great starting point.

You should send the report to me (laboratory instructor) via e-mail. The file format of the document must be Portable Document Format (PDF). Other formats are not accepted and will be automatically rejected. Only one team member should send the report, but do not forget to carbon copy (CC) the message to the other team members. In the reply to the message, I will send you invitation for the evaluation meeting.

As a result, the team will obtain coefficient $\omega_4$ . The report will be graded according to the following distribution:

Introduction and background (20%).
Description of the problem, solution, and evaluation (60%).
Report organization (10%).
Writing and formatting (10%).

Deadline

The deadlines for sending the report is the end of the day 2027.01.19.

Reports submitted after the deadline are subject to a 20% penalty for each day of delay.

Changelog

2026.09.29: Document published.