I also find it bizarre that so many people feel precious about the code. They have too much ego attached to what they type in and the AI kind of make them feel insecure.
I couldn't care less if I write the code, the AI or someone I told to write it.
> I also find it bizarre that so many people feel precious about the code.
Would you find it bizarre that a joiner feels precious about not just the cabinet they made (value), but how they made it? The joints they used, the process they went through, the wood (i.e., the code)?
A plumber, electrician, architect, designer, programmer -- we take pride in our skills.
Your analogy suggests that the code is the final product, akin to a cabinet or a building, something tangible that can be appreciated for its craftsmanship. In some instances, like open-source software, the code might indeed be viewed this way, but in most cases, it's not the code itself that end-users appreciate, it's the functionality it provides.
To refine your analogy, the code isn't the cabinet - it's more like the blueprint or the process used to create the cabinet. The user doesn't care if a hand saw or a power saw was used, as long as the cabinet is well-crafted and functional. Similarly, end-users of software don't see or appreciate the code. They only interact with the user interface and the functionality it provides. As a result, being "precious" about the code can sometimes be more about personal ego and less about delivering value to the end-user.
In terms of pride in craftsmanship, of course, it's crucial to take pride in one's work. However, this doesn't mean that one should be resistant to using better tools when they become available. The introduction of AI in coding doesn't negate craftsmanship - instead, it's an opportunity to refine it and make it more efficient. It's like a carpenter transitioning from using manual tools to using power tools. The carpenter still needs knowledge, skill, and an eye for detail to create a good product, but now they can do it more efficiently.
This is perhaps true for shrink-wrapped software (in so far as that still exists), but for B2B SaaS products, the ability to easily maintain and enhance the codebase is vital to the long-term success of the product.
Maybe it won't actually matter, because if AI generates a 5MM line ball-of-mud, it will be able to easily add features later due to the code being styled in alignment with its training, or maybe the context size limitations will allow future systems to digest the entire thing. It could end up being like coding in a very high-level language: who cares what crazy bytecode is kicked out as long as it performs within expectations.
Exactly, ultimately we are craftsmen, not artisans. They are two very distinct things. The difference being that the value of our output is directly tied to its' functional utility, not any sense of aesthetic or artistic expression. You can take pride in the means used to achieve an end, but they ultimately must be superseded by more efficient techniques or you just become an artisan using traditional tools, and not a craftsman who uses the industry standard.
Craftsmen are individual contributors. When you coordinate others, you're no longer an IC, you're a foreman, a boss. Coding with LLMs is about managing the contributions of other ICs. It's no different from coordinating low-level human coders who simply implement the design that was given them.
If that's the kind of 'craftsmanship' you enjoy, great. To me, this new model of 'bionic coding' feels a lot like factory work, where my job is to keep my team from falling behind the assembly line.
BTW, I've worked factory lines as both IC and foreman. In either role, that life sucks.
> Exactly, ultimately we are craftsmen, not artisans. They are two very distinct things. The difference being that the value of our output is directly tied to its' functional utility, not any sense of aesthetic or artistic expression.
That's the usual definition of an artisan as opposed to an artist. (Artisan vs. craftsman is a fuzzier distinction.)
An artisan uses artistic techniques and their own intuitive judgement to produce a practical good. Think bakers. No one would be upset that their local bakery was using tools and techniques from a thousand years ago to make their bread. But a carpenter, for example, is a craftsman. He may take an aesthetic pride in the finished result of his work, but it must match all technical specifications and building codes. And the customer would be pretty upset to see them using wood planes and hand saws to frame their house.
When assemblers were introduced, there were programmers who complained, because it ruined the intimacy of their communication with the computer that they had with octal.
They meant it, too. Noticing that the "or" instruction differed only by one bit from the "subtract" instruction told you something about the probable inner workings of the CPU. It just turned out that it didn't matter - knowing that level of detail didn't help you write code nearly as much as it helped to be able to say "OR" instead of "032".
I feel like there’s probably an unspoken division between people who enjoy building systems (providing value in your terms) and people who enjoy more of the detailed coding. The later group had a good thing going where they were extremely well compensated for doing an activity they enjoyed, so I think it make sense for them to be a bit distressed.
I couldn't care less if I write the code, the AI or someone I told to write it.
What matters is the value it provides.