How about people that understand things are changing whether anyone likes it or not and want to stay relevant. What about the people who care about the end product and not rabbitholing design decisions on a proof of concept. What about someone who understands there is more nuance than assuming people with a different perspective on AI are lesser than or lower than people who resist the technology. You may feel you know the “right way” but to everyone else who is interested in operating in a world changing beneath our feet and not whining about the fact that everything will be different, and denigrating the people who want to succeed in it, this opinion is not exactly convincing. You want to cludge your way through a problem you’re welcome to but it’s not necessarily logical to suggest this is the only “right” way and infer that people who build with AI don’t like “understanding systems”.

When I build with AI I build things I never would have built before, and in doing so I’m exposed to technologies, designs, tools I wasn’t aware of before. I ask questions about them. Sure I don’t understand the tools as deeply as the person who wasted like 10 hours going down rabbit holes to answer a simple question, but I don’t really see that as particularly valuable.

"Claude, lift these weights for me."

This says nothing about where people find enjoyment.

I like doing puzzles.

I like it more than planning.

At the end of the day, I'll do whatever builds the best thing, but I'll enjoy it more or less depending on what that involves.

Disagree. I think it was always obvious to me that there are at two kinds of developers. To make an extreme example: developer A writes long, sometimes tedious, security-minded, thoroughly tested code, and has written the CI pipelines too. When tasked with some ticket, they'll develop it to the letter, not one inch further, and even if it makes zero sense from the point of view of the users. Developer B knows nothing of that, doesn't write tests, can't be arsed about security and has no idea of how to deploy stuff, but thinks backwards from what the users (or other developers, or their future self) might like a lot and tries to make that. Both have been useful, though the first kind usually much more appreciated (maybe because it's really essential, while type B's contributions are harder to measure).

Probably AI has come a little bit earlier for type A, but type B will follow soon anyway. In the meanwhile, they're enjoying the ride a bit more since AI takes care of all the tedious but essential details.

The real split is between the capital owners, who live on our labour, typically through inheritance of a piece of paper that says they own a percentage of what I make.

Interesting to see more of this thinking on Hacker News

Perhaps one of the secondary effects of AI replacing developers will be mobilising a group of smart, motivated people to the left

(It's always interesting to think of the secondary effects which kick in past a certain point of growth. High-multiple stock valuations often fail to take these into account. For the East India Company, for example — your company can keep growing until it's the size of a country. But suddenly other countries treat you as a foreign power rather than a pet.)

> It's not about intelligence or whatever, it's a mindset or perspective thing.

I agree with everything except this last sentence. What you wrote looks highly intelligent and I would suspect a lot of people in the second camp are not up to par with this.

You are repeating the same thing. You think having good maintainable good is important - more than the first camp.

That does not mean you are correct. This mindset is useful only in serious reusable libraries and open source tools. Most enterprise code involves lots of exploring and fast iteration. Code quality doesn’t matter that much. No one else is going to see it.

When the craft coders bring their ideology to this set up, it starts slowing things down because they are optimising for the wrong target.

> and a major goal of every single good programmer I've known has been to make themselves obsolete.

I’ve always heard this mantra when coders were thinking they’re untouchable, not so much now.

I think the real divide is over quality and standards.

We all have different thresholds for what is acceptable, and our roles as engineers typically reflect that preference. I can grind on a single piece of code for hours, iterating over and over until I like the way it works, the parameter names, etc.

Other people do not see the value in that whatsoever, and something that works is good enough. We both are valuable in different ways.

Also, theres the pace of advancement of the models. Many people formed their opinions last year, and the landscape has changed a lot. There’s also some effort requires in honing your skill using them. The “default” output is average quality, but with some coaxing higher quality output is easily attained.

I’m happy people are skeptical though, there are a lot of things that do require deep thought, connecting ideas in new ways, etc., and LLMs aren’t good at that in my experience.

> The web was objectively awful as a technology, and genuinely amazing, and nobody got into it because programming in Perl was somehow aesthetically delightful.

As an old school Perl coder, not true. Lots of people had a taste for Perl. TIMTOWTDI was sold as an actual advantage.

Perl caters to things almost nobody else does, like the way you have a negative "if" in "unless" and placing conditions after the code. So you can do things like:

    frobnicate() unless ($skip_frobnicating);

     if (!$skip_frobnicating) frobnicate();

The bigger problem with Perl IMO is that it started as a great idea and didn't evolve far enough -- a bunch of things had to be tacked on, and everyone tacked on them slightly differently for no real benefit, resulting in codebases that can be terribly fragile for no good reason and no benefit.

> nobody got into it because programming in Perl was somehow aesthetically delightful.

To this day I remember being delighted by Perl on a regular basis. I wasn't concerned with the aesthetics of it, though I was aware it was considered inscrutable and that I could read & write it filled me with pride. So yea, programming Perl was delightful.

Enjoying something and getting satisfaction out of it are two different things. I don't enjoy the act of coding. But I enjoy the feeling when I figure something out. I also think that having to solve novel puzzles as part of my job helps preserve my brain plasticity as I age. I'm not sure I'll get either of those from claude.

I feel zero sense of sadness about how things used to be. I feel like the change that sucked the most was when software engineering went from something that nerds did because they were passionate about programming, to techbros who were just in it for the money. We lost the idealism of the web a long time ago and the current swamp with apex reptiles like Zuckerberg is what we have now. It became all about the bottom line a long time ago.

The two emotions I personally feel are fear and excitement. Fear that the machines will soon replace me. Excitement about the things I can build now and the opportunities I’m racing towards. I can’t say it’s the most enjoyable experience. The combo is hellish on sleep. But the excitement balances things out a bit.

Maybe I’d feel a sense of sadness if I didn’t feel such urgency to try and ride this tsunami instead of being totally swept away by it.

I think the argument is "a bit too nice," it isn't a binary, motivations are complicated and sometimes both feelings coexist.

If I reflect for a moment about why I personally got into tech, I can find at least a few different reasons:

- because I like solving problems. It's sad that the specific types of problems I used to do are gone, but it's exciting that there are new ones.

- because I like using my skills to help other people. It's sad that one specific way I could do that is now less effective, but it's exciting that I can use my knowledge in new ways.

- because I like doing something where I can personally make a difference. Again, it cuts both ways.

I'm sure most people would cite similar examples.

It's not a pure dichotomy though. I have always been both, and slowly mixing in agentic coding for work has left me some new headspace to do "trad" programming on side projects at home.

I love the exciting ideation phase, I love putting together the puzzle that makes the product work, and I also take pride in the craft.

"The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable."

Definitely not. Based on my observations from a career as an open source and agency developer it was obvious at a glance which of these camps any given developer lived in by their code quality. With few exceptions make-it-go types tended to produce brittle, hacky, short-sighted work that had a tendency to produce as many or more problems than it solved, and on more than one occasion I've seen developers of this stripe lose commit access to FOSS projects as a result of the low quality of their contributions.

"nobody got into it because programming in Perl was somehow aesthetically delightful."

Compared to trying to get stuff accomplished in C Perl was an absolute dream to work with and many devs I knew gravitated to web development specifically for their love of the added flexibility and expressiveness that Perl gave them compared to other commonly used languages at the time. Fortunately for us all language design and tooling progressed.

I think SWEs are genuinely pretty shocked and awed that codegen models can code at all, let alone code well. My guess is a lot of the agita around this is that people thought "I can code therefore I'm smart/special/etc." and then a machine comes by that can do pretty equivalent work and they're entirely unmoored. I sympathize with that, and I don't mean to dismiss it, but that's not what I feel. I really dislike this "doer vs. maker" binary stuff that comes up every now and again, as though everyone who thinks codegen models aren't perfect doesn't want to make anything. I really want to make things--good things--and I dislike the current hype wave behind codegen models because they often make it harder for me to make good things.

I've used Claude Code to build a few big things at work; I ask it questions ("where does this happen", "we have problem X, give me 3 potential causes", etc); I have it review things before I post PRs; our code review bot finds real heisenbugs. I have mixed success with all of this, but even so I find it overall useful. I'd be irritated if some place I worked, current or present, told me I couldn't use Claude Code or the like.

That said, I've not gotten it to be useful in:

- building entire, complex features in brownfield projects

- solving systemic bugs

- system design/evolution

- feature/product design and planning

- replacing senior engineer code review

It will confidently tell you it's done these things, but when you actually force yourself through the mental slog of reviewing its output, you'll realize it's failed (you also have to be an expert to perform this analysis). Now, maybe it fails in an acceptable way; maybe only slight revision is required; maybe it one-shots the change and verifying success isn't a big mental slog. Those are the good cases. More annoying are the times it fails totally and obviously, but the real nightmares are when it fails totally, yet imperceptibly. It also sometimes can do (some of) these things! But it's inconsistent, such that its successes largely serve to lower your guard against its failures.

And the mental slog is real. The artifacts you have to produce/review/ensure the model adheres to are ponderous. The code generated is ponderous. Code review is even more tedious because there's no human mind behind the code, so you can't build a mental model of the author. Getting a codegen model to revise its work or take a different approach is very hit or miss. Revising the code yourself requires reading thousands and thousands of lines of generated code--again with no human behind it--and building a mental model of what's happening before you can effectively work, and that process is time-consuming and exhausting.

I'm also concerned about the second-order effects. Because switching into the often-required deep mental focus is very difficult (borderline painful), I've seen many, many people reach for LLMs in those moments instead, first a little, then entirely. I've watched people copy/paste API docs into Gemini prompts to explain them. I've watched people unable to find syntax errors in code and paste it into ChatGPT to fix it. I'm confident I'm not the only person who's observed this, and it's a little maddening it's not getting more play.

---

I'm not saying SWEs don't fail in similar ways. I've approved--and authored--human PRs that had insidious flaws with real consequences. I've been asked to "review" PRs pre-ChatGPT that were 10x the size they needed to be. I've seen people plagiarize code, or just copy/paste Stack Overflow constantly. The difference is we build process around these risks, everything from coding patterns, PR size limits, type systems, firing people, borderline ludicrous amounts of unit tests, CI/CD, design docs, staging environments, red/green deploys, QA lists, etc.

I hate all of it! It's a constant reminder of my flaws and it slows down mean time to dopamine squirt of released code. I'd be the first person to give all this shit the axe. I would love to point Claude at the crushingly long list of PRs I have to review. But I can't, because it still has huge, huge flaws. Code review bots miss obvious problems, and they don't have enough context/knowledge about the system/bug/feature to perform a sufficiently comprehensive review. It would be a net time waste because we'd then have to fix a bug in prod or revise an already-deployed feature/fix--things I like even less than code review, if you can believe it.

These models cannot adequately replace humans in other parts of the SDLC. But, because pesky things like design and code review cap codegen models' velocity, our industry is "rethinking" it all, with no consideration of the models' flaws; "rethinking" here meaning "we're considering having an LLM handle all our code review, or not doing it at all". The only way to describe that is reckless disregard. It's unprofessional and unethical.

So, I think my grief isn't about "the craft". I don't think that's gone and I don't think I'd care if it were. My grief is about the humiliation of our profession, the annihilation of our standards and the betrayal of any representation we made to our users--indeed to ourselves. We deserve software systems that do what they say they do, and up until recently I really thought we were working hard to get there. I don't think that anymore; like many other things in our era (community, truth, curiosity, generosity, trust, learning, rationality, practice, compassion) it has retreated in the face of some flavor of self-interested, shallow grift. I really don't know how or why this happened, but regardless of the cause we truly are in a dark time.

Eh, it also feels like a classic "maybe we somehow have enough perspective on this watershed moment while it's happening to explain it with a simplistic dichotomy". Even this piece interrogates the feeling of "loss" and teases out multiple aspects to it, but settles on a tl;dr of "yep, dichotomy". There's more axes here too, where that feeling can depend on what you're building, who you're building it with, time and position in your career, etc etc.

(I'll admit, though, that this also smells to me a bit too much like introvert/extrovert, or INTP/INTJ/etc so maybe I'm being reflexively rejective)

> The web was objectively awful as a technology

I, for one, remember when I could crash Netscape Navigator by using CSS too hard (i.e. at all) or trying to make a thing move 10px with DHTML. But I kept trying to make browser to thing.

The divide was never invisible and there has always been at least three camps.

The "make-it-go" people couldn't make anything go back then either. They build ridiculous unmaintainable code with or without AI. Since they are cowboys that don't know what they're doing, they play the blame game and kiss a ton of ass.

The "craft-lovers" got in the way just as much with their endless yak shaving. They now embrace AI because they were just using "craft" as an excuse for why they didn't know what they were doing. They might be slightly more productive now only because they can argue with themselves instead of the rest of the team.

The more experienced and pragmatic people have always been forced to pick up the slack. If they have a say, they will keep scope narrow for the other two groups so they don't cause much damage. Their use of AI is largely limited to google searches like it always was.

I strongly disagree. There's always been two camps ... on everything!

Emacs vs. vi. Command-line editor vs. IDE. IntelliJ vs. VS Code. I could do like twenty more of these: dev teams have always split on technology choices.

But, all of those were rational separations. Emacs and vi, IntelliJ and VS Code ... they're all viable options, so they boil down to subjective preference. By definition, anything subjective will vary between different humans.

What makes AI different to me is the fear. Nobody decided not to use emacs because they were afraid it was going to take their job ... but a huge portion of the anti-AI crowd is motivated by irrational fear, related to that concern.

> AI doesn’t help me with these. At least not much. Mostly because the time I spend coding is time I spend understanding, diagnosing, and perfecting. Not the code. The product.

It can actually help a lot here too.

In fact I rarely have AI author or edit code, but I have it all time researching, finding edge cases I didn't think about, digging into dependencies code, finding ideas or alternative approaches. My usage is 90% of the time assisting with information gathering, criticizing (I have multiple reviewer skills with different personas, and I have multiple LLMs run them), refining, reviewing.

Even when it comes to product stuff, many of my clients have complicated business logic. Talking multi-tenant-company warehouse software where each process is drastically different and complexity balloons fast even for a single one of them. It helps to connect the dots between different sources of information (old Jira task, discord dumps, confluence, codebase, etc).

And it can iteratively test and find edge cases in applications too, same as you would do manually by taking control of the browser and testing the most uncommon paths.

I would do much less without this assistance.

I really don't get why people focus so much on the least empowering part (code), where it actually tends to balloon complexity quick or overwhelm you with so much content and edits that you can't have the energy to follow while maintaining quality.

> Coding is not the bottleneck to produce a qualify product.

I've been saying this too. The 10x engineer stuff simply cannot make sense unless previously you were spending 90%+ of your day just writing coding and now that's dropped to single digits because AI can generate it. If you spent 20-30% of your day coding before and the rest thinking about the problem, thinking about good UX, etc, then AI coding assistances mathematically cannot make you a 10x engineer. At a push they might make you a 2x engineer.

Given this I think I realised something earlier about my own output... I'm probably just a unusually good coder. I've been doing this since I was a kid so writing and reading code is basically second nature to me. When I was a young teen I would literally take my laptop on holiday with me just so I could write code - I was just that kind of person.

So I've basically always been the strongest or one of the strongest coders on any team I've been on. I very rarely have to think about how to do something in code. It's hard to think back to a time when code was a significant bottleneck for me.

However, my output was never really faster than anyone else when it come to shipping, but the quality of my output has always been wayyy higher. And I think that was because I always spent a lot more time thinking and iterating to get the best result, while other people I work with spent far more time writing code and just trying to get something they could PR.

My problem now is that the people I work, some of whom can't even read code, are able to spit out thousands of lines of code a day. So this forcing me to cut corners just to keep up with the rest of the team.

6-12 months ago I'd get at least 2-3 calls a day from people on my team asking for help to write some code. Now they just ask the AI. I haven't had someone ask me a coding related question in months at this point.

I find this frustrating to be honest. I'm seeing bad decisions everywhere in the code. For example, often a change is hard because it's a bad idea. Perhaps a page on a website doesn't really look great on mobile or desktop. Previously you would have had to think about how you could come up with a good responsive design and implement the right breakpoints. But now people can just ask Claude Code to build a completely different page for mobile, so they do. For a human that would be a huge effort, even if someone who stupid enough to think that was a good idea they probably be forced to do something thats easier to maintain and implement, but an AI? Who cares. It works. The AI isn't going to tell you no.

I know the quality of code is dropping. I see the random bugs from people clearly not understanding what Claude is writing, but if they can just ask the AI to fix it, does it even matter?

> All of those things does boost my productivity I think, but maybe somewhere in the order of 10% all in.

I'm very much like you. AI doesn't really boost my productivity at all but that's because I care about what I build and don't find coding hard. So AI doesn't really offer me anything. All it's doing is making people who don't care what their building and don't care about the quality of their code more productive. And putting me under pressure to trade quality for velocity.

> I like woodworking because I like building something that never existed before. I don’t mind using a CNC router or a 3 printer to help me out. I don’t care about the process, I care about the result. But I care deeply about the quality of the result.

Why not outsource it to someone else? That way you do none of the work.

You seem to be conflating code quality with product integrity.

All those problems are caused by business decisions, not the developers. You do make a good point though that AI may enable more people to build their own when they can.

You do realize that AI seems magical because text response is converted into actions or tool calls. The AI is deciding the order in which the tools get called to fulfill your prompts. True Intelligence of Type 2 and 3 above needs to formulate, plan, analyse tradeoffs, think critically and solve novel unforeseen problems.

you may notice tbat the same people benefit from 1 and 2 and 3 is just a fantasy sold to the plebs to detract attention from 1 and 2

what a councidence

True, there are people who are good with people. And they should totally become managers.

But there are also the third kind: who like to design the systems and let them be built by someone else..

> I was afraid the puzzle-solving was over. But it wasn't—it just moved up a level.

The craft can move up a level too. You still can make decisions about the implementation, which algorithms to use, how to combine them, how and what to test -- essentially crafting the system at a higher level. In a similar sense, we lost the hand-crafting of assembly code as compilers took over, and now we're losing the crafting of classes and algorithms to some extent, but we still craft the system -- what and how it does its thing, and most importantly, why.

And contribute your changes back upstream, right?

You don't need AI for this, we've had search engines and good online resources for decades

> Craft lovers can still lovingly craft away, even if they have to do it on their own time instead of on their now-AI-dominated day job, just like in ye olde days. Nothing's stopping them.

…except time, which sadly is limited. I’m sad about the real potential that I might not get to be paid to do something I enjoy so much anymore. I care about end products for sure, but that’s not why I’m in this career.

I do this because a large part of the work engages me in a pleasant way. I like TDDing in a tight loop. I like how it forces me to think one step at a time, how I get to stop myself from jumping ahead, and how I get to verify my thoughts or theories within seconds. I find efficiently manipulating text in my editor satisfying. I love the feeling of being validated that my architectural choice was right when a spec changes and the required code change is obvious, minimal, and clearly expressed. I enjoy the feeling of obtaining mastery for mastery’s sake rather than because it lets me create a product.

I’ve felt incredibly lucky for over a decade that my work gave me the opportunity to chase that. I may find enjoyment in wrangling AI, but I’m skeptical it’ll scratch that itch. If it doesn’t and I wanted to still scratch it, I’d have to do it on my own time. That would mean sacrificing time I’ve previously spent on other interests, and I don’t have a ton of time to begin with.

all this so people like us can do a job that wasn't that hard to begin with and was actually very comfortable all things considered, just a tiny bit easier in a way that isn't even measurable.

Yep it's not 'result chasers' but people who want to get credit while avoiding real work. And when their stuff breaks they are always too busy with something else or moved on to another project.

Could you please not create an account for every few comments you post? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...

This better matches my experiences and feelings than the divide which the author discusses. The craft is in the entire building, not specifically the coding aspects. I want to do a great job building a house, and if AI helps or even completes some aspects while meeting standards that's awesome. The problem is it hasn't yet shown it can be trusted as a sub trade, and we've got people outsourcing the entire project to an army of agents. The result looks a lot like the condo I bought a few years ago.

"Left behind" in terms of speed or are there other aspects that people are missing out on?

The average person can't afford the materials to build an SR 71 but they can afford a pencil case.

> I am enjoying crafting really good requirements documents.

Can you please come train the product people at my job? Maybe some of your love of the game will rub off on them.

Isn't the question really about what you can get paid for, have as your job?

People want to keep doing what they enjoy as their fulltime profession, making a (good) living out of it. Perfectly understandable. But neither AI, powertools or image generation is preventing someone from doing craft coding, hand woodworking or drawing/painting in their spare time and enjoying it.

I love drawing but since it went out of business as a viable career long before I was born I have never felt the grief of losing it. With craft coding we happen to exist at the point in time where it suddenly gets significantly de-crafted.

Your generalization are as useful as me saying that people in the first camp are just sloppy workers who dump their subpar code on others in hope that they’ll never need to touch it again.

Sure, I ran the post past an LLM for some ideas on clarity and tightening it up - but I wrote, edited, and published it myself.

Am I the only one who comes to the comments first to see if the blog/article is even worth reading?

What happens when providers achieve AGI, as they claim, and then use what they've learned from your company's prompts, context, memory and outputs to put you out of business

Even without AGI, that internal source code, data and trade secrets are valuable on their own. Would suck if someone capitalized on it

Well, yeah, that's what a lot of folks are sad about - they can't practice the craft concurrently with the livelihood quite as much. But if you don't have a livelihood, you probably don't have as much space for craft at all.

> Since then the world has changed. Everything I touch has AI built in. And it's really good.

Clearly you don’t use Amazon’s Alexa.

I agree some people go to work to work, and claude is find / good for them, but I feel that characterization of us who are loving claude is disingenuous. I’m a creative, while I loved coding and honed my craft, it was creating that always had me hooked. Claude is creating on steroids. Not to mention, it can help you massively improve your code cleanliness. All of the little nice-to-have features, the cleanups, the high unit test coverage, nagging bug fixes, etc., they’re all trivial to do now.

It’s not the same as writing code, but it’s fun.

If your coworkers can’t outpace your code output they’re either not using opus4.6 or they aren’t really trying.

It’s pretty easy to slam 20 PRs a day with some of them being complex changes. The hardest part is testing the diffs, but people are figuring that out too.

Your AI can rewrite it to your own standards for free.

You can tell your AI to read their code, and create a new requirements document for a clean-room implementation.

Then you have your AI implement using your own requirements document.

Completely agree. This is the framing people use to cope with their moral and psychological failure. Using tools that are literally scorching the earth just so they don’t have to use their brains anymore.

100% with you. I start a new job on Monday and I intend to keep building great young engineers who love their craft and their community. Enough of this vampiric unethical horse manure.

You're using it as a 'super compiler', effectively a code generator and your .md file is the new abstraction level at which you code.

But there is a price to pay: the code that you generate is not the code that you understand and when things go pear shaped you will find that that deterministic element that made compilers so successful is missing from code generated from specs dumped into an AI. If you one-shot it you will find that the next time you do this your code may come out quite different if it isn't a model that you maintain. It may contain new bugs or revive old ones. It may eliminate chunks of the code and you'll never know and so on.

There is a reason that generated code always had a bit of a smell to it and AI generated code is no different. How much time do you spend on verifying that it actually does what's written on the tin?

Do you write your own tests? Do you let the AI write the tests and the code? Are you familiar with the degree to which AIs can be manipulated to do stuff that you thought they weren't supposed to? (A friend of mine just proved this to his boss by bribing an AI with a 'nice batch of pure random data' to put a piece of unreviewed code into production by giving itself the privileges required to do so...)

You are building a system that has a shaky mental model and which may or may not adhere to the *.md files.

> I write *.md files that other devs are using, that we're using as guardrails, that ensures that we minimize the slop while increasing speed and basically lift every developers level up by several notches.

> > among the highest level ICs in my org.

Checks out. Real straight shooter with upper management written all over him.

Came here to say something similar. For me, the craft aspect is now even more exciting because I can craft more ambitious things without getting bogged down in the details. For me, refining my conceptual model, drawing diagrams, finding the right way to think about something was the craft.

Maybe that's another way of saying: I was trained as a designer, and now the distinction between design (read: architecture, service-design, product, ux, cx) and programming is blurring.

> I feel like this is really about how your identify is tied up in what you do.

This is it for me. One thing that's important to my identify making things. And I have a lot of trouble saying I made a thing that I asked someone (or something) else to make for me.

I know you're going to say, "But I'm making things, too!" However...

I could crank out a project a day with Claude Code and slap them all up on GitHub for my green squares, and I could say that I made them all.

Just like I could crank out a novel a day with ChatGPT and say that I made them all.

Or I could use it to write 100 blog posts a day and say that I made them all.

In all those cases, I caused things to get made. But did I make them? I don't feel like I can honestly say I did. (And the copyright office is starting to have a thing or two to say about it, as well.)

This is what I struggle with. I like making things.

As a capitalist, sure, your cash is good with me. Tell me where to shoot and I'll shoot. But in terms of keeping my soul fed, it's a tough one.

> If we end up in a place where the craft truly is dead, then congratulations, your value probably just dropped to zero

I think, then that the value of all knowledge work will have dropped to zero. Software engineering is, to my mind, “intelligence complete.” If you can do it with knowledge work, you can have software do it.

> If we end up in a place where the craft truly is dead, then congratulations, your value probably just dropped to zero

I think the craft is going to die and am not thrilled about it. I dont feel like there is a contradiction there

The beginnings of that sustainable approach is already out there: https://boristane.com/blog/how-i-use-claude-code/

These bear related sayings always make me laugh. The one I was told by a Russian: “don’t argue over how to skin the bear before you’ve killed it”

A couple of guys at work have been raving about Claude. How quick they get stuff done, how great the code is, how working any other way is a waste of time.

I just had the misfortune today to wade into one of their codebases. It's 60k lines of code for something that should have been simple, and it's an absolute fucking mess. I'm gonna have to rip out most of it and start over just to get it to do what we actually need it to do.

I use LLMs, they come in handy, and I use agents, but this "have agents do everything" nonsense is a disaster, and it's only going to get worse.

On the upside I'm getting paid to fix this shit show.

>This is going to blow up.

We are way past wringing our hands over agentic engineering. Every startup and all fast moving companies are onboard. They don't hand code anymore. There will not be some code quality crisis that will stop everyone in their tracks. I'm trying to cope with this too, but I don't think the best path is praying for failure.

I was still skeptical at the start of this year, but there seems to be a shift underway. Found the StrongDM Dark Factory docs in Feb and they've netted novel results that have been inspiring enough to keep studying and practicing.

https://factory.strongdm.ai/techniques

https://factory.strongdm.ai/products/attractor

If you've found better or ancillary resources, please share.

Yeah. We’re seeing a lot of posts from people dealing with their emotions about AI, and trying to rationalize those emotions. Blaming a straw-manned group of other people who supposedly don’t share some quality the author values is an easy way to do that rationalization. The reductively binary classification is a sign that they’re indulging in something other than a serious analysis.

It's different, but it isn't completely different. That's one reason why it's hard to make sense of this change.

Now about the grief angle. This is AI Inevitability Soothsaying.[1]

It’s all just a backdrop for hammering home the same inevitabilism: GenAI, GenAI, GenAI. Just slap on whatever excuse to hammer this over, and over, and over. Grief, self-identity, some other pseudo-humanistic angle.

Now is the time that programmers talk about their feelings. Give me a break.

Because the AI hype machine isn’t content with just eventually taking your job or your craft. It can’t just quietly get exponentially better until it sweeps your legs effortlessly. No, because there’s also a market out there, and a hype needs to be built. So now you need to see it all day in your tech news aggregator. Just push all the interesting stuff out. Replace with autopilot.

No, really. Even if AI worked perfectly right now you would still need to have a constant churn of content about how to babysit this thing that speaks English already and is more capable than you. I guess it’s kind of paradoxical.

[1] https://news.ycombinator.com/item?id=46935607

Weird you got downvoted for that. This is exactly the thing which has been bothering me about all of this.

Pre-LLM there are paid products and licenced stuff, but for the most part you could code in any language using free or community edition IDE's and mostly open toolchains. The total requirement for me as an individual to start using some language or stack is owning a computer and having internet access. Both provided by a stable market with consumer choice.

Post-LLM there is now this blackbox of a service which you depend on and for which someone is picking up a not-insignificant tab where the costs currently seem massively subsidised, and which is getting to be a requirement for your skill set. Open local models? Fine, but who is training them? How will those stay up-to-date?

Oh, and then there is the not-quite-insignificant ecological aspect and that bit where the powers-that-be seem to have collectively decided that copyright doesn't really apply here.

Submitted title was "The AI coding divide: craft lovers vs. result chasers" - which does seem to be a fair statement of what the article is about, and in that sense not so biased.

We've reverted the title to be that of the article now, though, in keeping with the site guidelines, since it was neither misleading nor linkbaity.

https://news.ycombinator.com/newsguidelines.html

Which bits? And don't say the em-dashes because I've been over-using them since high school