AI Tools in HCI and Development

Artificial intelligence has moved from being a research curiosity to an everyday presence in the toolchains of designers and software engineers. In the context of Human–Computer Interaction (HCI) and software development, AI tools now participate in nearly every stage of work: sketching interface layouts, generating boilerplate code, writing test cases, reviewing pull requests, and watching production systems for signs of failure. Understanding what these tools do well — and, just as importantly, where they fail — is now part of basic professional competence. This topic surveys how AI is used across the design and development workflow, and then establishes a clear set of expectations for how you may use AI assistance in this course.

A useful mental model throughout: AI tools are probabilistic pattern-matchers, not reasoning engines with accountability. They produce output that looks like what a competent practitioner would produce, because they were trained on enormous quantities of such output. That makes them excellent at generating plausible starting material and terrible at guaranteeing correctness. The human in the loop supplies judgement, context, and responsibility.

How AI Supports the Design Process

Interface design has historically relied on a mix of designer intuition, design systems, usability heuristics, and user testing. AI inserts itself into this process mainly as an accelerator for the early, divergent phases of design — the moment when you need many options quickly and none of them have to be perfect.

Suggesting layouts and colour schemes from behavioural data. Modern design tools can propose UI arrangements informed by aggregated data about how users actually behave. Several well-established behavioural findings are baked into these recommendations:

• Scanning patterns — eye-tracking research shows users scan text-heavy pages in an F-shaped pattern and image-rich pages in a Z-pattern. An AI layout suggester trained on high-performing pages will tend to place primary calls-to-action along those paths.
• Fitts's Law — the time to acquire a target is a function of its distance and size. Tools will flag a 24 px tap target on a mobile layout and suggest enlarging it toward the 44–48 px recommended minimum.
• Contrast and accessibility — a colour-palette generator can be constrained to produce only combinations meeting WCAG AA (4.5:1 for body text) or AAA (7:1) contrast ratios, and can simulate deuteranopia or protanopia to check that information is not conveyed by hue alone.
• Hick's Law — decision time grows with the number of choices, so AI tools often recommend collapsing a 12-item navigation bar into grouped categories.

A concrete example: a designer gives a prompt such as "checkout screen for a mobile grocery app, trustworthy and calm, high accessibility". The tool returns four variants — one with a single-column form and a persistent sticky "Pay" button, one with a progress stepper, and so on — each with a generated palette (e.g. a desaturated blue-green primary at #2E7D6B with #FFFFFF text, contrast ratio 4.9:1). The designer has in thirty seconds what might have taken an hour of manual mock-up work.

Automated visual testing. This is one of the most mature and least controversial uses of AI in the design/development boundary. Visual regression tools (Applitools, Percy, Chromatic and similar) capture screenshots of your UI across a matrix of browsers, operating systems, and viewport widths, then compare them against an approved baseline. Naïve pixel-by-pixel comparison is almost useless in practice — a one-pixel font-rendering difference between Chrome on macOS and Chrome on Windows would flag thousands of false positives. AI-based visual comparison instead uses computer vision to classify differences the way a human would:

These checks run in continuous integration, so a developer who accidentally breaks the responsive layout at tablet width learns about it from a failed build within minutes rather than from a user complaint weeks later. The same infrastructure can automatically run accessibility audits (axe-core, Lighthouse) on every commit, catching missing alt attributes, unlabelled form controls, and insufficient contrast.

Recommendations are starting points, not decisions. This caveat deserves genuine weight rather than lip service. AI design suggestions are derived from what was common and popular in the training data, which creates three systematic problems:

• Homogenisation. If every tool recommends the statistically average pattern, every product starts to look identical. Distinctiveness, brand identity, and delight are precisely the qualities that averaging destroys.
• Context blindness. The model does not know that your users are warehouse staff wearing gloves in cold storage, or elderly patients with tremor, or air-traffic controllers who must never be shown a modal dialogue. A statistically optimal consumer-app pattern can be actively dangerous in a safety-critical domain.
• Bias inheritance. Training data over-represents Western, young, able-bodied, high-bandwidth users. Suggestions may assume left-to-right reading order, fast connections, large screens, and familiarity with conventions (such as the hamburger menu) that are not universal.

The professional workflow therefore remains: generate candidates with AI → critique them against heuristics (Nielsen's ten usability heuristics, your design system, accessibility standards) → test with real users → iterate. AI compresses the first step; it cannot replace the third. A dark pattern is still a dark pattern even if an AI suggested it, and the designer who shipped it is the one accountable.

AI Coding Assistants

AI coding assistants — GitHub Copilot, Amazon Q Developer, Cursor, Codeium, JetBrains AI, Claude Code and others — have become the most visible application of AI in software engineering. They operate in several distinct modes.

Inline completion. As you type, the assistant predicts the rest of the line, the rest of the function, or the next several lines, using the surrounding file, open tabs, and sometimes the whole repository as context. The productivity gain is largest on repetitive, low-novelty code. For example, after writing a function signature and docstring:

def celsius_to_fahrenheit(temps: list[float]) -> list[float]:
    """Convert a list of Celsius temperatures to Fahrenheit."""
    # assistant proposes the entire body:
    return [(t * 9 / 5) + 32 for t in temps]

Here the assistant saves keystrokes and a context switch. The same applies to writing data classes, mapping JSON fields onto model objects, generating CRUD methods, or recalling the exact argument order of an unfamiliar library call. Empirical studies (including GitHub's own controlled experiments and subsequent independent replications) report task-completion speedups in the range of roughly 20–55% on well-defined, self-contained tasks — with the gains shrinking sharply on tasks requiring architectural decisions or domain knowledge.

Natural-language generation of code, tests, and documentation. Chat-style and prompt-driven interfaces let you describe intent in prose. A prompt such as:

Write an Express.js middleware that rate-limits requests to 100 per
IP per 15 minutes, returns HTTP 429 with a Retry-After header, and
uses Redis so it works across multiple server instances.

will produce a credible implementation in seconds. Equally valuable — and often more reliable — is using the assistant in the reverse direction, on code that already exists:

• Test generation: "Generate pytest unit tests for this function, including edge cases for empty input, negative numbers, and non-numeric types." The assistant is good at enumerating boundary conditions a tired human skips.
• Documentation: generating docstrings, README sections, API reference tables, and inline comments explaining why rather than what.
• Explanation: "Explain what this regular expression does, step by step" — invaluable when inheriting unfamiliar code.
• Translation and refactoring: converting a callback-based function to async/await, migrating a class component to hooks, or porting a script from Python 2 idioms to Python 3.

AI-assisted code review. Tools such as CodeRabbit, Codacy, SonarQube's AI features, Amazon CodeGuru and GitHub's own review suggestions attach comments to pull requests before a human reviewer looks at them. They are effective at the mechanical layer of review:

The practical benefit is that human reviewers stop spending their limited attention on comma placement and can concentrate on design and correctness.

Why critical review is non-negotiable. AI-generated code fails in characteristic ways, and knowing the failure modes is what separates safe use from dangerous use:

• Hallucinated APIs. The model invents a method that sounds right but does not exist — array.removeDuplicates() in JavaScript, for instance. Worse is slopsquatting: attackers register package names that AI models commonly hallucinate, so a developer who blindly runs pip install on a suggested dependency installs malware.
• Insecure patterns. Research has repeatedly found that a meaningful fraction of AI-generated code contains security weaknesses — string-concatenated SQL queries, eval() on user input, missing output encoding leading to XSS, weak hashing such as MD5 for passwords, disabled TLS certificate verification, or secrets written directly into source.
• Plausible but wrong logic. Off-by-one errors, inverted boundary conditions, incorrect handling of empty collections, or silently swallowing exceptions. The code runs; it simply produces the wrong answer on inputs nobody tested.
• Outdated practice. Training cutoffs mean suggestions may use deprecated libraries or superseded idioms.
• Context mismatch. The suggestion may be technically fine but inconsistent with your project's architecture, error-handling conventions, or logging standards.
• Automation bias. Humans systematically under-scrutinise machine output. Studies have found developers with AI assistance sometimes write less secure code while being more confident it is secure — a dangerous combination.

A worked example of a plausible-but-dangerous suggestion:

# AI suggestion — looks fine, is not
def get_user(conn, username):
    query = "SELECT * FROM users WHERE username = '" + username + "'"
    return conn.execute(query).fetchone()

# Correct version — parameterised, injection-safe
def get_user(conn, username):
    return conn.execute(
        "SELECT id, username, email FROM users WHERE username = ?",
        (username,)
    ).fetchone()

The practical discipline: never accept code you could not have written yourself and cannot explain line by line. Run it. Test it. Read the documentation for any unfamiliar API it uses. Treat every AI suggestion the way you would treat a code snippet from an anonymous forum post of unknown vintage — potentially helpful, definitely unverified.

AI Across the Software Development Lifecycle

Coding assistants get the attention, but AI now touches every phase of the SDLC. The pattern is consistent: AI is applied where there is a large volume of historical data and a need to spot patterns humans would miss or find tedious.

Planning: requirement gaps and timeline risk. Natural-language processing can be pointed at a requirements document or backlog and asked to find problems. Typical findings include:

• Ambiguity: "the system should respond quickly" — quickly compared to what, under what load, at which percentile?
• Missing non-functional requirements: a specification that describes twenty features but never mentions authentication, data retention, localisation, or accessibility.
• Contradictions: one section says sessions expire after 30 minutes, another says users stay logged in for 7 days.
• Untestable statements: "the interface shall be intuitive" cannot be verified; "90% of new users shall complete first checkout within 3 minutes without assistance" can.
• Unhandled paths: the happy path is specified but nothing says what happens when payment fails, the network drops mid-upload, or two users edit the same record.

On the estimation side, models trained on an organisation's historical issue tracker can flag risk signals: tickets whose descriptions resemble past tickets that overran, sprints where too much work depends on a single person, dependencies on an external team with a history of late delivery, or a steadily rising defect-reopen rate. The output is a probability, not a prophecy — "this epic has a 70% chance of slipping past the sprint boundary" is a prompt for a conversation, not a substitute for one.

Testing: generation and security scanning. AI test generation operates at several levels:

• Unit tests derived from function signatures and bodies, often with better edge-case coverage than hand-written tests because the model is not bored.
• Property-based and fuzz testing, where the AI generates thousands of structurally valid but adversarial inputs — enormous strings, Unicode edge cases, nulls, deeply nested JSON — to find crashes.
• End-to-end UI tests that are "self-healing": when a developer changes a button's CSS selector, a brittle Selenium test breaks, whereas an AI-driven locator recognises the same button by its text, role, and position and repairs the selector automatically — dramatically reducing test-suite maintenance cost.
• Security scanning, where static analysis augmented with ML triages findings. Traditional SAST tools are notorious for false positives; ML layers learn which findings your team historically dismissed and rank accordingly. Tools also scan dependencies against vulnerability databases and detect committed secrets.

A caution specific to AI-generated tests: a test generated from the implementation will faithfully encode whatever the implementation does, bugs included. If calculate_discount() wrongly applies the discount twice, the generated test will assert the doubled value and turn the bug into a permanent requirement. Tests should be derived from the specification, with AI used to expand coverage rather than to define correctness.

Post-deployment: monitoring and predictive maintenance (AIOps). A modern distributed system emits millions of metrics, log lines, and traces per minute. No human can watch that. AI here does three things:

• Anomaly detection. Rather than static thresholds ("alert if CPU > 80%"), models learn the normal seasonal shape of each metric — weekday peaks, Sunday troughs, end-of-month batch spikes — and alert on deviation from the learned baseline. This catches the 40% error rate at 3 a.m. that a static threshold tuned for daytime traffic would miss.
• Alert correlation and noise reduction. When a database fails, 200 downstream services alarm simultaneously. Correlation engines group these into a single incident and point at the probable root cause, reducing alert fatigue and mean time to resolution.
• Failure prediction. Leading indicators — a memory-usage curve climbing 2% per hour indicating a leak, disk filling on a trajectory to hit 100% in 36 hours, p99 latency creeping upward, a thread pool nearing exhaustion — allow automated or human intervention before users notice. A system can restart a leaking pod during low-traffic hours or auto-provision storage, turning a would-be outage into a non-event.

Real-user monitoring closes the loop back to HCI: session replay and interaction analytics can surface "rage clicks" (repeated rapid clicking on an unresponsive element), dead clicks, and form-abandonment hot spots, feeding concrete usability defects straight back into the design backlog.

Responsible Use of AI in This Course

The purpose of this course is to develop your capability. AI tools are permitted and in many cases encouraged, because learning to work with them is part of contemporary practice — but they are permitted under conditions designed to make sure the learning actually happens. The following four principles govern their use.

1. Read, understand, and verify everything. You are responsible for every line you submit, regardless of its origin. Before any AI-generated code enters your project, you should be able to answer, unprompted:

• What does each line do, and why is it necessary?
• What are the inputs, outputs, and failure modes? What happens with empty, null, or malformed input?
• What external libraries does it use — do they exist, are they maintained, what licence do they carry?
• Does it handle errors, or does it silently swallow them?
• Does it introduce a security weakness (injection, unvalidated input, exposed secrets)?
• Is it consistent with the rest of my codebase's style and architecture?

A useful self-test: close the AI tool and re-implement the solution from memory. If you cannot, you have not learned it — you have transcribed it. A second test: can you explain the code to a classmate and answer their follow-up questions? Viva-style questioning on submitted work is a legitimate assessment method, and "the AI wrote that part" is not an acceptable answer.

2. Over-reliance masks skill gaps that surface in assessment. The risk is subtle because AI assistance feels like learning. You produce working output, the project progresses, and the feedback loop is positive — but the cognitive work of structuring a problem, recalling syntax, forming a hypothesis about a bug, and reasoning through control flow is exactly the effortful practice that builds durable skill. Psychologists call this desirable difficulty; removing it produces fluency illusions. The gap becomes visible under exam conditions, in whiteboard interviews, in live debugging sessions, and in any situation where the tool is absent or the problem is novel enough that the tool is wrong.

A practical compromise is to stage your use of AI according to where you are in the learning curve for a given skill:

3. Intellectual property and licensing. AI-generated content raises genuine legal and ethical questions that you should be aware of as an emerging professional:

• Training data provenance. Code models were trained on public repositories carrying a range of licences, including copyleft licences such as GPL. A model can occasionally reproduce a substantial, recognisable chunk of licensed source. Some assistants offer a "filter suggestions matching public code" setting — enable it, and treat any suspiciously complete or idiosyncratic block (an unusual algorithm, a distinctive comment style) as worth checking.
• Copyright status of output. In several jurisdictions, including the United States, works produced without human authorship are not eligible for copyright protection. That means purely machine-generated material may not be protectable, which matters if you ever want to own or licence what you build.
• Confidentiality. Never paste credentials, API keys, personal data about real users, unpublished assessment material, or an employer's proprietary code into a consumer AI service. Some providers retain prompts for training unless you opt out or use an enterprise tier. Treat the prompt box as a public forum.
• Third-party assets. AI-generated images, icons, and copy may resemble existing trademarked or copyrighted work. Check before you put a generated logo on a submitted prototype.
• Terms of service. Different tools impose different conditions on commercial use and attribution. Read them for anything that leaves the classroom.

4. Document your use. Transparency is the simplest protection for both you and your marker, and it mirrors the disclosure norms emerging in industry and in academic publishing. For this course, maintain an AI usage log alongside your project and include it in your submission. A short, honest entry is sufficient:

## AI Usage Log — Sprint 2

| Date  | Tool            | Purpose                              | What I did with the output                      |
|-------|-----------------|--------------------------------------|-------------------------------------------------|
| 04/03 | ChatGPT         | Explain CSS grid vs flexbox          | Used for understanding only; wrote layout myself |
| 06/03 | Copilot         | Autocomplete form-validation helpers | Reviewed line by line; rewrote regex, which was
|       |                 |                                      | too permissive (allowed "a@b"); added 4 tests    |
| 08/03 | Claude          | Generate pytest cases for cart logic | Kept 6 of 9 tests; 3 asserted wrong totals, so I
|       |                 |                                      | corrected them against the spec                  |
| 09/03 | Midjourney      | Placeholder hero imagery for mockup  | Prototype only; flagged for replacement with
|       |                 |                                      | licensed stock before any public release         |

In addition, mark generated code at the point of use where it is substantial, for example:

// Initial implementation generated with GitHub Copilot (2024-03-06).
// Reviewed and modified: replaced naive email regex with RFC-5322-
// compliant pattern, added null guard, added unit tests in
// tests/test_validation.py.
function validateEmail(value) { ... }

Note what the good entries have in common: they record not just that AI was used but what you did to verify it. That verification record is the evidence of your learning, and it is what distinguishes legitimate tool use from academic misconduct. Undisclosed wholesale submission of generated work — particularly where you cannot explain it — falls under the institution's academic integrity policy in the same way that submitting a classmate's work would.

Putting it together

A reasonable way to summarise the whole topic is a division of labour. AI is strong at breadth, speed, recall, and tireless repetition: enumerating options, remembering API signatures, generating the ninth edge-case test, watching ten thousand metrics overnight. Humans remain responsible for depth, context, judgement, and accountability: deciding what problem is worth solving, knowing who the users really are, recognising when a plausible answer is wrong, and standing behind what ships.

• Use AI to go faster on things you already understand.
• Use AI to learn things you don't — by asking for explanations, not answers.
• Never use AI to produce things you cannot evaluate.
• Always disclose, always verify, always own the result.

Applied to your course project, this means AI may legitimately help you scaffold a component, draft tests, explain an unfamiliar error, or generate three layout variants to critique. It may not substitute for your understanding of the HCI principles you are being assessed on, for your own usability testing with real participants, or for your ability to explain and defend every artefact you submit.