I saw the opening for an AI-enabled Marketing Intern at QED42 and applied after reading the description because the role matched my interest in marketing, AI, and content. Even after I got accepted, I was still a little unsure about what the role would actually involve.
I was about to find out what it meant the hard way: by doing it.
I want to be honest with you about something.
Before this internship, I thought AI tools would make me faster. I thought the skill was in knowing which tools to use. I took courses on prompt engineering, watched YouTube videos about ChatGPT and Claude workflows, and genuinely believed I had a head start.
I was wrong about almost all of it.
Not because AI tools aren't powerful, they are…. But because everything I had learned was about the tools. Nothing had taught me how to think around them. And that gap between tool knowledge and systems thinking is exactly where most AI-assisted work falls apart.
Here is what my internship actually taught me that I could not have learned in any course.
Understanding the audience comes before touching any tool
Every course I had taken started with the tool. Here is the interface. Here is the prompt. Here are the results.
My internship started differently. Before I was allowed anywhere near a live project, I spent time reading QED42's entire website, studying its AI platform Aeldris, attending onboarding calls, and documenting my understanding of brand voice and positioning. Not because I was told to. Because I quickly realised that a well-structured prompt built on a misunderstanding of the audience produces confident, polished, completely useless output.
From where I saw it, AI did not know the brand; it only knows the buyer.
Building an AI tool is a judgmental task, not a technical task
I built three AI-powered tools during my internship, all using Aeldris:
- AI Blog Guardrail and Brand Compliance Tool — reviews content drafts and flags anything that violates QED42's tone, style, and brand guidelines before a human editor sees it
- AI Generated Content Reviewer — flags writing that reads robotic or tonally inconsistent with human editorial standards
- Content Repurposing Tool — takes a single blog post and generates multiple LinkedIn posts calibrated for different audiences. Keeps the same tone, messaging, and style across different content pieces.
The AI was the engine. I was the architect. And being the architect required marketing thinking, not engineering thinking.
Prompt engineering is not one skill
Every course treats prompt engineering as a single discipline. Write clear instructions. Give examples. Be specific.
That advice is correct and almost entirely insufficient.
Through building the enterprise intelligence system at QED42, researching 30+ companies across Healthcare, BFSI, and other sectors using a master Claude Project. I discovered that effective prompting at scale actually requires two separate skills that most people collapse into one:
Instruction design: The clarity of what I was asking for. This is what most courses teach. It is necessary but not sufficient.
Architecture design: For the enterprise system, I built a master Claude Project with three file layers: a research template, raw company research notes, and a strict style and register ruleset. The quality of the output depended as much on what I put into the project as what I put into the prompt.
The most impressive output is worthless if nobody uses It
The Content Repurposing Workflow got more adoption than any other tool I built. It is not the most sophisticated. It does not do anything technically complex. It takes a blog post and turns it into LinkedIn variants for different audiences.
But it solved a real, daily frustration that every member of the marketing team felt. And I recorded a walkthrough. And I shared it in the internal Everyday AI channel. And I followed up when people tried it.
The real skill is building systems, not tools
A tool solves one problem once. A system solves a category of problems repeatedly.
The enterprise intelligence system I built at QED42 is the clearest example of this distinction in my own work. The task was to produce research reports on 30+ enterprise companies across Healthcare, BFSI, and other sectors, the kind of intelligence that helps QED42 approach a potential client not with "we help enterprises modernise platforms" but with "we noticed your team has been posting simultaneously for a Drupal architect and a headless migration lead, which usually signals a platform decision already in motion."
A tool approach would have been: write a research prompt, run it for each company, compile the outputs.
A systems approach was: build a master Claude Project with a consistent 11-section research template, a raw signals layer for each company, and an editorial register ruleset enforced in a separate prompt pass, so the output quality was consistent across all 30+ companies, regardless of how different their sectors, structures, and platform contexts were.
The system took longer to build. But it scaled. And it produced reports that were specific enough to be genuinely useful rather than generic enough to be safely ignored.
Documentation is not the last step. It is half the work
I was not taught this in any course. I learned it the hard way when I realised that a workflow only I understood was not a workflow, it was a personal habit.
Every process I have built now exists in two forms: as a working system and as a written document that a team member could follow without any explanation from me. This is not just good practice for knowledge sharing. It is a discipline that forces clarity. If I cannot write down what the system does and why each step exists, I do not fully understand it yet. And if I do not fully understand it, I cannot improve it reliably.
The most important document I produced was a skill file for the enterprise research system, a set of explicit rules for how reports should be researched, structured, and written. Every new company research run now starts from that file. The output quality is consistent. The process is transferable. The system works without me.
.png)
.png)
The honest takeaway
Six weeks ago, I had never built an AI tool. I had ideas, curiosity, a tech background, and a title I didn't fully understand.
Today, I've built three tools, designed and run an enterprise intelligence system across 30+ companies in four sectors, written more prompt iterations than I can count, and shipped things that actually got used by real people. All from a marketing bent of mind, as they say it here. I am still building that mindset. Writing this blog was one of the exercises to get there.
That's what AI marketing looks like from the inside. It's not magic. It's not prompt engineering as a party trick. Its methodology was built slowly, tested honestly, and improved every single week.
I came in thinking AI tools would make me faster.
They did eventually. But not in the way I expected. The speed came not from the tools themselves but from understanding deeply enough what I was trying to produce that I could give the tools precise, useful instructions.
That understanding came from working on real problems with real stakes for a real audience. Not from a course. Not from a certification.
Today, because of this internship, I am more curious, AI tools are my playground, and marketing is becoming a way of thinking.
The title still sounds made up. But now I know what it means. And I'm just getting started.