I can provide a data point for what the article calls pseudo productivity: I extensively use LLMs as semantic search engines or expert systems (but not as agents). Recently I asked one how to consume a Google Pub/Sub topic using Python (context: I come from an C++/Java/JS background with some Python knowledge). The LLM gave me a good intro and some code. As it usually happens, I had a few follow up questions/clarifications, and then had to clarify the intent behind the code I requested. After a few relatively effortless rounds of back and forth, I got what I needed. It felt productive. But looking at the clock, about 20 minutes had passed without me even realizing it. Then I went and looked at the official overview page for the Google Pub/Sub Python client. It had everything I needed (including the code), in a more condensed, well-structured form. I could probably have arrived at the same outcome in 5-10 minutes. The only difference was that the latter method required some focus/discipline.
I'm wondering whether this is what they call pseudo-productivity: a lot of low-friction back and forth that feels productive, and perhaps even enjoyable, but in objective terms, takes longer?
This is a very common effect and I don't want to be defending LLMs here. But I've seen the same study with CLIs - people using them feel more productive but take longer than using GUIs.
What I want to say is that it's very situational and it's likely good to focus on the average. Using LLMs as docs are bad when good docs exist, but if you aren't sure if they do, it's a gamble. A much better approach would be to have somebody pre-create and edit the docs with an LLM for each service with bad docs.
Only when your situation isn't covered would it make sense to create new docs.
You are good with that 20 mins :)
I wrote a maxscript for 3Dmax to speed up some tasks, and i got stuck in coding. Then I asked the AI for debug, then to write a snippet, etc...I lost 3-4 days. At the end I found a developer on Fiverr who fixed my script for $20 :)
I think the answer is in the second sentence of the article. The most valuable person in this new world (using the author's own phrasing from the penultimate paragraph) is the one who is good at "building a working model of the domain in [their] head".
Depending on the domain, this may either be the domain expert themselves, or someone else trained in formal logic, data structures and organizing information into coherent hierarchies. If this is neither the domain expert nor the programmer, then it must be someone in between. In the old world, this role was called "business analyst".
I'm this person, and I do find AI to be quite helpful, though I'm mostly just playing around at this point.
I'm the daughter and granddaughter of programmers, and I learned the basics of how to code as a kid. I'm good at it and have a knack for it, but I didn't want to do it for 8+ hours a day and then spend my nights on it as well, so I didn't pursue it as a career. I did an undergraduate degree in Linguistics, which has been really helpful for having an intuitive sense for what 'language as data' can accomplish and for a strong understanding of the difference between language as data and language as meaning. I studied formal logic systems. Then I did a graduate degree in Library Science and worked in libraries for a decade and a half.
I can organize and define systems very well, and I'm trained in how to wheedle information people don't consciously know out of them without them knowing I'm doing it. I've spent enough time around actual devs to understand where my limitations are and when to loop in someone who knows more to check my work, and when it's important for the work to be super accurate versus when I can learn by fucking around. (Front end and design? Fuck around! Database structure? Fuck around but with an exceptionally robust backup system kept outside of the AI tools' purview + don't fuck around in prod. Storing credentials and people's information? Ask someone.)
The problem companies are going to have is I'm very disinclined to work for them doing this, particularly if they want us because they think we're going to be cheaper. Most people who are in this category a.) could be devs and opted not to, and there's a reason for that and/or b.) are the children, cousins, etc. of programmers. We're not stupid: we know we're just as disposable as they're trying to make devs.
> which has been really helpful for having an intuitive sense for what 'language as data' can accomplish and for a strong understanding of the difference between language as data and language as meaning.
100%. I think, intuitively, software developers understand that there's a strong connection here, but most fail to translate that into practice. It always amuses me when someone comments on the triviality of creating CRUD apps. Setting aside the fact that people usually get the mechanics of it wrong (despite it being a solved problem), they overlook the difficulty of producing a good information design.I've developed software in a variety of industries, and I would say maybe 5% of the designs I inherit are well-done and represent the concepts they're trying to model in an elegant, parsimonious way. Rather, most examples are replete with ambiguity, orthogonal concepts smashed together into single elements, and misleading naming and relationships.
And even when there is a well laid out information design, it often is laid out from the wrong point of view. Elegant information design should create a pattern subconsciously enabling people to build a mental model of the tool they're using without realizing they're doing it. But software whose information design works wonderfully from the point of view of a SDE is not going to be approachable to the average user. There are so many tools I've used where I can very clearly see the reasoning behind the decisions and the design and use it well and also be aware I could never explain how they work to the average person.
Having descended from a humanities social background and blundered into professional programming rather incidentally, a lot of this resonates with me.
I've frequently been credited as a person who can really string all the disparate elements of tacit knowledge together into a unified fabric in our particular subdomain, and helped a lot of people plug Swiss cheese gaps in their knowledge that way and come away with the feeling that it's all been tied together theoretically.
However, it's not immediately obvious to me how, in our LLM psychosis cultural moment, this facility shoots to the top of the value chain.
In theory, it's because we're going to be better at steering an LLM in some ways. A lot of the friction and hold up in building comes in the communication between people/departments/organization. If you eliminate that by holding the knowledge in one person/department, you see an efficiency gain.
What they're not saying is that they think we're more valuable because they think we'll be cheaper. They think they can have us do 2 jobs and pay us for 1: probably less than a decent SDE made in 2019.
Personally, I think it's likely to be a shitshow and backfire if that's how companies decide to try to go that route (especially the largest ones). First, if we wanted to be devs, we would be (like you). Most people with the knack for programming and thinking in systems know they have that knack, and if they haven't jumped ship to SDE before now, there's a reason. I could definitely hack a junior SDE role, skill wise, but I don't want to. Second, finding people like us is difficult. The hiring process (which is becoming more and more Gilliamesque by the day) is really bad at identifying us. There aren't credentials, and this sort of work tends to reside in the gaps, as you identified. It's harder for it to show up on a resume. Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions. I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context. Thirdly, I can't speak for you, but I've developed this perspective over decades and if people want it, they're going to pay appropriately. If they think I'm going to do any of this at my current salary level, they're deranged. And lastly, while most people in our position might roll our eyes at some techie discussions and culture, we do fundamentally like techies/devs and we tend towards placing a greater value on things like relationships than a pure SDE does. (Just speaking in generalities). So 'is willing to replace and/or toss out a category of people I like and respect' is a hint to us to start out assuming this is a hostile negotiation. (Whereas SDEs as a cohort over the last 20 years extended a lot of goodwill at first). We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing, especially since as a population we're more likely to have devs who will work with us as non-technical founders. Someone who's decent at marketing/sales/the stupid 'people stuff', understands a domain, and understands when a proper dev tells them what is and isn't possible and can even help with some of the most boring, rote parts of the technical side if needed/in crunch is an excellent non-technical founder, and as a group we're also more likely to have access to the technical connections that we'd need if we wanted to build something beyond our ability.
This is an underappreciated bit of insight and perspective, and I thank you for sharing it.
Thoughts that really stood out for congruence with my own experience:
> Most people with the knack for programming and thinking in systems know they have that knack
> Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions.
> I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context.
> We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing
If you consider that profit is a function of price and cost, and price is a function of scarcity (i.e. demand relative to supply), then over time, logic dictates that a strategy of profit maximization will work to create scarcity as soon as the profit curve plateaus. In economic orthodoxy, the only defense against this is the hope that there is more than one supplier and that they will remain adversarial, which is not an equilibrium state if you consider that a strategy of cooperative pricing and supply curtailment can at times maximize profits more effectively than competitive oversupply. Perhaps we've been judging the benefits of unregulated free markets based solely on our observations of the first half of the profit curve. Perhaps we're now seeing many of the world's markets moving to the latter half.
This is a rather strong analysis. And especially the point on behaviour change once market growth plateaus was new to me. Thanks!
I do want to nitpick on “unregulated free markets”. Because it’s almost an oxymoron. At least if one wants to rely on the theorems that prove free markets are best.
Those theorems assume a bit more than just a lack of regulation. They assume no information imbalance between parties. No ways outside of competition to keep out market entrants, and no collusion between market parties.
All of those assumptions, in order to approach them in the real world, really require some strong regulation.
Hence I would argue that the problem isn’t just the growth curve flattening, but also a US (and EU) halt to Trust busting. Massive weakening of consumer protection agencies, and a general weakening of regulatory agencies by e.g. court cases.
It’s not just that we need stronger regulation because tech companies reached a point in their lifecycle where they wish to exploit more, as you so clearly argued. On top of that, regulatory power has been pulled back.
Agreed. I would define a market as a mutual social contract that favours voluntary estimation of resource value, and exchange thereof, over violent competition for resources. Such a contact must necessarily be enforced, since voluntary compliance among humans is never 100%. So yes, some form of regulation is built into the very definition of a free market. I'm fond of saying that, as rules approach zero, competition approaches war.
When I first saw the third generation Nissan Primera [1] many years ago, this is the thought that occurred to me: some bold, enterprising designer somehow managed to convince the organization to push through a radical, risky departure from their usual aesthetic. The 2010 Nissan Juke too, felt similar (I owned one myself). In my view, both models worked out. I don't think Ferrari was that lucky.
I vaguely remember living room chairs with built in ash trays (like how some have cup holders now).
And in the late 90s, being on a plane and the chairs had a metal folding door on the armrest that exposed an ash tray. Smoking on planes was already gone or going away, but the hardware lingered for quite some time.
I've heard people describe commodity fetishism as replacing social relationships with relationships to things you own (e.g. your car, your iPhone etc). Is this accurate?
The issue is not primarily psychological attachment to objects, but that private labor (labor carried out independently by separate producers, whose social validity is only realized through exchange) takes on the appearance of its opposite: labor in a directly social form through exchange. Through exchange, the values of commodities appear to individuals not as a relation between producers, but as a property inherent in things themselves. Use-value appears as value, concrete labor appears as abstract labor, private labor appears as social labor.
This has a ton of effects. Some of the most important: it obscures exploitation (profit appears to derive from capital/risk/trade/etc., i.e. anything but labor), it naturalizes capitalism (markets, competition, money, and wage labor seem transhistorical), it disempowers producers (alienation), and it produces ideological mystification in general (people attribute to greed, unfair exchange, moral failure, production scale, division of labor, or technologies what should be attributed to the specific historical form of labor).
So your example is probably a third-order effect of commodity fetishism.
This condensation of the concept really sucked. I suggest struggling through Capital Vol. I, Ch. 1.
Another framing of this is that once you have fulfilled your basic needs of healthy, physical safety and companionship, almost everything else you do is massively deleveraged: you move vast amounts of matter and energy in order to make minute alterations to electrical impulses in your brain.
I'm wondering whether this is what they call pseudo-productivity: a lot of low-friction back and forth that feels productive, and perhaps even enjoyable, but in objective terms, takes longer?
reply