The unglamorous half of AI, and why it decides everything
Everyone wants to build the agent. Far fewer people want to build the thing the agent stands on, and that is exactly why this role matters. An AI sales agent that cannot read the calendar cannot book a call. A dashboard that shows a client a number nobody can trace is worse than showing nothing at all.
The systems work is where AI stops being a demo and starts being a product. You will spend your time on the parts that have to be right: the page that loads on a phone, the form that reaches the CRM, the deploy that actually went live rather than merely committed, the number on screen that traces back to a real record. None of it is glamorous. All of it is the difference between a client who renews and a client who quietly stops replying to emails.
What you will actually be building
Our clients get a website, a CRM, a set of agents, and one dashboard to run it all from. That is a lot of surface, and interns work across it rather than being parked on one corner of it for three months.
In a typical month you might build new pages on a live client site, add a section to a dashboard, wire a new data source into a report, write the checks that guard a build, or track down why a form stopped reaching the CRM. The work is varied because a small company cannot afford narrow specialists, and that variety is the fastest education available anywhere. You will touch front end, back end, data and deployment in the same week, which is unusual and is the reason people leave here able to build a whole thing rather than one layer of it.
Debugging is the skill we care most about
Most developers, when something breaks, try three things they half remember and hope one works. We do the opposite, and we will teach you how, because it is the single most transferable skill in this job.
You will learn to read the actual payload before theorising, to reproduce a fault with real inputs rather than a simplified version that quietly removes the cause, and to stop after two failed attempts and reconsider instead of pushing a broken approach for another hour. You will learn that ruling something out is a hypothesis, not proof, and that the only way to know a cause is to read every line in the path. This one habit will make you better than plenty of people with five years of experience, and it works on any stack you ever touch afterwards.
Working on live systems without breaking them
Interns here touch production, which surprises people. It works because the rules around it are strict, simple, and never bent for convenience or deadlines.
Everything happens on a branch. Nothing reaches a client without a human reviewing it. Every deploy is checked by loading the real page, not by trusting that the build passed, because a build passing only proves the code compiled. If a change is hard to reverse, it waits for an explicit yes from someone who can give one. You will learn to work quickly inside those rails, which is a far more useful skill than being fast in a sandbox where nothing matters. Employers do not need people who can move fast, they need people who can move fast without costing them a client.
Who this suits, honestly
This suits someone who is genuinely curious about how things work and slightly allergic to hand waving. If you enjoy the moment where a confusing bug suddenly makes sense, and you would rather understand the cause than apply a fix you found online, you will enjoy this a great deal.
It does not suit someone who wants a narrow, well defined ticket queue with every decision already made. The briefs are clear about the objective and the boundary, but you will often have to work out the middle yourself, with help available the moment you ask for it. Asking early is encouraged and never held against you. What is held against you is spending a day stuck in silence, because that costs the team far more than the question would have.
What you leave with
Three months in, people who have done well have shipped live work they can point at, learned to verify their own claims with evidence, and built at least one system end to end from empty folder to live URL. That is a portfolio that proves something, rather than a list of technologies.
The habits are worth more than the code. Reading before guessing, reproducing before theorising, checking the real page before saying it works, stopping and re-planning after two failures. Those transfer to every job you will ever have and to stacks that do not exist yet. We have been building with AI since 2019 and deployed 500+ AI agents, and the clients you build for are real businesses with real customers, from martial arts schools to regulatory consultancies.
How to apply
Send one email with a link to something you have built, one paragraph explaining a bug you fixed and how you worked it out, and the sentence “I want the AI automation developer role”. The bug paragraph is the part we read most closely, because it tells us how you think rather than what you have memorised.
We are looking for a specific shape of answer: what you expected, what actually happened, what you checked, and the moment you realised your assumption was wrong. Vague answers about “trying a few things until it worked” tell us the fix was luck. Shortlisted applicants get a short practical task, which is a problem we have already solved so we can compare your approach to ours. It is not unpaid work for us and it will not take your whole weekend.
