You build it, you own it
Even if a coding agent wrote every line of code, I still own the resulting product. I own both the successes and the failures.
So I need to consider:
What happens when what I shipped breaks? A formatting bug on an internal dashboard is annoying, but a 404 on a live page serving millions of users is an incident.
You could call this the blast radius. Is an issue just a nuisance to me + my direct team, or does it extend to our users + customers?
Who owns making the fix? Whoever is paged at 2am needs to have all the context to fix the underlying issue. For most production web infrastructure, this person is likely not me, the marketer.
Some of the most useful tools I’ve built with coding agents don’t need an engineer, because they never touch production infrastructure. Internal tools for data analysis or customer research don’t need an immediate fix if they break.
For example, each of the tools below took less than 4 hours to create on my own, and could even be public on the web by being deployed to Railway. They save me + our customer engineers tons of manual research time.
While not perfect, internal tools help me both understand behavior and solve problems in a much more automated way than I would otherwise.
This type of tooling is internal, not a core part of the product, used weekly by a few people, and if it breaks, the blast radius is mostly just my own time.
A few examples of internal tools I’ve vibe coded:
Before admitting a company into Railway’s partner program, we ensure they have a template that meets our best practices guidelines. Verifying this used to involve a support engineer launching the template and QAing it.
Now, I have an app to verify whether templates meet the standards by just entering the URL. This enables me to be self-sufficient and makes verification fairly instant.
Awareness campaign metrics dashboard
In 2026, Railway is prioritizing broad-market awareness. This means sponsorships + brand campaigns. These are notoriously hard to track, particularly because they depend on metrics that we can’t directly collect, like YouTube views. I built a dashboard where I can enter links of YouTube videos and OSS tools we sponsor, and with the Youtube API and public npm data, map their engagement metrics and release dates over our growth metrics to view correlation.
Content quality checker app
Community is everything to us - which is why we’ve invested in our affiliate program to reward users who share about Railway.
As an exploration, I looked into what it would be like to automate monetary rewards (we call them bounties) for user-generated content.
This app takes a link or plain text and audits the content against a set of criteria to check for authenticity and accuracy. Note: this isn’t live, and purely a POC.
Claude Code has completely changed my workstream - by investing just a few hours into vibe coding a tool that’ll help me do my core work, I’m able to make more informed decisions while burdening adjacent teams less with new ideas.
When you need engineering
Going back to vibe coding that landing page.
What if it’s not just a landing page, but a completely new section of the site, at a new subdomain, with new structure. That makes it a bit more complex.
I’d need to consider:
Traffic and scale. What happens to the site if it reaches 1M daily users? At Railway, our website infrastructure is maintained by our engineering team - so we have load handling, caching, CDN configuration, and graceful degradation already in place. These aren’t things as a marketer I’d want to setup or own.
Security. If the page collects user data or touches payments, this is particularly important. Even simple landing pages can be subject to attacks. There’s no way I would vibe code anything related to our Stripe integration, for instance.
Defensive thinking. I caught a gnarly bug once where all the buttons on one marketing page broke, because we switched from capital case to sentence case, but button paths were hardcoded to capital case. An engineer might’ve caught this with defensive programming, but the coding agent did not.
Monitoring. Anything user-facing should have tests and checks in place so if there’s an issue, I know about it before our users do.
All of these combine to form the underlying engineering system.
Wherever possible, I much prefer to ship within existing systems that my engineering team has already set up, vs adding new systems myself. This allows me to iterate quickly, while leaving ownership to the engineers.
A few examples where I could implement improvements myself on top of existing engineering systems:
- Implementing a new landing page for partners when launching our partner program in September 2025. It used existing design components, existing form integrations, and existing web infrastructure. The only truly new piece was the URL and copy.
- Testing a new banner within the product experience that promotes Railway’s referral program. The banner design existed, and the GraphQL query for new users was already exposed to the frontend to show it to only a subset of users.
The key insight here: while I am no frontend or design engineer by any means, I could self-serve growth experiments both on the website and within the product that are visual and copy-based, without introducing new infrastructure complexity.
How I choose when to vibe code
There’s a time and a place for non-engineers making code changes (in my case to web properties) with agents. For many of us, the time is now, so let’s pick the place.
Start with tasks you own end to end. If you own the outcome and have all the context for any fixes required, coding agents enable us to ship things we don’t have the skillset or time to do by hand. Research, internal tools, and analysis all fall into this bucket.
For frontend (web) work, separate ownership. Engineering maintains the systems, non-engineers build on top of those systems, with review. The key question is not “can I build this page”, it’s “does the system this page would live on already exist”.
Engineering-heavy work, like actual product implementation, should be owned by engineers. Non-engineers might implement MVPs to illustrate strategy and vision, but ultimately the user-facing stakes require engineering rigor in a production system.
The biggest shift coding agents have facilitated is where the handoff happens.
Non-engineers (in marketing, growth, dev rel, product, etc) have far more leverage today than we did a year ago. But for our use of coding agents to be sustainable, we have to work within the right boundaries, so we don’t get our friends in engineering paged at 2am.
