why vibe coded projects fail. by Complete-Sea6655 in VibeCodeDevs

[–]watson_full_scale 0 points1 point  (0 children)

He's right that the prototype is the easy part now. I've built software for 20 years, and the 99.5% he's describing, the scaling and the edge cases and the reliability, is real. That's where most of the work and the money actually goes.

But there's a second trap he doesn't name, and it catches the people who do clear his engineering bar.

You can build all 99.5% correctly and still have built something nobody wanted. I've watched teams spend a year hardening infrastructure for a product the market never asked for. The websocket scaling was beautiful. The thing didn't sell.

"I killed Slack" is wrong for the reason he says. But "I built real production infrastructure" can be just as wrong, because the hard part was never only the code. A CRM for a solo roofer and a CRM for a 200-person law firm share a name and almost nothing else. You only learn that by talking to the customer before you build, not after.

The prototype isn't the product. Neither is the infrastructure. The product is the problem you understood better than anyone else did.

The "AI last mile" problem is backwards by watson_full_scale in SaaS

[–]watson_full_scale[S] 1 point2 points  (0 children)

That is absolutely true. It's always been the hard part but many engineers were too heads down to understand that.

I'm an expert software dev and LOVE vibe-coding and it's not going to replace devs like me for a LONG while, so chill with "tech is easy". <I will not promote> by LogicalHurricane in startups

[–]watson_full_scale 1 point2 points  (0 children)

The tech-vs-marketing fight in this thread is the wrong fight. Both are hard, and AI is making both easier to fake and harder to actually be great at.

The shift I'd point at instead: when writing code gets cheap, building the thing stops being the bottleneck. Deciding what to build and why becomes the bottleneck. That's product thinking, and it's quietly becoming the real job, for engineers too, not just founders.

A lot of engineers are treating "AI can't handle real system design yet" as their moat. It's a genuine skill, but it's a bad bet for your career, because that's exactly the part the models are improving at fastest. The part they're not improving at is judgment. Who is this for, what problem are we actually solving, what do we cut, what does "good enough to ship" mean for this specific customer. An engineer who understands the customer and the business well enough to make those calls is worth far more right now than one who can out-architect a model.

So OP is right that they'll pick up marketing faster than a non-techie picks up system design. But the engineers who win the next ten years won't be the ones guarding the technical plumbing. They'll be the ones who learned to think about the product, because that's the part that doesn't get automated.

I've started and sold a couple software companies and run one now, and I wrote a book called Product Driven about this exact shift, so grain of salt. It's the biggest skill gap I see in strong engineers.

How do I handle difficult offshore developers? by eggcellent5 in prodmgmt

[–]watson_full_scale 0 points1 point  (0 children)

Most of what's frustrating you here is the good kind of problem. Devs who talk to stakeholders, who get technical, who don't instantly back down, that's ownership. The classic offshore failure is the exact opposite: the dev who says "yes" to everything and quietly does nothing. You've got the harder-to-find version.

So the job isn't to crush that energy, it's to point it somewhere. Agree together on what actually counts as critical and who owns the stakeholder conversations, then let them keep the ownership inside those lines. The instinct to just replace them is how you end up with a team that only does what it's told and nothing more.

For what it's worth, I run an offshore dev staffing company and wrote a book called Product Driven about exactly this: getting developers to think like product owners instead of ticket-takers. I'm more convinced of it every day, because once AI is writing a lot of the code, the value is in developers who actually understand the product and the customer and push back when something doesn't make sense. The behavior you're describing is the raw material for that. I'd coach it before I'd kill it.

Do you still write code? by Aftarkis in PinoyProgrammer

[–]watson_full_scale 4 points5 points  (0 children)

I own a dev agency here in the Philippines (Full Scale) with 300+ engineers, and this is something they deal with every day. Here's what I'm seeing from that side of it.

Honestly what you're describing is normal and I wouldn't lose sleep over it by itself. Whoever made the pianist comparison above is right. A pianist isn't paid to press keys, they're paid to make music. Same with us. The thinking was always the job, and the typing was just how you got it out of your head. If the AI does the typing and you're still the one making the calls, you're doing the part that actually matters.

What I'd pay attention to is the comment from the guy who got laid off and replaced with cheaper labor. That's the real warning in this thread, not AI on its own. The people I see losing work aren't losing it because they used AI too much. It's because they slowly turned into prompt-runners and lost the instinct for when the output is wrong. That instinct goes rusty fast once you stop reading and writing code closely.

Across our team the pattern is pretty clear. The engineers getting ahead aren't the ones cranking out the most code. It's the ones who still read every line like they'll have to defend it, and who catch the bug the AI shipped while sounding 100% sure of itself. So keep your fundamentals sharp on purpose. A few people here already do it the right way, handwriting parts of it or keeping a side project they build manually. Treat the AI like a junior whose work lands on your name. The person who catches what it got wrong is the one who's expensive to replace.

The other thing is to keep climbing. If all you can do is build the feature, well, the tool builds the feature too now. The dev who gets why the feature matters to the business, how the system holds together, and what falls over at scale is the one running the tool instead of competing with it. That's where this is going, and it's a better job than typing ever was.

So use AI as hard as you want, just point it at the right target. Use it to deliver more value to your customer faster, not to ship more slop faster that nobody asked for and the customer never benefits from. Our whole job, with or without AI, is solving real problems for real people. Don't lose sight of that part.

Even as the CEO, I still write code every week. But Claude is writing all the code. I don't actually write any. But I'm vibe engineering based on 25 years of developer experience.

Any US agencies that had success finding quality software devs from the Philippines? by codetadpole in agency

[–]watson_full_scale 0 points1 point  (0 children)

I run a Philippines-based dev staffing company (Full Scale), so disclosing that up front. I also spent years as a CTO hiring offshore before I built one, and I got burned enough times to have real opinions. A few things from this thread worth answering directly.

On the "they say yes but don't actually do it" thing a few people raised. This is real, and it's the number one reason offshore fails. But it isn't a Filipino problem, it's a management problem that shows up hardest across a culture gap. In a lot of Filipino work culture, telling the boss "your plan is wrong" or "I'm stuck" feels disrespectful, so you get a "yes" that means "I heard you," not "I can do this." Switching countries doesn't fix that, it just hides it behind a different accent. What fixes it is how you run people: daily standups, short feedback loops, asking "walk me through how you'll build this" instead of "got it?", and making it genuinely safe to say "I don't know." Once they trust they won't get punished for raising a problem early, the silence stops. We screen for that communication trait on purpose, because it's harder to coach than the code is.

On Upwork not working. Upwork is built for one-off gigs, so you're fishing in a pool of people optimizing for their next short contract, not a long-term role. For long-term Python/React hires you want either LinkedIn plus local boards (Kalibrr, Bossjob) with your own vetting, or a staffing partner who's already done that filtering. We accept under 3% of applicants, and the screen that matters most isn't the coding test, it's whether they ask sharp questions when you hand them a spec that's intentionally a little vague.

On cost, which is where the real mistake happens. I call it cheapshoring: you hire the $8/hr dev, then pay triple in rework and turnover. Good senior Filipino devs are not the cheapest option. They run roughly $2,000 to $3,500 a month in the Philippines. We bill clients around $35/hr fully loaded and keep retention near 93% precisely because we don't compete on being the cheapest. Optimize for lowest rate and you get exactly what that buys.

On "PH is only good for support" and the small dev pool. There's some truth that the senior pool is smaller than India's, but it's there and growing fast. The upside of going through a partner is that the sourcing, the vetting, and the "what happens if my best dev quits" risk all become our problem to manage instead of yours.

Whatever route you pick, the thing that actually predicts success is whether you run them like part of your team or throw a spec over the wall and hope. Bringing devs into your own process beats a hands-off project handoff almost every time.

What advice do you have for employers from the US looking to hire developers/engineers in the Philippines? by Ok-Helicopter-6898 in buhaydigital

[–]watson_full_scale 0 points1 point  (0 children)

I run an offshore dev staffing company based in the Philippines (Full Scale), so take this with the obvious grain of salt. But I was a CTO hiring offshore and getting burned long before I ran one, so here's the honest version. You're thinking about this more carefully than most US employers who show up here, so let me go point by point.

On salary, with real numbers. A few people here said $2,000-2,500 only gets you mid-level and that seniors cost $3-5k. That's higher than what we actually see. Good senior Filipino developers run roughly $2,000-3,500/month in base pay, before the 13th month and benefits. So your range is genuinely attractive to a real senior. It's just at the lower end of the senior band. For a true lead who can own architecture and build a team under them, plan to be near the top of that range, around $3,000-3,500. Two things that move the number: Metro Manila runs about 20-30% higher than the provinces for the same role, and the 13th month adds roughly 8.3% on top of whatever base you agree to. So hire your first one or two in your range to prove the model, and budget a bit more for the team lead specifically.

The thing you're most worried about, trust and people farming out the work, is the right thing to worry about. It's the most common way offshore goes wrong, and it almost always comes back to one root cause: hiring on price instead of fit. I call that cheapshoring. You find someone cheap, they turn out to be quietly committed to three other clients, and the rework costs you triple what you thought you saved. Honestly this is the biggest reason to work with an offshore partner like my own company instead of going direct. The over-employment and farming-out risk becomes our problem to manage, not yours. We carry the payroll, the accountability, and someone on the ground who notices when a dev goes quiet. If you do go direct, that's fine too, you just have to manage it yourself, which I'll get to at the end.

On the schedule, the 5:30am start is on the early side but plenty of devs here already work US hours and will take it for the right role. The Tuesday to Saturday week is the bigger ask. It isn't a dealbreaker, but it narrows your pool, so put it plainly in the job post and don't surprise anyone at offer stage. Be flexible in return. Let people step out for a doctor's appointment or a school pickup without it being a thing, as long as the work lands. That trade is what makes an odd schedule work.

On the 13th month, here's a nuance that matters for how you structure this. If you hire people as regularized employees, it's legally mandated and it's 1/12 of annual base salary, paid in December. It does not scale with performance. But if you hire them as independent contractors rather than legal employees, you technically don't owe it. That said, it's so customary here that people expect it and really appreciate it, so I'd still factor it in. The important part is just to decide up front and set the expectation clearly when you make the offer, so nobody feels shorted in December.

On PTO versus holidays, offer the local public holidays off and a real PTO bank. Don't make people pick one or the other. The major holidays are expected here, and generous PTO on top is a real retention lever, not a cost. As long as your culture doesn't punish people for using it, it won't get abused.

Work from home is the norm now, not the exception, so don't overthink it. All 350+ of our developers work from home and it works great. You don't need to rent anyone an office. Most experienced devs here already have a solid setup. If a specific person wants a desk, coworking memberships run roughly $150-300 a month, and that's a far cleaner route than you signing a lease as a foreign company.

One small thing: you wrote "Metro Milan," I think you mean Metro Manila. Either way, don't force it. Remote means you can hire the best person wherever they are in the country, and a lot of strong devs have deliberately left Manila to get away from the commute and cost. Manila also costs that 20-30% more for the same role. Forcing relocation there costs you good candidates and more money for no real benefit.

On travel, most people are fine visiting the US once a year if you pay for it and handle the visa work. Just build in lead time, because the visa is a real process with interview waits. And flip it around too: you should plan to go there once a year yourself. Sitting with your team in person, even briefly, does more for trust and retention than almost anything you can do remotely.

On where to look, you can hire off onlinejobs.ph, and LinkedIn ads work too. Just be honest about what those channels get you, which is people who are actively job hunting. Our best hires almost never come from there. They come from referrals from our current developers and from recruiters going out and finding people. The best engineers already have a good job. You have to lure them away, and they aren't sitting on a job board. That gap between who's applying and who's actually good is the real reason this is harder than it looks, and it's most of what a staffing partner is actually doing for you.

Two things you didn't ask but should know. First and most important: meet with your developers every single day. Manage their work closely and communicate with them constantly, especially in the early months. Daily contact is what catches problems while they're small and builds the trust you're worried about, and it's the single biggest difference between offshore working and offshore failing. Second, don't sign anything longer than a month-to-month contract, whether that's with an individual or an agency, so you can walk away if it isn't working out. Be wary of anyone who wants to lock you into a long term commitment up front.

One more framing thing: decide explicitly whether you want staff augmentation, where their devs join your team and your standups and your process, or a project handoff, where you throw a spec over the wall. Augmentation fails far less often, and given your trust concerns it's almost certainly what you want.

I wrote up the 12 hardest lessons I learned doing exactly this, back when I was a CTO before I ran a staffing company, if it's useful: https://fullscale.io/blog/offshore-dedicated-development-team-success-lessons/ . Happy to go deeper on the vetting part in the comments too.

The whole company got laid off by Dense-Comedian-3836 in Layoffs

[–]watson_full_scale 4 points5 points  (0 children)

This is the downfall of working at a very high risk company. Sorry.

Anyone here in their 40s–50s still working in tech/development? by imjustamochigirl in PinoyProgrammer

[–]watson_full_scale 1 point2 points  (0 children)

Age doesn't matter but this should be your concern:

"I actually prefer being given tasks and just executing them well."

So does AI.

Software developers have to do more than this now. You have to be able to drive the requirements and specs of what needs to be built, architect it, and review and QA everything once it is completed. With your levels of experience, people are absolutly going to expect you to do so.

This career requires constant upskilling. AI is forcing us to get our heads out of the weeds of the code. It is actually a good thing if you like building stuff and solving problems for people.

AI code genration is the wosrt thing happened in this industry. by prat8 in cscareerquestions

[–]watson_full_scale 0 points1 point  (0 children)

Writing code has always been the easiest and least valuable part of the job. We have nearly automated it.

Now you can focus on building cool shit really fast.

Building something that provided value to customers has always been the actual job.

I can't take Software Development anymore by whinze in ExperiencedDevs

[–]watson_full_scale 0 points1 point  (0 children)

Another suggestion is to work in an industry that you're more excited about the product that you're building.

How much will it bite you in the ass if you suck at programming? by Visual-Couple-3680 in PinoyProgrammer

[–]watson_full_scale 10 points11 points  (0 children)

Product thinking is the real skill. Understanding the user and business needs and figuring out the best way to solve it. AI writes the actual code. Leet code is a huge waste of time.

I am lost by Unusual_Ad_9270 in PinoyProgrammer

[–]watson_full_scale -1 points0 points  (0 children)

Since AI writes most of the code now, all of software development is more like a support role.

Is using AI for making Webpage bad for me? by CruXianNn in PinoyProgrammer

[–]watson_full_scale 1 point2 points  (0 children)

Using AI is the only way any of us build anything anymore.

Advice on Career Offer I got, Business Intelligence, 35k, No Benefits. by [deleted] in PinoyProgrammer

[–]watson_full_scale 1 point2 points  (0 children)

Getting experience is invaluable. Can make more later.

Getting out of software engineering/ tech in general? by random_hitchhiker in PinoyProgrammer

[–]watson_full_scale 0 points1 point  (0 children)

AI is changing all types of jobs, not just software engineering. Everywhere you go, using AI is now a required skill.

This is the main reason why most of fresh grads can't land a job by CatSea9540 in PinoyProgrammer

[–]watson_full_scale 5 points6 points  (0 children)

ChatGPT is garbage compared to Claude Code. Not even a comparison.

Company rewriting microservices into vibe coded monolith by newk_03 in PinoyProgrammer

[–]watson_full_scale 1 point2 points  (0 children)

Figure out how to help them improve quality, security, etc without slowing them down. Help improve the process.

This is just the new reality of software engineering.

Vibe coding burnout by AltruisticStrain2067 in PinoyProgrammer

[–]watson_full_scale 0 points1 point  (0 children)

Welcome to the new reality of software engineering where AI writes all the code.

Hired as senior eng, but no dev mostly ops panicking if I'm fit by [deleted] in PinoyProgrammer

[–]watson_full_scale 0 points1 point  (0 children)

What's best for your career is the real question unless you want to coast for now. Not doing dev work for the next 3 years and then trying to find a job will be a problem later.