Vibe coding is boring..

Coding just ain't the same as it used to be

Vibe coding is not boring because it is weak. It is boring because it can be incredibly effective. Once everything is connected and an AI coding agent has the access it needs, I can describe a feature, let it write code, run the simulator, test the happy path, fix a few bugs, update the backend, deploy Firebase Functions, and upload a build to TestFlight.

That is a ridiculous amount of execution for one prompt. It is also a completely different day of work than the version of software engineering I learned 15 years ago.

I spend more time prompting, waiting, reviewing, answering questions, and multitasking than I spend typing code from scratch. For an early app without millions of users, I am comfortable letting AI handle a lot of the initial testing before I bring in beta testers and use the app naturally myself. For an established product at scale, I would still do deeper manual testing, end-to-end testing, observability checks, and release review.

That distinction matters. AI can move fast. It cannot silently inherit responsibility for the consequences of a bad release.

What vibe coding actually changes

When people say vibe coding, they sometimes mean telling AI what to make without understanding the code at all. That is one version. The version I use is closer to directing a fast, tireless implementation partner.

I still decide what is worth building, what the user needs, what a feature should feel like, what tradeoffs are acceptable, and when a result is good enough to ship. AI handles more of the mechanical execution: reading files, proposing changes, wiring screens together, writing tests, chasing errors, and explaining unfamiliar parts of the project.

OpenAI's Codex overview describes the category well: an agent can work across a codebase and use tools to help complete software tasks. That changes the bottleneck. The scarce part of the work moves away from producing lines of code and toward judgment, product taste, context, review, and accountability.

Why it can feel boring

The old loop had a particular kind of reward. You sat with a hard problem, got stuck, tried something, learned why it failed, and eventually made the thing work with your own hands. A clean build after hours of debugging felt earned because you personally carried every frustrating step.

Now I can sometimes say what I want, wait a few minutes, and come back to a pull request, a simulator running, or a build ready for testing. I can still be proud of the decision, the creativity, and the final result. But it is not the same pride I would feel if I built every part myself and somebody complimented the craftsmanship.

It feels like telling someone how to build your house exactly the way you want it. You own the vision and the choices. You may even have supervised every important decision. But you did not personally frame the walls, and that changes the feeling.

That does not mean the new work has no craft. It means the craft is changing shape, and I think a lot of professional software engineers are quietly mourning that.

The new workflow is mostly directing and verifying

Once an AI setup is connected to the right repositories, simulators, credentials, and deployment tools, a normal task can look like this:

1. Define the user problem and success criteria.
2. Ask the agent to inspect the relevant code and propose a scoped plan.
3. Review the plan for product, security, and architecture mistakes.
4. Let it implement the focused change and run targeted tests.
5. Use the simulator or the real app to check the experience yourself.
6. Deploy only after you understand what changed and what could break.

The part that feels passive is the waiting. I fire off prompts, answer a question when the agent needs me, then move to the next task. That lets one person cover more ground, but it also interrupts the satisfying rhythm of deeply inhabiting one technical problem for hours.

AI can test a lot, but it cannot be your only quality bar

For early-stage products, I let AI handle a lot of initial testing. It can launch the simulator, follow a known flow, inspect errors, make a fix, and repeat. That gets you to a usable internal build much faster than manually checking every obvious detail first.

But early testing is not the same thing as real validation. AI does not have your users' habits, accessibility needs, expectations, or annoyance threshold. It may confirm that a button technically works while missing that the label is confusing, the transition feels slow, the notification is poorly timed, or the feature solves the wrong problem.

That is why beta feedback still matters. Apple's TestFlight overview explains how to distribute builds, collect tester feedback, and track crashes before release. AI can help you reach that stage faster. Actual people tell you whether the product deserves to move past it.

For an established product, I would go further: manual regression testing, end-to-end test coverage, analytics review, logs, crash monitoring, privacy checks, and a real rollback plan. Speed does not remove the need for engineering discipline. It makes discipline more important because you can create risk faster too.

The backend and deployment part is where the stakes rise

Front-end polish is visible. Backend changes can be quietly dangerous. An AI agent may update a Firebase Function, a database rule, a scheduled job, or an API call in seconds. The change can look reasonable and still create duplicate notifications, expose data, raise costs, or break a production flow.

Cloud Functions for Firebase lets teams run backend code in response to requests, events, and schedules without managing servers. That convenience is powerful, but it does not make deployments casual. I want scoped changes, focused tests, a diff I understand, and a live readback after deployment.

The same principle applies to builds. AI can handle build settings and upload steps, but the engineer should know what version is being released, what changed, who is testing it, and how to respond when something goes wrong.

What I still want to do myself

I do not think the answer is to fight AI just to preserve an older feeling. I embrace the power it gives us. But I am trying to preserve the parts of software engineering that make me better and keep the work human.

I still want to spend time on these things:

• Talking to users and deciding what problem is real.
• Designing the product behavior, not just the screen layout.
• Learning enough of the system to spot a bad answer.
• Reviewing code that touches trust, payments, privacy, and reliability.
• Debugging a hard issue occasionally instead of outsourcing every uncomfortable moment.
• Measuring whether a shipped feature actually helped anyone.

AI can draft options. It cannot have your relationship with the customer, your responsibility for the business, or your long-term understanding of why a product should exist.

How to keep the work fulfilling

The fulfillment may not come from typing every line anymore. It may come from becoming much more intentional about the parts only you can own.

Pick problems that matter. Learn the architecture behind the prompts you send. Treat AI output as a first pass, not a mysterious authority. Build a taste for what good software feels like. Make time to understand a difficult bug before asking the agent to erase it. Keep a record of the user outcomes you created, not just the tickets you closed.

That is still craftsmanship. It is just craftsmanship at a different level of abstraction.

It is okay to feel uncomfortable about it

I have been a programmer for 15 years, so I feel the difference. Some of the joy, pride, and fulfillment that came with solving coding problems and making code build something has changed. I do not think it is irrational or anti-technology for experienced engineers to feel a little loss there.

At the same time, I do not want that feeling to become paralysis. The tools are here. They can help us build better products, test more ideas, and make useful software accessible to smaller teams. The move is to adapt without pretending the transition feels emotionally neutral.

The goal is not to become a person who only prompts. The goal is to use AI to extend your ability to build things that genuinely matter.

Final thoughts

Vibe coding can be boring, and it can also be one of the most empowering shifts in software development I have seen. Both can be true.

I still care about the craft. I still want to understand the systems I ship. I still want the final product to feel intentional. I just have to find new sources of pride beyond writing every line manually.

If you are a developer feeling weird about this change, you are probably not alone. It is okay to take a minute to mourn what the job used to feel like, as long as it does not stop you from learning what the job can become.