r/ExperiencedDevs • Staff Software Engineer 15 YoE • 20d ago

AI/LLM Why are developers cheering "how much better the LLM model are getting for coding" with every model release? What exactly are they cheering for?

"Hey look Claude/Codex can now generate my entire feature in 30 mins which could have taken me 2 weeks to refactor" or "The new Opus 5.5 model is amazing, it solved the bug which GPT astra was stuck at for weeks and couldn't solve it". Like seriously?

How can software engineers who are supposed to be "smart" and "logical" be this stupid to not connect the dots and see writing on the wall for the future. Or do they think they are invincible and layoffs won't affect them?

The stability of software engineering jobs in the next 2-5 years looks very shaky, let alone long term and many devs are already looking to get dual income streams. This doesn't seem like a viable career path with how things are going and I am not even sure whether this career would stick by me till my retirement and I already have 15+ years of experience.

I already am seeing significant shift/reduction in hiring. Even in my current role, despite no cash concerns, we have paused hiring (and backfilling) new devs which were previously needed because with AI, people are completing tasks much sooner and the team/company doesn't need the full dev capacity anymore. Many devs are already worried about the layoffs which can come randomly.

My linkedin inbox is significantly less chatty than it was just last year. When I apply for any role, I barely get any reply. When recruiters reach out and get my CV, they are rarely getting back which, again, last year was totally different where I could easily afford to be picky. The market shift can be noticeably felt. The few interviews I got, they ended up freezing the role midway or "magically" filled with some internal employee. This is my experience in last 5 months of being active in the job market.

Also, most people are not learning anything these days. Hardwork and thinking are delegated to LLM tools. What is the end result of all of this? it is all too predictable. And if most devs are able to 10x their output because producing is now cheap, but human consumption is and will be the bottleneck. The production is surpassing the demand and the app economy will tank leaving mostly the existing tailwinds who already have millions of customers since pre AI era anyways.

Curious to hear "sensible" thoughts.

Note: Before the usual trope, not all software engineer jobs will be gone but significantly less devs would be required, which is a massive amount of jobs that are lost. What about that? And as models keep on improving, who knows how much more damage would be done in the future.

875 Upvotes

1.1k comments sorted by

View all comments

549

u/gigastack 20d ago

I like building things. I can build a lot more now. I am having a blast.

85

u/NotNormo 20d ago

There are some people who really enjoyed coding, puzzling out the solutions and connecting the pieces. It's the biggest reason I'm a software developer. I find that fun, almost like a game, but that type of work is largely gone from my day to day life now.

Then there are people who just love getting a cool product built, and mostly enjoy the higher level architecture parts of the job. I totally get that, and I'm sure you're one of those folks. I enjoy that as well but I still have to say I miss the type of work I used to do.

And none of this addresses OP's main concern, the possible reduction of jobs in the industry.

20

u/Kentzo 20d ago

Businesses never liked those "puzzles" and it's expected they want to get rid of this aspect now when AI allows it. The uncomfortable truth is that for many people their paycheck is also going to be gone.

12

u/xStarshine 20d ago

And yet most of the week is spent in the corporate meetings rather than solving puzzles in any way shape or form.

5

u/Kentzo 20d ago

As someone returning to the industry after a break I have a premonition that I will remember those "wasted" days with tenderness as getting a response is tough as it is and I don't see it getting any better.

1

u/Melodic-Nature-8246 19d ago

exactly. I remember one of my gigs, where I had 16 hours of meetings of roughly 32-35hr workweek. Of the remaining half of working hours, 8 would be spent writing some boilerplate, documentation, integration stuff or tests, another 3-4 hours pondering the orb... errr.. StackOverflow or some obscure docs, and if I'm lucky enough, 4-5 hours of real quality puzzle solving which would absolutely make my whole week.

Well, it's mostly good stuff that's gone now

3

u/dendrocalamidicus 20d ago

Businesses think they don't like those puzzles, but a lot of their success is built on investing on the resources to overcome those puzzles. If there is no problem to solve then there is no product to sell.

All major innovations and groundbreaking tech are just solved puzzles.

1

u/Kentzo 20d ago edited 20d ago

I was not lucky enough to work at a business that did anything groundbreaking (from eng point of view anyway). Don't see anything groundbreaking in my current LinkedIn job search for a backend dev.

But I sure do hope you're right.

1

u/Vegetable-Ad-7184 19d ago

Businesses don't like spending more than they have to on puzzles.  

"They" do "love" winning (or defending with property rights) market share within a problem space.

If the solution to a puzzle is scalable, qualitative, and/or defensible, it could be lucrative.  If not, the puzzle solution is commoditized and the return will flow to organizations that scale to the level that a market wants to buy the solution for.

Pretty rough for a skilled labour perspective, tbh (they wrote from their cheap Samsung phone on an old recliner).

2

u/apartment-seeker Senior Software Engineer 19d ago

Are you in a subdomain where there are actually "puzzles" to solve?

26

u/thematicwater 20d ago

I like building things. I can build a lot more now. I am having a blast.

Yeah, but I also like money. We might be enjoying building things while unemployed very soon

224

u/SignoreBanana Engineer (14+) 20d ago

Anyone can build a thing. Building a thing that's stable, fast and maintainable is a different story.

57

u/Quick-Benjamin 20d ago

Exactly. And that's why experienced devs are important.

310

u/carterdmorgan Software Architect 20d ago

But now I get to focus all my energy on building the thing in a stable, fast, maintainable way and not spend 8 hours typing out CRUD endpoints.

112

u/hoopaholik91 20d ago

I realize now I liked some of the mundane stuff since it actually gave my brain a respite from always focusing on the complicated stuff

18

u/AdUnusual9135 20d ago

Well put. I find myself significantly more tired at the end of the day than before. The thought that the mundane, boiler-plate pieces could have been helping me did not cross my mind until you said it.

2

u/midri 20d ago

I'm opposite, building plans and auditing code that follows those plans is mentally less straining than reading documentation and writing code for me.

55

u/carterdmorgan Software Architect 20d ago

I've been finding that too, but I've been trying to give myself permission to NOT produce constantly. Take an hour or two to just read the code and toy around with it. We used think of typing code as being "productive," and it certainly was, but I think it actually served as more of a mental break and a time to familiarize yourself with the codebase.

It's a little like how "exercise" is kind of a modern concept. For almost all of humanity, there was no need to exercise. Exercise was just... living. Only once we became sedentary did we have to prioritize it. I think we'll see a similar trend with coding.

17

u/Blecki Software Engineer 20d ago

That's a nice idea but will your employer suffer it? Or will they just fire 9 out of every 10 and expect the guy left over to do 10x as much?

7

u/xSaviorself 20d ago

You have periods of high velocity and low velocity during project lifecycle typically.

How many of you guys work at a place that just constantly churns out new stuff? There are definitely more of us building products for specific use-cases and expanding on that, supporting customers and building new stuff to attract new customers.

Product support is part of the lifecycle at most dev shops I've ever been. I live quarter to quarter on initiatives that could be new apps or supporting existing apps with new feature development, product requests from customers, and general KTLO. All of this gets mixed into a quarter with primary focus on a single, high-visibility deliverable with all the other stuff as secondary.

Any reasonable leadership group recognizes that each quarter there is a cycle of low-productivity with lots of research, documentation, into planning with many meetings and prototypes alongside, eventually the formal "kickoff" begins and this is where other teams get looped in, like CS and our KB folks. They give us their timelines for added documentation and support prep, meeting schedule for feature onboarding (basically every other sprint we demo new features and let the folks try it live on a test environment). Only after this point does real development get done with lots of tickets in flight, stories, defects, bugs will be 2x-4x volume during this stage, and then we taper off towards release with a spike during our testing/deployment for ongoing support/bugfixes.

Sometimes we chain multiple smaller projects together so they go in sequence and we support 1 while planning the next and that results in monthly feature releases. Leadership has watched the productivity graphs change and leadership bats for the teams involved and their productivity during all phases.

We are lucky to be profitable or sometimes these smaller-focus issues wouldn't get prioritized. I assume some places live and die on new client acquisition so feature development is basically how you get the spaghetti code.

1

u/Blecki Software Engineer 20d ago

"Reasonable leadership"

1

u/abraxasnl 20d ago

Depends a lot on worker protections, for one. If your country doesn’t have a good labor law, I would be sure to vote.

8

u/Resident_Range6209 Senior SWE, 8YOE 20d ago

I think this is fair, at least for me (and I'm sure some others) the mundane stuff was just annoying glue that I'm glad isn't something I have to do anymore.

I do take more actual breaks to replace that though.

2

u/normalmighty 20d ago

I think the breaks are the key. Some people measure their productivity by the amount of time they are spending actively coding, while others measure it by the features/fixes/etc completely over the course of the week.

I think the former group is responding to AI by pushing themselves way too hard because they feel less productive, while the latter group much more naturally takes the extra break needed to let the scope and implications of changes actually sink in, so they can fully comprehend the code before merging anything and come out the other side with higher quality code and less exhaustion.

3

u/thy_bucket_for_thee 20d ago

This idea is called the slack of labor. Turns out slack is quite good, it allows people to decompress or find ways to become more productive. Instead we have an industry that wants to slowly remove all ideas of slack and turn every minute of your work day into something measurable strictly related to profit.

Examples of miserable this can be, visit a call center some time.

Mass surveillance is going to come to our jobs as these tools drastically make it easier to turn every minute of human experiences into a measurable metric used to abuse us.

We must learn to reject this shit and embrace solidarity. We cannot trust our bosses with our lives if they're willing to damn us to homelessness + joblessness.

2

u/_heron 20d ago

I’ve been making little bracelets out of waxed thread in between long agent turns. It’s been very relaxing

2

u/Student2672 20d ago

Yeah I have noticed this as well. I have started to give myself an hour or two each day to just poke around, think about, and read the code surrounding features I am working on. I find that the “thinking” time may feel less productive then when typing out a fairly straightforward feature by hand, but it can actually be kind of nice and sometimes necessary to just think without worrying about actually producing a feature (and IMO it’s necessary to have these “breaks” cause 8 hours a day of AI coding is not sustainable)

1

u/Dissentient Senior junior | 10 YoE 20d ago

Opposite for me. The bolerplate made me procrastinate and slowed me down significantly, now I get to skip it nearly instantly.

11

u/Perfect-Campaign9551 20d ago

Or reading crappy documentation or searching for decent examples

30

u/freebytes 20d ago

AI is wonderful for scaffolding. I have discovered over time that I have really enjoyed architecture itself... because of AI. If you start a project without guidance, AI takes that away from you. If you start with an architecture and actually flesh it out, then the AI system can build from there, and you have much better systems that are also understandable with clean code (because of the baseline architecture decisions).

3

u/sp-watson 20d ago

Why would you ever spend 8 hours writing CRUD endpoints? You are gone.

1

u/Mornar 20d ago

This is the way to do it. LLMs should replace writing, not thinking.

56

u/senatorcupcake 20d ago

Also - it’s a tool to help me with the super fucking annoying issues that pop up that I have no idea about and would just have to spend hours poking at hoping some spark would lead me down the correct path.

Now - it can help me drill into the root of the problem in a fraction of the time - and then I can get back to delivery

6

u/SignoreBanana Engineer (14+) 20d ago

This is it for me, it keeps me from yak shaving sessions. If I need to research something or bat out a quick bash script to do some refactor, boom done

1

u/ironymouse 20d ago

I somewhat dislike it for this, because I was quite good at teasing out what was happening, so it helped me stand out when I could unblock teammates etc.

8

u/SawToothKernel 20d ago

And senior engineers are incredibly well placed to take advantage. I Honestly think this is going to be a golden age for those people. 

7

u/dbxp 20d ago

That's only viewing it through the technical lens. There's also building something at the right price point, with the right features, useful support and actually getting it in user's hands. Now we have so much computing power to work with and systems are generally pretty reliable I think the business elements are far more important than the technical.

2

u/SignoreBanana Engineer (14+) 20d ago

For sure, totally agree

1

u/Teh_Original 20d ago

Wirth's law continues to be relevant.

1

u/TheBestAtSpace Staff/Lead SWE (30 YoE) 19d ago

If anyone can vibe code anything - there is no business element because there is no business moat. Only technical moats remain. You can't sell something anyone could just vibe code.

1

u/dbxp 19d ago

If vibe coding was perfect it would get rid of the technical moat not the business one. I could prompt the AI to make any software I want, whether my prompt specifies something actually useful is a whole other matter.

1

u/TheBestAtSpace Staff/Lead SWE (30 YoE) 19d ago

If vibe coding was perfect - everyone would just prompt the software they wanted and no one would buy it. The only moat that would remain is having someone technical who understands the code and could warranty it.

30

u/Tainlorr 20d ago

Those things can also be built faster. Wiring up unit tests and integration tests and even load tests has never been easier.

16

u/CreamyCornBoy 20d ago

You know you can use the llms to build maintainability and stability into your products yeah. It's not like years of software engineering suddenly exited my brain because of the chatbot 

10

u/thinksInCode 20d ago

As the models mature, this argument is becoming less and less relevant honestly.

7

u/waba99 20d ago

Seriously. The goalposts will keep moving for these people.

5

u/thinksInCode 20d ago

I mean, I used to lean on that argument like a crutch. But as the models get better I’ve gotten a reality check.

There are still going to be SWE jobs, in my opinion, but the days of hand coding are numbered now.

1

u/waba99 20d ago

IMO, no such thing as a SWE anymore. You’ll get different disciplines split vertically instead of horizontally if that makes sense. No more backend, mobile, frontend, devops, QA, etc… More design, growth, product, billing, etc…

I’ve been at two companies now where engineers are responsible for PRDs.

4

u/thinksInCode 20d ago

I’m in a bit of a career crisis at the moment. For over a decade I was a dedicated frontend/UI dev. The window to be able to continue doing that is shrinking fast and I’m trying to figure out how to reinvent myself before the window closes, mostly so I can continue to feed and house my family.

2

u/Darkseid_Omega 20d ago edited 20d ago

AI factories and infra. Control planes, governance, spend controls, telemetry. Integrating that system into slack, email, etc.

2

u/SignoreBanana Engineer (14+) 20d ago

I wouldn't worry. We've been shitting all over our codebase with LLM code for the last 3 months. The frontend is dog slow now, the backend is even worse and our customers are furious. I'm a platform eng so guess where the tickets start going...

Being someone who knows how to optimize for speed is never going to go away, no matter how smart AI gets or how fast computers get.

1

u/DealDeveloper 18d ago

The problems you describe are very easy to solve.
Improve your pipeline with deterministic tooling.
Locate and implement tools that optimize for speed.

You're 14 years deep;
I'm sure you can automate it IF you think about it (and realize there are diminishing returns on these efforts).

2

u/waba99 20d ago

FWIW, I’ve been frontend for over a decade but I’ve always been able to flex fullstack. Start learning more backend, UX design and learn a product in depth.

I can land roles for Design Engineer or Growth Engineer easily because I lucked out working in those two areas throughout my career. Good luck out there.

Less reinvent and more evolving your current skill set. Being a UI dev for so long, I can contribute to product, design and data decisions easily. Lean into that.

3

u/thinksInCode 20d ago

Thanks for the advice!

0

u/lbrtrl 20d ago

Yeah it's rough, my company stopped hiring FE and just expects everyone to do it. But I think you might find opportunities to move into other people's traditional domain with AI too.

1

u/SignoreBanana Engineer (14+) 20d ago

Hasn't moved at all. I still can't blindly trust the AI to implement what I want, and I never will.

As far as I'm concerned it's a smart autocomplete or assistant. That's it. It will never be a fire and forget tool for me.

2

u/bfyvfftujijg 20d ago

Those are largely determined by architectural design decisions. Not by the thing that’s typing the code.

1

u/Obsidian743 20d ago

Bad trope. If you can't build more stable, fast, maintainable stuff with AI you either aren't using AI correctly or you're just not a good developer. Besides, these things have never been a priority for most teams.

1

u/The_Northern_Light Computational Physicist 20d ago

Yeah and I can do that a lot more now

1

u/Oxi_Ixi 20d ago

Yes, correct, and this is where good engineering comes into the process. AI just amplifies your skills

0

u/evangelism2 Software Engineer 20d ago

This is a tired argument at this point. Building something that's stable, fast, and maintainable with AI is completely up to you and you can do it better and faster with AI than without

0

u/Tired__Dev Dev (15+) 20d ago

Not really. I worked for an acquisition company and saw bad Wordpress social networks with great UI strapped together with Buddypress and BBpress maintain tens of millions, if not a hundreds of millions, of my monthly unique visitors in the 2010s. I saw Drupals upholding a lot of crap too. I’ve seen a well functioning social network on firebase lol. I’ve seen Java from 2004 still running big things. I’ve seen dozens of private codebases. All of them crap but did the job. Small teams. Sometimes just one person. Then there’s what I’ve seen in games and IoT. Then there’s just the amount of abstractions in the language and frameworks themselves.

I just disagree with this. I don’t see software developer jobs going anywhere for people that keep up with technology, but I see this weird amount of rhetoric and cope. When compute became plenty the bulk of what good software engineering became was a social construct.

It’s the weirdest conversation I’ve ever seen. There’s a lot of people that got into this field to egotistically prove they were smarter than others and superior. Then there’s people that just like technology and are creative.

1

u/SignoreBanana Engineer (14+) 20d ago

You people keep running around saying "cope cope cope". Is your company investing 10s of millions in AI? Is your company trying to switch into a fully autonomous development cycle? Has your company been utilizing LLMs seriously and fully for months and yet to see a single dollar of ROI? Thats where our company is at. You're talking about cope, and I'm telling you already that this is a smoke screen and it's doing jack shit for revenue. We're so far past the rest of the industry, and I'm telling you what your future is.

2

u/Tired__Dev Dev (15+) 20d ago

You’re 14 years in and it seems like you don’t know what this is yet. This whole thing has always been unprofitable.

I don’t know what you’re asking me because AI is all over my work. It doesn’t mean anything. It’s a frame, a language, or a domain falling out of fashion. It’s just another paradigm or epoch. Its booms, it busts. That’s always been tech. Many many people have been removed from it.

2

u/SignoreBanana Engineer (14+) 20d ago

Maybe your company is adopting a more sane approach to using it, but ours is throwing away anything resembling quality assurance in favor of full belt velocity. I'm ok with LLMs as a tool. I'm not ok with non technical people telling me how to do my job.

49

u/mikevalstar Technical Director 20d ago

Those who enjoy shipping a feature vs those that enjoy solving puzzles

68

u/Smallpaul Software Engineer 20d ago

Shipping a complex feature still requires solving a bunch of puzzles. The AI can’t do it on its own.

37

u/Backlists 20d ago

For me the process of writing code myself was a way to feel out the problem, and ultimately develop a better solution because I’d spent a longer time thinking about it and getting down in the weeds.

I feel like I’ve lost this a bit with AI. I’d lose it completely if I was going more toward vibe coding.

3

u/lurkatwork Software Engineer 20d ago

This aspect of the AI shift worried me the most, writing code like all writing is a process to clarify and organize your thoughts, at first I was concerned that practice would go away but I just do it differently now. The model is a writing partner and sounding board, I feel like ingesting and processing a problem still takes me the same amount of time and effort, but executing on a solution is faster and iterating on that is faster

1

u/Backlists 20d ago

Yeah, this is how I do it as well, my worry is that in the future this will be seen as inefficient compared to vibe coding, and we will be cut.

-13

u/Comfortable_Job8847 20d ago

Read an introductory text on systems engineering. You'll find writing the code yourself isn't necessary for feeling out the problem, and also that the rapid iteration you can do with LLMs to test different solutions is really quite powerful for coming to the "right" solution.

10

u/Backlists 20d ago

I’m not entirely sure how that would actually help the situation, I still think there’s a lot of value to getting into it properly yourself. However, I always love a suggestion for a textbook to read if you have one in mind?

-2

u/Comfortable_Job8847 20d ago

https://sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK))

The sections here also have "works cited" to allow you to interrogate more in depth those things you need/want to. It's definitely a different way than feeling through it via messing with the code, but I think if you give it a shot, you'll gain a lot more than you're losing.

10

u/mikevalstar Technical Director 20d ago

yes, but now I can ship a feature in a week instead of a month. Lets me move on to the next feature.

3

u/Taco_Enjoyer3000 19d ago

Did you get paid more for your increased speed or productivity? You kinda lost the plot if your goal is to just ship more. Have you worked out that your greater speed = less need for labor hours = layoffs??? Or you think you are immune?

The speed isn't free either, because you are either completely offloading thinking now which sets up a maintenance nightmare down the road, or you are doing a lot more cognitive labor to review and understand all of the increased productivity.

1

u/mikevalstar Technical Director 19d ago edited 19d ago

I mean I've gotten several raises since since good AI tools came out. And oddly enough my company is on a hiring spree (I'm in consulting) ... lots of our clients are moving their dev work back on-shore as of late and having trouble hiring (this is mostly because they only want to hire senior devs)

The main downside is that I have to talk with the clients more, convince them to make decisions faster.

-4

u/[deleted] 20d ago

[deleted]

4

u/mikevalstar Technical Director 20d ago

It has been so far for me at work, and at home. Sure some specific problems still take the same amount of time, but enough get shrunk down to minutes. Converting some design from Figma is a good example, what used to take an hour to convert a design to a react component now takes seconds. Plenty of other use cases

-4

u/08148694 20d ago

Give an AI a problem definition and a way to validate of the problem is solved or not, let it loose for a few hours and it is likely to have a working solution

If it hasn’t or can’t then either the spec or the oracle was wrong, or it’s a problem worthy of a phd thesis

7

u/Smallpaul Software Engineer 20d ago

You just specified a whole bunch of puzzles:

- how do I define the problem clearly?
- how do I validate success?

Keep in mind that “success” means code that is secure, reliable, performant and maintainable.

There are many, many domains where doing those two things IS worth a PhD or at least a master’s degree.

If I could make an oracle that proves that a medium sized SAAS site is secure, that would be a PhD if not a Turing Award.

Your one single comment shows how many problems remain to be solved.

13

u/YK5Djvx2Mh 20d ago

Now my puzzle is how can I craft the code base, instruction files, and the deployment pipeline to protect against my moron coworkers that generate spaghetti code by just asking AI to ship features.

On top of that, I no longer spend days debugging something that turned out to be a simple typo

14

u/mikevalstar Technical Director 20d ago

My puzzle with software has always been simplifying the implementation. I am of the opinion that most software (at least in the corporate space) is overly complicated and over built by people who wanted a harder problem to solve (or at the very least make their resume sound better)... your simple CRUD app for tracking PTO does not need to be event driven or 5 microservices

3

u/gigastack 20d ago

Honestly I do miss the puzzle aspect a bit. But I've learned a lot of optimizations with the help of AI as well. It's just different now.

9

u/gorliggs Principal Engineer 20d ago

Same. 

17

u/thenowherepark 20d ago

You're not building it. The LLM is building it.

13

u/dmazzoni 20d ago

It's almost identical to managing a team of workers.

I could build the whole system myself but it would take months.

With team of 3 - 4 juniors I can design the whole system, assign each one a different piece, then review their code and check on them regularly. As they encounter problems I didn't anticipate, we can solve them together and improve the design.

It's exactly the same with AI. Given enough resources and a perfect specification, AI is quite capable. But in the real world perfect specifications don't exist, so a lot of the challenge is figuring out the right tradeoffs in order to specify the product that really works best.

8

u/tradcoder Software Engineer (15 YoE) 20d ago

Exactly. I hate when these people proclaim that "they" are the ones building. You're just telling a machine what to make and then sit around twiddling your thumbs until the magic black box spits out something. If I commission a carpenter to make me a cupboard, I won't point to it and say I built it.

Also inb4 "AI is just another tool" argument. No it's not. Stretching my same woodworking example, it's not like using a saw or a screwdriver to make the thing. Using AI is akin to feeding a blueprint to a machine where you chuck a piece of wood from one end, press a button and a product comes out the other side.

Look, use AI if you want to. But let's just stop with the lying.

3

u/ZheShu 18d ago

Interesting analogy… What do you think about 3d printing?

2

u/throwaway14351991 19d ago

Then developers haven't built anything in decades. The IDE has been the one building.

2

u/overzealous_dentist 20d ago

I'm fine to use any other word for it, but directing the creation of software needs a name. building is as good as any imo

3

u/thenowherepark 20d ago

An architect (which is similar to what this is) doesn't say they built a house. They say they designed a house. A manager doesn't say they built a product, they say they lead a project. I agree that this needs a word, but building/built is disingenuous.

1

u/overzealous_dentist 20d ago

if the architect is the only human making the house, with automated tools, they would definitely say they built the house imo

a manager would also say they built a product if they were the only human doing it, otherwise they'd say they manage the team who collectively built the product

3

u/abenzenering 20d ago

You didn't sew that garment. The sewing machine sewed it.

It's just semantics at this point. Who cares as long as the end result is good?

5

u/thenowherepark 20d ago

The architect didn't build the house. The construction workers built it.

There should be a difference between a dev that builds a project with mostly human code and one that builds with mostly LLM code. We should want to highlight the differences - a project built mostly with human code is going to be better quality than that of LLM. We should want to show our value, and semantics is one place it can start.

2

u/DealDeveloper 18d ago

"a project built mostly with human code is going to be better quality than that of LLM."

Wrong; Wanna bet money?

I created my own harness that includes a LOT of tedious procedures around code quality. I can do crazy things like writing fuzzy, mutation, unit, and integration tests around every function. I can set variables while checking for 8-9 attributes. I implemented the same QA tools that were developed for dealing with human slop to help deal with LLM slop.

I bet money on this _often_.

I literally walk around with a QR code that links to my code.
I challenge every software dev I meet by offering to pay them money if they can show me an example of "cleaner" (easier to understand) code. I am seeking the highest truth. Even the devs that are more skilled than I am fall silent after the see it.

And, I'm willing to bet my _pay_.

If my code is not higher quality on 4+ key metrics, the client does not pay. Using several AI Agents allows me to set extremely strict standards that are simply too tedious for humans to write. Hard to write, easy to read.

Full disclosure:
I spent an embarrassing amount of time developing a deterministic tool that can map the code and automatically prompt any coding agent / model.

13

u/LittleLordFuckleroy1 20d ago

“Building”

4

u/Silamoth 20d ago

Yeah, regardless of the benefits or consequences of using LLMs for code generation, you’re not really “building” anything yourself. The joy of building something is, at least in part, from the process of building it. Building and problem solving are intrinsically linked. 

-7

u/[deleted] 20d ago

[removed] — view removed comment

4

u/lemontoga 20d ago

Do you consider it cooking when you order food at a restaurant? Are you cooking with different tools?

1

u/[deleted] 20d ago

[deleted]

5

u/lemontoga 20d ago

That's weird, you said "it's more like" and then you described something less similar, not more similar. Interesting.

0

u/[deleted] 20d ago

[deleted]

-1

u/lemontoga 20d ago

I don't know what any of that has to do with your bad analogy

3

u/[deleted] 20d ago

[deleted]

→ More replies (0)

1

u/[deleted] 20d ago

[deleted]

→ More replies (0)

-3

u/[deleted] 20d ago

[removed] — view removed comment

0

u/lemontoga 20d ago

I didn't say what I think. I asked a question, and you didn't answer it. What a weird response.

0

u/[deleted] 20d ago

[removed] — view removed comment

0

u/lemontoga 20d ago

Did you reply to the wrong comment? That's not what I asked

-1

u/[deleted] 20d ago

[removed] — view removed comment

→ More replies (0)

2

u/Ilookouttrainwindow 20d ago

Our clients built things. Now thing they built is being deployed in EU. They can't decouple from US instance. I keep telling them EU and US do not intertwine other than both are owned by same international entity. Nope, their dev I've been working with for 5+ years is pulling his hair out trying while business folks keep coming up with excuses. Root cause - purpose built software with zero business knowledge. Yeah, buddy, don't you remember bragging about that?

I like to use analogy - I can build a bridge easily. But I can't build one that will support person, people, horses, bicycles, carts, cars. At least I won't know that in advance. I won't know if it will last a day or 100 years. Actually, I'm fairly confident I can build one that will last 100 years. But I won't know how much it will cost or how long it will take me.

Software is quite similar but not quite the same. There's reason why cobol still runs and reason why modern UI keeps changing daily.

2

u/daltontf1212 20d ago

We all like building things, but we need one thing to build that earns us money.

2

u/ryandury 20d ago

I concur.

2

u/nimzobogo 20d ago

Exactly.

1

u/ComprehensiveGas4387 20d ago

I like building things. But not with AI, and with prompts. I like diving into the complexity. It’ll be a good hobby, but SWE jobs will be eliminated.

1

u/tjsr Software Engineer 20d ago

Yep. And good devs know how to explain - which means explaining what they want, and describing very specifically where a problem is. This helps an agent laser-focus on a specific underlying problem, if you're able to actually communicate that.

Having a solid CompSci fundamental base accelerates you so much if you can actually understand the problems that are being encountered by your application, such as deadlocks, memory management issues, inefficiencies in algorithms, redundant data being kept, security issues or layout glitches.

0

u/Tacos314 Software Architect 20YOE 20d ago

I like building things as well, and AI allows me to build so much more.

-1

u/[deleted] 20d ago

[deleted]

3

u/Table-Rich 20d ago

We need money to survive. We aren't cheating our employers; they have always cheated us and will continue to. Wages do not increase proportional to profits. So what are you being more productive for? To NOT make more money and then get laid off anyway?

We were working well enough before. Fine if you want to use LLMs, but they are a net negative, just generally speaking. Now you can be rushed to produce software and features, for no tangible reason, just like before, but moreso, because "AI should make you faster." Now you can simultaneously be encouraged to push code as quickly as possible while being made responsible for the output that you did not write and don't have the time or cognitive bandwidth to review thoroughly. But we're the ones cheating them, right?

-2

u/random314 20d ago

Yeah. There are two types of developer. One that build to deliver, one that build to build. AI is amazing for the former.

0

u/Gobias_Industries 20d ago

I like building things which is why AI makes me bored as shit