every job is a programming job now
december 2025 will be remembered as the moment agentic coding had its chatgpt moment. the latest generation of models, such as opus 4.5, gpt 5.2 codex, and gemini 3.5, are a stepwise increase in autonomous programming ability. much like chatgpt's product experience was able to illustrate gpt 3.5's capabilities and value, the ergonomics of agentic cli tools like claude code, codex, and opencode are able to harness the models' programming intelligence in an accessible and reliable way. i think the cli tools are a perfect example of product design and model capabilities merging together. we've been testing these tools at my own job, and it's fairly obvious (to me at least) that every knowledge work job is going to change dramatically over the next 5 years. this post will try to describe where i think knowledge work is headed, with some more specific commentary on financial services. my view on knowledge work is built on two counterintuitive beliefs:
- there will be proportionally fewer software engineers ten years from now than there are today building a very different class of software
- there will be exponentially more programmers ten years from now than they are today, and they will not have "software engineer" as a job title
programming versus engineering
one of the bigger, more contentious, debates going on in the broader zeitgeist is how software engineering will evolve with agentic coding tools. i do not think software engineering, as a job, will be eliminated, but i do think the future will require fewer software engineers and what the job looks like will change dramatically.
the objective of a software engineer is to use computers to create reliable systems that solve problems in repeatable and high leverage ways- meaning the unit economics of the solution improve with scale. that objective does not change with llm's. however, prior to llm's, programming was a key part of how a software engineer accomplishes that objective. there are a lot of software engineering roles, particularly junior roles and product engineering roles, that are specifically focused on creating the programs that capture the business context of the problem in question and the proposed solutions. unfortunately, these are the software engineering roles most at risk for disappearing over the next decade for the following reason.
llm's allow any capable and intelligent person to create programs, without the months, years, and decades of experience we typically associate with coding. as a result, those with the most intimate knowledge of the problem they are solving- those that know the problems edges, the nuances, the pitfalls, and what a successful and good solution look like- will be able to create the programs that solve the problems they face themselves. the awkward, difficult, and time consuming translation of business problem to program can go through significantly fewer nodes of communication when the program can be created through clear natural language specification. if a user can describe the requirements of what they want, then an llm will be able to create a program that meets those requirements.
i believe the natural result of this will be that (1) knowledge workers will use llm's to write programs for their day to day tasks and (2) software engineering will transition from writing the program itself to creating systems and tools that allow knowledge workers to reliably create their own programs.
the programming knowledge worker
the result of llm's is what i'm calling "the programming knowledge worker." the programming knowledge worker is someone who's core job is not programming, but leverages programming to accomplish what their actual responsibility is. the idea of the "programming knowledge worker" is derivative of a comment made by amjad masad, essentially stating that coding agents can be used as general agents. the more time i spend with these tools, the more i believe this is true. i have three examples of "the programming knowledge worker" to illustrate the concept of coding agents as general agents: product managers, data analysts, and investment analysts.
product management
product management is my core function. i define product management as "figuring out what problems we need to solve for our user in order to deliver them value, and then validating that we have the right solution to those problems." there are a lot of things product managers need to do in order to figure that out: talk to customers, review what has happened in commercial discussions, review revenue and product analytics, construct discovery plans and roadmaps, and more. for the last 20 years, product managers have been drinking from a firehose of various b2b saas products to help them accomplish each of those tasks; while most tools start out very specialized on one job to be done, over a long enough time horizon, they all try to expand to owning the full product discovery and development lifecycle.
a lot of focus on AI and the product role is on vibe coding prototypes and product managers shipping code. i think those changes are certainly true, but are fairly limited when i think about a product manager's core objective. vibe coding prototypes help product managers move faster, but that is only one dimension of being an effective product manager; the other dimension is having the the right mental model of your user and how to deliver value for them. having spent a few weeks with claude code, product managers will now be able to tackle that second dimension by creating the tools they need themselves. more importantly, because i can create these tools as computer programs with llm's, they inherit certain benefits: these tools are reusable, customizable, and extensible. what is even cooler is that through claude code, i can instruct an llm how to stitch the tools i create together to accomplish specific tasks without my intervention.
data analyst
at my current company, data analysts are one of the most critical functions in delivering value to our customer. as a data company, we have to build complex data integrations with messy source data packages. our data analysts own the process of interpreting the wide range of data we receive and modeling this data within our software systems. these workflows are highly bespoke and manual, which means that building scalable software based solutions for these workflows is difficult to estimate, time consuming, and expensive. meanwhile, data onboarding is one of the biggest bottle necks for our business.
over the last few years, we have been trying to improve the technical capabilities of our data analyst team, now mandating SQL and some basic python skills. because of this, our data analysts have a much deeper understand of what needs to happen for data to be onboarded correctly, from mappings to data tieouts and more. historically, a lot of time has gone into taking what a data analyst knows needs to happen to the data they are trying to onboard and translating that into computer programs and software that can do it automatically.
agentic coding tools will dramatically shorten that translation time, and i believe that data analysts will be able to write their own programs that they can use to onboard data, both at my own company and across every industry where you have analysts manually reviewing and onboarding data. similar to product managers creating their own tools, i believe that data analysts will first use llm's to create data mapping, data quality, and data transformation programs as tools, and then they will leverage their domain expertise to instruct llm's how to use those tools effectively.
investment analyst
an investment analyst's core responsibility is to identify and execute good investment ideas. in the past, this has meant combing over data rooms, complex spreadsheets, industry material and more. over the next decade, the core responsibility of an analyst won't change, but how an analyst accomplishes will change dramatically because now an analyst can use a llm to write programs to assist in their analysis. even more so, analysts will leverage the reasoning capabilities of llm's to help figure out which program they need to write, which is nomrally something they would rely on an IT or engineering team to help determine.
financial services is highly dependent on spreadsheets. most of the time, when faced with a new tool, investment analysts will reply "i can already do this in excel." spreadsheets, while powerful, have their deficiencies; they are often bespoke and lack context, which makes it difficult to use them repeatably. they are also difficult to verify at scale. if you've made it this far, you should not be surprised at how i think investment analysts will be able to operate in the future: rather than manually reviewing information and using it to construct spreadsheets themselves, investment analysts will interface with llm's to describe very specifically what they want, and the llm will create computer programs that output the artifacts (likely spreadsheets) that they want. over time, llm's will learn from investment analyst on how to compose the generated programs to help analysts understand their investment options and decisions more quickly and efficiently.
closing thoughts on the programming knowledge worker
i think we've already seen a decade+ transition towards the "programming knowledge worker" in most industries, as firms have increasingly hired talent with programming skills. more and more roles already expect some level of technical capabilities such as SQL and python. llm's and agentic coding tools will exponentiate these capabilities across knowledge work.
i believe the most successful people over the next decade will be the knowledge workers who use llm's to codify their core jobs to be done into scalable programs and then help llm's use these programs within the right contexts. in short, every knowledge work job at scale will require programming, even if the program itself is written by a llm through natural language instruction.
the software we need to create
"As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming had become an equally gigantic problem. In this sense the electronic industry has not solved a single problem, it has only created them, it has created the problem of using its products. To put it in another way: as the power of available machines grew by a factor of more than a thousand, society’s ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between ends and means. The increased power of the hardware, together with the perhaps even more dramatic increase in its reliability, made solutions feasible that the programmer had not dared to dream about a few years before. And now, a few years later, he had to dream about them and, even worse, he had to transform such dreams into reality!"
--- Edsger W. Dijkstra, 1972
given all of the above, it should be obvious that i think software engineering as discipline will change dramatically compared to what we saw in the 2010s, which i would (somewhat tongue-in-cheek) call the era of the scaled application engineer. however, i am not doom-and-gloom regarding software engineering as a whole like other counterparts in the industry because whenever there is a major platform shift, like what is happening right now, there is a new generation of infrastructure and tooling that we need to build. in my opinion, the most valuable use of software engineering skills will be to build the infrastructure and tooling that allows knowledge workers to reliably create and leverage computer programs using llm's. if you are presently a software engineer, this is what i would learn how to do because creating intelligent systems that compound the information that knowledge workers can distill into coding agents is going to add trillions of dollars of value.
i include the above quote from dijkstra, a legendary 20th century computer scientist, to illustrate the fundamental crisis of software that has existed from the moment programmable machines emerged. as humans get more and more powerful computing machines, we will create larger and larger volumes of computer programs with increasing levels of complexity. llm's are the new machine that allows more programs to be created, and as a result, there will be innumerable challenges in creating, testing, and deploying these programs. allowing knowledge workers to do this will be a defining opportunity across every vertical and in every enterprise market over the next ten years.