[jyounker]

The problem with outsourcing, as opposed to remote developers, is that it takes a really good manager and tech lead to make it work.

My experience is that you have to write extremely detailed design documents and work specifications in order to get effective results. These generally have to be as detailed as most effective prompts.

Once you've written specs that detailed, why do you need outsourced developers and frontier models?

[munk-a]

It's funny - the problem with outsourcing is the same problem as AI and it's all a huge callback to the early 2000s. Companies are astonished by just how much money can be saved without realizing the damage to their product. Some will have extremely fastidious oversight from strong product/project leads that will become the new generation of developers and some will buy the pitch and just fail when their software becomes unmaintainable.

In ten years my prediction is that we have just as many developers as now building more products than they build now and AI is used for automation in isolated areas where it makes sense but most software development just happens at a higher level of abstraction where less text garbage is required to express the same concepts and the meat of code becomes even more focused on specifically encoding and highlighting the intricacies of the strange edge cases.

I started my journey in software development working on a MUD that had been passed down through a dozen hands and was extremely dirty software. I can't see anyone wanting to try and pick through the ball of mud and spaghetti that'd result of letting AI build software without severe oversight and corrections.

The core of software development has always been problem solving (or, more accurately, problem identification). As time has gone on we've gotten rid of more and more of the cruft to focus on that point. I suspect that trend line will continue and we'll evolve towards even leaner and more abstract languages to state problems and try and isolate the fiddly logical flow components, driver bits and math more and more into libraries and tools because for most daily work it is important but can be assumed to have been done by someone else better.

[dogcomplex]

I think this is a very reasonable middle-of-the-road AI take and our likely future. Just with the caveat that there's still a major threshold being hit here where we jump up to a new casual capabilities class where it becomes silly not to use AI for the majority of work, but there are still some high-intricacy problems which become much more load bearing than they ever were before and our new abstraction level doubles down on those.

I would like to submit that the high-intricacy work congregates in Protocols themselves, and we start seeing the cycles of development and all the ways to direct AIs, programs, inter-person/inter-company interactions, etc etc all as types of protocol design - and studying those rules of interaction themselves becomes the new job of a programmer (systems architecture). What used to be hard rules and deterministic programs becomes soft self-governing tendencies and probabilistic behavior that can nonetheless be managed and bounded with the right system, but it's new and weird and more akin to management or herding cats than architecture. This is still very different from what most of us were working on before AI, but it's still familiar - especially to those who worked on internet protocols, or defensive UX design around users, physical engineering systems, or team management. Less programming languages, more - control theory, flows and throttles, quality control, design theory, etc. And clearly the field is still wide open as everyone seems to be experimenting with their own take on the AI orchestrator.

[tomp]

The entire business model of "outsourced" developers / shops is to overbill people - "we have 4 engineers working on your project" (and also on 5 other projects).

Even if the engineers themselves are cooperative, their managers / business owners will resist close cooperation and enforce work at arm's length (e.g. 1x weekly calls).

Ask me how I know. I once spent £300k (fortunately not my money) on an outsourced team of developers, and they delivered nothing at the end. Most of the time it was simply about aligning the work! We (me and my partner, we together had some idea of what we actually wanted) tried repeatedly to make sync-s more frequent, to better align the efforts, but their managers kept resisting. It's the "consulting" business model!

For remote jobs, the incentives are reversed. You're literally a full-time employee, there's no management layers to impede communication, and (unless you're lazy or a fraud) you probably want to work on interesting problems and not be bored!

[Tade0]

> "we have 4 engineers working on your project" (and also on 5 other projects).

Largest such scam[0] I've heard of was "we have 11 senior engineers working on this project" (actually three, two of whom were actually junior-to-mid-level).

[0] Let's call a spade a spade.

[tintor]

"we have 4 engineers working on your project" (and also on 5 other projects)

Does it matter how many engineers work on supplier's side?

Supplier is tasked to deliver the project. It is up to them to figure out how many people would they need, and to manage them.

[svachalek]

Depends how billing works, but it's pretty rare to see terms that say we'll deliver exactly what you asked for, on a fixed price and fixed timeline, and take all the liability for failure. To some degree or another you are paying for time and effort, which are easy to misrepresent.

[jpalawaga]

if your supplier promises you an iPhone 17 Pro, and then delivers you a Pixel 4a because 'thats all you need', you will be understandably miffed.

[_puk]

Exactly where my head is at.

Not only do you need to spec everything to the right level of detail (at which point an LLM can likely make a good go of it), but a lot of the outsourced teams don't build in anywhere near the same way as those internally, and the difference in the level and speed of delivery is absolute.

Not to mention with everything changing so quickly, why would I be spending time and money training up someone else's staff to be keeping up with the cutting edge?

[janpeuker]

Outsourcing usually gives you exactly what you pay for, arguably more transparently than other ways. It’s just that transparency (i.e. the price for quality) is sometimes not passed on from management / procurement taking that decision down to the team eventually having to work in a distributed fashion.

I think that’s also where the assumptions of the original post are off - the difference between DeepSeek and a frontier model is not usually what low quality outsourcing can cover. So you probably end up paying a highly qualified outsourced engineer who may not be significantly cheaper (most outsourcing is not just due to cost but capacity and capability).

[zdragnar]

Having worked at a place with few or no design documents, few or no specifications and a team that was at least half outsourced or more, I can say that was not an effective place to work.

[fridder]

My problem has been just a lack of ownership. Unless it is a small focused outsourcing firm it is easier for the companies to just ship it, regardless of quality or maintainability. I have admittedly a small personal sample set though

[SoftTalker]

> you have to write extremely detailed design documents

Luckily LLMs can do that too.