Working smarterwith AI.
Value created for the team
Made ideas testable early — the team could react to a working version instead of imagining a description.
Achievement
Shipped three working artefacts inside two weeks: a draft Events Toolkit site, a functioning loyalty mock-up and filmed storyboard reenactments.
My supervisor's feedback named this directly: strong technical capability, strong understanding and application of AI tools, applied effectively to development projects — and, in the same paragraph, a tendency to look for the quickest approach. Both halves are about the same instinct.
Where the technical work actually happened
The development-shaped work of my internship was the Events Toolkit website draft, the loyalty programme mock-up with its group account, points wallet and membership status, and the TikTok storyboard reenactments. These were the projects where I could build something testable quickly instead of describing it — and where being fast to a first version genuinely changed what the team could react to.
Where speed helps and where it does not
Repetitive work
Reformatting, restructuring documents, producing variations of a message. Optimise aggressively. Nothing is lost by being fast.
Exploration
Generating options to react against. Useful precisely because the output is disposable — the value is in seeing what I disagree with.
Development and prototyping
Getting a draft site or a mock system in front of people early. A rough working version produces better feedback than a description of the same idea.
Analysis
Support for thinking, not a substitute. A tool can structure a comparison; it cannot know that a rebate would undercut a premium venue's positioning.
Final decision
Human. Brand judgement, context, taste, ethics, fact-checking and understanding the customer are the parts I have to own, because they are the parts I would be defending.
Efficiency is a strength until speed becomes the objective.
Reaching an output quickly can hide the fact that the wrong problem was solved efficiently. My development is not to use fewer tools — it is to know which kind of task I am in before I reach for one.
My working rule
- Low-complexity / repetitive → optimise
- Creative / strategic → generate and challenge, decide myself
- High-impact or hard to reverse → slow down
Where this went wrong in practice
In Week 6 I recognised that I had sometimes assumed what was required instead of checking, and parts of my work had to be redone. That is the shadow side of moving fast: the speed was real, but it was applied to my own interpretation of the task rather than the actual one. A few minutes of clarification at the start would have saved considerably more later.
Evidence from the internship
The specific moments this case study is built on.
I completed a draft website for the Events Toolkit and then revised it on feedback, reorganising how information and the restaurant concepts were presented.
I treated finishing the build as finishing the task.
The first version's job was to reveal what needed to change. I also stopped evaluating it as a school deliverable — the question became whether a real customer comparing venues could use it, not whether every section was complete.
I filmed reenactments of TikTok storyboard concepts rather than leaving them on paper, and shot original footage for several of them.
The concepts read well written down, so I expected the filming to be execution.
Filming exposed pacing and angle problems that were invisible in the storyboard. Building a rough version of an idea is the cheapest way to find out whether it survives contact with reality.
I completed whole projects before seeking feedback, then found that assumptions I had made needed unwinding.
I saw asking questions mid-task as a sign that I had not understood the brief.
Clarifying is how you make sure your understanding matches everyone else's. I now aim to show the storyboard or the structure early, when changing direction is still cheap.
I built a working mock of the membership system instead of only describing the concept in slides.
I expected the mock-up to be a presentation aid.
Designing the actual screens forced decisions the concept had let me avoid — what status means, how a reward is redeemed, how two very different venues share one account. Prototyping is a thinking tool, not a communication tool.
The trade-off
What pulled against what
Momentum against accuracy; my confidence with tools against the risk of choosing a tool before understanding the problem.
Why the obvious answer was not enough
Speed compounds whatever direction you are already pointing in. Applied to a misunderstood brief, it produces more wrong work faster — which is exactly what happened in Week 6.
Why I chose this approach
Sort tasks by reversibility and impact before choosing an approach, and use prototyping specifically where a rough version will produce better feedback than a description.
Going deeper
The reframe I took from the criticism
The feedback could be read as 'slow down'. I do not think that is right, and neither is 'use less AI'. The strength — finding faster ways to work — is worth keeping. The correction is diagnostic: name the type of task first. Most work deserves speed. A minority deserves the slower route, and I was not distinguishing between them.
What I actually used AI and technical tools to support
Four concrete uses, all recorded in my Week 6–7 reflections. First, building the Events Toolkit draft website — structure, sections and layout produced fast enough that the team could react to a working page instead of a description. Second, the loyalty membership mock-up: generating and iterating the account, points wallet and status screens so the concept could be argued from something visible. Third, drafting and re-drafting variations of customer-facing copy — captions, WhatsApp messages and hashtag sets — where I wanted options to react against rather than a finished line. Fourth, structuring research on how other restaurant groups run loyalty into a comparison I could reason from. In each case the tool produced the first version; the brand judgement, the fact-checking and the final decision stayed mine.
Where a tool must not replace me
Brand judgement, context, taste, ethics, fact-checking, understanding the customer and the final decision. Everything on that list requires knowing what it felt like to sit in the room, which is the one thing the tool does not have.
The obvious answer
Use AI and technical tools to do the same work in less time.
What was more complicated
Speed compounds whatever direction you are already pointing in. Applied to a misunderstood brief, it produces more wrong work faster — which is exactly what happened in Week 6.
What I would test nextProposed next test
I would keep a short record of where a tool genuinely removed work versus where it removed thinking, so the judgement becomes evidence rather than instinct.
What I contributed
Made ideas testable early — the team could react to a working version instead of imagining a description.
I built the Events Toolkit draft website, a working mock-up of the proposed loyalty membership system and filmed storyboard reenactments — turning concepts into testable versions the team could react to rather than descriptions they had to imagine.
Decision rules I would carry forward
Understanding of a brief is confirmed in writing before work starts, not after a first version exists.
Send a three-line restatement of the next five briefs and count how many get corrected — that number is the cost of the old habit.
Structure and rough drafts are shown at the point where redirection costs minutes, not days.
Share a wireframe or outline at 20 per cent complete on the next three deliverables and log how much rework each one avoids.
Every task is named reversible or high-consequence before deciding how fast to move; reversible work ships and gets corrected.
Classify a week of tasks in advance, then review which classifications were wrong and why.
Keep the experimentation, and judge every shortcut by one test: does it remove work, or does it remove thinking?