Manager of agents: a day in the life of an AI engineer at Hostinger

Eylül Güleryüz is a developer who doesn’t write code. She could, but she doesn’t.

She’s an AI engineer on Hostinger’s WordPress team, and every week she ships fixes, gets pull requests approved, and makes the sites built with Hostinger’s AI tools work a little better each time.

Her AI agents do the coding while she decides what they build, improves their skills, and checks their homework. On some tasks, her hands-on time can be just a few minutes.

“I call myself a manager of agents,” she says, “because that’s what I do.”

Her direct reports never take a lunch break and have never asked for a raise. They do ask a lot of clarifying questions, although one of them once spent 8 minutes building something that already existed.

Eylül’s agentic coding setup

You might picture an AI engineer swiping agents across a wall of glowing screens like the hero of a sci-fi movie. Eylül’s setup is simpler.

She works with Claude Code, Anthropic’s coding agent, running in the Claude desktop app, and often has several chats going at once.

Each kind of task runs through its own Claude skill: a saved file with a description, a goal, and steps, or as Eylül puts it, “more like a playbook of what you need to do.”

Her agent’s memory lives in a desktop folder she named Awesome Things, because why aim low?

Setting it up took one request. She told her agent to save what it learns in every session there, and to remember to keep doing it. It’s been taking notes ever since, from how she likes her code to the tone she prefers in her writing.

Model Context Protocol (MCP) connections link the agent to Slack, Jira, Amplitude, and more. Every session starts blank and fills up with the agent’s memory and data from those connections, and the task she’s working on decides which skill the agent uses.

How she starts her day

Her first task of the day is the daily standup. Every morning at 9 a.m., a thread pops up in her team’s Slack channel asking the same two questions: what did you do yesterday, and what are you doing today?

For a while, Eylül answered it manually like everyone else. “I was so sick of doing this all the time,” she says, and most of us would be too. So she did what she does with anything she keeps explaining to her agent: she had the agent turn it into a skill.

Now, at 9:05 a.m. every day, her agent goes through her calendar, Slack messages, Jira tickets, and pull requests from the day before, works out what she did and what’s next. She can check the draft before it goes out or let the agent post it straight away.

She also planned ahead in case the agent ran twice by accident and wrote a rule into the skill: if she’s already replied, check with her before posting again.

The rule got its first test during a demo, when Eylül ran the skill again, having forgotten she’d already replied that morning. The agent checked first, spotted her earlier reply, and held off. “It’s smarter than me,” she said.

Anything repetitive goes to the agent, and her time goes to the work that needs her.

From Jira ticket to merged PR

With the standup out of the way, she moves on to the real work. Most of her tickets take one of two routes to production.

Her What to work on skill ranks her sprint tickets in Jira by impact, so she usually knows where to start. Sometimes she already has one in mind, like a bug she found while testing recently: websites made with Hostinger’s AI builder for WordPress showed special characters like “&” as little codes, such as &.

The cause turned out to be a small gap in the instructions for building those sites. WordPress stores these characters as codes, and expects whatever displays the text to turn them back into the real characters.

Nobody had told the agent that builds the site to do that, so visitors saw raw codes where an ampersand should have been.

Then she picks a route.

For a small fix, she hands the ticket to her Implement until human review skill, which sets up a fresh environment so it doesn’t touch her other work and only pings her once the tests and linters pass.

For this bug, she called Plan and ship. The agent read the code, drafted a plan with four decisions already made, and came back with three open questions.

The first was whether to also scan finished pages for leftover codes. She said no and kept the fix to the two steps the ticket named, since scope creep is a problem even when your developer never gets tired.

The second mattered more: should the site decode the text with a small existing library, or with a hand-written, five-line decoder? The agent recommended the library, because a hand-written one could miss a rare code and leave it showing on the site. She agreed.

The third was about the order in which to merge this fix and another open PR.

The agent writes the fix and opens a pull request (PR) on GitHub. It works from the plan the two of them agreed on, and it comes back to her whenever it needs a decision or access only she can give.

Eylül doesn’t read every line of the result. She checks that the fix does what the ticket asked and that the page looks right, because an agent can be perfectly happy with a page that looks wrong. This time, the ampersand was back.

If a codebase needs a teammate’s approval, the agent keeps watch and merges as soon as someone signs off.

The same run ends with a retrospective. The agent looks back at what slowed it down and what it could do better, and Eylül decides which lessons are worth acting on, so every run learns from the ones before it.

On this bug, the testing step took 28 of the agent’s 37 minutes, and about 8 of those went into building a new tool to launch its test runs, even though one already existed in an older project.

The agent filed that as an issue in Hostinger’s shared skills repository, so the fix will reach every engineer’s agent, not just hers.

Plenty of human engineers have done the same, though fewer of them admit it in writing.

While the agent builds one fix, Eylül is free to start the next, so she rarely works on one ticket at a time. Having three running in parallel is a normal day for her.

Teaching her agent how she works

Her agents weren’t always this well-behaved. Early on, before she’d turned working with agents into a proper process, one kept sprinkling comments all over her code. Telling it to stop in one chat didn’t stick, because nothing carried her preferences over to the next one, so her teammates kept flagging the comments in every review.

The fix came from two directions. She told her agent to save lessons like this to her Awesome Things folder, so it can refer back to them in every session instead of starting from scratch.

At the same time, as part of Hostinger’s company-wide AI adoption, teams wrote instructions for agents in each codebase, from code style and best practices to how a PR should be titled. These days, she says, the agent rarely gets it wrong.

As Eylül puts it, people pick these things up with experience, while an agent only knows what you tell it.

That memory folder pays off outside of code, too. Claude Code was built for programming, but Eylül uses the same agent, with the same memory, for plenty of work that isn’t code.

When she worked on a WordPress AI improvements presentation, it drew from the notes in her memory folder on everything they did together.

She kept the slides open on one side of her screen and the agent on the other, and gave feedback out loud using Wispr Flow, a tool that types what you say into the agent’s chat box while you hold the Fn key.

“I don’t like page nine and this table on there,” she’d say. “Can you change that one?” And the agent would rework it.

What new AI engineers get, and where anyone can start

Setting up the memory folder took one request, but Eylül’s skills and the notes inside that folder grew out of trial and error. New engineers at Hostinger get to skip most of that.

From day one, they get the agents, the written guidelines for each codebase, and the internal hub’s skills section, where anyone can publish their skills and borrow other people’s.

Eylül adds hers whenever she spots a task her teammates are probably repeating too. When she shared the standup skill, her reasoning was simple: “I’m not the only one who’s bored of this, probably.”

So new engineers inherit a library of ready-made skills, standup included, and build their own as they go.

For engineers anywhere, her advice is to start with a knowledge base.

“Agents and skills are applicable to everyone,” she says. “But what you like is very much about you, and you need a knowledge base your agent can feed from.”

Set up a folder (Awesome Things is taken, but feel free to aim that high), tell your agent to save what it learns there after every session, and let the notes pile up.

The third time you type the same instructions, you’ve found your first skill.

Want to work like Eylül?

At Hostinger, an AI engineer’s day goes into guiding agents, checking their work, and turning anything repetitive into a skill. That leaves more time for deeper projects, like working out which AI models should power Hostinger’s website builder.

The WordPress improvements from her presentation came out of exactly that. Eylül designed the tests around real requests from users and set the rules, and her agent did the legwork: drafting reference answers she checked by hand, scoring each model’s output, and rerunning the evaluations on every pull request.

She made the final calls and only switched models when the numbers backed it up. Across 18 features, from color palettes to product descriptions, quality went up on every one she changed, and website generation now costs 35% less.

If that sounds like the kind of work you’d enjoy, and you’d rather share a good skill than keep it to yourself, take a look at our open engineering roles.