Beyond the Agent's Claim
ICS 314 · Dennis Sarsozo · August 2026
I. Introduction
Before ICS 314, I thought AI would be useful for basically everything in software engineering. That was true in a broad sense, but it was not a useful enough answer. This semester taught me that AI is most valuable when it gives an engineer leverage without removing the engineer’s responsibility for the result. It can explain an error, scaffold a page, find a likely root cause, draft documentation, and turn a rough voice memo into a readable first draft. It can also make the wrong assumption, drift into unrelated work, commit something I did not want committed, or claim that a task is finished when it cannot even see the system that would prove it.
I used Claude, ChatGPT, Codex, and local Gemma models. I use Claude and ChatGPT in daily life already; in my experience, Claude has strong pre-training, while ChatGPT has the better post-training and coding harness. Codex became the tool I used most for ICS 314 work because it could read a project, make bounded changes, run checks, and show its work. I also used local Whisper and Gemma for the voice-to-draft workflow I use for technical writing.
The main lesson is simple: an agent reporting completion is not the same thing as an engineer proving completion. That distinction shaped how I used AI in the course.
II. Personal Experience with AI
1. Experience quizzes
I used Codex on the Jamba Juice TypeScript experiences, especially E12 through E14. A representative request was: “Implement the E12 MenuItem and Menu classes from the existing starter code, add the required menu items, and test findMenuItems("mango").” Codex gave me a working first pass, but I treated it as a draft. I checked every price and calorie value against the menu image, caught an incorrect special-pricing assumption for Strawberry Dragon, corrected it, and then checked the search result in TypeScript Playground.
For E13 and E14, I similarly used AI to help extend the existing model with drinks, orders, inventory, and store behavior. I still checked the calculation and fulfilled-item behavior myself. The benefit was speed in repetitive TypeScript setup. The cost was verification time for prompts, generation, source-data checking, and integration. AI did not remove the need to understand the classes or validate the real-world data.
2. Practice quizzes
I used AI for some practice work involving Bootstrap navigation and layout patterns. A representative request was: “Build the Bootstrap navbar and button layout from this assigned mockup, keep it simple, and stop before committing so I can review it.” This helped with repeated UI patterns that I already understood conceptually but did not want to retype from scratch.
The useful part was getting a visual starting point quickly. The cost was that a page that looks close in source code is not automatically correct in the browser. I still had to compare the layout to the mockup and decide whether the generated structure actually fit the assignment.
3. Quizzes
For the Maui Brewing and Island Snow React work, I used Codex to turn an existing mockup and assets into components. One representative request was: “Convert this mockup into simple React-Bootstrap components, keep the existing styling, and check the visual result in the browser.” The tool helped create pieces such as navigation, image, and footer components.
I did not treat that as a finished quiz just because the components existed. I ran lint and builds, inspected desktop and mobile layouts, checked the mobile hamburger behavior, and confirmed that a fresh development-server restart still rendered the expected server-side result. Some generated paths and TypeScript data shaping needed correction. The benefit was faster scaffolding; the cost was browser QA and integration work that the generated code did not solve by itself.
4. Essays
For essays, I use a voice-first workflow. I record my actual thoughts, transcribe them with Whisper, and ask an AI tool to organize grammar and structure while preserving the ideas. A representative request was: “Clean up this voice transcript into a technical essay, keep my ideas and tone, do not add claims, and include the required AI disclosure.”
I reviewed the Markdown manually before accepting it. I also tried a local Gemma LoRA style experiment. That was useful because it gave me another way to compare structure and tone, but it exposed a limitation too: the first LoRA revision sounded almost identical to the earlier draft. I had to ask for a real structural rewrite and then decide what still sounded like me. AI helped with presentation, not authorship of my opinions.
5. Final project
AI was deeply involved in Mānoa Club Compass, our full-stack club directory. Early on, I asked Codex to read the project-management requirements, distinguish must-ship work from optional extra credit, and help make a minimal, low-risk scope for a club directory with roles, data, pages, tests, and CI. It turned scattered course requirements into a usable plan, but it did not replace team decisions or course verification.
Later, I used it for implementation and troubleshooting. A representative request was: “For #7, are there CI tests for it? The login has a server error. Root-cause it and fix it.” The work covered authentication and role access, Prisma migrations, Playwright baseline tests, CI database setup, and project issues. I still made the task decisions, reviewed the work, performed manual QA, and checked the actual GitHub Actions result.
6. Learning a concept or tutorial
AI was useful when I knew programming already but did not understand a TypeScript or JavaScript detail. For example, I used Claude to debug TypeScript loop, indexing, and .includes syntax while working on a duplicate-detection algorithm. A representative prompt was: “Explain why this TypeScript loop and .includes check are failing, then show the smallest correction and why it works.”
The benefit was getting an explanation faster than searching through several Stack Overflow answers. The cost is that an explanation can sound convincing even when it is not right for the exact code. I tested the final algorithm and made sure I could explain the Set and array-return behavior myself.
7. Answering a question in class or in Discord
I did not use AI to generate answers that I posted as my own in class or Discord. I wanted those interactions to be real contributions based on what I had checked, discussed with teammates, or understood from the course. AI could help me privately narrow a technical question, but it was not a replacement for participating honestly in the course community.
8. Asking or answering a smart question
I used AI to turn broad uncertainty into more specific engineering questions, especially during project planning and debugging. For example, I asked it to separate required Club Compass milestones from optional work and later to determine whether a login failure came from code, database state, migrations, or deployment configuration. Those are better questions than simply asking whether something is broken.
The benefit was that AI helped identify the next check. The cost was that I still had to bring evidence back to the real system. A good question is only useful if I can verify its answer in the repository, the database, the deployed app, or the course requirements.
9. Coding example
The Jamba Juice findMenuItems("mango") task is a small concrete coding example. Codex created the initial class structure and test, but I validated the source data and corrected a pricing edge case. This is the pattern that worked best for me: let AI handle first-pass structure, then verify the behavior and the facts that matter.
10. Explaining code
I used AI to explain existing code and error messages, not only to generate new code. In the TypeScript exercises, it helped explain why particular loop/indexing code or an .includes call was not behaving as expected. In Club Compass, it helped explain the relationship between authentication, Prisma migrations, seeded data, CI, and the deployed environment.
The value was a faster mental model. The limitation was that I could not stop at the explanation; I still needed to read the relevant code and reproduce or test the behavior.
11. Writing code
For larger implementation work, I used Codex to scaffold UI components, role-based access, tests, CI setup, and project features. For E40, I asked it to complete the Island Snow page while stopping before each commit so I could verify the change. For Club Compass, it helped implement focused features such as role checks and the Super Admin approval workflow.
This let me spend more time on the requirements, architecture, and review. It did not mean I typed nothing or understood nothing. I reviewed generated changes, fixed type and path issues, decided when a scope was acceptable, and used lint, builds, browser checks, and CI as evidence.
12. Documenting code
I used AI to help write and organize project documentation, including the Club Compass user guide, portfolio project page, issue notes, and effort documentation. A representative request was: “Draft the portfolio project page from the real project page, screenshots, and my contributions; keep it professional and do not invent issue details.”
That last constraint mattered. When the GitHub issue API was unavailable, the tool grounded the page in the checked-out repository instead of inventing issue numbers. Documentation is useful only if it accurately represents the project, so I reviewed the text, images, and claims before keeping it.
13. Quality assurance
QA is where AI was useful but least trustworthy without proof. I asked it to diagnose a Club Compass login failure and add focused role/CI coverage. The root cause was not an abstract Auth.js problem: the configured database lacked the expected tables, and migrations were pending. After fixing the data and configuration path, I checked live sign-in behavior, an authenticated session, the club API, and the actual GitHub Actions result.
I used the same habit on smaller work: lint, builds, browser checks, responsive checks, and regression tests. AI can suggest a test or a fix, but it cannot truthfully claim success without access to the relevant environment. I learned to distinguish a green local check from deployment evidence, and a passing CI test from proof of every possible user flow.
14. Other uses in ICS 314
Other uses included planning GitHub issues, checking project-board state, estimating work, preparing browser QA, reviewing course requirements, and drafting portfolio material. I tracked AI-related prompt, generation, verification, and integration time in the course effort log where applicable.
This planning support was valuable because it turned a large task into ordered, checkable work. Its cost was that project boards, estimates, and a polished plan can create a false sense of progress. The real completion criteria were still working features, documented evidence, team coordination, and human submission steps.
III. Impact on Learning and Understanding
AI improved my comprehension when I used it as an interactive explanation tool. It shortened the time between seeing an error and understanding the relevant TypeScript, React, Prisma, or CI concept. It also made me more willing to try unfamiliar web-development work because I could ask focused follow-up questions instead of getting stuck alone.
At the same time, it challenged my understanding by making it easy to accept an answer before I had earned it. I handled that by intentionally doing some WOD and basic JavaScript work without AI first. My standard became: if I cannot explain the result, test it, or correct it when it breaks, then I do not yet own the work.
IV. Practical Applications
Outside ICS 314, I use the same voice-to-document workflow for technical writing and built a local Gemma LoRA style experiment over the summer. The purpose is practical: speak a rough mental model, get a structured draft, and then review it in my own Markdown. It is effective for reducing typing friction and organizing ideas, but it does not replace judgment. The LoRA experiment itself showed that style adaptation can be superficial; a draft can sound polished and still need a better structure or a human correction.
The Club Compass work was also a practical example of AI in a real collaborative project. It helped with planning, scaffolding, debugging, testing, documentation, and deployment investigation. Its effectiveness came from pairing it with sources of truth: the repository, issue board, tests, browser behavior, GitHub Actions, and the deployed system.
V. Challenges and Opportunities
The main challenge was over-trust. I saw agents make incorrect assumptions about pricing, produce generic essay revisions, auto-commit against instructions, and report completion while lacking access to GitHub or production systems. These are not reasons to avoid AI; they are reasons to set better boundaries and verification requirements.
There is a real opportunity to integrate AI into software-engineering education more explicitly. Students should learn prompt design, repository context, source verification, test design, debugging, privacy, and how to state what AI did. The goal should not be to ban leverage. It should be to make students accountable for the systems they build with it.
VI. Comparative Analysis
Traditional learning still has strengths. Reading documentation forces me to follow the official model of a tool. Stack Overflow can expose multiple approaches and real edge cases. Instructors, classmates, and Discord provide context that an isolated model may not have. Doing an exercise manually is the best way to find out whether I actually understand the process.
AI is better at fast iteration. It can explain a syntax failure in context, generate a small starting point, or turn a vague debugging situation into a list of checks. The strongest workflow is not AI versus traditional learning. It is AI-assisted iteration followed by documentation, source review, testing, and human feedback. AI increases engagement because it reduces friction, but knowledge retention still depends on doing enough of the reasoning and verification myself.
VII. Future Considerations
AI will become a normal part of software-engineering education and work. I think future courses should require evidence-based AI use rather than pretending students will not use it. That could include representative prompts, an explanation of accepted and rejected output, test evidence, and a breakdown of prompt, generation, verification, and integration time.
Students should be expected to understand the foundations underneath their prompts. The difference between “make me a website” and “build a full-stack club directory using a React framework, Bootstrap, Prisma, role requirements, and testable acceptance criteria” is the difference between vague generation and engineering direction. The fundamentals are what let someone steer the tool instead of being steered by it.
VIII. Conclusion
My conclusion from ICS 314 is that AI is a collaborator, not merely a shortcut. A software engineer is not valuable because they type every line manually. The job is to communicate, understand problems, and solve them with software. AI can make that process much faster, like using a lawnmower instead of scissors, but someone still needs to choose where to mow and inspect the result.
My advice to future ICS 314 students is to use AI and learn how to use it now. Use it to build projects that show what you can do, but understand the system at the same time. Ask better questions, preserve the evidence, test the behavior, and be honest about the tool’s role. When the fundamentals are underneath you, AI can help you go much farther. Without them, it can only generate something that looks finished.
AI Disclosure
The ideas and examples in this essay came from Dennis Sarsozo’s experience and his recorded voice answers. Whisper transcribed the recording. ChatGPT/Codex and local Ollama Gemma models assisted with organization, grammar, drafting, and a local LoRA style experiment. Dennis reviewed the source facts, representative prompts, claims, and final Markdown before publication.
Written for ICS 314, Software Engineering I. University of Hawaiʻi at Mānoa, Summer 2026.