Generative AI tools are easily accessible and very useful in professional software development. You may use them in this course. I am not going to attempt to ban them, implement convoluted surveillance regimes, or make unprovable judgments about whether your code was written by a person or generated by a tool.

However, you should be very clear about the tradeoff you are making.

The point of this course is not to accumulate completed assignments or to obtain a particular grade. The point is to develop the ability to design, build, debug, operate, and reason about cloud-scale systems. Developing the skills to do that effectively requires personally working through unfamiliar problems: reading documentation, making incorrect assumptions, testing them, debugging failures, understanding why a system behaves as it does, and revising your design.

AI can shortcut much of that work. It can also shortcut much of the learning.

If you use an AI tool to generate a solution that you do not understand, you may receive credit for an assignment that appears to work. But you will not have gained the skills the assignment was designed to develop. You are ultimately responsible for deciding whether that is a worthwhile use of your time and the tuition you're paying for this class.

A graduate course is a substantial investment. You can choose to use AI primarily to complete tasks quickly and optimize for grades. Or you can use it selectively, in ways that support your learning while preserving the productive struggle required to become a competent cloud engineer. I will not make that choice for you.

My Recommended Approach

For most assignments, you will learn substantially more if you first attempt the problem yourself. A productive workflow is:

• Read the assignment and relevant documentation.
• Form a hypothesis about the design or implementation.
• Attempt to write the code yourself.
• Test it and inspect the resulting behavior.
• Debug using logs, error messages, documentation, and experimentation.
• Consult AI only after you can describe the problem you are trying to solve.
• Manually verify every suggestion using documentation and additional tests.
• Make sure you can explain the final design and implementation without consulting the AI tool.

This does not mean you must struggle indefinitely before asking for help. Use office hours, Ed Discussion, documentation, fellow students (within the collaboration rules), and AI tools appropriately. The important distinction is whether a tool helps you learn through the problem or simply completes the problem in your stead.

You may use generative AI tools for activities such as:

• Explaining a cloud-computing concept in different words. The way that I describe concepts may not be the way you best understand them; AI tools can provide good alternative explanations of the material.
• Asking for clarification on how to use an AWS API, Python feature, HTTP behavior, or interpret an error message.
• Identifying relevant AWS, boto3, Flask, Python, or other documentation and helping you navigate the sometimes less-than-intuitive structure of official documentation.
• Brainstorming possible debugging hypotheses.
• Generating short examples to help you understand a service feature or API.
• Suggesting test cases, edge cases, failure modes, or questions to investigate.
• Reviewing code that you wrote and suggesting potential defects, readability improvements, or gaps in error handling.
• Helping interpret logs, stack traces, or unexpected results.
• Comparing alternative architectural approaches, provided that you independently evaluate the tradeoffs and understand why a certain approach is optimal.
• Helping improve the clarity or grammar of your written explanation after you have developed the underlying analysis yourself.

These are similar to legitimate uses of documentation, search engines, code examples, technical forums, or a knowledgeable colleague. They can be valuable when they support your reasoning rather than replace it.

AI tools can substantially undermine your learning. In particular, you are strongly discouraged from using AI to:

• Generate an entire assignment solution before you have attempted it yourself.
• Produce code that you commit and submit without understanding it.
• Generate a complete description, design rationale, performance analysis, or postmortem that you cannot defend.
• Interpret experimental results that you did not personally collect and examine.
• “Complete A8”, “write my DynamoDB query”, “implement the A9 SQS worker”, or otherwise solve an assignment requirement.
• Avoid reading the official documentation relevant to the service you are using.
• Keep prompting until an AI-generated answer meets the specification without understanding why it works.
• Generate code/a configuration that gives your application overly broad permissions, exposes data, incurs unnecessarily cost, or changes cloud resources without understanding the consequences.

A working result is not the same thing as understanding. This distinction becomes particularly important in this course because running applications in the cloud has real consequences: data can be exposed, messages can be lost or duplicated, resources can become unavailable, and poorly chosen infrastructure can generate unexpected costs.

Your Responsibility

You are responsible for all material you submit, deploy, or claim to understand, regardless of whether AI assisted you. This includes:

• Every line of code in your repository.
• Every AWS resource you create, including things like IAM permissions, security-group rules, queue configurations, database key design, scaling policies, and launch configurations.
• Every statement in a README, design document, performance analysis, or assignment write-up.
• Every result you report from a benchmark, load test, or experiment.
• Every decision that affects reliability, security, privacy, performance, availability, durability, or cost.

If an AI tool suggests that you use a particular AWS service, API parameter, retry strategy, DynamoDB access pattern, SQS message-handling approach, etc., you are responsible for determining whether it is appropriate within the context of the assignment you're working on.

AI tools can produce code and explanations that are plausible, confident, and wrong. In our case, “plausible but wrong” can mean a broken deployment (not good for your grade), a public data bucket (a major security hole that affects all of us!), an unintended billing charge (a REALLY big deal, since we have very limited budget for supporting this class), a non-scalable design, or a failure mode that appears only under load.

With the above in mind, before submitting an assignment, ask yourself: If I were asked to explain, modify, or debug this part of my system without AI assistance, could I do so?

For example, you should be able to explain:

• Why direct browser-to-object-storage upload is preferable to moving large files through the web server.
• What a signed S3 policy authorizes, how long it is valid, and what its restrictions prevent.
• Why a datum belongs in durable storage rather than on the local filesystem or in-memory Python dictionary.
• Why a DynamoDB query() using the appropriate index may not return the data you expect.
• Why a message queue improves availability and decouples a web service from a worker service.
• When a message should be acknowledged or deleted, and what can happen if a worker process fails before or after that point.
• Why a webhook and a polling worker have different delivery, buffering, availability, and scaling properties.
• Why an object may be archived while job metadata remains accessible.
• Why a user’s account role should not be replicated in multiple databases.
• Why a stateless web tier can be placed behind a load balancer and replaced automatically.
• Why an Auto Scaling policy responds with delay rather than instantly when traffic or queue depth changes.

If you cannot explain these things about your own implementation, then you have completed the artifact but not the learning objective.

On Grades

A course grade is a limited and imperfect signal. It may matter for immediate academic or career reasons, but it is not the durable outcome of this class. The durable outcome is your ability, months or years from now, to independently:

• Read cloud-service documentation and make an informed choice.
• Build a service that works across failures and retries.
• Diagnose why a distributed system is slow, inconsistent, unavailable, or expensive.
• Reason about the tradeoffs among latency, availability, consistency, idempotence, durability, security, and cost.
• Critically review AI-generated architecture, design, infrastructure or application code, rather than accepting it because it looks convincing and "works".
• Take responsibility for a deployed system that affects real users and real data.

You may decide to use AI heavily and optimize for completing assignments efficiently. That is your choice. But do not mistake a good grade earned that way for the skills that the grade is intended to represent.

You are paying for the opportunity to develop those skills. Make sure you get them.