Deep Blue
36 points by carlana
36 points by carlana
All of the chess players and the Go players went through this a decade ago and they have come out stronger.
Professional Chess and Go players are coaches and performers, not wage-laborers. Deep blue is a thing because we're afraid AI threatens our economic opportunities.
There have been many technology revolutions but somehow we never ran out of wage-labor. Sometimes people need to switch careers and of course that is painful.
So the question is: Is it different this time?
There is certainly a good argument that the invention of AGI will be a different one but I don't think we are at AGI yet. Today's "Deep Blue" might more like the switch from assembly programming to high-level languages (like C).
We have never run out of jobs to do in general, but many people have run out of a specific job that they can do. This is an important distinction. You mention switching careers and retraining, but this is rarely easy, usually involves a significant reduction in pay (as one needs to start largely from the beginning again), and may not even be possible for people later in their careers.
Jobs are not fungible, which means that any technology that potentially affects someone's ability to do the job that they are currently doing threatens that person's economic opportunities. Being afraid of that is completely understandable.
(To what extent AI will actually affect developers and their careers seems to very much be an open question — to what extent agentic coding will become the norm, to what extent current developers will find it easy to adopt LLMs as a development tool, to what extent people's knowledge and experience will remain relevant, etc. But given the uncertainty involved, I hope you can see why many individuals would be very worried about their future economic opportunities.)
Software engineering is prestigious, pays well, isn't physically demanding, and has low barriers to entry. When we all switch careers, will we end up with anything nearly as good?
There is always something getting automated or completely changed, rendering some skills irrelevant. However, my assumption is that in the past the change was slower? It was pretty normal to work at one place forever. Maybe current anxiety stems from the fact that nowadays nobody really trains employees properly?
We also don't really need AGI, all it takes is to change how we approach professional programming to reduce the demand and that can cause big troubles for the unlucky ones who will be laid off.
There is also a possibility that indeed, it will create more opportunities.
Meaning coders are not coaches (senior+) and performers (daily standup) ?
No, they're wage laborers. That's a very silly interpretation, but I suppose we are on a tech forum.
The idea that senior engineers are coaches only halfway[0] made sense for a time in the 2010-2022 period where we saw rapid exponential growth in the number of engineers, and there weren't enough seniors.
But once growth slows or stalls, either most engineers won't make senior, or senior engineers will not primarily be coaches (because there aren't enough juniors for them to coach). The first option is a perfectly reasonable interpretation of what "senior" means, but it's not the one the industry has settled on.
[0] I don't think it ever really made sense, it was just a flattering idea. But at least back then it was less obviously untrue.
I think you're largely right, but I think this take is slightly more reductive than it should be. It doesn't have to be all of one or the other.
I'm confident I could do product management work if given a chance, but I don't really want to. There are also some other downsides (more manager's schedule), but even if you take away the economic angle, I'm more interested in the work I've done in the last decade than most of the non-programming alternatives.
Should we coin Spark Orange in contrast? The joy of getting things done, of shipping things, of the end to your bucket list of ideas to try but never have the time to try.
I’m not sure "Deep Blue" is the best choice here. For most people in tech, that name is permanently associated with IBM's chess computer, and it's a pretty iconic reference point. Reusing it for a psychological state feels like it's just going to create confusion, more so in discussions about AI because IBM's chess win was AI too back in their days. So this term is ripe for confusion.
When someone says "Deep Blue," I think about the chess computer, not AI-induced career angst. It might be cleaner to coin a fresh term that stands on its own instead of borrowing one that already has so much history attached to it and create confusion around it.
The connection to that iconic 1997 man-vs-machine moment is exactly why I like the term so much.
Oh! That actually makes it even more surprising to me 'coz that connection is exactly why I dislike muddying such a well-established term. 😄 But to each their own.
I think it's clear enough in context - "sounds like you've got a case of Deep Blue" in a conversation about feeling worried about the impact of AI on a career.
Something I've learned about coining terms is that nobody will ever look up a term they've just heard for the first time - they'll guess what it means and assume that's the definition. I think "Deep Blue" is going to work well for that.
Grammatically Deep Blues would be more natural. We don't say someone has a case of the blue, they have a case of the blues. It would keep it slightly distinct from the proper noun Deep Blue while keeping the origin connection.
We tend look for 'surface similarities' between various types of jobs, and conclude that result pan out the same.
My take on this [1] is that Software Development will get split into at least 2 jobs:
Similar to hardware engineering, where some produce chip designs, and some 'productize' them into end-user devices.
Current software engineering, just like most other professions before it (eg Surgery) will be split into more specialized areas with specific training (on the job or in school), specific certifications for specialties, etc.
So yes, the time of 'polymath' software engineers doing design plus productization is probably coming to an end. But the human-lead engineering/scientific decision making will continue to flourish.
There will be some cross-discipline disciplines, similar to how it is in medical field wrt diagnostics methods. In our world, this will be security, performance analysis -- areas that require cross-section knowledge of hardware, OS, software, compilers and theoretical systems.
[1] https://lobste.rs/s/kfo7mc/building_breakwater_with_ai#c_89ssb6
I expect realignment- we already have specialisms. That first discipline on your list sounds a lot like a combination of product management and qa. Tbh I’m p sure product management exists because upper management is more comfortable dealing with bullshitters than craftspeople.
first discipline on your list sounds a lot like a combination of product management and qa
I was not thinking about those when mentioning 'system design'. I was thinking more of TLA+ specifications, constraints expressed for SAT, state management leveraging type systems formalizing undesired states. Protocol definitions for interfaces, etc.
I do not think product management does those.
I’m very interested in trying out all those things for software construction with agents. However, it’s not obvious to me that these go that far to address the actual problems with telling agents to make software for us.
What agents need is basically a loss function that describes how what they have made is different from what is desired. It’s not clear to me (basically a non user of these technologies) that they make it faster to describe enough interesting properties of programs that it’s worth doing before doing the other testing that they can’t express.
I do not think current AI-assisted coding tools address what I am envisaging will happen to our industry.
I am saying that today experienced software engineers act as system designers as well as engineers that do productization of the system.
To me, these are separate activities, and we will follow the path that has been established in hardware engineers.
Expressing stateful business rules, functional constraints, functionality of the system -- will be done by system designers, I am claiming. These tasks today do not have (at least for the wider software engineering community) tools, standards and processes that express that 'design'. So AI-assisted coding today cannot help that, but I hope this type of system design will get CAD-like and AI-assisted tooling as well.
The productization part, in my mind, includes UI coding,, standard error logging, coding/interfacing with run-time subsystems responsible to things like identity management, installation/rollback/configuration management (eg, business-functions-level configs, as well as feature-flags/etc) , observability enablement,... probably too much to list. And I am saying that the productization part, which is also done by engineers, who often do the design, today, will be separated out. We will have colledge degree programs that focus on these separate aspects. Incidentally, today LLMs help with the coding for productization part a lot more.
I also personally foresee future tools (eg, programming languages, debuggers, etc) separated for these two tasks.
So I am envisioning also companies that produce designs, but not the implementation (productization) of those designs. It as if we will end up having two-five companies producing designs for Online Word processors, spreadsheets, email tools, and then 200 companies productizing these designs into products (that those will have different names, different tradeoffs, etc). (as an example)
I was careful not to re-repeat the things I wrote in [1] https://lobste.rs/s/kfo7mc/building_breakwater_with_ai#c_89ssb6 So apologies in advance if I am duplicating.
I think that’s reasonable although I suspect the designs will be open source.
I agree with you. Many good designs will be open source in the above model. Maybe many will be created in academic communities too (sort of like RISC-V, BSDs) Some will be commercial, I am sure.
These 'designs' in my mind will come with an SDK that contain, perhaps
Probably a lot more things I cannot envisage yet :-)
I hope Bryan Cantrill gets a gold star; it's a fun prediction. Does he win if his podcast influences the discourse?
That said, if this plays out as another enclosure of the commons, and pretty much all productive activity becomes predicated on paying rent to a megacorp, we all will be feeling pretty Deep Blue.
That would be pretty bad. I also thing our little precious deep blue feelings will be overshadowed by how people living next to all those new datacenters will feel.
I recommend listening to this segment of the podcast, it's fun: https://www.youtube.com/watch?v=lVDhQMiAbR8&t=2835s
(And if you keep on listening you'll get to the bit about kākāpō breeding season.)
I'm going to regret weighing into this but
The idea that this could all be stripped away by a chatbot is deeply upsetting.
In my opinion it's not the "chatbot" that I think any sane person is concerned would strip anything, it's the decision makers[1] involved in the stripping inflection points that make folks wonder if there is any limit to that adage about "market irrationality ... your solvency"
1: and for this exercise, that list extends as far as the eye can see: hiring managers, CxO, venture capital's LPs, maybe even actual fund managers for all I know
And, I guess to double down on the "I'm going to be sorry," I am acutely aware to whom I am making such a distinction, so I hope we can limit our disagreement to whether you do or do not actually think the upsetting part is the chatbot (i.e. the technology) or whether the irrationality could possibly be the deeply upsetting component
I may have been a little flippant with "stripped away by a chatbot" - you're absolutely right, the bigger question is around decision makers in the industry itself.
Personally I think anyone who lays off their development team because "Claude can do it" is making a huge mistake, and will quickly learn the error of their ways... but that's no comfort at all to the development team who got laid off in the meantime.