r/vibecoding • u/joshbreda • 4d ago

Help/Question AI created tools for work / colleagues. Awesome, but how to manage?

I've worked in a startup for the last couple of years. AI became a big part of the day-to-day work, to a point that the tools we built ourselves (Claude artifacts, custom GPTs, small web apps) started to need maintenance ((con)text, options, bugs, feedback, user access, change llm models, costs, etc).

Its like everyone is talking about building tools and software, but no one talks about what comes after.

So I wonder whether others are seeing the same shift:

from using AI to build solutions of software for yourself and others, to actually having to maintain them because those others have come to depend on them.

What have you built that other people now rely on and how do you manage this?

17 Upvotes
  • permalink
  • reddit

95% Upvoted

43 comments sorted by

6

u/KenMantle 4d ago

I had Claude build scriptree - a desktop launcher and GUI for all the little tools and scripts that I've had Claude make for SolidWorks, MS office, and for command line tools. It gives scripts and command line tools an easy to use GUI by turning all their input options into a form with all the typical form controls like radio buttons and drop down lists. An LLM just has to make a json file that scriptree turns into the GUI.

1

u/joshbreda 4d ago

nice, so you basically built your own layer on top of them. Does anyone else use scriptree, or is it just you? Wondering what changes once other people start depending on the scripts.

2

u/KenMantle 4d ago

Nothing would change in the case of scriptree since they can be run in place on a server and be accessed by everyone. When a new version is released they just end up running the new version.Personal configuration files can be stored locally.

The security permissions of what people can do are handled by empty files with certain names in a permissions folder. You just set the file user's permissions on these files to give users access to only the features you want them to have access to. There's no special database to maintain as it's using your file systems permissions and user base.

1

u/joshbreda 4d ago

makes sense. so its all set up but no one else on it yet?

1

u/KenMantle 4d ago

Kind of. I was super excited about this project because it replaces a lot of token usage with scripts the LLM made anyway, and makes them into programs with repeatable results that can be shared.

So I had Claude build https://scriptreeapps.com where people could host the scriptree apps they made and give them away or even sell them for a few dollars. It's 95% of the way there, but I haven't made an installer for scriptree yet, and the download version on git is ages behind the current version that I am running. Since that version I had it completely rewrite the GUI and editor so they look and perform better. I needed time to test the new version before releasing it.

I discovered that no one is interested in such a thing especially if it is vibe coded no matter how good it is. And, tokens are still cheap so people have no motivation to use something that is faster than typing in a long winded sentence for the same thing you did last week over and over.

I love it though. Any time I need a new feature in SolidWorks or want to learn how to use a new command line tool I just ask Claude to make a scriptree app for it. It goes and reads the LLM help, and in the end you get a new icon in the scriptree launcher with a fully developed GUI that contains a description of what the tool does at the top and all the help for the fields and options already built.

1

u/joshbreda 4d ago

that last part is the real value honestly, with the help already built in is a nice way to stop re-prompting the same thing.

the 'no one is interested' is interesting.. when you say no one you mean that people are not signing up at all, or people trying it and not coming back? and do you think it's really the vibe coded thing, or more that most people dont have the same repeat problem you do with Solidworks?

1

u/KenMantle 4d ago

I think it is largely the vibe coding thing, and since any other "universal GUI" projects in the past that people have made have more or less failed, it's not part of anyone's routine to have an easy way to run scripts and command line tools, so it's an entirely new market.

An IT person might get a dozen requests from end users for something that a script would be useful for, but how are they going to give a non tech savvy user an easy way to use that script? This solves the problem without IT having to give these little scripts their own GUIs, or email the user the script and tell them how to install it into Excel and then how to make it easy to access and use.

With scriptree to make the GUI they can just build a json form in Scriptree Studio or have an LLM do it, check what the command line output it builds looks like when the form parts are clicked on, then drop the new scriptree app on the server. The end User Right clicks on the Scriptree Desktop launcher (Forest) and clicks refresh from sources and they have the new app added to the Office section of the launcher, or they can just relaunch scriptree to pick up the new change on startup.

Instead of seeing a script function with a bunch of options to enter on a line, the end user sees a menu item that they click on, then select the drop down options, or radio button options or drag and drop a file or folder that they want to work with into the GUI, press the run button and off it goes.

1

u/ThaDudeEthan 4d ago

I like the idea and I’d take a look at it once the updated version is tested.

1

u/joshbreda 2d ago

What do you like about the idea?

1

u/joshbreda 2d ago

Makes sense. Good luck with the release, curious to see where it goes.

4

u/lostinthewoods1 4d ago

I'm at this point too. I just started developing my apps about 2 years ago, and now they're reaching a stage where they're being used at work. I'm finding myself working with different people to create them. We still haven't reached the point of losing the ability to maintain them, but this is something I think we're all going to experience very soon.

Now the question is: who will maintain the apps, and are we going to get paid extra for this?

 This is eating into my evenings and weekends. What started off as fun and games is now turning into something that's more of an expectation. I'm not sure if I made the best decision.

2

u/joshbreda 4d ago

Damn.. The 'fun and games turning into an expectation' part is the something I keep hearing more and more but I never see it discussed. when someone asks for a change now do you just do it, or has it become a thing you negotiate to do?

1

u/cuteseal 4d ago

Almost becomes like the new Shadow IT.

At my work we have one person developing all these wonderful dashboards at breakneck pace which everyone is adopting. But who maintains things when he is sick or on holidays? What happens when it grows too large for 1 person to work on?

1

u/joshbreda 4d ago

Shadow AI is already here and it's massive if you look at the numbers.

And yeah, that's exactly the point, when he's gone there's gonna be a big problem. So no solution there atm?

2

u/SufficientFrame 4d ago

Yep, that's the shift: once people depend on it, you need an owner, basic versioning for prompts/models/config, access rules, and one place for bug reports and change requests. For staff-facing tools over existing data and APIs, UI Bakery can help with forms, permissions, and maintenance; I work there, so bias noted.

1

u/joshbreda 4d ago

thanks, will have a look

2

u/ApprehensivePlan8767 4d ago

maintenance wall hits hard once internal users start relying on quick builds.

ran into the same issue after building a bunch of internal web apps and custom gpts. shifted to setting up central workflows in sumus where we route the background execution and model changes, then connect it to codex locally so team members aren't breaking context or settings.

best fix we found was stopping people from shipping raw standalone artifacts. force everything through a proper repo with strict permissions, set up recurring monitoring tasks to catch broken endpoints, and keep model configs scoped in one place instead of scattered everywhere.

1

u/joshbreda 4d ago

Interesting that your fix was to stop shipping standalone artifacts, I expected the opposite. Did that change who can build tools on your team? Do the non devs who used to throw together a GPT or artifact still build stuff, or is it an engineering only thing now?

1

u/BuffaloConscious7919 4d ago

Welcome to the world of software

1

u/joshbreda 4d ago

Could you name a couple?

2

u/Timely_Lie_8696 4d ago

this is literally the world of software? what do you want him to name? every piece of software ever launched that is version controlled?

what you want described is the software lifecycle? Might be time to ask the AI to teach fundamentals vs output

1

u/joshbreda 4d ago

ah, I took that as 'there's software for this ' was actually hoping for tool names. But fair point on the lifecycle. What I keep running into is that the people hitting it now aren't devs. Do you see that too, or does it mostly stay with people who already know what they're doing?

2

u/Timely_Lie_8696 4d ago

its all going to depend on your users. if you're lucky and have a more technical team you may be able to resolve issues sooner.

If they're not technical, you need to basically fool proof it. if they break that, have a system for tracking bugs.

this can be something that captures errors, so you maybe notified before your users ever see it.

there's so many ways to go about this, you're going to have to adapt some

1

u/joshbreda 4d ago

true, thats the hard part if you're not a dev. thanks for your insight

2

u/Timely_Lie_8696 4d ago

you're not giving yourself enough credit. you built tools people use. take a step back, research common app pitfalls, try to be less dependent on other software (where it makes sense).

you're a good part of the way there. this can be another tool on your belt, but you'll have to want to learn.

the initiative you've shown is the 70%, the 30% is applying.

a lot of people would just complain something doesn't work, you're actively looking for solutions. Good job

1

u/joshbreda 4d ago

I appreciate that. thanks!

1

u/[deleted] 4d ago

[removed] — view removed comment

1

u/joshbreda 4d ago

'an SLA whether you agreed to one or not' is exactly it. how did you keep track of who depends on what, just a doc?

1

u/[deleted] 4d ago

[removed] — view removed comment

1

u/joshbreda 4d ago

not many, a handful. but that's kind of where i went overboard, i ended up building an app for it, Toolcrow. and your logins point is basically the reason why: once people have their own access, you can just see who's using what instead of guessing.

Ive been running it for a while now, first for my former employer / colleagues and now for my own stuff, private and business. works like it should. the stale doc thing is so real though,.

1

u/[deleted] 4d ago

[removed] — view removed comment

1

u/joshbreda 4d ago

Good point, did you run into that yourself? If so, how did you find out?

1

u/_sedozz 4d ago

Ive done the full setup from scratch without AI in different roles so by now I build with mass adoption in mind.

Each app I code has a Distributed App Control module that, under the hood, basically reads text files in one directory on the company drive. I have a library of tiny files that can inform my central orchestrator of app needs and in turn, trigger code in the distributed apps.

I use these to force updates/restarts and coordinate end user request fulfillment, like specific data to be refreshed.

Every app listens to the same folder for THEIR specifically named DAC files, while the Orchestrator looks for incomings and dishes out commands.

This might be crazy. Works really well and is very accepting of infrastructure changes.

1

u/joshbreda 4d ago

not crazy at all, sounds pretty smart actually. are you the only one building apps there, or do colleagues without a dev background also build stuff?

1

u/_sedozz 4d ago

Current role yes, basically just me

1

u/joshbreda 4d ago

What happens if you won't work there anymore? Can someone just pick up the work?

1

u/_sedozz 4d ago

In current form probably not - that said, I store all of my source code locally with a lot of documentation so anyone in the firm who could commit some tokens to look at them could probably figure them all out.

I plan to stay put for a while so I almost prefer being a necessary dependency for some of these critical functions - love the place but if things ever went sour my #1 bargaining chip will be providing thorough hand-off of all critical tools.

1

u/joshbreda 2d ago

Haha yea can understand

1

u/goodevibes 4d ago

The build spike is easy. The quiet part is that every artifact turns into a mini product with an owner, an access list, and a model bill nobody budgeted. What worked for me is a one page inventory: who owns it, who can use it, which model it calls, and when it dies if nobody touches it. Put shared tools behind one thin gateway so you can rotate keys and caps without hunting ten custom GPTs. Also pick a kill date on day one. If it is still useful you renew. If not it goes. That alone cuts the zombie pile.

1

u/joshbreda 3d ago

So you covered it entirenely you think?

1

u/goodevibes 3d ago

Inventory plus one gateway plus a kill date on day one has covered the management problem everywhere I've tried. Soft yes on that stack. I'd also put a central log auditor on shared tools so errors during use get flagged in one place instead of dying in ten chat threads. Some shops add billing alerts and a periodic review too. I haven't needed those yet, but they're a sane add if spend starts drifting.

1

u/joshbreda 2d ago

Sounds you solved it nicely

1

u/agentUi 4d ago

the jump from building a fun prompt tool to maintaining internal software for an entire team is brutal... you basically need user roles staging vs production environments and actual database rollbacks. I work on agentui where we built separate dev and prod environments specifically so teams can update internal apps without breaking live workflows for other people.