Non-Programming Grading

Non-programming courses and assignments (essays, written assignments, problem-solving, etc.) will have grading standards detailed within the course or assignment. In general, you can expect grading to be based on logic, accuracy, and adherence to specifications. Good writing practice, style, grammar, spelling, and organization will also apply. You will be held to competent college-level writing standards. Handwritten, poorly organized, or sloppy work will not be accepted. Cell phone photos of work, images, or diagrams will not be accepted unless specifically requested.

Programming Grading

In an AI-Integrated Classroom, programming grades do not attempt to measure how much code you personally typed. Generative AI may produce substantial portions of working code. You are still responsible for producing and managing correct, well-designed software using an appropriate development process, and for demonstrating the programming competence represented by the work you submit.

Programming assignments will normally be graded using the following breakdown:

• Process & Professionalism (30% of your grade): Adherence to assignment specifications, required development process, repository and project structure, version control practices, documentation, submission requirements, and other professional expectations. Major failures may result in a zero for this category; minor defects will normally reduce the category proportionally.
  
  
• AI & Development Reflection (10% of your grade): Assignments may include a short set of questions about how AI was used, what was delegated to AI, how generated work was evaluated or verified, what was changed or rejected, and what was learned during development. This reflection is part of the learning process; it is not, by itself, proof of programming competence.
  
  
• Technical Quality (60% of your grade): This includes functional correctness, adherence to technical specifications, good programming practice, style, modularity, architecture, robustness, maintainability, clarity, elegance, and accuracy. AI may assist in producing the software, but you are responsible for the quality of the resulting system.

Technical Quality Explained: Technical quality is graded holistically. A score in this category is based on the overall quality of the software (i.e., the code), not simply on the number of errors found. A typical scale is:

• 60: No significant errors detected. The program satisfies the assignment and is well designed, robust, readable, and maintainable.
• 54-59: Excellent work. Problems are minor and would require only small corrections or refinements.
• 48-53: Above-average work. The program substantially meets the requirements; there are significant problems, but they are reasonably straightforward to correct.
• 42-47: Average work. The program meets much of the assignment but contains substantial problems requiring meaningful correction or rewriting of portions of the code.
• 36-41: Below-average work. The program only partially satisfies the assignment or contains substantial design, correctness, or implementation problems.
• 30-35: Well below average. The program runs and resembles what was requested, but contains major flaws and would require extensive correction or rewriting.
• 0: Work below the previous category receives no Technical Quality credit. Failure to compile, interpret, or run in the required environment, or a substantial failure to implement the core assignment requirements, may result in a zero for Technical Quality regardless of other factors.

Process & Professionalism Explained: These requirements are part of software development, not separate paperwork. You are expected to follow them carefully. Major failures can result in a zero for this category, while smaller mistakes will normally result in proportional deductions.

Major failures include, but are not limited to:

• Failure to submit the correct repository or required project.
• Failure to submit properly as instructed, including submitting an incorrect repository link. Use the normal web URL, not an SSH or .git clone URL.
• Failure to maintain meaningful incremental development history using Git. You are expected to commit often, small, and smart.
• Missing major required project artifacts such as a README or .gitignore when required.
• Missing commenting or documentation.
• Substantially incorrect project or repository structure, including required files that are missing or misnamed.
• Submission of substantial stray files, generated files, build artifacts, IDE files, or other material that the assignment specifically requires you to exclude.

Other professional requirements may include:

• Using file comment headers as instructed.
• Ensuring there are no minor repo issues such as a misnamed file or the submission of a stray file, such as a .DS_Store.
• Correctly documenting/commenting functions and methods as instructed.
• Following formatting guidelines.

Demonstrating Programming Competence

A completed program is evidence of programming competence, but it is not necessarily sufficient evidence by itself. Throughout the semester, competence may be evaluated using multiple forms of evidence, including completed programs, development history, testing, debugging, modification of existing software, and other programming work.

If the normal body of coursework does not provide sufficient or consistent evidence of competence, additional verification may be required. A correct-looking artifact does not automatically establish that the underlying learning has been demonstrated.

General Grading Philosophy

Just because it runs doesn’t mean it earns a good grade. Your grade reflects modularity, architecture, style, clarity/elegance, sound practices, robustness, correctness, and adherence to instructions. “It works” by itself is worth little. “It works and is well-designed, maintainable, and built to standard” is what earns high marks.

You are not training to produce code that merely functions. You are training to write clean, maintainable, professional software—and to think with the discipline of an engineer and computer scientist.

Generative AI makes functional code easier to produce. That does not make software quality, disciplined development, or programming competence less important. It makes them more important. AI may participate in producing the artifact; you remain responsible for understanding, evaluating, testing, correcting, and maintaining the work.

An academic analogy: Imagine you are in a research writing class. You are told to research a topic and write an essay about it. You are instructed it has to be 5,000 words or more, and you are given specific guidelines on how to format, cite, and submit it (e.g. typed, double-spaced, 1" margins, table of contents, citations, etc.). Imagine you write that essay, and you very accurately explain the topic, but you have spelling errors, grammar errors, run-on sentences, inconsistent and poor formatting, you only wrote 1,800 words, and you submit it handwritten on 50 bar napkins. Despite the fact you may have very accurately described the topic, your assignment will fail, and you should expect it to. You would not be able to credibly argue, "But I did the research and wrote the essay!" Obviously, the point of such an assignment in a research writing class is not simply to explain the topic, but rather to learn and demonstrate proper research writing techniques and discipline.

That is how you need to think of learning to program. You are not just learning programming. You are learning computer science, engineering, computational thinking, logic, and discipline. The programming itself is a demonstration of those concepts. In the age of AI, it is more important than ever to learn the underlying concepts and discipline, and to be able to apply them in a way that is correct, maintainable, and professional.

"It works" is worth nothing.

It works and it is done right is worth everything.