This is something I've been really struggling with lately. I do (and always have) at least somewhat enjoyed the actual process of writing code. Over the past few years, I've pivoted to a role that is more focused on architecture and orchestration, so for me, the shift to AI-assisted coding has likely been a bit softer than it otherwise would have been.
But I still feel like there's something missing. The satisfying "core" of the work itself is now largely automatable to the point where it feels like a waste of time to code by hand. If I can design the spec and have a robot write the code, then review and confirm it myself, and the end result is more or less exactly what I would have written in the first place, why would I choose to write it myself?
On the other hand, I spend a LOT more time now doing code review for other devs. I used to know the individual coding styles of the devs I work with. Now that nobody is writing their own code, it's all over the place.
I also miss that the development cycle used to be slower. It’s impossible to explain to management that we have bugs in production because when you spend less time writing code you also spend less time thinking about the code you’re writing. AI will only fill in the blanks so much, if you don’t tell it to cover some case, it wont, and since you didn’t have the time to think of it, you didn’t tell it to.
They think that we can just extend the planning phase and solve this issue, but every single company Ive ever worked for discovers requirements during testing. Every single one. There are things that no one thinks about until they actually try to use the feature. That is just life.
Since they’ve taken away our “play around with it” time and forced us to ship it directly to QA who then discovers requirements which then are solved by AI without thinking about how people actually use the feature that whole “gets worse before it gets better” bugfixing/testing phase ends up happening when the feature is already in production.
I enjoyed coding and solving issues with code. I've been doing this professionally for about 20 years soon. With an LLM I am certainly able to churn out more, both in terms of lines of code and actual features. I've mostly settled into validating the output of the code; not the code itself. Design and QA is taking a larger portion of my time at work. Downside is that, while it is still satisfying to ship features and improve the product, it isn't as enjoyable a craft anymore. I no longer have a deep understanding of the underlying code.
I know that, in general, I am still able to produce code at a higher level of quality than an LLM, but that doesn't matter that much to me. Something ineffable is missing now. I tend to think this is similar to how artist feel about gen ai in general. They can see the flaws produced by e.g stable diffusion, but does it diminish the sense of creating? Is the process tarnished in some way? I think it is for me.
Does it feel sort of like you'd imagine a craftsman would feel going from hand crafting furniture to watching over a factory mass producing furniture? Maybe like a stone carver would feel a loss suddenly having to use a 3D carving machine to do the same work?
You lose freedom to alter it during production, that personal touch that makes it yours. Might feel no skill was needed as the machine did it all, losing some pride in your work. You no longer get to enjoy the process of crafting as your work becomes planning and inspecting.
Not entirely. My goal when making software haven't been overly focused on the craft. I focus on solving problems. The analogy with the craftsman never sat entirely right with me. A furniture carpenter finishes a table and then that table is done. For a software developer the work is continual. Maybe more like a gardener where the garden is in a continuous flux. So a gardener that goes from tending the garden to sitting in a tower far away with binoculars and a megaphone screaming at the robots to "prune the trees and make no mistakes"... I don't know. Not great at analogies.
On the other hand, I spend a LOT more time now doing code review for other devs. I used to know the individual coding styles of the devs I work with. Now that nobody is writing their own code, it's all over the place.
In my company code review has kind of died. Most projects now have a single engineer working on them with an llm doing most of the work. We are kind of faster, but the PRs are now regularly 20k-50k lines of code each, on new codebases we know nothing about and on features we know nothing about. We tried using llms to help explain the PRs but it is a lot of effort and that is useless most of the time.
I'm sure there are lots of good teams out there that can take advantage of these tools, but I think lots of average companies / projects are going to be crushed by the weight of the technical and organizational debt llms are creating, specially when prizes get corrected and you can't just tell them to "fix it" at a reasonable cost.
When I read about something like that, I wonder what kind of software you are running in what business - if I may ask? Because I am sort of in charge of the codebase for a smaller company in the saas business. We are about 40 people and I would be terrified to run it like that, as that would risk the livelihood of all employees if our service broke down for our customers if something hit production that only an LLM has looked at and understood. Any sort of breaking change or longer disruption could kill us quickly. So I have been extremely defensive with things that go to production and AI isn’t really speeding things much as pure code speed isn’t exactly the bottleneck. Are these setups where entire companies run on pure AI development just in less risky areas or larger organizations where code doesn’t hit production that easily? Or is it just greenfield projects and not on top of 10-20 years of legacy with risk of breaking things for existing customers?
Kind of niche B2B stuff. We luckily do not have lots of operational complexity so things are working out fine. We were already working on smaller teams in greenfield(ish) projects. We are just kind of pushing harder and harder in that direction.
I'm kind of venting at this point, but I kind of fear that LLMs are eroding engineering culture in general. It is like we got this new rockstar hire that takes over the company because he works so fast and is always saying the right thing to his managers, but in reality is doing a mediocre job. And now the rest of the team have both the expectation of being as fast as him and fixing all the shortcuts he is taking.
So does anyone actually understand your current codebases? I feel like that's the direction we're headed as well, but I'm catching major issues during review on a semi-regular basis (I should be clear that I do use Claude during my reviews, but I also generally run through the same manual review process I've done for years). I think it would be a disaster for us if the traditional code review went away completely.
I'm lucky in the sense that many of the projects I'm working on are small enough for me to basically be able to hold the whole thing in my head at once. I can't imagine this no-review vibecoding ending well for larger projects.
For the more complex projects we still have several people in the loop but the newer projects have as little people as possible, usually 1-2 engineers working on different areas, with little to no overlap. It is actually kind of hard to argue against this setup now. LLMs are very local to the current task and do not wait to chat with your colleagues LLM sessions to agree on architectural decisions and redoing work is common.
I also use Claude for reviews. It works OK for the most part, but has a tendency to rise issues and then retract them when you ask for more details. My stack is not super common and it probably does not help either.
We do, actually, but spec languages like gherkin are very verbose so you end up generating the specs anyway.
It is hard to justify putting effort in things that the agents can do, even if agents absolutely need this extra effort in testing / specs to work properly.
For me, writing code is an exercise in hands-on puzzle solving using an intersection of math and imagination. You have to mentally parse the data, guess how the computer is going to interpret it, then iterate on the pattern until you achieve the results you were looking for.
Architecture is its own kind of puzzle solving, but it’s less immediate than the problems you encounter coding. You’re laying out the structure of the code before you type a single line. You’re solving a meta problem and breaking it into smaller tasks.
Both are very much like being handed a bucket of LEGO and being told what your end product needs to be, but architecture is making the design documentation of where the bricks will go (thus ending up with instructions that anyone can follow) and programming is assembling the bricks to build the thing itself.
Both valid, both important, both benefit from having the other.
It also closely mirrors my experience with writing fiction prose: there are “two” types of writers we’re told, plotters and pantsers. Plotters are like architects, who carefully lay out a design document before they write the first word of the story. Pantsers start writing and discover the story as they go. The secret is that they’re both going to end up revising things as they discover the story. The plotter is going to discover the story as they go to write, and the pantser is going to discover the structure as they go to revise.
Current LLMs can be somewhat useful tools in the hands of someone who already knows what they are doing. I am not convinced this tool will ever be able to create novel code autonomously or used by someone who does not understand programming.
There will always be place for someone who understands what the code does and who is able to translate user requirements into the needed structure. And understanding that code will require engagement comparable to writing it by hand.
Unless of course there ceases to be any requirements for quality, maintainability and security and everyone just accepts that all sw breaks frequently in highly visible ways and will never be truly fixed but hotfixed on an ongoing basis. Or we achieve AGI.
Totally agree. To me, it's sort of like the process of learning math in grade school. As a kid, you can just sit there and think "but why do I need to know this when I can just use calculator". Sure, the calculator can do it for you, but you need a foundational understanding to have any clue what's going on in the more complex math.
Except in the case of AI, the 'calculator' constantly makes mistakes, lies to you, and literally makes stuff up that doesn't exist. So if you don't know what you're doing, you're going to end up with really poor results.
I think it will be sort of like writing poetry or making crossword puzzles - something you do for fun, with the expectation that other people will read the source code because there’s something interesting about it, not just run the program.
I really dislike this modern likening of non-vibe coded software to assembler because the gap is much much wider. A C compiler will not forget to leave an admin user misconfigured on a server or something.
Which mind you, I'm not claiming that LLMs are useless, I just think even the best agents are not as good at being autonomous as they're trying to sell them.
IMO it could be instructive to see how folks perceive handwriting assembler, or the micro-optimizations necessary to eek out a few percentage points of perf from archaic hardware (e.g. game consoles and the like)? Since paying that level of attention to your code has been considered largely pointless in the modern era where throwing more hardware at the problem is economically optimal 99.9% of the time. The last forty to fifty years have seen a downwards trend in attention paid to the nuts and bolts of the software actually being written, with I think the sharpest decline happening in the last few years.
So, that in mind, and given my observed appreciation of others towards said code, I'd assume that people will find it a little sad/kind of inspiring that people could even work that way, before feeding it into slopzilla to churn out v3 of your old software code (statistically, in Rust). We haven't really cared about the code in software for ages, and I doubt folks will start now that it has become even more devalued (see also: visual arts).
(sorry for my pessimism ... I'm not a huge fan of how the industry prepared for this, responded to it, and what it figures will be the future)
This has always been how I’ve expected things to go too. I love the craftsmanship and sheer dedication that made Rollercoaster Tycoon happen, I love older stories about physically mapping drum memory for efficiency, and I love seeing people find techniques to squeeze ever more complex feats out of vintage hardware*.
But I can’t pretend that compilers and garbage collectors and even electron apps were a bad idea when it comes to getting shit done, even if they can be easy to misuse and facilitate a lot of slop. Same goes for coding agents, but as with many things in our thin-end-of-the-singularity cyberpunk dystopia, it goes faster and more extreme now, for better and for worse.
*Side note: why do so few people seem to notice the insane quality of ultra-specialist hardware and software work going on in the retro gaming community? These people have the skills to run rings around some of the most highly paid engineers on the planet, and they’re investing thousands of hours into random niche projects for the literal love of the game. I want every tech executive looking at a huge flashing neon sign that just says “where’s your capitalism now?” and points to some dude in a basement engineering an entire motherboard single-handedly. Anyway…
I came here to say something like your comment but not quite.
I also have the comparison to assembly and low level languages in mind but I think I see it a little differently.
As time as gone on new tools and languages have been created and widely adopted, yes as hardware has improved too.
We had a step change where developers were once writing op codes and along came C and other low level languages. A time saver and devs could do more with less. People 100% complained at the time that it was better to write in assembly than C.
Since then we've had higher level languages, source control, IDEs and intellisense. Does no one remember when intellisense first dropped and every developer thought they'd get lazy and forget how to code?
I think AI is just another tool in the chain. We might end up writing less code, maybe no code? A developers job will change, even slightly, as the tools are useful.
My personal opinion is they are much more effective at non-coding tasks, but the right person can steer AI to write reasonable code, and it should get better and cheaper at it as time goes on.
Some developers will quit, because they won't want to use the new tools. Most will just adapt and live with the new way of working.
I think, eventually, writing an application end to end with no AI input will be either:
Passion project, like the low file size games you see, or people experimenting and having fun. I suppose you'd call this artisanal in the development world
Contractors and consultants offering a "human first" service for a stupid price and actually getting companies to hire them based off some marketing bullshit
I don’t think that LLMs are another tool in the chain.
The way I do my job has fundamentally changed.
Its more similar to using those giant textile machines vs a loom. It’s a whole industrial revolution.
It’s not a better product. It’s not even easier to use. It just mass produces mid quality shit so fast you have no time to even wonder why we’re doing this. Most clothes end up in the trash and most software rots in a github repo, never even seeing production.
Thanks, I have good days and bad days. I’m very fortunate to still be making crazy money and I’m saving everything I can cause I know I’ll be unemployed in maybe five years when the business decides they can just write features by themselves since it doesn’t actually matter if any of it ever gets used by a customer.
I have several backup plans, and each of them sound like way more fun than what Im doing, just for less money, so I’ll be okay.
AI creates 100% of my code now. I haven't written or edited a line of code in months.
but they also point out that:
Professionally I'm sitting at around $4k/month (~$50k/year), almost all of it on Claude Opus.
Personally I'm closer to $200/month on the Max 20x plan, but I don't push my AI nearly as hard at home as I do at work (largely cause I'm at work, not working on personal projects every day).
$200-4k a month is NOT nothing, especially PER PERSON on a team. Tell me I can spend $50k more per person on salary and I'll get you a fuckload of results as well, and this is still probably a subsidized cost.
I don't doubt that AI is going to be a tool used for all code going forward, but there's still going to be a lot of handwritten stuff.
There will be a collapse of "uniqueness" as coding will help people settle on a similar style, but that's 99% a good thing, and I have 0 doubt I'm still going to crack open billion dollar company production code and see an IF statements that run identical code on each branch.
I dont use nearly that amount at work and I also hardly write code. Theres several ways to save on tokens. You can use a cheaper model, lower your context window, swap between expensive and cheap models depending on what you’re doing, etc.
Gourd | a day ago
This is something I've been really struggling with lately. I do (and always have) at least somewhat enjoyed the actual process of writing code. Over the past few years, I've pivoted to a role that is more focused on architecture and orchestration, so for me, the shift to AI-assisted coding has likely been a bit softer than it otherwise would have been.
But I still feel like there's something missing. The satisfying "core" of the work itself is now largely automatable to the point where it feels like a waste of time to code by hand. If I can design the spec and have a robot write the code, then review and confirm it myself, and the end result is more or less exactly what I would have written in the first place, why would I choose to write it myself?
On the other hand, I spend a LOT more time now doing code review for other devs. I used to know the individual coding styles of the devs I work with. Now that nobody is writing their own code, it's all over the place.
[OP] snake_case | a day ago
I just miss building something myself.
I also miss that the development cycle used to be slower. It’s impossible to explain to management that we have bugs in production because when you spend less time writing code you also spend less time thinking about the code you’re writing. AI will only fill in the blanks so much, if you don’t tell it to cover some case, it wont, and since you didn’t have the time to think of it, you didn’t tell it to.
They think that we can just extend the planning phase and solve this issue, but every single company Ive ever worked for discovers requirements during testing. Every single one. There are things that no one thinks about until they actually try to use the feature. That is just life.
Since they’ve taken away our “play around with it” time and forced us to ship it directly to QA who then discovers requirements which then are solved by AI without thinking about how people actually use the feature that whole “gets worse before it gets better” bugfixing/testing phase ends up happening when the feature is already in production.
Ugh.
archevel | a day ago
I enjoyed coding and solving issues with code. I've been doing this professionally for about 20 years soon. With an LLM I am certainly able to churn out more, both in terms of lines of code and actual features. I've mostly settled into validating the output of the code; not the code itself. Design and QA is taking a larger portion of my time at work. Downside is that, while it is still satisfying to ship features and improve the product, it isn't as enjoyable a craft anymore. I no longer have a deep understanding of the underlying code.
I know that, in general, I am still able to produce code at a higher level of quality than an LLM, but that doesn't matter that much to me. Something ineffable is missing now. I tend to think this is similar to how artist feel about gen ai in general. They can see the flaws produced by e.g stable diffusion, but does it diminish the sense of creating? Is the process tarnished in some way? I think it is for me.
SteeeveTheSteve | a day ago
Does it feel sort of like you'd imagine a craftsman would feel going from hand crafting furniture to watching over a factory mass producing furniture? Maybe like a stone carver would feel a loss suddenly having to use a 3D carving machine to do the same work?
You lose freedom to alter it during production, that personal touch that makes it yours. Might feel no skill was needed as the machine did it all, losing some pride in your work. You no longer get to enjoy the process of crafting as your work becomes planning and inspecting.
archevel | 11 hours ago
Not entirely. My goal when making software haven't been overly focused on the craft. I focus on solving problems. The analogy with the craftsman never sat entirely right with me. A furniture carpenter finishes a table and then that table is done. For a software developer the work is continual. Maybe more like a gardener where the garden is in a continuous flux. So a gardener that goes from tending the garden to sitting in a tower far away with binoculars and a megaphone screaming at the robots to "prune the trees and make no mistakes"... I don't know. Not great at analogies.
[OP] snake_case | 23 hours ago
This is exactly how I feel. Writing code was a bit of an artistic outlet for me in the same way writing s novel might be for someone else.
parsley | a day ago
In my company code review has kind of died. Most projects now have a single engineer working on them with an llm doing most of the work. We are kind of faster, but the PRs are now regularly 20k-50k lines of code each, on new codebases we know nothing about and on features we know nothing about. We tried using llms to help explain the PRs but it is a lot of effort and that is useless most of the time.
I'm sure there are lots of good teams out there that can take advantage of these tools, but I think lots of average companies / projects are going to be crushed by the weight of the technical and organizational debt llms are creating, specially when prizes get corrected and you can't just tell them to "fix it" at a reasonable cost.
winther | a day ago
When I read about something like that, I wonder what kind of software you are running in what business - if I may ask? Because I am sort of in charge of the codebase for a smaller company in the saas business. We are about 40 people and I would be terrified to run it like that, as that would risk the livelihood of all employees if our service broke down for our customers if something hit production that only an LLM has looked at and understood. Any sort of breaking change or longer disruption could kill us quickly. So I have been extremely defensive with things that go to production and AI isn’t really speeding things much as pure code speed isn’t exactly the bottleneck. Are these setups where entire companies run on pure AI development just in less risky areas or larger organizations where code doesn’t hit production that easily? Or is it just greenfield projects and not on top of 10-20 years of legacy with risk of breaking things for existing customers?
parsley | a day ago
Kind of niche B2B stuff. We luckily do not have lots of operational complexity so things are working out fine. We were already working on smaller teams in greenfield(ish) projects. We are just kind of pushing harder and harder in that direction.
I'm kind of venting at this point, but I kind of fear that LLMs are eroding engineering culture in general. It is like we got this new rockstar hire that takes over the company because he works so fast and is always saying the right thing to his managers, but in reality is doing a mediocre job. And now the rest of the team have both the expectation of being as fast as him and fixing all the shortcuts he is taking.
Gourd | a day ago
So does anyone actually understand your current codebases? I feel like that's the direction we're headed as well, but I'm catching major issues during review on a semi-regular basis (I should be clear that I do use Claude during my reviews, but I also generally run through the same manual review process I've done for years). I think it would be a disaster for us if the traditional code review went away completely.
I'm lucky in the sense that many of the projects I'm working on are small enough for me to basically be able to hold the whole thing in my head at once. I can't imagine this no-review vibecoding ending well for larger projects.
parsley | a day ago
For the more complex projects we still have several people in the loop but the newer projects have as little people as possible, usually 1-2 engineers working on different areas, with little to no overlap. It is actually kind of hard to argue against this setup now. LLMs are very local to the current task and do not wait to chat with your colleagues LLM sessions to agree on architectural decisions and redoing work is common.
I also use Claude for reviews. It works OK for the most part, but has a tendency to rise issues and then retract them when you ask for more details. My stack is not super common and it probably does not help either.
ssk | 8 hours ago
Why aren’t you using a spec driven approach then if you don’t mind me asking?
parsley | 6 hours ago
We do, actually, but spec languages like gherkin are very verbose so you end up generating the specs anyway.
It is hard to justify putting effort in things that the agents can do, even if agents absolutely need this extra effort in testing / specs to work properly.
Narry | a day ago
For me, writing code is an exercise in hands-on puzzle solving using an intersection of math and imagination. You have to mentally parse the data, guess how the computer is going to interpret it, then iterate on the pattern until you achieve the results you were looking for.
Architecture is its own kind of puzzle solving, but it’s less immediate than the problems you encounter coding. You’re laying out the structure of the code before you type a single line. You’re solving a meta problem and breaking it into smaller tasks.
Both are very much like being handed a bucket of LEGO and being told what your end product needs to be, but architecture is making the design documentation of where the bricks will go (thus ending up with instructions that anyone can follow) and programming is assembling the bricks to build the thing itself.
Both valid, both important, both benefit from having the other.
It also closely mirrors my experience with writing fiction prose: there are “two” types of writers we’re told, plotters and pantsers. Plotters are like architects, who carefully lay out a design document before they write the first word of the story. Pantsers start writing and discover the story as they go. The secret is that they’re both going to end up revising things as they discover the story. The plotter is going to discover the story as they go to write, and the pantser is going to discover the structure as they go to revise.
Tiraon | a day ago
Current LLMs can be somewhat useful tools in the hands of someone who already knows what they are doing. I am not convinced this tool will ever be able to create novel code autonomously or used by someone who does not understand programming.
There will always be place for someone who understands what the code does and who is able to translate user requirements into the needed structure. And understanding that code will require engagement comparable to writing it by hand.
Unless of course there ceases to be any requirements for quality, maintainability and security and everyone just accepts that all sw breaks frequently in highly visible ways and will never be truly fixed but hotfixed on an ongoing basis. Or we achieve AGI.
derekiscool | a day ago
Totally agree. To me, it's sort of like the process of learning math in grade school. As a kid, you can just sit there and think "but why do I need to know this when I can just use calculator". Sure, the calculator can do it for you, but you need a foundational understanding to have any clue what's going on in the more complex math.
Except in the case of AI, the 'calculator' constantly makes mistakes, lies to you, and literally makes stuff up that doesn't exist. So if you don't know what you're doing, you're going to end up with really poor results.
skybrian | a day ago
I think it will be sort of like writing poetry or making crossword puzzles - something you do for fun, with the expectation that other people will read the source code because there’s something interesting about it, not just run the program.
On that note, I once tried writing poetry in the Inform programming language.
donn | 23 hours ago
I really dislike this modern likening of non-vibe coded software to assembler because the gap is much much wider. A C compiler will not forget to leave an admin user misconfigured on a server or something.
Which mind you, I'm not claiming that LLMs are useless, I just think even the best agents are not as good at being autonomous as they're trying to sell them.
EDIT: Re-articulated some parts.
kacey | a day ago
IMO it could be instructive to see how folks perceive handwriting assembler, or the micro-optimizations necessary to eek out a few percentage points of perf from archaic hardware (e.g. game consoles and the like)? Since paying that level of attention to your code has been considered largely pointless in the modern era where throwing more hardware at the problem is economically optimal 99.9% of the time. The last forty to fifty years have seen a downwards trend in attention paid to the nuts and bolts of the software actually being written, with I think the sharpest decline happening in the last few years.
So, that in mind, and given my observed appreciation of others towards said code, I'd assume that people will find it a little sad/kind of inspiring that people could even work that way, before feeding it into slopzilla to churn out v3 of your old software code (statistically, in Rust). We haven't really cared about the code in software for ages, and I doubt folks will start now that it has become even more devalued (see also: visual arts).
(sorry for my pessimism ... I'm not a huge fan of how the industry prepared for this, responded to it, and what it figures will be the future)
Greg | a day ago
This has always been how I’ve expected things to go too. I love the craftsmanship and sheer dedication that made Rollercoaster Tycoon happen, I love older stories about physically mapping drum memory for efficiency, and I love seeing people find techniques to squeeze ever more complex feats out of vintage hardware*.
But I can’t pretend that compilers and garbage collectors and even electron apps were a bad idea when it comes to getting shit done, even if they can be easy to misuse and facilitate a lot of slop. Same goes for coding agents, but as with many things in our thin-end-of-the-singularity cyberpunk dystopia, it goes faster and more extreme now, for better and for worse.
*Side note: why do so few people seem to notice the insane quality of ultra-specialist hardware and software work going on in the retro gaming community? These people have the skills to run rings around some of the most highly paid engineers on the planet, and they’re investing thousands of hours into random niche projects for the literal love of the game. I want every tech executive looking at a huge flashing neon sign that just says “where’s your capitalism now?” and points to some dude in a basement engineering an entire motherboard single-handedly. Anyway…
kaffo | 23 hours ago
I came here to say something like your comment but not quite.
I also have the comparison to assembly and low level languages in mind but I think I see it a little differently.
As time as gone on new tools and languages have been created and widely adopted, yes as hardware has improved too.
We had a step change where developers were once writing op codes and along came C and other low level languages. A time saver and devs could do more with less. People 100% complained at the time that it was better to write in assembly than C.
Since then we've had higher level languages, source control, IDEs and intellisense. Does no one remember when intellisense first dropped and every developer thought they'd get lazy and forget how to code?
I think AI is just another tool in the chain. We might end up writing less code, maybe no code? A developers job will change, even slightly, as the tools are useful.
My personal opinion is they are much more effective at non-coding tasks, but the right person can steer AI to write reasonable code, and it should get better and cheaper at it as time goes on.
Some developers will quit, because they won't want to use the new tools. Most will just adapt and live with the new way of working.
I think, eventually, writing an application end to end with no AI input will be either:
[OP] snake_case | 23 hours ago
I don’t think that LLMs are another tool in the chain.
The way I do my job has fundamentally changed.
Its more similar to using those giant textile machines vs a loom. It’s a whole industrial revolution.
It’s not a better product. It’s not even easier to use. It just mass produces mid quality shit so fast you have no time to even wonder why we’re doing this. Most clothes end up in the trash and most software rots in a github repo, never even seeing production.
kacey | 22 hours ago
(generally agreed with this statement. Just wanted to add that I hope you're doing OK; things sound rough)
[OP] snake_case | 20 hours ago
Thanks, I have good days and bad days. I’m very fortunate to still be making crazy money and I’m saving everything I can cause I know I’ll be unemployed in maybe five years when the business decides they can just write features by themselves since it doesn’t actually matter if any of it ever gets used by a customer.
I have several backup plans, and each of them sound like way more fun than what Im doing, just for less money, so I’ll be okay.
Eji1700 | 22 hours ago
Doubt it. Depends on your definition of "years from now" but I don't see it being financially viable at this time, both in quality and cost.
As a datapoint, I sorta follow this blog.
They'd probably agree with you, as they claim:
but they also point out that:
$200-4k a month is NOT nothing, especially PER PERSON on a team. Tell me I can spend $50k more per person on salary and I'll get you a fuckload of results as well, and this is still probably a subsidized cost.
I don't doubt that AI is going to be a tool used for all code going forward, but there's still going to be a lot of handwritten stuff.
There will be a collapse of "uniqueness" as coding will help people settle on a similar style, but that's 99% a good thing, and I have 0 doubt I'm still going to crack open billion dollar company production code and see an IF statements that run identical code on each branch.
[OP] snake_case | 20 hours ago
I dont use nearly that amount at work and I also hardly write code. Theres several ways to save on tokens. You can use a cheaper model, lower your context window, swap between expensive and cheap models depending on what you’re doing, etc.
d32 | 8 hours ago
Prices halve every few months.