D682 Artificial Intelligence Optimization for Computer Scientists, catalog number ICSC 3112, is the three CU course in the WGU School of Technology that guides students through implementing and optimizing artificial intelligence solutions for various applications through extensive research. The word carrying the weight is optimizing. Getting something to work is the entry condition here, and the assessed skill is making it work better for a stated reason.
Optimization needs a measured before
The structural requirement of ICSC 3112 is comparison. You cannot demonstrate optimization without a baseline, and a submission that presents only a final implementation has removed its own evidence. That means measurement discipline is the first thing to set up, before any tuning happens.
Which measurement depends on what you are optimizing for, and naming the objective is itself scored. Accuracy, latency, memory footprint, training time, inference cost and interpretability all pull in different directions, and improving one usually degrades another. A submission that states which objective it is optimizing, and what it is willing to trade away, reads as engineering. One that reports a single improved number without saying what got worse has reported half a result.
The catalog description mentions extensive research, and that is worth taking literally. Optimization decisions in this field have a literature: why a particular pruning or quantisation approach helps, what a given search strategy costs, where an approximation is known to break. Citing that literature converts a set of experiments into an informed investigation, and it is the clearest difference between a submission that reads as undergraduate and one that reads as considered.
Turning scored aspects into a section plan
Scoring detail lives in your Course of Study rather than the public catalog, so open the rubric before starting and count the aspects. Each is judged independently against a three point scale and each needs a 2 for the task to pass. No averaging means a substantial speed improvement cannot rescue a thin research section.
Where an aspect is satisfied by code, name the file and the function in the narrative. Evaluators score what they can see, and an optimization implemented at line 200 is invisible unless the report points at it.
The word budget, worked. Assume six scored aspects and roughly 1,900 words of narrative outside the code. Reserve 150 words for an opening that names the problem and the objective, and 120 for a close. That leaves near 1,630, about 270 per aspect. Then move 60 words from each of two descriptive aspects into the aspect covering the research basis for your choices and the aspect covering measured results, taking each to around 340. Those two carry the investigation, and everything else is context around them.
A structure that fits an optimization investigation
Where your task directions specify a structure, follow it. Where they leave the shape open, this ordering matches how the aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Problem and objective | The application, and the specific quantity being optimized | An unstated objective makes every result uninterpretable |
| Baseline implementation | The working version, with its measurements and environment | Without this there is nothing to optimize against |
| Research | Techniques considered, with sources, and why each might apply here | Named in the course description; frequently thin in submissions |
| Experiments | One change at a time, each measured under identical conditions | Multiple simultaneous changes make attribution impossible |
| Results | A comparison table with every objective tracked, not only the target one | The strongest single artefact in the submission |
| Trade offs | What each improvement cost elsewhere | Where engineering judgment becomes visible |
| Recommendation | Which configuration you would ship, under what conditions | Turns experiments into a conclusion |
Hold the environment constant across every measurement and say that you did. Timings taken on a laptop that was doing other things are not comparable, and an evaluator has no way to know unless you address it.
Evidence craft for optimization work
Everything persuasive here is a measurement, and measurements need context to be believed.
- Report hardware, library versions and dataset size with every timing. A number without conditions is anecdote.
- Repeat measurements and report variation. Single runs on a shared machine are noisy enough to invent improvements that do not exist.
- Track every objective in the comparison table, including the ones that got worse.
- Cite the technique to a methodological source rather than to a tutorial or a library page.
- Show the code change alongside its result, so the cause of an improvement is traceable.
- Use APA throughout and keep quotation short.
Report an optimization that did not work. It is genuine evidence, it demonstrates that the investigation was real rather than curated, and it usually supplies the most interesting analysis in the whole submission.
What separates Competent from a submission sent back
Aspects score independently, so returns are usually a single section deep.
- A baseline exists and is measured under the same conditions as everything after it.
- Each experiment changes one thing, and the report says so.
- Every technique used is tied to a cited source explaining why it should help.
- Results report all objectives, including regressions.
- The recommendation names conditions rather than declaring a winner unconditionally.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so a return costs calendar rather than standing. Terms run six months at a flat rate, and experiment heavy courses lose time quickly to rework, which makes a documented method the cheapest insurance available.
Six mistakes that cost time in D682
- No baseline. The most common structural failure, and it cannot be repaired at the end without redoing the work.
- Changing several things at once. An improvement with three possible causes teaches nothing.
- Reporting only the target metric. An accuracy gain that tripled inference time is a result that needs stating.
- Unrepeated timings. Run to run variation on a normal machine is large enough to mislead.
- Research reduced to a reading list. Sources have to explain choices, not decorate the reference section.
- Optimizing without a target. Faster is not an objective until somebody says how fast is enough.
- Measuring on a machine that is doing other things. Background processes, thermal throttling and a browser left open produce swings large enough to swamp a genuine improvement, and an evaluator has no way to separate the two unless the conditions are stated and held constant.
Designing an experiment sequence that proves something
The difference between a set of tweaks and an investigation is the sequence, and it is worth planning on paper before any code is changed.
Start by profiling rather than guessing. Most optimization effort in student work goes to the part of the code that looks slow rather than the part that is slow, and a profile usually shows that the majority of time sits somewhere unexpected. Recording that profile as your starting evidence answers a research aspect and prevents the most common waste of effort.
Then order the experiments by expected return against effort. Algorithmic changes usually dominate implementation tweaks, and data level changes such as reducing input dimensionality often dominate both. Working from the largest expected effect downwards means that if you run out of time, the work you did is the work that mattered.
Fix everything except one variable per run and record the full configuration each time, including the seed. It is tedious and it is the only way the comparison table means anything. Where randomness affects the result, repeat and report a range rather than a point.
Finally, stop deliberately and say why. An investigation that ends because the remaining gains were smaller than the added complexity is a conclusion, and stating it explicitly, with the numbers that justify it, is a stronger ending than a list of further ideas nobody pursued. That sentence also answers a recommendation aspect directly, since it names the condition under which you would spend more effort.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: a measurement protocol, a research section where sources explain choices, an experiment plan that changes one thing at a time, a comparison table tracking every objective, and a recommendation with conditions. Plus a walkthrough so the investigation is yours to defend.
D682 sits alongside the other applied computing courses and its measurement discipline transfers directly. Terms run six months at a flat rate, so setting up the harness properly in week one is what keeps the course inside a single term.
Questions students ask about D682
Is D682 the same course as ICSC 3112?
How much prior AI experience does D682 assume?
Can you write and optimize the code for me?
Where D682 sits in WGU's programs
The July 2026 catalog places this code in 2 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.