> Before AI, both camps were doing the same thing every day. Writing code by hand. Using the same editors, the same languages, the same pull request workflows. The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable. The motivation behind the work was invisible because the process was identical.
Helps explain why some people are delighted to have AI write code for them while others are unhappy that the part they enjoyed so much has been greatly reduced.
> That feeling of loss though can be hard to understand emotionally for people my age who entered tech because we were addicted to feeling of agency it gave us. The web was objectively awful as a technology, and genuinely amazing, and nobody got into it because programming in Perl was somehow aesthetically delightful.
"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.
> 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);
Which is sure, identical function-wise to:
if (!$skip_frobnicating) frobnicate();
But is arguably a bit nicer to read. The first way you're laying out the normal flow of the program first of all, and then tacking on a "we can skip this if we're in a rare special mode" afterwards. Used judiciously I do think there's a certain something in it.
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.
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,...
For instance, the ones that look at it from an economics perspective, security perspective, long term maintainability perspective and so on. For each of these there are pros and cons.
I'm a 23+ year dev; among the highest level ICs in my org.
It's still craft, its just that the craft is different. I don't write *.ts, *.cs files anymore; 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.
I went from building one kind of framework/platform level artifact to another type of framework/platform level artifact.
If one's perspective is that it's just a shift in what "craft" means, then it's still craft. I'm still building systems; just a different kind of system.
> 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.
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...
Lots of mentions of the term mourning... As they say in my country, don't sell the skin until you kill the bear.
All I'm seeing around me is people dropping best practices in a FOMO driven push for speed: let's stop reviews, let's drive 5 agents in parallel, let's not even look at the code!
This is going to blow up.
Only after we pick up the remains we'll find a more sustainable approach for AI usage. I suspect that version will still require crafters.
If we end up in a place where the craft truly is dead, then congratulations, your value probably just dropped to zero. Everyone who's been around startup culture knows the running jokes about those 'I have a great idea, I just need someone to code it' guys. Now you're one, and you'll find how much ideas are worth.
I'm a bit in the middle. I enjoy the craft but I also seek and enjoy the result.
The thing about AI is that you don't have to use it for everything. Like any other tool you can use it as much as you'd like. Even though I like the craft, I find myself really enjoying the use of AI to do things like boilerplate code and simple tests. I hate crafting verbose grunt work, so I have AI do that. This in turn leaves me more time to do the interesting work.
I also enjoy using AI to audit, look for bugs, brainstorm, and iterate on ideas. When an idea is solid and fleshed out I'll craft the hard and interesting parts and AI-generate the boring parts.
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.
I think it's more granular than this, though. I also like to "make computer do thing" and have enjoyed using AI. But I also like building systems, optimizing systems. I find AI is a great partner in that. I can churn out prototypes more quickly, iterate on them more quickly etc. That also applies intra-system level. I might have a theory about how a different data structure or caching layer will affect application performance. It's now so much faster to test those kind of theories, and actually building good scaffolding around them to test them scientifically.
Yes, sometimes I can also ask AI to evaluate things at the system level and it often has surprisingly good insights, but that is usually a collaboration where our powers combined comes up with a better solution. I enjoy that process, too.
I do sympathize with the people "in mourning". I feel like this is really about how your identify is tied up in what you do. I have generally identified as a command line wizard. The xkcd of the guy flying in with "perl" very much speaks to me. But AI absolutely crushes at this. It's not that useful a skill anymore. Now I identify more as a local AI expert instead :D
You can use gen AI entirely in the spirit of craft. For instance if you need to consume, implement or extend some open source software you can load it up in an agent IDE and ask “How do I?” questions or “how is it that?” questions that put you on a firm footing.
Yes but the lords are not satisfied with this. They demand the 10x productivity they sold to investors. If you do it this way you will not produce 10x the code.
Every little minor dispute can be split into some arbitrary dichotomy which is vaguely defensible. Not interesting.
Twelve years ago I would have the bright idea of why not make a little, just a tiny little (what I would call now) preprocessor for Java which does the same thing in less characters and is clearer. Everyone would love it. Of course no one loved it. Well, I never implemented it. Because I got some sense: you can’t just make tiny little preprocessors, a little code generation here and there, just code-generate this and tweak after the fact. Right? It’s not principled.
You can cook up a dichotomy. Good for you. I think the approach is just space age technology meets Stone Age mindset. It’s Flintstone Engineering. It’s barely even serious.
I am not offended that you took my craft. I am offended that you smear paint on the wall with three hundred parallel walls and painters and pick the best one. Or whatever Rube Setup is the thing that will take over the world as of thirty minutes ago.
Make something rock solid like formal verification with LLM assist (or LLM with formal verification assist?). Something that a “human” can understand (at this point maybe only the CEO is left). Something that is understandable, deterministic.
I might be out of a job. But I will not be offended. And I will respect it.
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.
I'm a craft lover but I like using the Ai for tedious tasks. Just today it tracked down a library conflict in a pom that from experience would have taken a day of trial and error.
I think there are far fewer developers who reject it for search tasks, like the one you describe, than those who reject it for (production-)code generation tasks.
The important thing to remember is that for a large number of people (in the US), "work" is a place where they do things that they hate for eight hours a day, for people they hate (surveys routinely show between 40% and 60% of people are "satisfied" with their jobs). Those of us who are in the tech industry because we like actually programming computers (the "craft-lovers", in the parlance of this blog post) have been lucky enough to have jobs where where we get to actually do something we enjoy (even if it's intermingled with meetings and JIRA). If AI slop really is the future and programming becomes as rare of a job as hand-building wood furniture, then most of us are going to be living the normal experience of capitalism in a way that we are probably not well-prepared for.
Personally, I have noticed that I still produce substantially more and better code than the people at my company spending all day writing prompts, so I'm not too worried yet, but it seems plausible at some point that a machine that stole every piece of software ever written will be able to reliably turn a few hundred watt-hours of of electricity into a hallucination-free PR.
People who say directing an AI is just "moving up another level of abstraction" are missing the point that it's a completely different kind of work. Everything from machine code to Haskell is a predictable deductive logical system, whereas AIs are not.
I am enjoying crafting really good requirements documents. I use an iterative process. The implementation is the test of the requirements document. If it's not right, I adjust the doc, discard that implementation, and try again.
I’ve heard this thesis a lot, but it’s almost always from the result chasers.
It doesn’t resonate with me because I am a result chaser. 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.
I don’t care about the beauty of the code, but I do care that nearly every app I load takes longer than it did 15 years ago. I do care that my HomePod tells my wife it’s having trouble connecting to iPhone every 5th time she adds something to the grocery list. I care that my brokerage website is so broken that I actually had to call tech support who told me that they know it’s broken and you have to add a parameter to go back to the old version to get it to work.
I care that when I use the Claude desktop app it sometimes gives me a pop up with buttons that I can’t click on.
I’ve used Claude and Cursor enough to have what I think are valid opinions on AI assisted coding. Coding is not the bottleneck to produce a qualify product. Understanding the problem is the biggest bottleneck. Knowing what to build and what not to build. The next big one is convincing everyone around you of that (sometime this takes even more time). After that, it’s obsessively spending time iterating on something until it’s flawless. Sometimes that’s tweaking an easing value until the animation feels just right. Sometimes that’s obsessing over performance, and sometimes it’s freezing progress until you can make the existing app bulletproof.
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 does help crank out one off tools. It does help me work in unfamiliar code bases, or code bases where for whatever reason I care more about velocity than quality. It helps me with search. It helps me rubber duck.
All of those things does boost my productivity I think, but maybe somewhere in the order of 10% all in.
> 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.
Brilliant engineers, among the best software craftsmen out there are using AI daily and speeding up their processes.
The author of Redis, antirez, stated a month ago he spent 2 weeks on Redis tinkering with LLMs...and it was just design phase, not a single line of code was authored. The ability to interrogate LLMs and have them criticize his ideas and edge cases sped up his process by month.
He also used LLMs successfully to find multiple issues in Redis that would've took him longer to do without.
I myself spend with AI way more time tinkering and gathering information than authoring code.
Am I a craft lover or a result chaser?
But sure, let's keep everything in the divide conservative vs liberal, black and white, craftsman vs vibe coder...give me a break..
94 comments
[ 2.6 ms ] story [ 90.8 ms ] thread> Before AI, both camps were doing the same thing every day. Writing code by hand. Using the same editors, the same languages, the same pull request workflows. The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable. The motivation behind the work was invisible because the process was identical.
Helps explain why some people are delighted to have AI write code for them while others are unhappy that the part they enjoyed so much has been greatly reduced.
Similar note from Kellan (a clear member of the make-it-go group) in https://laughingmeme.org/2026/02/09/code-has-always-been-the... :
> That feeling of loss though can be hard to understand emotionally for people my age who entered tech because we were addicted to feeling of agency it gave us. The web was objectively awful as a technology, and genuinely amazing, and nobody got into it because programming in Perl was somehow aesthetically delightful.
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.
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:
Which is sure, identical function-wise to: But is arguably a bit nicer to read. The first way you're laying out the normal flow of the program first of all, and then tacking on a "we can skip this if we're in a rare special mode" afterwards. Used judiciously I do think there's a certain something in it.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.
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,...
For instance, the ones that look at it from an economics perspective, security perspective, long term maintainability perspective and so on. For each of these there are pros and cons.
I'm a 23+ year dev; among the highest level ICs in my org.
It's still craft, its just that the craft is different. I don't write *.ts, *.cs files anymore; 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.
I went from building one kind of framework/platform level artifact to another type of framework/platform level artifact.
If one's perspective is that it's just a shift in what "craft" means, then it's still craft. I'm still building systems; just a different kind of system.
> > among the highest level ICs in my org.
Checks out. Real straight shooter with upper management written all over him.
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...
All I'm seeing around me is people dropping best practices in a FOMO driven push for speed: let's stop reviews, let's drive 5 agents in parallel, let's not even look at the code!
This is going to blow up.
Only after we pick up the remains we'll find a more sustainable approach for AI usage. I suspect that version will still require crafters.
If we end up in a place where the craft truly is dead, then congratulations, your value probably just dropped to zero. Everyone who's been around startup culture knows the running jokes about those 'I have a great idea, I just need someone to code it' guys. Now you're one, and you'll find how much ideas are worth.
The thing about AI is that you don't have to use it for everything. Like any other tool you can use it as much as you'd like. Even though I like the craft, I find myself really enjoying the use of AI to do things like boilerplate code and simple tests. I hate crafting verbose grunt work, so I have AI do that. This in turn leaves me more time to do the interesting work.
I also enjoy using AI to audit, look for bugs, brainstorm, and iterate on ideas. When an idea is solid and fleshed out I'll craft the hard and interesting parts and AI-generate the boring parts.
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
Yes, sometimes I can also ask AI to evaluate things at the system level and it often has surprisingly good insights, but that is usually a collaboration where our powers combined comes up with a better solution. I enjoy that process, too.
I do sympathize with the people "in mourning". I feel like this is really about how your identify is tied up in what you do. I have generally identified as a command line wizard. The xkcd of the guy flying in with "perl" very much speaks to me. But AI absolutely crushes at this. It's not that useful a skill anymore. Now I identify more as a local AI expert instead :D
Twelve years ago I would have the bright idea of why not make a little, just a tiny little (what I would call now) preprocessor for Java which does the same thing in less characters and is clearer. Everyone would love it. Of course no one loved it. Well, I never implemented it. Because I got some sense: you can’t just make tiny little preprocessors, a little code generation here and there, just code-generate this and tweak after the fact. Right? It’s not principled.
You can cook up a dichotomy. Good for you. I think the approach is just space age technology meets Stone Age mindset. It’s Flintstone Engineering. It’s barely even serious.
I am not offended that you took my craft. I am offended that you smear paint on the wall with three hundred parallel walls and painters and pick the best one. Or whatever Rube Setup is the thing that will take over the world as of thirty minutes ago.
Make something rock solid like formal verification with LLM assist (or LLM with formal verification assist?). Something that a “human” can understand (at this point maybe only the CEO is left). Something that is understandable, deterministic.
I might be out of a job. But I will not be offended. And I will respect it.
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
Hell no. I, a craftsman, was going out of my way to use things like Haskell. I was very aware of the divide the entire time. The present is a relief.
Engineers be loving the craft.
It's a dance, but AI is unfortunately looking at us like we're dancing, and meanwhile it's built a factory.
Personally, I have noticed that I still produce substantially more and better code than the people at my company spending all day writing prompts, so I'm not too worried yet, but it seems plausible at some point that a machine that stole every piece of software ever written will be able to reliably turn a few hundred watt-hours of of electricity into a hallucination-free PR.
It doesn’t resonate with me because I am a result chaser. 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.
I don’t care about the beauty of the code, but I do care that nearly every app I load takes longer than it did 15 years ago. I do care that my HomePod tells my wife it’s having trouble connecting to iPhone every 5th time she adds something to the grocery list. I care that my brokerage website is so broken that I actually had to call tech support who told me that they know it’s broken and you have to add a parameter to go back to the old version to get it to work.
I care that when I use the Claude desktop app it sometimes gives me a pop up with buttons that I can’t click on.
I’ve used Claude and Cursor enough to have what I think are valid opinions on AI assisted coding. Coding is not the bottleneck to produce a qualify product. Understanding the problem is the biggest bottleneck. Knowing what to build and what not to build. The next big one is convincing everyone around you of that (sometime this takes even more time). After that, it’s obsessively spending time iterating on something until it’s flawless. Sometimes that’s tweaking an easing value until the animation feels just right. Sometimes that’s obsessing over performance, and sometimes it’s freezing progress until you can make the existing app bulletproof.
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 does help crank out one off tools. It does help me work in unfamiliar code bases, or code bases where for whatever reason I care more about velocity than quality. It helps me with search. It helps me rubber duck.
All of those things does boost my productivity I think, but maybe somewhere in the order of 10% all in.
Why not outsource it to someone else? That way you do none of the work.
Brilliant engineers, among the best software craftsmen out there are using AI daily and speeding up their processes.
The author of Redis, antirez, stated a month ago he spent 2 weeks on Redis tinkering with LLMs...and it was just design phase, not a single line of code was authored. The ability to interrogate LLMs and have them criticize his ideas and edge cases sped up his process by month.
He also used LLMs successfully to find multiple issues in Redis that would've took him longer to do without.
I myself spend with AI way more time tinkering and gathering information than authoring code.
Am I a craft lover or a result chaser?
But sure, let's keep everything in the divide conservative vs liberal, black and white, craftsman vs vibe coder...give me a break..