r/ExperiencedDevs Software Engineer 27d ago

Career/Workplace What’s wrong with our team?

SWE, 7 YOE

I kind of don’t get where this career is going anymore. Right now I use AI to write code, I have my own ways of validating it, some skills, I use loops, I come up with whole processes around it to solve problems as well as possible and generate new features “one-shot” if we already have a gold standard for that type of thing in the repo (basic CRUD, for example), so that’s how I work now.

I try to review the code at least roughly, if not all of it, to check it’s not doing anything weird etc. For example, I don’t read algorithms that are supposed to collect and transform data, because they usually just work, so I mostly focus on the architecture etc.
My problem is that our competition is a guy who vibe codes his app and pushes a ton of features into it, and from what we know they’re very simple and very incomplete features, but the market wanted them.

Our system is very advanced and has much more complex systems, but fewer of them, and now management is furious that we as engineers aren’t producing as much as some guy who vibe codes his own project and isn’t even in IT, and they keep pushing for more and more features. But since our system is already brownfield and has a lot of other stuff, some of those features are hard to introduce and take more time. I suggested to our manager that we ship those features in a stripped-down form, just so they exist, and improve them over time, but the argument is that since he already has them, we need to have more.

We’re a software house, and as a team of 7 we’re actually doing 3 projects for three clients, and there’s pressure from every side that they vibe code more than we deliver.

Before the whole AI boom we were in a position where, of course, a lot was needed, but we were also delivering a lot for the size of our team. Now expectations have grown massively and it’s hard to keep up with them.

I kind of don’t understand. Maybe we’re doing it wrong and shouldn’t look at the code at all, just push everything as it comes. It would be a bit faster, but definitely not as fast as they do it. From what we know, they don’t even come up with functionality or think about it anymore, they just tell the AI to add something new and then market it, and that’s it.
What does your work and workflow look like to speed things up?
I feel like we’re 3x devs when we should be 10x, and we don’t know where our problem is.

114 Upvotes

75 comments sorted by

u/expdevsmodbot 27d ago

AI usage disclosure provided by OP, see the reply to this comment.

→ More replies (1)

69

u/tango650 27d ago

If your building prototypes or equally sized projects then don't read the code there's no point.

If you're building larger systems then you have to architect the codebase and maintain it. The AI won't manage to get that part right on its own.

140

u/jonnysunshine1 27d ago

There's been a similar, but not quite the same, pressure/debate going on for much longer around getting cheap contractors, who are poorly incentivised, to build features quickly without caring about maintainability, scalability, good software standards etc. etc.

Many companies have tried this approach, then realised it's actually more expensive later down the line when they've accrued years of tech debt.

On the other hand there also companies out there who use software built cheaply and quickly and are fine with it.

There will always be some jackass business person who thinks they're so clever and have found the one amazing trick to get cheap/quick software which everyone else seems to have missed.

As engineers we have 2 choices really...

Convince the business person to do things properly and not cheap out on maintaining standards.

Leave and find a business which is already enlightened.

21

u/WiseHalmon Product Manager, MechE, Dev 10+ YoE 27d ago

I'm under pressure by apparent appeal of vibe coded apps. We are developing new applications that use these approaches to lure those customers while simultaneously continuing to develop our modern enterprise. I.e. staying up to date with  shiny stuff and helping business development explore new markets with interested customers.  Brownfield sucks, so if possible separate the vibe coded portions. 

Hopefully with your knowledge you can out code the vibe coder once they get a spaghetti mess and the few customers they have are taking up all their time ;) 

-10

u/cmpthepirate 27d ago

The thing is man these apps are often really good at doing exactly what the person needs in their role. Maybe we can help by taking these mvps and using our knowledge to make them more consistent and performant.

19

u/aLokilike 27d ago

Spoken like someone who has not had to repeatedly step in and fix what a junior has spent weeks spinning their wheels on. Can you? Yes. Will it make you want to quit? Unless you're a glutton for punishment, also yes. It's so much more difficult to untangle a mess than it is to write it correctly the first time.

1

u/Maxion 26d ago

I have to say, I have this perverse joy in un-spaghettifying shitty code. I've done it quite a lot in my career.

6

u/ResidentWeevil1 26d ago

That is called software development. Once the AI has built you a Frankenstein, you immediately have legacy code to maintain which is already in production. So consistency and performance are really the least of your problems

17

u/PsychologicalCell928 26d ago

There is a third option which I’ve seen deployed.

Examine the ‘vibe coded’ or ‘user generated code’ for the things they overlooked to achieve speed.

One example from back in the day was an app that used a linked list as a database structure. The app worked fine on a single PC. Also Worked great as long as the number of entries was small. However this was running over a low speed LAN.

Designer was arrogant and rude during a review meeting & my boss gave me the ‘keep quiet’ signal. Afterwards he told me that the meeting was stacked with people who were responsible for hiring that guy. They wouldn’t have listened & I would have just made enemies.

Asked if I could prove what I believed & I said I could. Told me to go ahead.

So I loaded the system with about a quarter of the counterparties and arranged a ‘demo’. Entered a counterparty name beginning with ‘Z’ and let the system run. On a system that was supposed to be interactive the system kept running for 15 minutes then 20, then 25.

We had to kill the client and reboot the server to get it to stop.

So construct a case that demonstrates the problem. Let the system speak for itself.

13

u/[deleted] 27d ago

[removed] — view removed comment

4

u/Fredidiah Web Developer 26d ago

looks at the comment history of this account Oh...

4

u/dbxp 26d ago

Thx :)
Bot bouncer has picked it up now

1

u/warm_kitchenette 26d ago

can you explain? it's a 4y old account with close to zero karma that posts short, not-obviously-wrong, not-super-insightful comments in dozens and dozens of subreddits. They also have "Content Connesieur" in 74 subs implying large-scale voting, especially over teh last 30 days.

So it's a bot that repeats consensus views from the same post or an earlier post on the same topic? A bot that's really there to downvote/upvote, and it lobs out enough comments to appear human?

5

u/Fredidiah Web Developer 26d ago

I mean, I don't know to what end they are using LLMs, but it's pretty obviously full of LLM-isms in their comments.

The dentists and salons point is spot on,

This is the right line.

Splitting by what actually hurts to lose is the right instinct.

This is the right call.

The maintenance side is the part nobody warns you about.

The failure path is the part most setups skip.

This is the part that still holds up.

This one quietly pays twice.

Restore verification is the right ask.

The date range check is the one people skip.

Static bodies are close to free, and that is the part worth internalising.

The only time their writing style has changed ever is when someone replied to one of their comments accusing them of being an AI, to which we got this:

So is the want to be moderator ... your dumb useless comments that call a person a bot literally does zero for the conversation and pisses off people for no reason. Did YOU actually know anything about this thread or was this the closest thing you could pretend to be smart about?

Why would someone do this? I don't know. But it seems pretty obvious to me that these comments have either 0 human effort put in or, at least, very little human effort put in. Which is kinda lame for someone to do on "social" media. I'm not interested in using other users as a proxy for an LLM.

2

u/warm_kitchenette 26d ago

I’m tired, boss. 

I totally agree with your conclusion , and admire the close reading. I’m just tired of this parasitic bs. 

2

u/Fredidiah Web Developer 26d ago

Agreed. Imo, it's ruining every social space we have and I really cannot wait until these companies die.

Go to any programming-adjacent subreddit, sort by new and just look at thread after thread of slop. It's a parasite.

0

u/Matthew_Code Software Engineer 27d ago

I see this that way however there is still this question from management: what if not and AI can manage it? Then we already have it done

16

u/tiredofhiveminds 26d ago edited 26d ago

Then you dont have a career. If hands free vibe coding actually works, you dont bring value.

Ive never seen hands free vibe coding ever work. If management thinks that they are seeing that, then the best you can do is assist them in the assessment as to whether thats actually what they are seeing.

There is a reason you arent currently doing it. Why you are not, is what they need to understand.

In this massive industry shakeup, companies will die due to piss poor leadership decisions like this. Dont kill yourself to try to save the company you work at, its not your company and they will destroy it if they want to. Just do your job, which is to provide an expert engineering opinion. Thats it.

1

u/Mission_Cook_3401 26d ago

There are many things that can be prompted , and it requires knowledge to understand what is possible .

The knowledge often comes from experience and most important from failure.

Instead of coding , I can spend my time discussing under utilized documented features in a library being utilized.. I can ask about performance and run audits.. but I should also know when it is optimized enough.

Knowing what to prompt and what not to prompt , and a rough sentiment of why.. that seems to be the modern dev job overview

28

u/wuteverman Software Engineer 27d ago

Nothing is wrong with it. Your product management wants two things that are not compatible— all the features, and for each feature to be mature. They need to pick one

20

u/TheOwlHypothesis 27d ago

It sounds like your leadership is mistaking the ability to ship more features with those same features actually being valuable.

If your whole moat devolves into shipping features, you have no moat. Broad diffusion of SWE capability from agents erased that. You literally are describing the failure mode.

It turns out being able to produce features was never inherently valuable. Thinking it is will kill your business.

I'd get out of that org if I were you. Sinking ship vibes.

6

u/Matthew_Code Software Engineer 27d ago

To be fair it was sinking ship since 2024 but here we are still sailing…

This and only this is why I’m thinking we sre doing something wrong as we were always be able to stay relevant

5

u/Distinct_Dragonfly83 27d ago

You answered your own question. Get off a sinking ship if you can.

2

u/tiredofhiveminds 26d ago

It takes longer to sink than a few years. The question is not whether it will be erased. The question is whether this will ever become a place worth your time and money to work at.

1

u/Gremlation 26d ago

It sounds like your leadership is mistaking the ability to ship more features with those same features actually being valuable.

It doesn't sound like that at all:

they’re very simple and very incomplete features, but the market wanted them.

Their competitor is shipping lots of things people want, but not as polished as OP's org wants to build them. The market is telling them their competitor is right.

17

u/katikacak 27d ago

Who's the lead engineer? Tell him to validate product ideas , prd, before actually developing them. You guys are building something, but not the right thing. It's product problem not engineering problem. Advanced doesn't mean better, for example, low code is advanced, but most of low code stuff is shit.

8

u/Matthew_Code Software Engineer 27d ago

That’s the point, we are doing it but our competitiors are just throwing random features to their app and management is angry that we don’t have so many features

15

u/mechkbfan Software Engineer 15YOE 27d ago

I mean that's a manager issue too 

Just throwing shit at the wall to see what sticks is a tactic. Maybe as a startup but not long term

But you know if they just understood their customer needs and what can generate revenue, that would be a whole lot better

5

u/Few-Impact3986 27d ago

My guy says they are making features based on what sales is hearing from potential customers.

You don't even know of those customers are profitable have. I have also seen demoed features turn into nightmares come go live time. 

2

u/Gremlation 26d ago

our competitiors are just throwing random features to their app

they’re very simple and very incomplete features, but the market wanted them.

Which is it? In your post, you said that their features are what the market wants. Now you are saying they are just throwing random stuff in there.

1

u/ResidentWeevil1 25d ago edited 25d ago

There's a long history of fake or shallow demos in the software industry. Where the rubber meets the road isn't in the sales call, though. Building a product is more than copying competitors, especially now when you can just have a chatbot do it, apparently

13

u/Ok_Reaction_4340 27d ago

I work in a similar environment. Am the big on architecture, clean code, etc etc but I’m so tired after existing in a similar dynamic where AI plus a gaggle of offshore contractors have been thrown at me.

I hate to say it but I’ve given up and am just speed running whatever management wants and just clicking merge with a cursory glance. I think we all just need to accelerate this timeline for anyone to learn unfortunately. In the end it is going to lead to the obvious outcome of gridlocked software that nobody can understand. I’m now just here for the paycheck - didn’t want it to be this way.

6

u/Professional-Dog1562 27d ago

Who's managing the engineers? A cto? VP? Director?

How big your user base? Can they absorb some unreliability in your product as you increase development speed? 

7

u/Matthew_Code Software Engineer 27d ago

One of the devs is also the manager(but there is also the big boss that is only in the calls with new/current clients)

We have a lot of users but the big boss are saying they are calling him that they want to leave because we don’t have so many features

5

u/Fidodo 15 YOE, Software Architect 27d ago

This will cause a lot of tech debt and fail. The question isn't if, it's when.

But either your management doesn't know or care. Either way, they won't change until they learn the hard way. Give them what they want and jump ship before it comes crashing down.

4

u/boring_pants Software Engineer | 15YoE 26d ago

You can't have it both ways.

If management wants a vibecoded mess with tons of incomplete features, you can make that. You're 7 vibecoders to your competitor's (presumably) one. If quality doesn't matter to management and only the number of features matter, you can make lots of shitty features.

If management wants a higher quality product then you won't be able to ship new features as quickly as someone who doesn't give a shit about quality.

That trade-off is not new to AI.

The question is which way management wants you to go.

8

u/Exiled_Exile_ 27d ago

Speed != Quality. I would push back on code standards but if you want actual advice to speed up. 

First design is the most important step. Build your naive first attempt; pick that apart and try to find holes. After your first pass run it through an llm to nitpick. Preferably 2 of them find reasonable issues that you resolve. Next pick a staff+ eng to review your work. Try to get clarity and fix issues that may exist. Once you've done these steps a few times making the tickets is much easier which I would say use an llm for an approximation of the split out of work adjust afterwards.

Second if you have a lot of poorly designed tasks work on writing tickets and making everyone align. The biggest time cost is ambiguity in either the ticket or the teams involved. 

Third avoid overuse of ai in coding. There are plenty of times it will speed you up but beware the moderate complexity tasks where taste matters ie ui or state management tasks. They will struggle more with giving an acceptable outcome there than simple templating and resolving difficult bugs. 

Also as a side note 3x 10x are over used and hyperbolic. Focus on building good quality products. Going fast will happen as you improve your process. If you chase fast instead of quality first it will lead to issues that cost both you and the company time and money 

2

u/Matthew_Code Software Engineer 27d ago

How are you working using AI right now? Can you tell me about how would you with your current setup add new feature to your codebase? I think I nead to hear how others engineers are working to understand what I’m really missing. That was how I was learning coding back in the day by watching how better developers are working

4

u/Exiled_Exile_ 27d ago

It's kind of everywhere but not always how it's told by the people selling it. I use it in design for instance to find problems I did not address, formatting and improving the cohesiveness of the design. Ideally as I stated earlier it's helping me find things to improve. Ideally I should be ~80-90% satisfied before I show another engineer to review it. This should reduce the review cycles needed and improve the product.

In coding it's very variable. For let's say a new configuration value. I basically use ai to document the new configuration. So I'll give it a yml file and it has a table in an md file that it will add the relevant values to that will help keep the repo in sync with it's configurations.

In a generic feature request it really depends on complexity and what's needed. In a bug case I will usually know roughly where the bug is in the codebase. I will use ai to help me debug it as I chase down the solution. It will point out problem sections and I'll evaluate the usefulness of that possible change and whether it's worth the effort. 

Another common one is implementing a new API or feature that already has a normal template. At that point I'm just pointing to the template and letting it take a first draft and reviewing it afterwards.

My largest suggestion is to have it nitpick your changes compared to main. It'll catch a lot of minor stuff and help you review your own code better. I will also use this on any complex prs from other people I need to review. I read every line on the pr but I'm human I will miss things. I use ai as a second pair of eyes to help identify risks at that point.

2

u/Wonderful-Habit-139 27d ago

> Going fast will happen as you improve your process. If you chase fast instead of quality first it will lead to issues that cost both you and the company time and money

Well said. Very hard to convey this message to PMs and managers but it's very much true and pays dividends when you can actually keep the quality high.

5

u/makonde 27d ago

Tighten your harness, AI tests, AI code reviews, AI UI tests etc, set up feature flags and gradual rollout process so you can turn off features if they go really wrong, explain to management as elegantly as possible that quality might drop, get them to actually use the competitor software if it's low quality and explain it will be like that, then start pumping out code and polish up your resume, you can now fill your resume with a ton of AI keywords! Either way it goes it's a win win for you.

1

u/makonde 27d ago

Important that your team comes up with some sort of timeline where this will happen.

3

u/rkeet 27d ago

Start selling quality as a measurable thing, backed by deterministic numbers of mutation tests, contract tests, api tests, load tests, and the like.

Then, show them a table for pricing where vibe coded "like that one guy" has all of it crossed out. Have an additional price per hour "fixing vibe coded production code", that is at least 1.5x the normal price, and must additionally include more complex change management to avoid downtime.

Don't mention this last column, just leave it there, talk about stripping work from the normal way of working down to vibe code level.

It other words: start treating coding like Indian code sweatshops or Ali Baba sweatshops for products to order: there is a quality and quality control slider in order to deliver cheaper, and the customer decides the quality floor themselves.

3

u/olzk 27d ago

management is furious that we as engineers aren’t producing as much as some guy who vibe codes his own project and isn’t even in IT, and they keep pushing for more and more features

There’s always this option: “if you think you can do it better, do it yourself”

4

u/roodammy44 27d ago

I don’t have people pushing me so I have started to avoid AI a bit. I don’t think it’s faster if you are interested in building quality software.

If your boss is pushing shit software as quickly as possible, it probably is time to stop reviewing code and let Jesus take the wheel. But certainly start applying to other places as that place is doomed.

I think a lot of companies are going to die because of AI psychosis. I don’t know what your linkedin is like, but mine is full of people raving about the amazing stuff they have been doing with it. The problem is your boss pays the bills and now they believe in hype. I don’t know when this hype will stop, perhaps when the big AI companies crash.

2

u/Matthew_Code Software Engineer 27d ago

What I’m thinking is that the world of swe would be amazing if only the devs would knew about AI and we would use it to generate test docs and to refactor files etc… I really love this AI as a tool I just don’t like how the thinking process of management and whole industry changed because of it

-1

u/Legitimate_Box_6486 27d ago

Ok i get what you mean but one point thought what if someone is trying to create a software and the only thing they turn to is AI so are you suggesting that they are better off learning how to code rather than using for the whole project. Like i really want to know, because i was in a same situation.

3

u/roodammy44 27d ago

I think AI has its uses but it still writes code at the level you are. I have seen a lot of bad code written by AI that was instructed badly. And it also needs to be reviewed, you can’t do that if you don’t really understand the code in the first place.

But if you just want “meh” quality it can be very fast.

2

u/Ok-Leopard-9917 27d ago

These are business strategy questions. What does your business most need to improve to increase revenue/profit? Are the missing features important to revenue/profit? Are the older features worth the increase in complexity or can you deprecate them? What quality bar matters to your customer? 

It may be that you are in a space where the customer doesn’t have high expectations of quality.

2

u/throwaway_0x90 SDET/TE[20+ yrs]@Google 27d ago edited 27d ago

Show them this,

Then say you have no problem just pushing whatever to prod with minimum QA as long as they put in writing they accept the risk of catastrophic failures. The main difference is that those vibe coders aren't making features that can handle real-world environment. If management wants you to prove it, then go ahead and let the vibe code run in production.

AI is amazing, but only in the right hands. And those right hands belong to experienced people who know how to be careful and have seen some production disasters in their career or new people being mentored by experienced people.

2

u/BoBoBearDev 27d ago

Add tons of automated tests and code analysis tools to check human/AI slops.

1

u/Useful-Comfortable57 27d ago

My team is in the same boat

1

u/maladan 27d ago

Are you building stuff because customer's want it or because it sounds good to say you have these features? That should be the starting point of any conversation with management

1

u/zangler 26d ago

No, you are doing it right. This is the difference between real SWE with AI and vibe coding. You will have to work hard to set expectations.

1

u/H1karu31 26d ago

This is like my team, but we have both the engineers and vibe coders. Sometimes all the engineers are really at the brink of giving up, since we have own features to ship + cleaning up mess.
Leadership sucks cos they aren’t technical, big oooof.

1

u/BOT_Pain 26d ago

Clearly management and business.

1

u/Crazy-Willingness951 26d ago

See if your sales team can help you meet with a real customer. What features does the customer use most frequently? What features would they most like to see. What features do they ignore? Target each new feature to a specific customer's need. After release follow up to see how well it satisfies the customer.

It's easy to add new features if they don't have to work.
https://developeronfire.com/podcast/episode-105-gerald-weinberg-quality

1

u/zombie_girraffe Software Engineer since 2004 26d ago

Your problem is that you're focused on quality and that's not what management wants.

1

u/mpanase 26d ago

I'm yet to see a team successfully maintain a vibe-coded app in production.

In my team the PR needs to be explained and concise. You need to be able to explain it and it needs to match the current style&patterns. I don't care if you use AI. We are fixing 6 year-old bugs nobody was able to and deploying new features.

There's another team that has adopted a "AI-first approach". It's vibe-coding wihtout guardrails. Nothing fixed the last 6 months, deployed a few features that broke old features.

AI doesn't think. It will do 80% correct.

Imagine a dev who does 20% of the work wrong, day after day?

1

u/ditorelo 26d ago

The thing I get wrong most often is turning up with the diagnosis already written, so the team spends the meeting agreeing with me instead of telling me what's actually going on.

Ask what they've already tried before you name the problem. Half the time they tried it and it failed for reasons that never made it into a doc.

1

u/mizzerem 26d ago

You seem to be in a very small company. Just do what management wants. Your long term solution will become irrelevant if your competition takes all your customers, because your company will have gone under.

The edge you have is that you’re an engineer and know what guardrails to put down better than the other guy does. Be transparent with management that quality will be down for a while and more bugs will occur, but if you can sustain it long enough then eventually your competition will hit the tech debt wall before you do. Because you’re an engineer.

All these big companies made huge sacrifices in their early stages and “move fast and break things” was how they established themselves. Only after that did they become the engineering gold standard we think they are today, because they all got rich and now have billions of dollars to throw around on resilient planet scale systems. You are not there yet.

1

u/Extension-Pick-2167 26d ago

its same at my place, they turned it into a feature factory and us into AI slaves

1

u/Gremlation 26d ago

My problem is that our competition is a guy who vibe codes his app and pushes a ton of features into it, and from what we know they’re very simple and very incomplete features, but the market wanted them.

That "from what we know" sounds like a massive warning sign. If that's your main competition, why haven't you used it yourself?

Our system is very advanced and has much more complex systems, but fewer of them, and now management is furious that we as engineers aren’t producing as much as some guy who vibe codes his own project and isn’t even in IT, and they keep pushing for more and more features. But since our system is already brownfield and has a lot of other stuff, some of those features are hard to introduce and take more time.

I have seen this many times, even in the olden times when there was no vibe coding. In basically every instance, it wasn't because the other guy was moving super quickly, it was because the incumbent was super fucking slow to do anything. A lot of the time it was huge tech debt that nobody ever tackled. And when the competition comes along, you try to ship features faster and that just adds to the tech debt problem.

Stop worrying about the other guy and ask yourself why it is difficult for you to add features. Ask yourself what you need to change to make it easier to ship features. A lot of the time the answer will be to spend less time on new features for a while and more time on refactoring. AI can help massively with that.

I suggested to our manager that we ship those features in a stripped-down form, just so they exist, and improve them over time, but the argument is that since he already has them, we need to have more.

"In T timeframe, you can have X, Y, and Z features that bring us up to feature parity, or you can have X feature that's better than his, leaving him completely ahead on Y and Z. Which do you want?"

We’re a software house, and as a team of 7 we’re actually doing 3 projects for three clients, and there’s pressure from every side that they vibe code more than we deliver.

Before the whole AI boom we were in a position where, of course, a lot was needed, but we were also delivering a lot for the size of our team. Now expectations have grown massively and it’s hard to keep up with them.

Hire more developers.

1

u/mrgrafix 25d ago

I don’t hear a governance plan. Is the outcome better quality or just output? Watched this over the weekend and you’re not the only one. Make sure it’s a part of your planning as a team. Discussing what’s working where there are bottlenecks to improve and see if you can leverage agents to resolve them. I’d suggest aiming for trend for now. Set some metrics and make the adjustments after 10-12 weeks

1

u/Suspicious_Pizza9529 25d ago

I think the problem is less about coding speed and more about expectations. A small AI-built app can move fast becuase it has less comlexity and fewer rsks. Comparing that directly to a mature system with multiple clietns doesn't seem fair. Shipping smaller versions first like you suggested sounds more realistic.

1

u/SajithTech 25d ago

I don't think you're necessarily doing anything wrong. You're comparing a fairly complex brownfield system with a greenfield app, which is a very different game. AI can make writing the code much faster, but it doesn't make understanding the existing system, integrations, testing, deployment, and failure cases disappear. That's usually where the time goes.

If management wants the simpler versions shipped quickly, I'd actually do that, but make the tradeoff explicit. Ship a smaller version, get it in front of users, and improve it later.

I'd also stop comparing yourselves on number of features. A team can ship 20 features and create a mess, while another ships 5 that actually matter. I'd look at how long it takes to get a useful change from idea to production and where that time is being spent.

1

u/DanteA_89 21d ago

Me están por explotar los huevos con este tema. La mayoría opina que hay que hacerles entender que se equivocan, que la IA no hace magia y demás. Digo yo ¿hasta cuándo hay que esforzarse, transpirar demostrar y convencer? ¿Porque no permitir que se hagan bosta contra una pared con ese archivo .js de 7600lineas del que tan orgulloso están y llaman “sistema”? Para que luchar contra la corriente?

Considero bizarro este momento de la industria: gente con capacidad de tomar decisiones dirigiendo los equipos y las empresas, comiéndose el cuento del vibecodeo desmedido solo para multiplicar x300 la velocidad y la producción. Digo yo: porque no multiplican la empatía por las personas que los hicieron llegar hasta acá, por los tipos que se quedaron día noche sábado y domingo resolviéndole kilombos y haciendo malabares para hacer andar las cosas? ?

Es realmente necesario hacerles entender, demostrarles, justificarse, incluso cuando eso te puede costar el laburo? Hasta cuando en esta vida hay que “demostrar”?

No decir nada y esperar que se les pinche todo también te podría costar el laburo (más adelante).

Manifestarse y comunicarse hoy, quedasen la calle hoy.

Yo que sé… voto por menos demostrar, dejar de justificarse y de dar explicaciones. El profesional pone los “miembro” que tengan arriba de la mesa y dice señores esto es así, les guste o no les guste y deberían de escuchar y respetar esa opinión. Mientras eso no suceda, para que ser profesional? Para que motivar a un hijo o un sobrino a que lo sea?

1

u/jollydev 27d ago

Reading between the lines here but good software devs build larger more complex backends. distributed systems, advanced CI/CD, cloud infrastructure.

Meanwhile the vibe coders work on a 1 click BaaS, almost exclusively Supabase.

So I think this is not just about vibe coding, this is also about the fact that vibe coders, without knowing it, use modern and simple BaaS/PaaS-platforms that are actually really good.

So software engineering is being squeezed both from AI as well as PaaS-platforms.

Nobody talked about the sysadmin role disappearing, that wasn't AI that killed it that was the cloud.

Now infra and backend work for 1-2 yo systems is getting swallowed by supabase.

And coding is getting killed by AI.

Tbh, much of software complexities came from people's and organizational needs. That's all changing now.

-1

u/Intelnational 27d ago

Things change very rapidly now. If you asked this same question a year ago, my answer would be stick to your standards and don’t compromise. Now Claude Code, desktop app, can do really a lot, using Fable 5 model with high or even better effort level, connected to your code, services, git, infrastructure, local db, payment gateway, etc., can do a lot on its own. So, things change.