You explained exactly the person that I am as well. Same motivation, same inability to use stuff I don't fully understand, same way of learning things, same feeling of emptyiness after LLMs appeared. It's wild, and I do not have an answer either. I just try to adopt and use the agent as some form of new processor for logic. And invent my own language around it for the logic harness to jail and align it properly, which is the only interesting thing right now to me as it touches fundamental principles of logic, information theory, computer science - but everything else, like writing compilers for regular problems, writing programs, writing code, are all dead uninteresting to me now, even though I exactly know that other people struggle to get complex stuff out of LLMs (like seeing this Theo spending half a million dollar in tokens on a TypeScript compiler that I could build in like a month for 1/1000 of the price), but this doesn't give me as much really to attack it - and the reason is, because once I solve it and publish it, people can just steal the ideas, the energy that went into it (all the thousands of micro decisions), this was not possible before on the same scale and needed the same brain power. This inbalance pretty much makes it impossible to me to release anything anymore as open-source.
I think programmers are frustrated in part because the code used to be our place to do our thinking, but now LLMs just buzz through the file changing thousands of lines and we can't keep up.
It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together.
I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.
The closest thing I know to this is org-babel, part of Emacs, which allows you to push code blocks out of an org file into an actual source files, or pull them in from actual source files. This is mostly done manually by invoking functions called `tangle` and `detangle`.
I intend to investigate this further in Emacs, since I'm an Emacs user, but Emacs is never going to be the friendly UI we need to make this tooling common.
I feel like we also need better non-LLM driven ways (like better static analysis tools) to analyze LLM-driven changes. The way changes are presented in modern IDEs was designed around reviewing human-created changes and doesn’t really feel like it’s keeping up with presenting and validating what modern LLMs are doing.
> now LLMs just buzz through the file changing thousands of lines and we can't keep up. It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that.
I do it differently, I focus on better recording what the user wanted, the so-called "user intent". To do this, I record all messages typed by the user since the start of the project, whether 3,000 or 10,000 messages. An LLM can churn through them in 10 minutes and derive a fresh, up-to-date interpretation from the raw data. This can be used to judge whether the implementation has diverged from the intent, or, in other words, to realign the code and tests. The messages the user writes are usually designs or corrections, a very rich, compact signal. If the user struggles with something, it could result in a tool, a skill, updates to the project docs, or new tests.
> I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.
I think the solution is still code, just at a much higher level of abstraction. Maybe a start is kind of typed ADR or FSM that guides (constrains) the agents.
I believe more type checking guarantees will be more and more important for agents.
> It's still valuable to deeply understand parts of a program
Part of woe is that once you've reviewed, validated, and comprehended a piece... Later gets casually mangled by some other LLM-generated urgent change.
The workflow I use to still keep up with everything is to start coding by hand and only once I have a good idea how the rest is gonna look like and am bored I had off the rest of the pr to the LLM.
Could be just defining the methods without filling them but depending on the mood I code more by hand or less.
Yeah, I can relate to this. However, I haven't found it too difficult to adjust. I have found myself creating draft PRs, and then just sitting on them and thinking about it for a day or two before I even consider merging it. This lag time is the time that I used to spend typing it out and thinking as I went along, now that's happening later. I have closed more than a couple of my own PRs once I had time to consider them. I am rarely shocked when I wake up the next day, look at it, and think: "Eh, this change is not sufficient because it doesn't address X".
> If anyone can point an LLM at slow code and it automatically finds a hot loop and uses a trick it found somewhere on the 'net to vectorize it, there is little point in hiring someone with a focus on that.
LLMs are not very good at performance issues unless you walk into it with a clear idea of the likely root cause and the bigger picture regarding actual hardware and desired customer experiences.
"Please make the code go faster"
vs
"I am noticing what appears to be contention between threads under workload A, B & C, but not with workload D".
These are completely different universes of capability and outcomes.
Even if an LLM can fight its way to the answer on its own, you can achieve a specific desired result much faster and with significantly lower risk if you are genuinely an expert.
I've seen a concrete example of this recently. I profiled the client's product "the hard way" and arrived at a change to a single line of code that would eliminate a mutex issue. One of the client's developers used the LLM and wound up with a change set that touched hundreds of files, but otherwise achieved approximately the same performance fix. The other developer even had my hint that it was a single file change and couldn't figure out how to do this despite prompting a leading edge model regarding this exact possibility over and over.
Taste and aesthetics apply to absolutely everything. Not just UI/UX design. Perhaps it is even more important that we care about the things that are invisible to the customer. It is certainly easier to forget about them or treat them like they don't matter as much.
I am sure people could find code such that an LLM can optimize it 10x fold. I have seen many types of code in my life (well written, horribly written, fast, slow, etc.).
I do feel there is a limit to LLM-s today. I did not try, but I doubt it will work if I would tell it "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Knowing where that limit is, is as hard as it always was knowing how fast a team of engineers was going to do a project.
Not every optimisation is the same. LLMs can optimize code that is behind known practices, but won't usually invent new data structures or algorithms to solve a unique problem.
The fact that you're pointing it to PyTorch code in the first place is being specific.
Pointing a frontier model to a 10 or 100MLoC codebase and saying "make this code fast, make no mistakes" doesn't work. As an experiment I recently tried this with a relative small (500KLoC) codebase and it got stuck on believing that the primary cause of slowdown was the database not using a connection pool. (Which was completely irrelevant for this specific code.)
I don't know why but in Typescript when I tell an LLM to write code to check if a character is of a type, it often uses a whole Set() instead of just using a string and doing indexof. It's weird because not only should strings be faster, doing it with strings should also be the prevalent way in the dataset. Yet it uses a Set.
This is the kind of person for whom AI is making the most negative change. I feel sad for them. For me, I love this new world. I never took pleasure in craftsmanship or perfectionism, I just want things to work and then iterate on it with as little effort as possible.
> I never took pleasure in craftsmanship or perfectionism, I just want things to work and then iterate on it with as little effort as possible.
The problem with this outlook (not with you personally) is that the increase in accessibility for you comes at a cost, but the way things work these days the cost is not paid by you but by someone else — someone you'll probably never even meet. The cost has been abstracted away from you and foisted onto somebody else against their will. This shows up as people adversely affected by local data centers (increased pollution, higher electricity prices), people displaced in the workforce (author of the article), people of the future who will not understand things because it's easier to skip understanding for now (students, early learners), and so many more.
It's very liberating — so long as you are given the ability to not think about the consequences for these other people, and the abstraction process by which AI companies are providing their services gives you that freedom by design. At the very least, it is something about which you perhaps ought to be wary.
That process is nothing new. That’s happened many times in history over and over. And in far more dangerous ways than not understanding how some complex piece of code keeps their favorite or most critical application running. At this point, people have long lost the ability to have even basic survival. How long would people last if they needed food or water? They have no idea on step one to achieving the basics. It’s all abstract to them, which includes us. That’s the loss that actually matters. Not that they know how their Amazon Fire TV works.
I find it a breath of fresh air to be able to tackle backlogged tech debt items simultaneously with business priorities in parallel and stuff like that.
That being said, I can't see this entire field existing in five years anymore. I'm hoping for at least two more years, but who knows?
This stuff is coming for all white collar, the barrier to entry is completely gone now. Maybe not the barrier to mastery (yet), but the bottom has fallen out.
... could never have had a proof attempt presented without the mathematicians setting the stage and working to verify the proof.
I think you might be viewing AI and humanity as a zero sum experiment. It's really not. Go read some David Brin (Existence is a good start). We don't know all the positive and negative aspects to come, but we aren't in a dark forest situation. Existentially, AI is here, what are we going to do with it?
I see sentiment like this (which is valid; it’s a different perspective), and then I look at my company’s current caseload of breaches and how most of the (insane) increase in business we’ve received is caused by poorly coded apps with obvious security issues, along with the inability of orgs to remediate those issues or adequately follow incidents because no one actually knows the applications anymore.
And I’m wondering if this isn’t the enormous amount of organizational debt from having security second to everything finally coming calling.
I _am_ a craftsman - software, wood, and a few more domains. There is a lot of personal satisfaction I find in woodcraft through the motion and the exercise. I love that this is a luxury hobby instead of a personal necessity. The difference there is that if I take my time on personal necessity where the market isn't paying for it, I may take food out of my kids' mouths or lose the roof over their head. Luxury craft hobbies face only self-imposed pressures.
AI is letting me build similarly. I can continue to craft my Rust and my Python and my Typescript and my Fortran to my heart's content - and those skills help in the day to day - yet I'm also able to compete in the market and build things that were really infeasible before.
I feel that pain. My job involves a considerable amount of reverse engineering and software development, and I've always been interested in getting down to the lowest levels and figuring out what's actually going on.
LLMs are becoming remarkably competent at both of these skills. Not quite at expert levels yet but I expect it won't be long until this happens. I'm astounded at what they can do already, with the benefit of relentless, persistent effort on top of this.
How I've been using LLMs is twofold. Firstly, using chat mode, as documentation to talk to. Secondly, using agentic mode to develop tooling to help me with reverse engineering. Ranging from one-off scripts to analyse complex structures to modules that use the API of my own framework I've developed to extend it.
For now I think I've got a decent balance between using the LLM as a useful timesaving tool and understanding things myself. I feel I have to draw a line around there, otherwise I'm babysitting a black box, which almost anyone can do.
I'm lucky though - as a hybrid engineer/manager, I've been able to lean away from the former and into the latter.
And I've come to notice that humans doing agentic work seem to need more emotional support per unit effort than those doing traditional engineering.
So there are opportunities there. I don't want to spend a second longer than I have to prompting machines - there is zero dopamine loop in that for me, I get more doing housework and at least that makes my wife happy - but I'm happy to support a few other humans engaged in that kind of work.
It's sad though. I used to love dreaming intricate machines into existence and then watching them come to "life", or at least actually start working. That dream seems dead for now, I hope it comes back but I won't hold my breath.
Yeah I feel this. My strongest passion in computing is simply learning how the machine and OS work. The code I would write would usually be experiments, not projects or tools.
I'm less pessimistic than the author though. There is always room for people who know what they are talking about. Take a deep breath.
> I'm less pessimistic than the author though. There is always room for people who know what they are talking about. Take a deep breath.
But what will their day to day look like? Meetings?
Previously, I'd have to work days undisturbed to get important stuff out of the door. There was effort involved to reach an elegant solution that fit business need.
Now I'm a meat bag pressing enter on a "recommended" option Claude already figured out was the best approach.
I wish that I could agree with you that "There is always room for people who know what they are talking about." I think that you are right in the long term. Eventually we will return to a world that values people who know what they are talking about.
In the short term, I have seen a lot of managers and other higher-ups talk about how we do not need to worry about low-level details anymore. In their minds, we are now all designers and architects, so we do not think about the small implementation details that ultimately do matter for performance and reliability.
People who know what they are talking about worry about all of the details from the big picture down to the small scales. We can still operate using abstractions like designers and architects, but we must know enough to choose the right abstractions that account for the concrete details properly. I've discussed this point earlier this year [1] using the tree swing diagram [2].
One suggestion for the feeling that has been great for me. Finding a hobby where you can focus on sweating the details. Detach it from economic imperative (the core definition of a hobby, you dont make money from it). Ham radio, maker and micro electronics, woodworking, calligraphy, music. Of course there are more technically advanced solutions to the problem, that's not the point. The point is the effort and discovery.
I was never the best programmer and never was to keen on building things or providing some value to users. I'm more interested in how systems work, especially computers and the OS, and so far, LLMs haven't taken that away from me. If programming and solving problems had been important to me, I'd probably have a problem right now. While I feel for OP, what interests him most—namely, understanding things and developing an intuition for them—is not a productive activity in the sense that it’s not about building or producing things. But the job of a software developer has always been exactly that and LLMs take an ongoing trend to the extreme. I think people like OP have no choice but to separate their personal interests from their job, as hard that may be.
Room where? You're obviously not going to hire someone for their knowledge alone in late 2026... ChatGPT probably knows more than you know in every domain. What questions could I ask you that ChatGPT wouldn't be able to answer?
ChatGPT is a fantastic encyclopedia for knowledge retrieval and even is occasionally accurate!
It doesn't yet know when I brushed my teeth last, what specific foods in what quantities give me heartburn/indigestion, what that funky smell from my running shoes might be.
It can write pretty good code on a recursive loop when its provided a clear target. It can write better code when it has someone who understand architecture guiding it. It can review code reasonably well as well.
ChatGPT tied to robotics might even be able to do more interesting things!
It does pretty poor on highly specific knowledge where a RAG better supports -- something like Agent Search at GCP or AI Search at Cloudflare. But it can synthesize.
In effect, we've built an amazing library registry and need to up our librarian skills and the skills of people or systems that can use the information the librarian and their system can find.
You won’t hire someone to answer questions for you; you might hire someone to make decisions for you. And domain expertise is still very useful in both making good decisions and convincing other people to trust your decisions
I'm not nearly as detail-oriented but I can certainly relate. The craft I've spent 20+ years mastering is disappearing and I'm not sure if I'll enjoy whatever replaces it. It's reassuring to know there are others who share the sorrow.
> Hobbies still exist, but they don’t pay the bills, and increasingly retrocomputing and performance optimization are being infested by LLM fans that seek recognition rather than the experience, which sucks the fun out.
Isn't this whole post seeking...recognition? I am so confused at the metahypocrisy here. Why is it valid to want recognition for something when you do it, but not when someone who uses an LLM does it?
There's a great post I read on twitter on how marathons and Iron Man have come to be the new status signal. The argument was that people who grew up with privileges find it hard to show something they've personally worked for. Every other "achievement" could be attributed to something other than their hard work.
ex: getting a big seed round from a VC for your start up still may show that your parents had connections.
but marathons have this grindability and somewhat stable feedback loop.
I think understanding the details is still important. However, it moves toward the more central parts of the application, where the risk is higher and agentic workflows can’t be pushed as far. I think the author may benefit from specializing in those parts of the system where unattended agentic work is still too risky.
Your article matches my own intuition, and there's a case to be made for adjusting our architectural patterns to better compartmentalize those parts of the app we can let an agent go nuts on. For example, could we leave all of the UI to the agent? Or things like the MCP Server implementation of the app? I'm not quite sure where to draw the line yet. I'm quite comfortable leaving unit tests to the agent by now, but if it's user visible behavior, I still find the agent's work to be off somehow. Ymmv, I guess.
This reminds me a lot (mostly for worse) of the industrial revolution. The industrialization of textiles didn't help weavers weave better clothes. It displaced smaller, higher quality output with dramatically less varied, lower quality output in much greater quantities, more cheaply. It also dramatically undermined the relative autonomy of weavers and the control they exerted over the structure and details of their own workdays.
What I think we're likely to witness here, or at least what AI investors ultimately are hoping to see happen, is the displacement of code as we know it (often already sorely lacking in quality and craft) not by more of the same varieties of code, but a massive profusion of shittier, more homogenous code. It won't have to win by being better; it'll be able to do that by being cheaper alone. And we're frankly kidding ourselves if we think that doesn't mean a profound deskilling and potentially deprofessionalization across the whole class.
> This reminds me a lot (mostly for worse) of the industrial revolution. The industrialization of textiles didn't help weavers weave better clothes.
I don't think comparing it to the industrial revolution is appropriate, as the political and social conditions were completely different. I think you can compare the disruption that is introduced by artificial intelligence more with the deindustrialization of regions such as the Ruhrgebiet in Germany.
I think that, with the amount of vibecoded code of mediocre quality being produced, there will start to be a demand for "hand-made" software that someone took time to make as delightful as possible to use.
Yes, I think so too. Just like there is a demand for handmade objects like vases, cooking knives and beverages, which was the norm before the industrial revolution and has now become a thing of intrinsic value, provides they are of higher quality than their factory-made counterparts (I have a background in the spirits industry, where "small batch" and "handmade" have often been used to justify premium prices despite clearly lower quality. I've become a little more discerning since when I see those labels anywhere and don't take quality for granted).
Demand from whom? I think a lot of people are pretty constantly observing that software quality in applications they use (or are forced to interact with) has been declining across the board for a while, and that this seems to have accelerated recently. The average lay understanding of this is "because AI" but it's probably a combination of sometimes being models producing sloppy code and sometimes being poor morale and management and product design in this industry that's essentially coming apart at the seams from the perspective of its workforce. I think it's uncontroversial to say that people already dislike this and wish for better software quality. For the most part, though, they either don't have or won't use any levers of market pressure for this. Their software choices are largely limited to what google or apple will allow for their phones, or what employers require them to use. I'll tell anyone who will listen that they should use FOSS where they can, but people really resist this idea even where it's extremely feasible and the tradeoffs are mostly familiarity (like their desktop OS). Consumers of software seem to partially think this way because they have been disempowered so thoroughly that they seldom have a choice
So as market pressure goes, that leaves employers. I do see the occasional oddball project that resists this wave, but "doing things correctly even if it takes longer" is not a value you're really allowed to have in an economy where the make or break factor for your business is usually getting investment capital, and capital is, as a population, probably the most all-in on LLMs of anyone, to the point where I believe they'd push for vibecoding even in instances where they can't find numbers that justify doing so.
A ton of people not in tech hate genAI so much that they say they'll, for example, not purchase a game if they know someone used it for any part of it, and yell about it online, and such, but games are pretty much the only consumer-facing software people make purchasing decisions about, so maybe that moves a needle there, but gamers failed to rally against microtransactions, DLC piecemeal replacing game dev, or even things like always-on DRM or revoking purchases that literally remove their ability to play their games, so I doubt that's going to materialize a change in something that could be more easily obfuscated in response to this pressure like the provenance of the software
I commiserated so much with this post. I feel like I got out of software at just the right time - folks like me that have an inherent need to understand the lower level details feel like this agentic coding world, where there is simply not enough time to even read the code, let alone understand it, is hell.
I left software and went into violin making and I couldn't be happier (though of course I'm extremely fortunate to have saved up enough in my software career to comfortably make the transition). In violin making a tenth of a millimeter is considered a lot and we endlessly stress over details like the corner shape and the f-holes. And while some of this nitpicking is certainly excessive, it serves more as proof to show that we're extremely careful with the details so that stuff that really matter, like tonal quality and playability, will also get enough detailed focus.
Yep it’s pretty depressing all around. Even when the truth is revealed about the output of an Llm (not quality, full of errors, made up details, nonsense code, etc), people are still claiming it as a better way of working because they had a chat with it. There is very little room for anyone not interested in slop.
I was recently replaced by a young developer and the only thing that keeps me smiling is that they still haven’t fixed the part of the application I raised concerns about (because the young dev decided to write on a fresh non-compatible stack even after my warnings). I hope eventually it leads to their own loss of career since that’s what they did to me. All of that to say that Llms have made people into over confident morons.
Like the old joke about alcohol not "turning" someone into a jerk, but instead revealing the jerk that's been hiding all along, I think the same is true for the idea that LLMs are "turning" people into overconfident morons. I don't believe these people are being changed, I think it's how they always were, and now it's easier to see.
I think part of the grief is losing the way we learned to do something we loved. Most people care about what software does, not how we made it. The hard part is accepting that what makes the job satisfying for us isn’t always what makes the result useful to others.
It's great that she takes joy in his work, and sad that economics is pushing her to focus on different details with less joy. But the same can be said for a horse groom who loves her work being pushed to transition into a mechanic. Change sucks, but less than petrification.
I'll introduce the concept of Hobbies for those who crave the details. Hours spent in the basement/attic/office/garage/workdesk sweating the details in an inefficient and un-economic way. Learning music, painting figurines, woodworking, playing with microelectronics, making sculptures, model aircraft, ham radio. Offline things, intentionally far away from the frontier that bring joy, depth of understanding, and are intentionally not going to be gobbled up by an LLM.
This is about the loss of the opportunity to support oneself.
Offering hobbies, which require ppl to already be supporting themselves, is like a slap in the face.
This is like telling a coal miner that if they enjoyed the work they did in their career, they can go digging tunnels in chalk cliffs after renewable energy destroys the demand for coal.
It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together.
I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.
The closest thing I know to this is org-babel, part of Emacs, which allows you to push code blocks out of an org file into an actual source files, or pull them in from actual source files. This is mostly done manually by invoking functions called `tangle` and `detangle`.
I intend to investigate this further in Emacs, since I'm an Emacs user, but Emacs is never going to be the friendly UI we need to make this tooling common.
I do it differently, I focus on better recording what the user wanted, the so-called "user intent". To do this, I record all messages typed by the user since the start of the project, whether 3,000 or 10,000 messages. An LLM can churn through them in 10 minutes and derive a fresh, up-to-date interpretation from the raw data. This can be used to judge whether the implementation has diverged from the intent, or, in other words, to realign the code and tests. The messages the user writes are usually designs or corrections, a very rich, compact signal. If the user struggles with something, it could result in a tool, a skill, updates to the project docs, or new tests.
Sounds, like you already mention with org-mode or similar ones) like literate programming (https://en.wikipedia.org/wiki/Literate_programming) or jupyter notebook.
I think the solution is still code, just at a much higher level of abstraction. Maybe a start is kind of typed ADR or FSM that guides (constrains) the agents. I believe more type checking guarantees will be more and more important for agents.
Now, when someone sends a working PR in, even high quality and well tested, they may actually have no idea how it works.
Part of woe is that once you've reviewed, validated, and comprehended a piece... Later gets casually mangled by some other LLM-generated urgent change.
Could be just defining the methods without filling them but depending on the mood I code more by hand or less.
LLMs are not very good at performance issues unless you walk into it with a clear idea of the likely root cause and the bigger picture regarding actual hardware and desired customer experiences.
"Please make the code go faster"
vs
"I am noticing what appears to be contention between threads under workload A, B & C, but not with workload D".
These are completely different universes of capability and outcomes.
Even if an LLM can fight its way to the answer on its own, you can achieve a specific desired result much faster and with significantly lower risk if you are genuinely an expert.
I've seen a concrete example of this recently. I profiled the client's product "the hard way" and arrived at a change to a single line of code that would eliminate a mutex issue. One of the client's developers used the LLM and wound up with a change set that touched hundreds of files, but otherwise achieved approximately the same performance fix. The other developer even had my hint that it was a single file change and couldn't figure out how to do this despite prompting a leading edge model regarding this exact possibility over and over.
Taste and aesthetics apply to absolutely everything. Not just UI/UX design. Perhaps it is even more important that we care about the things that are invisible to the customer. It is certainly easier to forget about them or treat them like they don't matter as much.
You’re probably limiting the frontier models by being specific.
I do feel there is a limit to LLM-s today. I did not try, but I doubt it will work if I would tell it "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Knowing where that limit is, is as hard as it always was knowing how fast a team of engineers was going to do a project.
Pointing a frontier model to a 10 or 100MLoC codebase and saying "make this code fast, make no mistakes" doesn't work. As an experiment I recently tried this with a relative small (500KLoC) codebase and it got stuck on believing that the primary cause of slowdown was the database not using a connection pool. (Which was completely irrelevant for this specific code.)
The problem with this outlook (not with you personally) is that the increase in accessibility for you comes at a cost, but the way things work these days the cost is not paid by you but by someone else — someone you'll probably never even meet. The cost has been abstracted away from you and foisted onto somebody else against their will. This shows up as people adversely affected by local data centers (increased pollution, higher electricity prices), people displaced in the workforce (author of the article), people of the future who will not understand things because it's easier to skip understanding for now (students, early learners), and so many more.
It's very liberating — so long as you are given the ability to not think about the consequences for these other people, and the abstraction process by which AI companies are providing their services gives you that freedom by design. At the very least, it is something about which you perhaps ought to be wary.
That being said, I can't see this entire field existing in five years anymore. I'm hoping for at least two more years, but who knows?
This stuff is coming for all white collar, the barrier to entry is completely gone now. Maybe not the barrier to mastery (yet), but the bottom has fallen out.
I think you might be viewing AI and humanity as a zero sum experiment. It's really not. Go read some David Brin (Existence is a good start). We don't know all the positive and negative aspects to come, but we aren't in a dark forest situation. Existentially, AI is here, what are we going to do with it?
And I’m wondering if this isn’t the enormous amount of organizational debt from having security second to everything finally coming calling.
I _am_ a craftsman - software, wood, and a few more domains. There is a lot of personal satisfaction I find in woodcraft through the motion and the exercise. I love that this is a luxury hobby instead of a personal necessity. The difference there is that if I take my time on personal necessity where the market isn't paying for it, I may take food out of my kids' mouths or lose the roof over their head. Luxury craft hobbies face only self-imposed pressures.
AI is letting me build similarly. I can continue to craft my Rust and my Python and my Typescript and my Fortran to my heart's content - and those skills help in the day to day - yet I'm also able to compete in the market and build things that were really infeasible before.
LLMs are becoming remarkably competent at both of these skills. Not quite at expert levels yet but I expect it won't be long until this happens. I'm astounded at what they can do already, with the benefit of relentless, persistent effort on top of this.
How I've been using LLMs is twofold. Firstly, using chat mode, as documentation to talk to. Secondly, using agentic mode to develop tooling to help me with reverse engineering. Ranging from one-off scripts to analyse complex structures to modules that use the API of my own framework I've developed to extend it.
For now I think I've got a decent balance between using the LLM as a useful timesaving tool and understanding things myself. I feel I have to draw a line around there, otherwise I'm babysitting a black box, which almost anyone can do.
I'm lucky though - as a hybrid engineer/manager, I've been able to lean away from the former and into the latter.
And I've come to notice that humans doing agentic work seem to need more emotional support per unit effort than those doing traditional engineering.
So there are opportunities there. I don't want to spend a second longer than I have to prompting machines - there is zero dopamine loop in that for me, I get more doing housework and at least that makes my wife happy - but I'm happy to support a few other humans engaged in that kind of work.
It's sad though. I used to love dreaming intricate machines into existence and then watching them come to "life", or at least actually start working. That dream seems dead for now, I hope it comes back but I won't hold my breath.
I'm less pessimistic than the author though. There is always room for people who know what they are talking about. Take a deep breath.
But what will their day to day look like? Meetings?
Previously, I'd have to work days undisturbed to get important stuff out of the door. There was effort involved to reach an elegant solution that fit business need.
Now I'm a meat bag pressing enter on a "recommended" option Claude already figured out was the best approach.
And how long can that last? We’re expensive meat bags…
In the short term, I have seen a lot of managers and other higher-ups talk about how we do not need to worry about low-level details anymore. In their minds, we are now all designers and architects, so we do not think about the small implementation details that ultimately do matter for performance and reliability.
People who know what they are talking about worry about all of the details from the big picture down to the small scales. We can still operate using abstractions like designers and architects, but we must know enough to choose the right abstractions that account for the concrete details properly. I've discussed this point earlier this year [1] using the tree swing diagram [2].
[1] https://news.ycombinator.com/item?id=46422597
[2] https://en.wikipedia.org/wiki/Tree_swing_cartoon
It doesn't yet know when I brushed my teeth last, what specific foods in what quantities give me heartburn/indigestion, what that funky smell from my running shoes might be.
It can write pretty good code on a recursive loop when its provided a clear target. It can write better code when it has someone who understand architecture guiding it. It can review code reasonably well as well.
ChatGPT tied to robotics might even be able to do more interesting things!
It does pretty poor on highly specific knowledge where a RAG better supports -- something like Agent Search at GCP or AI Search at Cloudflare. But it can synthesize.
In effect, we've built an amazing library registry and need to up our librarian skills and the skills of people or systems that can use the information the librarian and their system can find.
Knowledge has been available just by asking Google for decades now. The LLM makes it easier but it's a difference of degree not of kind
Until the models are 100% reliable knowledge will be required in order to quickly spot issues and work efficiently with the model to address them.
I'm not sure how it plays out in 5 or 10 years, but that's how it is now.
Isn't this whole post seeking...recognition? I am so confused at the metahypocrisy here. Why is it valid to want recognition for something when you do it, but not when someone who uses an LLM does it?
Training a year, and running a marathon feels more worthy of recognition than driving 42km in a car from the start to the finish.
While I don't empathize with the defeatist tone of the post. I do empathize with this part.
ex: getting a big seed round from a VC for your start up still may show that your parents had connections.
but marathons have this grindability and somewhat stable feedback loop.
Wrote a post some time ago on how we'd be helped by segmenting and ranking the domains of our systems so we can be deliberate about where we stop short of full automation: https://ljtn.github.io/epiq/blog/cost-of-cognitive-debt.html
What I think we're likely to witness here, or at least what AI investors ultimately are hoping to see happen, is the displacement of code as we know it (often already sorely lacking in quality and craft) not by more of the same varieties of code, but a massive profusion of shittier, more homogenous code. It won't have to win by being better; it'll be able to do that by being cheaper alone. And we're frankly kidding ourselves if we think that doesn't mean a profound deskilling and potentially deprofessionalization across the whole class.
I don't think comparing it to the industrial revolution is appropriate, as the political and social conditions were completely different. I think you can compare the disruption that is introduced by artificial intelligence more with the deindustrialization of regions such as the Ruhrgebiet in Germany.
The death of every sub culture in a sentence.
So as market pressure goes, that leaves employers. I do see the occasional oddball project that resists this wave, but "doing things correctly even if it takes longer" is not a value you're really allowed to have in an economy where the make or break factor for your business is usually getting investment capital, and capital is, as a population, probably the most all-in on LLMs of anyone, to the point where I believe they'd push for vibecoding even in instances where they can't find numbers that justify doing so.
A ton of people not in tech hate genAI so much that they say they'll, for example, not purchase a game if they know someone used it for any part of it, and yell about it online, and such, but games are pretty much the only consumer-facing software people make purchasing decisions about, so maybe that moves a needle there, but gamers failed to rally against microtransactions, DLC piecemeal replacing game dev, or even things like always-on DRM or revoking purchases that literally remove their ability to play their games, so I doubt that's going to materialize a change in something that could be more easily obfuscated in response to this pressure like the provenance of the software
Thanks for making me feel old
cool to see it come full circle and see another person thrown into the industry by the work of another forum member.
I left software and went into violin making and I couldn't be happier (though of course I'm extremely fortunate to have saved up enough in my software career to comfortably make the transition). In violin making a tenth of a millimeter is considered a lot and we endlessly stress over details like the corner shape and the f-holes. And while some of this nitpicking is certainly excessive, it serves more as proof to show that we're extremely careful with the details so that stuff that really matter, like tonal quality and playability, will also get enough detailed focus.
A good programmer or a good knowledge worker knows how to work with lossy details.
I was recently replaced by a young developer and the only thing that keeps me smiling is that they still haven’t fixed the part of the application I raised concerns about (because the young dev decided to write on a fresh non-compatible stack even after my warnings). I hope eventually it leads to their own loss of career since that’s what they did to me. All of that to say that Llms have made people into over confident morons.
Offering hobbies, which require ppl to already be supporting themselves, is like a slap in the face.
This is like telling a coal miner that if they enjoyed the work they did in their career, they can go digging tunnels in chalk cliffs after renewable energy destroys the demand for coal.