Stream: interviews

Topic: 632: Reaching industrial economies of scale

Logbot (Mar 13 2025 at 01:35):

Beyang Liu, the CTO & Co-founder of Sourcegraph is back on the pod. Adam and Bryant go deep on the idea of "industrializing software development" using AI agents, using AI in general, using code generation. So much is happening in and around AI and Sourcegraph continues to innovate again and again. From their editor assistant called Cody, to Code Search, to AI agents, to Batch Changes, they're really helping software teams to industrialize the process, the inner and the outer loop, of being a software developer on high performance teams with large codebases. :link: https://changelog.fm/632

Chris Duzan (Mar 15 2025 at 18:53):

@Adam Stacoviak I'm not sure I share your enthusiasm over the idea of "industrializing software development."

I love the idea of the end goal of taking away the "tedious" tasks of software (I think most developers would agree). But, I think I'm hung up on the term "industrialize". So I would like to get your interpretation.

Chris Duzan (Mar 15 2025 at 18:54):

The picture that comes to my mind is an assembly line. So, maybe it's just a bad analogy, but it seems like this idea of factory work (eg. 1 human produces X products per hour) is something we (as software developers) have been trying to escape. One example is that for the longest time the software industry has tried to measure developer productivity by lines of code committed (or number of commits, or number of PRs, etc). But we know that this doesn't directly correlate to value.

Maybe I need to shift my mental model away from classic factories. And maybe this "industrialization" of software will look like something completely different. But "industrialization" seems to butt heads with the creative problem solving that software developers do today.

Ron Waldon-Howe (Mar 15 2025 at 23:14):

@Chris Duzan https://www.smbc-comics.com/comic/sad-2

Adam Stacoviak (Mar 16 2025 at 02:03):

I’m attracted to the “economies of scale” aspect. We’re already automating, just not that efficiently. That last 125 years of humanity has been iterating on more efficient automation.

Chris Duzan (Mar 16 2025 at 14:01):

Yeah, no argument from me there. I see 2 potential routes for better scaling of teams.

1. Faster, better understanding of the entire system (I assume this is where AI comes in) so developers can make informed decisions sooner and not be bottlenecked trying to understand everything all at once.
2. Reduce the scope per developer so they don't need to know much outside of their one responsibility. That way you can drop in, for example, a "REST API developer" at any company and they can almost immediately understand their small scope and start providing value for the team.

Ideally companies like Sourcegraph are moving us toward number 1. While number 2 feels like the "assembly line" version of things. But who knows, that revolutionized the auto industry, maybe something like that is what we need.

Adam Stacoviak (Mar 16 2025 at 16:52):

I think both points are being solved by Sourcegraph. Understanding systems and large codebases has been their core thesis since inception. And you can draw a line from “reduce the scope per dev” to “innovate within constraints” like we talked about on the show.

James McNally (Mar 16 2025 at 19:57):

What they have sounds really cool but I've also slightly wary of that message. Comparing software to manufacturing has always felt wrong to me.

If you are building a car you design it then build 1000's in an automated fashion because the build process is repetative. Software however is much more like the design than the manufacturing. It is just hard to see since mostly the "manufacturing" of software is build and send bits over a wire.

That said I do think AI is well placed to automate several elements in a productive way, mostly as an evolution of where existing tools get stuck because we can't set defined rules or evolve those rules over time. Will be fun to see what they come out with!

Adam Stacoviak (Mar 16 2025 at 19:59):

@James McNally have you listened yet? Beyang addresses this feeling as well.

Sukhdeep Brar (Mar 18 2025 at 23:46):

The industrialization, or economies of scale, analogy is about enabling more people to contribute to the goal. The car example shows that industrialization meant more people can contribute to making a car a reality. I agree with James's point that in software, by design, we're not stamping out the same thing again and again, and I think that's where comparing to assembly lines falls apart in this analogy. However, the idea of industrialization still holds, in my eyes. Do I want a team is seamstresses knitting the sleeves on my shirt, or can that toil be replaced. Do I need a expert in welding bicycle frames or do my systems allow for any welder to become a frame expert.
My interpretation of the goal was how do we make software easier for more people to contribute to. As the contributors scale up, what efficiencies can we put in place that would benefit from that scale.

Sukhdeep Brar (Mar 19 2025 at 00:58):

Thinking about it more: "democratisation" might be a better term. It covers the "more people can contribute" better, but leaves out the economies of scale.

Last updated: Apr 04 2025 at 01:15 UTC