In the beginning of my career, I've been once told by my senior management that I should never again:

1. Optimize things so that they work 10 000 times faster because it makes us look incompetent (must be done slowly to show gradual progress).

2. Brag about such optimization (to stakeholders) without first synchronizing this with them (so they can brag proportionally to their pay rate :) ).

I can relate to this so much. When I was a newly joined Google consultant at a partner firm, we went to their office - some 13 different types of cuisines, different types of game rooms, lounges and what not. A luxury star hotel experience. We were waiting for our meeting on behalf of this one particularly large media client who was bleeding money on Wordpress.

3 engineers arrived - fashionably late. We explained them the situation and all we wanted from them was some GCP offering that would cure our woes and one that would cut our bills. The senior consultant - and presumably the only tech guy (rest seemed to be salesy) wasted our time like a used car salesman - he didn't even understand Google's own product portfolio and recommended us to use something like Spanner - which was totally not the solution to the problem, not to mention, expensive.

My boss and I left the meeting pissed off and he told me - "Neya, you probably know more about the product portfolio than these guys. Let's leave". That weekend, I went with my tried and trusted favorite Db - PostgreSQL - CloudSQL with a custom Elixir middleware based an old CMS I wrote a decade ago. After some trial and error, the solution worked flawlessly (and still does till date on auto-pilot). My client still has the lowest cost in the region - 1/3rd the cost of their competitors...7 years later. Back then, there was no vibe-coding, no AI, no auto-completion. Just pure thinking and experimentation.

All this just to say I agree that the new guy sometimes can make the best solutions to a problem and not always screw up. I always listen to new hires these days (now I'm a fractional / CTO) because you never know who could pull off that 1/3rd cost cutting framework move.

> Later my boss told me not to do that again because it caused havoc with schedules and such.

Did you talk to anyone about your plans before you brought in the demo or let them know they were solved problems? Often these sorts of reactions come down to your boss not wanting their team to lose their jobs because of the perception that it can all be handled by one person who's happy to work weekends.

Oh I have seen this story and was the one who caused this story when I was younger.

In a lot of cases the "new guy" thinks its an easy software and does it on his free time and thinks he did a great job.

In reality the specs are never 100% done correctly. The "new guy" misses some edge cases everybody but him knew because its just company knowledge. A lot of info in the specs was missing since they are not complete and so on.

This over the weekend never works in the long run. The ORM worked for all the happy path and written down cases but then you have cases were the ORM just is not good enough or fast. So you start to add strange code to work around the ORM. The same for the web framework or the validation lib.

To me the author of this comment sounds like the typical "Freelancer" coming in into a company knowing everything better then all the people and then leaving after a few months and now everybody else has to deal with his code.

Take this idea and bring your own validation library and forms and UI components to the next job, and you've described what I do. And then you have real lock-in.

Also, some people want to work on what's already familiar to them. If building a framework from scratch is what appeals to them, they'll do that even if a framework already exists. Busywork to look productive.

Yeah, that definitely happens.

But I don't think Claude Code is going to prevent an org that thinks they can prompt their way to a replacement for all their SaaS from having internal political bickering that makes them end up with a extra-shitty mega-compromise to try to make all the internal stakeholders happy.

If you've got no vision and no taste, you need to find a vendor who will protect you from screwing up your internal processes and tools.

Internal tools teams have rarely cared much about UX or the day-to-day experience of their poor users. The quick-and-dirty internal-prompt-based one is likely to similarly be unimaginative and unintuitive.

I was complaining about SQLAlchemy's insane quirks to a group from my alma mater and one of the grad students said, "Well, the solution to your problem is clear: Write your own ORM." and I had to explain that this startup does not want to get into the ORM-writing business.

> feel free to doubt.

I don't doubt you at all.

I once worked on a project that was a new sign-up process for a large retailer (~90k employees at the time, four figures worth of outlets, quite a few billions in turnover).

There were about 60 people across, I can't even remember, maybe 10 teams that I knew about. One of the managers there assured me that the true participant figure was closer to 160. I was agog.

This project took months, and it had been going for months before I joined. And, as you can imagine, with that many people involved over that sort of timescale, there was turnover: people, sometimes key people, would leave and be replaced - sometimes by others who'd already worked on the project, but sometimes by new people - with the expected disruption that causes.

It was two web pages, plus some back end plumbing across multiple systems.

But, in the grand scheme of things, nothing that complex. I reckon it was a handful of thousands lines of code total across the full stack. I was mostly on the database side and, IIRC, I wrote a few hundred lines of SQL in a couple of stored procedures (wouldn't have been my preferred solution building from scracth but, you know, we weren't, and we had to integrate with a legacy systems that had to keep working as expected).

Overall it took 8 or 9 months from kick off to shipping and I was involved for perhaps 3 months of that towards the end. I was on the call with dozens of other people whilst me and one of the other guys hooked the final pieces together and tested it end to end for the first time... and it worked. There was actual cheering.

Large enterprises are genuinely ridiculous.

I had a similar experience where someone that had prior experience with django while we were using sqlalchemy started to design a django-like ORM on top of sqlalchemy. Of course it took him some time to get working, was a hell to understand and extend and most importantly lacked support for basic features.

Fortunately it was limited to a small isolated service but I can imagine the damage on the long term if you continue that route on what becomes a huge monolith after a few years.

Isn't this agreeing with the parent? If Django were the B2B SaaS product, you didn't vibe-code Django, you just used Django. You aren't responsible for maintaining Django itself.

It feels like I have worked with you (though obviously not). Had same experiences to the T.

Maybe it's just something that happens to many in web development world, not-invented-here and all...

Rule #1 of power: never outshine the master

I resonate strongly with this story. I’ve seen three people teams get in one month where SAP could not in year, and also let and witnessed incredible number of total fakers in SaaS enterprises.

Big corpo may be too big to fail, not so sure about their whole cohort of partners and fakers.

> Sometimes the new guy can make a better version themselves over the weekend, not because they’re a supergenius, but because they’re not hampered by 47 teams all trying to get their stamp on the project.

In 99.9% of cases what seems to be "the better" version is better only for the "new guy" or rather his ego.

Those 47 teams hampering doesn't necessarily mean a bad thing, and more often than not actually well justified "stamps".

You only understand those things when you turn from the "supergenius" into an owner who have to take care not only of numbers on screen, but also security, interfacing, management and so on.

Or you don't turn into.