Element x LinkedIn integration is live: project recap
LinkedIn confirmed today that Element’s XML feed has been approved and our clients’ job postings are now publishing directly to the platform. On the technical side, this is a full integration with the LinkedIn Jobs XML Specification v1.2: a single public endpoint aggregates job postings from every Element client into one XML file that LinkedIn pulls and indexes. On the human side, something else matters more: I built this entire project from scratch to production using vibe coding with Claude Code, and I’m not a developer.
This is the third post about the integration. The first one ran back in September 2025 and framed the project as a test of a thesis: that someone without an engineering background can build serious digital systems together with a language model. After eight months of work, I have an answer backed by data.
What "a non-developer built an enterprise integration" actually means
I’m the CEO of Element, an AI consultant and implementation lead for companies, and I run workshops on the practical use of AI in business processes. I configure systems, design processes, and validate architecture, but I have never written production code. Until now, integrations with external platforms went straight to the dev team: backlog, estimate, sprint, code review, deploy. This time I ran the full cycle, from the first architecture draft to the final security fix, by myself with Claude Code. Element still has a development team, but I took this particular project on my own as an experiment, in the spirit of what I teach clients: moving from AI curiosity to operational use of these tools in real work.
The result: 8 calendar months, 75 commits in the current cycle, and 18 pull requests. The stack is PHP 8.1+, Symfony 5.4, Angular 13, and TypeScript. The backend architecture is built on DDD with CQRS and event sourcing, multi-tenant, with a separate read model in a dedicated config database, because LinkedIn required a single XML file for all platform tenants. Coverage landed at 540 green integration tests and 800 green Behat scenarios.
Vibe coding isn't a shortcut, it's discipline
The first attempt failed. Six pull requests were closed without merge after the team’s code review. The architecture was too monolithic, module boundaries blurred, the event projection wired straight into the controller. The team was right, and the language model, without a sharp brief, took the path of least resistance, which is stuffing all the logic into one place.
The reset forced a decomposition into three phases with clean boundaries: Phase 1 was the LinkedIn provider integration with the existing factory, Phase 2 was the read model aggregating jobs across tenant databases, and Phase 3 was the public XML endpoint compliant with the LinkedIn Jobs specification. The second attempt went through with no major corrections. Vibe coding isn’t about hammering prompts until something passes. It’s about listening to feedback carefully and replanning when the plan falls apart. Claude Code caught the code review feedback, proposed the decomposition itself, and came back with a better structure, but only because I didn’t try to push the previous version through by force.
Back-and-forth with LinkedIn LTS Support
Shipping the first version of the feed to production on October 17, 2025 didn’t close the project. LinkedIn rejected the feed on the first validation pass, because the company field was hard-coded as Element.app instead of the actual client names. Along the way it turned out that several field names didn’t match the spec: wrong case, wrong industry vs. industryCodes structure, dates in ISO 8601 instead of MM/DD/YYYY. One large pull request added 740 lines and remapped five enums to LinkedIn codes, where engineering became eng, technology became 6, and mid_senior_level became MID_SENIOR_LEVEL. All with 540 green integration tests.
Then came the iteration loop with LinkedIn LTS Support. Each report was a micro-incident: the field is called CompanyId, not linkedInCompanyId; the description has to be raw HTML, not escaped; the city field is missing, location is being ignored; some jobs have no country or city at all; one tenant is still missing a country in config. Seven spec-compliance pull requests, each one to three days from LinkedIn’s report to production. Full vibe coding flow at every step: investigation, plan written to a file, code, tests, code review, build, deploy, status update.
Defensive engineering: the Element.app incident
A few weeks after the first green validation, an unpleasant note came back from LinkedIn: jobs were appearing in the feed, but two of them were once again showing Element.app as the employer. The cause was an asymmetry between frontend and backend validation, meaning the form required a company name as a mandatory field, but the server-side system treated it as optional. Any non-standard path to creating a job (a stale browser cache, a direct API call, or an older data migration) could bypass the form and leave that field empty, and when it did, the internal fallback mechanism eventually walked all the way down to the platform name, which is Element.app.
The fix wasn’t about correcting those two specific job ads. I closed the entire mechanism so that Element.app could never reach the feed again, no matter how a job is created. Backend validation was aligned with the form, and if for any reason the employer name is empty, the job is dropped from the feed and the system logs a warning. Better not to publish a job than to publish it under the platform name. That’s how ATS behaves when it has to be stable in production with real clients: not patching individual cases, but closing whole classes of failure at the system level.
The role of Element's developers in code review
Vibe coding didn’t happen in isolation. Across the full eight months, every plan I wrote and every pull request went through code review by Element’s developer team. They were the ones who caught the problems in the first attempt and forced the decomposition into three phases, they held the line on production code meeting the same standards as the rest of the repo, and they flagged the architectural dead ends that the language model was happy to walk into. Not a single commit from this integration would have reached production without their review.
This needs to be said directly: the project is not proof that developers are no longer needed. It is proof of something else, namely that a person who understands the domain, plus a language model, plus a disciplined review team is a configuration that works. Vibe coding without review is a hobby project. With review, it becomes a production process.
I want to publicly thank the Element development team for their contribution to this project. Every green merge under a pull request was their call, not mine. This article wouldn’t exist without their willingness to patiently work through the first attempt, point out the failures, and then run the second attempt through exactly the same standard as hand-written code. Thank you.
What this means for someone who doesn't write code
The first lesson is obvious but often overlooked: AI doesn’t replace architectural skill, it amplifies it. The project reset after the first code review showed that without the ability to read feedback and replan, even the best language model won’t pull a project out of a hole. My contribution as CEO of Element and AI solutions architect was to recognize that module boundaries were blurred, to accept the criticism, and to steer the model toward decomposition.
The second lesson is about discipline in keeping the plan alive. Every non-trivial change has its own plan file with PR links, decisions, and a risk log, and the plans are updated during implementation, not written once and abandoned. Same with tests: 800 Behat scenarios didn’t appear because Claude Code likes writing tests, but because I consistently demanded them for every micro-incident.
The third lesson matters most to me: vibe coding works when you genuinely understand the business domain. I have never written production code, but I’ve spent more than a decade in recruitment, ATS systems, and integrations with job platforms. That’s why I could tell whether Claude Code was heading in the right direction when it proposed a country fallback chain based on a city dictionary. Without that domain, the model would have hammered out code that passes tests but doesn’t fit the business.
Where we are today
The integration is stable, CI is green, the regression vector is closed, and the message from LinkedIn confirms that jobs are now publishing through the feed. From a business perspective, Element has just opened a new distribution channel for job postings across all platform clients, without recruiters having to publish ads on LinkedIn manually.
From a personal perspective, I built an enterprise XML integration from scratch in vibe coding mode, in a stack I have never written by hand. This is a lesson about the future of work in the age of AI. Language models won’t replace developers, but people who understand the business domain can now take on things that, a year ago, required a team of senior engineers. I wrote about this more broadly in The Great Reorg: companies are rebuilding around AI.
If you run a company and you’re wondering whether AI is a good tool for building your own integrations, the answer is yes, provided you have someone who understands the domain and has the discipline to keep the plan alive. If you’re looking for a recruitment system that publishes jobs to LinkedIn automatically, take a look at Element.
DISCOVER ELEMENT!
Maciej Michalewski
CEO @ Element. Recruitment Automation Software
Recent posts:
The AI job apocalypse is a fantasy, says a16z. But Poland?
David George of a16z says the AI job apocalypse is a fantasy. I test his thesis against Polish data and a fresh vibe coded experiment of my own.
Vibe Coded Element x LinkedIn integration is live: project recap
LinkedIn approved Element’s public XML feed, fully built in vibe coding mode with Claude Code. What that means for people who don’t write code.
danehr.pl: a new data hub for the Polish labour market
Polskie Forum HR has launched danehr.pl, a portal that gathers employment, wages, unemployment and labour market reports in one place. Element is the technology partner of PFHR and feeds one of the portal’s sections.
The Great Reorg: companies are rebuilding around AI
Foundation Capital interviewed 25 companies and found that AI is not just speeding up work — it is forcing organizations to rebuild from the ground up around four human roles.
Gallup 2026: the workplace is cracking and managers lose drive faster than the rest
Gallup State of the Global Workplace 2026: engagement fell to 20%, managers lose drive faster than their teams, and the AI paradox is clear: personal productivity rises, organizational does not.
A Polish-founded robot that drives screws faster than humans
A Polish-founded robot that drives screws faster than humans When people think about automation, they usually picture chatbots, image generators, and coding assistants. Meanwhile, AI
