Skip to content

aidevelopment

You Vibe Coded It. Who Keeps It Working?

You Vibe Coded It. Who Keeps It Working?

Let’s say you’ve used an AI coding tool to build a customer portal. It looks good. Customers can log in, find what they need, and get something done without calling your office. You’ve solved a real problem, and you didn’t have to wait for someone else to build it for you.

A month later, one of its dependencies needs a security update. The agent proposes a patch, runs the tests, and tells you everything passed. How do you decide that’s enough to release it while your customers are using the system?

That’s something I’d want to work through with you before you’re staring at an update wondering whether to click Deploy.

What happens after people start using it?

Once your team or your customers depend on that application, someone needs to handle updates, investigate failures, and answer support questions. Changes need review, especially when they affect other systems or the information your business relies on.

Who reviews your code? Who checks access to customer data? Do your logs help explain what happened when something goes wrong, and are they collecting information they shouldn’t?

I’d ask those questions if you’d hired a development team, too. They can be easy to miss when you get from an idea to a working application so quickly that people are already using it before you’ve thought through how to look after it.

Just the agent?

An agent can help with maintenance. It can help prepare patches, investigate problems, and explain code you didn’t write yourself. We should make use of that.

I’d still want us to understand how we’re deciding its work is ready. Passing tests tells us something useful. We also need to know whether those tests cover what your business depends on.

What the agent can help with, and what someone has to decide. Security updates: the agent prepares and tests the patch; someone decides whether the tests cover what the business depends on. Releases: the agent reports what passed; someone decides when the update is ready to release. Code review: the agent explains code you didn't write; someone decides whether changes to other systems are safe. Customer data: the agent helps review who has access; someone decides who should have access. Logs: the agent helps investigate failures; someone decides what the logs should and shouldn't collect. Support: the agent traces what happened; someone decides what the customer expected and how to put it right. Corrections: the agent makes the correction; someone decides what it's allowed to change.

Support raises similar questions. Say a customer tells you their information is wrong. The application hasn’t crashed, and the monitoring hasn’t raised an alarm. Someone needs to understand what the customer expected, trace what happened, and decide how to put it right. If we ask an agent to make the correction, we need to be clear about what it’s allowed to change.

That takes an understanding of your business as well as the software. The person who knows how your billing works may recognize a problem that wouldn’t look like a software failure at all. I want that person involved.

How we can help at Clevyr

At Clevyr, we can help you understand what you’ve built and what your business needs to keep it working.

We can sit down with you, look at how you’re using the application, and work through what needs attention. That might include reviewing the code and how it handles data, looking at its connections to other systems, or figuring out who’s responsible when someone needs support.

There’s an education piece here, too. We can help you and your team get better at evaluating what an agent produces and recognizing when you need another set of eyes. You should understand enough about your application to make informed decisions about changes, access, and support.

That’s where we can put decades of experience creating and maintaining software to work for you. How much help you need will depend on what you’ve built, who’s using it, and what happens to your business when it stops working.

I wrote recently about taking responsibility for what happens after software is built. That responsibility follows the application into everyday use, however you created it.

If you’ve built something useful, bring us what you’ve created and what you need it to do. We can help you work through what it’ll take to keep it working.

Keep reading

YOUR NEXT DECISION

What is your business working around?

Tell us what's slowing you down, what you've tried, and what needs to be different. We'll start there.

Come with a problem. You don't need a specification.

The first conversation helps define the next step, whether or not that step is with us.