Software Engineer, Frontend (Vue)

Copenhagen, on site. Permanent, full time. Mid or senior. Pharma communication is slow for a good reason. Every claim needs a reference, every asset needs approval, and every market has its own rules. We think the software that wins in this industry treats those rules as part of the product rather than something to work around, and that is what we build. Anthill builds the software pharmaceutical companies use to create, approve and run their digital communication. At some of the world's largest pharma companies, commercial and medical teams rely on our products to produce and distribute regulated content. We're around 70 people, headquartered in Copenhagen, with four products: Activator, Arcane, Amplify and Anthill Cloud. Our products are already delivering GenAI-powered capabilities to Enterprise customers around the world. We're growing fast, and it's a good time to join. In our Copenhagen office, engineers, designers, product people and strategists all sit in the same room. We're 15+ nationalities, so English is the official and everyday language in the office and in the codebase. We are hiring a software engineer into our frontend chapter. What you will actually work on You will work across our product line, building the tools our users produce regulated content in, so the work gets faster for the people doing it and more controlled for the people signing it off. In practice that means editors, chat-style interfaces and the approval flows around them, all Vue and TypeScript, on our new shared design system that the products build on instead of each keeping their own. Coding agents write a growing share of our frontend code. Your work is deciding what gets built and how, writing it down so people and agents build on the same decision, judging what comes back, and writing the code yourself when that is the better way. In your first year you will:

• Take part in the decisions that shape our frontends: how a component should behave, and where shared code ends and product code begins.
• Own features end to end in one of our products, from design handover to production.
• Write the specs, agent instructions and checks that keep generated code inside the design system, and tighten them when something gets through.
• Direct the agents that migrate real product screens onto the shared design system, and own what gets migrated, rebuilt or left alone.
• Build new content types on our authoring framework, where each type is an editor experience that plugs into a shared contract.
• Review what agents and designers send as pull requests, including token changes from Figma, to the same standard as any other.
• Work directly with product design and with the engineers who own the APIs you consume.

Our users are medical and marketing teams inside large pharma companies. They spend their whole working day in our tools, they work under regulatory constraints, and they notice when something is slow or unclear. That is a good constraint to design against. The levels We are hiring at mid or senior level and will fit the role to the person we meet. What changes between the two is scope rather than the kind of work. A mid owns features and lives with their consequences. A senior owns decisions that outlast the mission they were made in. Tell us where you think you sit, and we will tell you if we see it differently. You do not need to tick every box below. Some of this is learned here. What we are looking for

• Vue, JavaScript and TypeScript you can write well yourself, without an agent. That means both the Options and Composition APIs, and the DOM and object model underneath.
• Component work you have lived with: building or maintaining shared components or a design system that more than one team depends on, and keeping it coherent as they pull in different directions.
• Experience with agent-driven development: daily work with coding agents such as Claude Code, giving them the context they need, and knowing when to stop and write it yourself.
• The judgement to reject a change that works but is wrong for the codebase, and to explain why in writing.
• Tests as part of the work: unit tests in Vitest and stories in Storybook.
• REST APIs, state management in Pinia, Vuex or nanostores, modern build tooling, and Git in a shared trunk.
• The ability to hold a position with a designer, and to change it when the argument against you is better.
• Working English. Danish is not required.

Useful, not required:

• Design systems built for agents: token layers, component specs, agent instructions, or MCP servers that expose them.
• Accessibility against WCAG, including automated checks.
• Browser security in practice: CSP, CORS, embedding across origins and handling access tokens.
• Performance on data heavy interfaces such as editors, tables and canvases.
• Experience in a regulated industry, or any other setting where being wrong has consequences beyond a bad sprint review.

How we work Engineers belong to a chapter and work in missions. The chapter is your professional home and where your craft is developed. Missions are time boxed, cross functional teams pointed at one outcome. When a round of missions closes, people rotate and a new set forms. The rotation is the point. Over a couple of years you work with most of the engineering team and across most of the product surface, instead of spending three years in one squad on one corner of the codebase. Product decisions run through HIVE, our gate model. Nothing gets built because someone senior liked the idea. Initiatives pass through evidence, solution framing and a funding decision before engineering starts, and they are not closed until the outcome is validated rather than when the code ships. As an engineer this means you get told why something is being built, and you are expected to argue if the reasoning is thin. We work trunk based on Anthill Cloud and review each other's code. We expect the person who built something to be able to explain how it runs, and we hold the line on security and access because our clients audit us and we hold their data. What we offer

• A permanent Danish employment contract, pension and health insurance.
• A salary set from our salary bands, the same way for everyone at the same level. Where you land in the range depends on your experience and skills, and on pay equity with colleagues at that level.
• Five days a week in our Copenhagen office, with two work from home days a month as the default. We are on site because most of what engineers learn from each other happens in conversation at someone's desk.
• Colleagues who have shipped software into pharma and know how demanding that audience is.
• Clients whose problems are specific and constrained, which is more interesting than it sounds.
• Occasional office dogs, who expect to be petted.

In the interview you use the tools you use at work, coding agents included. You will also write some code without one, and review code an agent wrote and tell us what is wrong with it. Daniel Kvistgaard leads the frontend chapter and would be your manager. Questions about the role can go to him on LinkedIn. Applying If you can recognise yourself in just some of these requirements or skills and simply want to learn the rest, we would love to receive your application. We offer an open environment with freedom under responsibility, where you have the opportunity to grow professionally. Apply through LinkedIn, or get in touch directly if you would rather have a conversation before a formal application. We read everything ourselves. Your CV does not need a photo, your age or anything else that is not about your work. If there is a repository, a component library, a design document or a postmortem that tells us more than a cover letter would, send that too. We review applications as they arrive. Where the role has a closing date, it is stated at the top of the ad. Otherwise the role stays open until we find the right person. We only work with recruitment and search firms under a written agreement, and we do not pay fees for candidates we did not ask for. Please do not send CVs to the hiring manager.