I. Technology

At some point in the last few months, I saw a tweet from a software engineer who had just started using Cursor, one of the new AI-powered code editors. His hot take went something along the lines of:

I realized that 80% of my engineering skills have become obsolete.
My leverage on the remaining 20% went up 10x.

I was intrigued, so I downloaded the app. I was impressed. Cursor was well-done, with 95% of the product being a clone of VS Code, a popular mainstream code editor, with the other 5% being a few thoughtfully-designed commands for integrating AI into a development workflow. I had been using Github’s Copilot for a few months at that point, and found Cursor’s product to be more useful in practice.

Curious about who had made this tool, I found their “About” page. It looked as though Cursor was made by a half-dozen MIT alumni, just a few years out of undergrad. The next generation has come to turn me to glue, I thought to myself.

Within a matter of days, I found myself using Cursor’s features regularly, to handle tasks like writing tests and implementing new functionality. Cursor’s AI functionality is exposed more or less through three tools:

• Generative auto-complete, in which the code editor will directly suggest text while you type.
• A shortcut for inline edits. Useful for writing tests, e.g. “Write a test showing that function X obtains behavior Y.”
• A shortcut for interactive chat. Useful for pasting in error messages or having more discursive conversations.

The auto-complete in particular is quite helpful, not necessarily because the suggestions are always correct, but because it is easy to accept them when they are, and ignore them when they are not; you don’t feel like you are constantly fighting with the tool. Having used Cursor for a few months now, I have developed an intuitive feel for the probabilistic nature of the suggestions: the earlier you are in implementing a piece of functionality, the more random the suggestions will be (less data means wider variance), while the later you are in implementing, the more accurate the remaining suggestions will be (as Cursor has more context to draw on). The best way to describe Cursor would be as an eager intern – often wrong and needing guidance, but enthusiastic and indefatigable.

Another example of Cursor’s utility is in facilitating front-end development. I am not a front-end developer, but I have enough of a foundation that I’m able to meet my basic needs. My experience of front-end is that of having to comprehend the myriad interactions involved with HTML and CSS, and to stay on top of the ever-evolving abstraction layers related to them. Cursor allows me to develop bespoke styles interactively, leveraging the latest techniques:

Me: Can you help me embed this YouTube video?

Cursor: Of course, here is a sample iframe configuration

Me: It isn't rendering properly, what's wrong?

Cursor: Sorry, the settings need to updated to include the new `aspect-ratio` property

Me: Awesome, thanks. Can some of this code be removed?

Cursor: Yes, some of my suggestions are now redundant, let me remove them

Leaving me with a clean YouTube embedding and a minimum of black-magic styling, in all of ten minutes. In another example, I was able to develop an entire React SPA for a scavenger hunt I helped organize in less than an hour. Obviously, there is material risk in using code you don’t understand, but I’m not sure if this risk is different in kind or merely in degree when compared to “copy and pasting from Stack Overflow,” which developers have been doing (albeit furtively) for years.

As I my workflow evolved in conversation with this tool, I found myself returning to that tweet. There is truth to it. Cursor makes development much less error-prone. The auto-complete is excellent at catching syntax and formatting errors as you work. When writing a piece of functionality, once you have demonstrated sufficient intent, the editor can often finish the rest. From an information-theory perspective, software engineers no longer need to write “informationless” code – if a diff of code provides “no new information” beyond what has already been written, the editor can usually infer it. In the ideal case, the most tedious half of the engineer’s job has been removed, allowing the more high-impact and creative parts of the role to take up more space.

II. Labor

What will this mean for the workforce? Are we a few years away from massive unemployment among software developers? It’s a valid concern.

I think it’s fair to say that software engineers, especially in the US, have enjoyed a cush existence this past decade or two. A relatively low bar to entry (relative to other professions), combined with strong demand driven by rapid industry growth, meant that software engineering was, for better or worse, about as close as you could get to free money.

How will AI change this?

In the late Obama years, I attended the Personal Democracy Forum, a technology-and-society conference held at NYU’s campus. One of the talks featured a young policy wonk, sharply dressed and not much older than me, talking about technology’s impact on the labor market. I was impressed by this man, who would confidently use terms like “labor categories” and reassured the audience that new types of work always emerge in the wake of technological change.

I suspect the same will be true today. I don’t think software engineers will be obsolete, but I do think that the skills in demand in five years will look very different from those of five years ago. Nor will software engineering departments in larger organizations be structured the way they are today.

Specifically, I suspect that teams will be smaller as a rule, across the board. At every level of scale and complexity, it will take fewer people to develop and maintain a given amount of software.

Further, the software engineering role will broadly have “moved up” the abstraction stack. Much like newer programming languages meant that average programmers needed to know less about kernel memory management, so will more advanced editors mean that average programmers will need to know less about language syntax, library APIs, and the like. The relative premium on an encyclopedic knowledge of languages and libraries will decline. As a corrolarly, there will be a relative premium placed on product sensibility, user sensitivity, and design fluency. New workflows will be more iterative and high-level.

If we wanted to be alarmist, we could read this as “job loss.” But I disagree. I don’t think this logic clearly leads to fewer people working in software; it might even lead to more. But what we likely will see is more, smaller, and specialized teams, iteratively developing custom solutions for specific niches. The “junior dev” role will increasingly disappear, and seniority will increasingly include aspects of product management. The wider diversity of teams and products will make it easier to find work that is more personally fulfilling.

Compensation ranges will likely widen, much as it did for lawyers in the 2010’s, as weaker engineers will find themselves struggling to demonstrate value, while stronger engineers will be able to leverage their abilities even further. On the flip side, it will become easier for less naturally technical people to find their way into the profession, broadening its accessibility at the entry levels.

The result is better and more finely-tailored software serving a wider variety of niches, made by people more deeply connected to their work, and with a more accessible profession overall. That does not seem particularly bad to me.

III. Distribution

Around the same time as the first tweet, I saw a second tweet on the broader effect of AI on the tech industry. The take was something to the effect of:

As the marginal cost of software declines, distribution matters more.

This is something I have been thinking about a lot, and I’m not the only one.

Broadly, the argument goes something like this: ten years ago, it was difficult to develop software. If you could build a team that could successfully deliver software, you had a business. Demand would be strong enough that anyone could be taught to sell it. The competitive advantage was technical superiority.

Now, however, the market logic has reversed. Anyone can develop software, and there is too much of it. People don’t know what software to use, or how to choose. What really matters is having the marketing and media savvy to cut through the noise and actually reach people. The competitive advantage will be communication and distribution.

This is something I’m taking seriously. After spending 4+ years (largely single-handedly) developing Chore Wheel as a software product, I am now investing in capacity for content and distribution. I have taken a Twitter class, and am trying to develop greater fluency with X, which is its own world and language. I have started a Substack, and have committed to publishing monthly long-form writing. I have been spending significant mounts of time developing marketing materials and iterating on messages.

Distribution is unfamiliar territory for me. For years, I focused on developing my technical capacities. I am now learning that distribution, sales, marketing are deep disciplines unto themselves, and that fluency will come only with time and effort.

In my first steps on this journey, I read Seth Godin’s This is Marketing. He wrote one thing which really struck me: “The amateur does what they like. The professional does what other people like.”

In some ways, engineering and distribution are highly complementary, the yin and yang of technology business. Both are deeply creative, involving the iterative definition and solution of problems. The engineer might ask: how can I develop software to achieve my objective? The marketer might ask: how can I develop a message to reach my audience? In both fields, your intuition might be right. But it just as often might not be. Where intuition ends, disciplined discovery begins.

IV. Vision

Unflagging optimisim my most obnoxious feature. I can find a silver lining in any circumstance.

It will be important to tread carefully over the next few years. As Karl Polanyi wrote in his seminal The Great Transformation, it is not the change itself that causes harm, but the rate of change. The speed with which AI is poised to reorganize labor markets has potential for real harm.

That said, if we can squint our eyes and gaze far into the future, there is much to look forward to. The promise of smaller, more tight-knit engineering teams embedded more closely with the communities they serve. The potential of more “whole people” – a more humanist kind of tech worker, less instrumental and more curious. The hope of technology being something that people can increasingly create for themselves, realizing the science-fiction settings of some of the best graphic novels.

There is much to look forward too, and perhaps not much to fear.