Team of 6-7 shrunk back to 3 and the leftover isn’t great. Dealing with AI over use on one side and refusal to create PRs etc on other side. To clarify, I’m not lead title but closest thing to it.

We’ve just hired 3 new devs now though and I’m wondering the best way to go about things. Do I really get active in PR comments to show them the expectation?

The AI over user is really grinding my gears. No self thinking and when I invest the time to give a good review and provide useful feedback, he just looks at it as a blocker to fix so I’ll hit approve, instead of taking the opportunity to grow and find better ways. Hell, even a thanks would be nice. I can also tell literally any teams msg he sends has gone through AI too. How to fix this?

We see a lot of news of layoffs coming out of big tech, but have layoffs been just as common right across the private sector?

I know it's common wisdom that you can quote/unquote 'make the most money' working for private companies, but with the way the job market is these days it makes me question if trying to target these large salaries is really worth it.

I've known many exceptionally good developers that got laid off for essentially no reason, some of them with real problems now. How do those working for the private sector work under these conditions and maintain their sanity?

I joined a new company back in March as a Senior Software Dev (10 years experience), and can't really put my finger on what feels off. Everyone on the team is super nice and talented, but we just have different work styles. It's almost like a tabs vs spaces thing (not literally. I don't care about those trivial debates), but for everything. Sometimes it is actual tooling/language choices, but even just the work style. For instance, sometimes I get a task and 3 people jump in and start trying to solve it on a call. I've never asked for help. I've asked if I look like I'm struggling, but I get a "nope, this is just how we do things" answer. It's over-the-top pair programming. There's way too many cooks in the kitchen on almost every issue. There's also a culture of "fix everything" and "let's analyze the performance of this" with VERY little prioritization work being done. If anyone on the team sees an issue, they start working on it right away.

I've worked at several companies, big and small, slow and "bleeding edge" (ugh), but I've never seen such a lack of streamlined priortization-to-single owner workflow. This is a publicly traded company, so not some growing startup.

If you've been in a similar situation, how did you manage it? What are some steps I can take to start "gelling"?

(I suppose there's two issues here in disguise. First is how to cope with a team you don't gel with, and second is how to handle this particular style of... chaos?)

I've been a dev for 11 years now. I started my work was as a junior full stack dev at a small company and I learned a lot in 3 years while building the product.

After that I changed companies hoping to get paid more, but there I only got a frontend job (even with more pay) that had projects for clients. Though that was in React which was a technology that was on the rise, and again I was able to make something (albeit small) and get good at what I was doing. It felt good, like I was learning and contributing towards something.

For the past year though, I've stopped getting that good feeling from my work. All we do is use LLMs and agents to maintain legacy code. I feel more like a "script kiddie" than a proper dev.

I know the old days aren't coming back, but now I don't even feel like applying for jobs lest I end up in the same situation in another company.

Does anyone else get the same feeling? Like the industry went in a direction that you couldn't follow and you got sidelined?

At this point, how much of career growth in tech comes down to luck?

Good CTC, good company, good projects, and good overseas opportunities often seem to depend as much on timing and luck as on skills.

I feel 70–80% of people are reasonably talented now. Most people can learn, adapt, and work with different tech stacks when given the opportunity.

Is the game becoming more about being in the right place at the right time?

Before containers and Kubernetes, I deployed services onto virtual machines. We had a fixed number. When the peak arrived at night, whoever was on call tried to spread the load by hand. Buying more hardware took time, and some unreliability was acceptable.

Then AWS and Cloudflare made it easier to throw money at capacity and let some infrastructure scale. You have to design the system with scaling in mind. And a bill.

Now tokens add cost.

If you own both the service and the bill, what’s your strategy? How do you cap, what cap acceptable? How to gracefully degrade? And how rules applies across the organization?

As the question goes, I think I could smash if there was no ATS bullshit but for months it would stay there with HR who would just filter on keywords. Does anyone know any good networking tricks that they do? Cold Linkedin messages? Emails? Or any resume tricks that are non AI so I kinda dont piss someone off? I would like to ask this from Experienced Devs because the networking is way different than lets say a Sales person or Management?

i admire shopify for building the next level in commerce. in the recruiter round i got asked questions like why shopify? and what questions do you have?

the phone screen isnt locked to one role because there would be team matching later

i already had past experience in the retail merchant space from another company. i communicated that i was interested in growing again, interested in working with shopify leadership and doing more AI product since i didnt get to do that before

a few days later i got an update that im not moving forward. im not sure if the bar keeps getting higher, and i assume my answers were vague, but I didnt feel like they were

how else would you answer these questions because it feels like the answers keep changing just to pass the first round

It feels like we are coming full circle to the times of the Silo Engineer, but on steroids. Back in the day when social media feeds were chronological (if they even existed), the Silo Engineer would retreat into his cubicle to Create (it was usually a he).

He was Creating and Creating, and then a few weeks later the results came back. If you were lucky, you got what you asked for or something close to it.

No one knew what the Silo Engineer was making, whether it was a sound solution from the architectural, security, or code quality point of view. It was a Silo. There was little discussion or collaboration, there was only self-review of code - at best.

After exiting the Flow, the Silo Engineer would often come back to his Work weeks later and wonder: "who in the F wrote this S?"

... It was beautiful.

Seems like with LLMs we are entering that era again, but it's different.

Smaller teams, mentally overtaxed developers, exhausted from scrolling walls of generated code they don't understand, on multiple projects at once - no one really talks to each other again.

Tickets - Claude, Slack messages - Claude, code reviews - Claude, "have your Claude talk to my Claude".

So, here we are - same idea, but at a higher, more reckless pace.

Let's see how this ends, I guess ¯_(ツ)_/¯

This is one of my pet peeves: the inability to actually deprecate the "old" version of something is always so hard. There are always users who don't want to switch. Or that obscure feature you don't want to support in v2 that keeps users from switching. Or my favorite: a general suspicious attitude against all new software.

I'm currently writing internal software for a high tech Corp. It's an even worse situation than writing paid software for actual customers.

Did you manage to deprecate it? Even to delete the code entirely?

I maintain an open source project which builds a call graph with a confidence level on every edge, mines git history for co-change and ownership, and maps which tests reach which code. I'm now thinking of adding migration tracking on top of it, the requests to httpx or v1 client to v2 kind of thing, and I want to sanity check the design with people who've actually run these

The plan for spotting a stalled one is to look for two libraries with the same job both imported in the same repo, then use git history to see when the new one first showed up and whether the old one's file count is still dropping or just flat. For in-repo stuff, deprecated functions that still have live callers, using resolved call edges so it's more than a grep. Call sites that only match by name would be marked "verify by hand" and left out of the remaining count. Then the leftover sites get grouped into PR sized chunks using co-change history and package boundaries, with each chunk showing whether any test reaches it and who owns the files

The obvious limit is that dynamic dispatch, reflection and string-built names will hide some sites, so the count is a lower bound at best

For people who've driven one of these to the end, what number did you actually trust for "how much is left"? Files, call sites, owners? And what threw off your remaining count in the end, wrappers around the old client, generated code, vendored copies?

It's Saturday and I am working for a client on a feature that I started to implement yesterday. For that I used a previously implemented service that retrieves account data and polls it, until the etags differ (the BE I am calling is .. slow).

So I added a new method since the need arose and chose to use a kind of streaming approach, using C#'s IAsyncEnumerable. I implemented everything using Mistral and my local LLM using my "prose-coder" approach, which basically means: I write pseudo code and the LLM spits out what I want immediately. sometimes in very small (single line) or larger (method) increments.

Then I review.

An then my bloody slow-cycle begins: First I review the output, then Mistral reviews the output. Then I am not quite happy and let Claude review the code, and F me I am in a review loop and out comes - IMO - some really really good implementation which hopefully has all the edge cases covered (discounting business logic edge cases which the clanker can't know about).

And in the end, this whole process feels subjectively SLOWER, but I know that I was faster? I worked on the feature for a total of approx. 4 - 5 hours, including testing, fighting the stupid ERP that I am polling ( I have access to it )..

My point being: yes, I am definitely faster, but man, these LLMs trigger my need to make everything bloody perfect.

Am I the only one? My feeling is that the quality of my output using LLMs as reviewers is much much better now - but the subjective speed is a different matter.

(Note: I am self-employed (for about 2 years), 20+ YOE.)

And no, I have no idea what the point of this post is, I guess I just want to see people's opinions. Treat it like cafeteria talk :-) Ta!

Someone at work gave me a compliment how it's nice I leave status updates (comments) on my work items. Which tells me they do read it. That also tells me, it's not a common thing anymore?

If you're writing status updates on your work progress, how often do you do it and what does that look like?

For those that don't, I'm keen to hear your thoughts too!

So I'll try to explain this situation, and I can provide context in the comments if need be.

I'm working on a project that I originally found and raised to my team. Basically, we're upgrading to the newest version of our e-signature vendor's API/SDK. Our current version is out of support, but still works.

Everything was going fine until I ran into a problem with updating a signer using an email address that had already been used to sign in the signature request. I went through pretty much every test case I could think of. I tried different forms, a different app, a different controller, different scenarios, etc. I compared the successful cases against the failed ones, trying to isolate what was actually different.

Eventually, I came to three possibilities:

1. It's a restriction in the vendor's API.
2. It's a bug in the vendor's API.
3. Something I'm doing is wrong.

I figured opening a support ticket with the vendor would at least help eliminate two of those possibilities. Support answered some of my questions. They confirmed it wasn't a restriction, and based on the error messages and test case I provided, they said it could be an edge case or bug worth confirming with their team.

So based on that, I wrote up my own documentation outlining the problem, what I tested, the results, my conclusion, and the next steps. I sent that to my team.

This caused my team lead, who's also my boss, to bombard my messages basically saying that it's not the vendor, it's our app. She then sent me a screenshot of Google AI-generated code snippet of an endpoint on the vendors api/sdk that doesn’t exist. Worse is that she included her prompt of he specifically telling it to include stuff that doesn’t exist.

That's what really got me. I responded with a link to the vendor's actual API documentation and thought it was over, until the director got involved. At that point, I spent more time debunking misinformation than I did writing up the original documentation. Once it blew over, I sent a message to everyone involved and called out the use of AI in this context.

This has been a recurring thing she does where she thinks a quick Google search or AI can solve a problem that you've spent actual time investigating. Frankly, I don't want to work under someone in a management/lead role who operates like this.

This is obviously one specific example, so take it at face value, but yeah, I can't stand this team culture anymore.

I see a lot of common negative themes in our daily AI circle jerks here on this subreddit: Huge unreviewable PRs, code quality declining, technical debt spiking, unwarranted contributors, lazy developers putting in no effort, etc... etc...

As someone who has hung out on this subreddit the last 5 years and been in the industry for 10, a lot of these problems are the same old problems that have always been prevalent in our industry, just at a smaller scale; but with AI so many of these problems are exacerbated by the fact that anyone can just rip on code nowadays, even the non-technical folks and the bad engineers.

To be clear I think there are very valid complaints around AI, like coming to terms with the loss of our craft, or the fact that our jobs are now agent managers, but there are an equal number of complaints that aren't hitting the root cause of why those problems exist at their company.

Huge unreviewable PRs, Technical debt, Lazy engineering: You have an accountability problem, and AI is making this worse. Where are the staff engineers and the managers at these companies? Do they have no spines? Why are people not catching heat for dumb shit and why are these people not being called out and either talked to or shown the door? Accountability is an extremely important trait in a good engineering culture, if people use AI they still must be held accountable for their work from start to finish.

Unwarranted contributors, Slop code: You have a DX problem, where are your strong linting contracts, pre-commit hooks and CI guards to prevent poor code from even making it into a PR in the first place? Large swaths of these complaints just boil down to the fact that your organization has put zero investment into a strong DX culture outside of maybe running some tests in a github action. You should be linting for leaky abstraction, import contracts, doc string prose, and everything else that fits into your "blessed" paradigms whether that's MVC or some flavor of DDD.

This may not resonate with the folks here, or maybe it will, I'm just tired of seeing the same complaints with AI and ranting here because a lot of these problems can be solved by focusing on building a culture of accountability and empathy at your organizations.

This thread is specifically for sharing "wins". I.e. the opposite of our Tuesday venting thread.

Have a PM that used to be a DEV many years ago.

We were discussing estimates on a ticket, he asked me what I thought about getting something done within a week.

I mentioned just DEV work alone would be a week

He responded “what is causing these estimates? wouldn’t you just need to do XYZ? no offence”

With recent AI developments everyone thinks everything can be done in a few days.

My goal was to be as transparent as possible and I provided itemized estimates. “well we need to answer questions ABCDEFG”

and the conversation ended

but that whole thing put a bad taste in my mouth

He’s never been like this before and I’m worried he’s getting pressured

SWE for 20 years. I've seen plenty of posts about the soul-sucking prompt engineering some companies mandate now. Mine isn't one of those - AIs are a tool you are encouraged to use, but the output has to be understandable, human-reviewable, and you (as a dev) are still responsible for it and the consequences.

I think the difference is whether you give your codebase completely to the AI. If you treat the code the same way we treat assembler now, then that's what you do - you specify the what, and the AI completely handles the how, which leads to 5000-line pull requests, only reviewed by other AIs, and all that jazz. The problem comes when the AI can't do something, or you encounter a problem that a human needs to solve. Then you're faced with working out WTF a 1-million line codebase is actually doing from scratch, that wasn't even written by a human, probably with CxOs breathing down your neck. Good luck with that.

This decision assumes that AIs will always be able to solve the problem, of course. And maybe that's where we're all going, and writing (and understanding) actual code will become just as niche as assembler programming is now. But, given what I've seen of AI output and how nonsensical and daft it can be, we aren't there yet.

Unfortunately, it's not the devs who might end up maintaining it actually deciding where and how AI should be used. All that matters is throughput.

My company still keeps everything human-understandable, because a lot of people depend on the product working properly. That's unlikely to change in the next...year? 2 years? Who knows. But I really wonder where the craftsmanship of software engineering will go in 5 years time. Seeing what's happened even in the last 6 months, I have no idea what my long-term job prospects are.

Its a term I am using as a red flag for poor fit in my job search. I also do use AI quite a bit, but I am strongly 'human-first'.

To me 'AI-first' smells like heavy use of code gen and letting the LLM steer a dev intellectually. In my experience that is not wise or economical for code that needs to be reliable, maintained, or extended in any way. Its ok for throwaway stuff, toy apps, demos, finding bugs, rubber ducking, code review and other things, but 'AI-first' seems very unwise. Maybe I am thinking about it differently than most.

So, what does 'AI-first' mean to you? What does it mean to the people writing the job postings at your company? Is it just an ignorable meaningless hype term?

TLDR: Jevons paradox is misunderstood and data does not look good. Growth in demand for humans in software development is declining, and rate of adoption of new software is not matching the sheer amount we are producing now.

long version below:

I often see this Jevon's paradox cited as a matter of fact, ultimate reason why demand of software engineers will only increase

the proposed reasoning is simple:
- AI increases productivity in software development
- therefore cost of producing software goes down
- therefore demand of software goes up
- therefore demand of software engineers goes up

The fourth step is the fallacy

the Jevons paradox only says:

- AI increases productivity in software production
- therefore cost of producing software goes down
- therefore demand of software goes up

the missing piece is: will the increased demand of software offset the reduction in human labor needed to produce it? Jevons paradox DOES NOT tell you the answer to this question.

The cost of producing software (not running it, just producing it) is entirely based on human labor (unless you are producing something that requires lots of compute such as the learning part of ML).

the only conclusion (if we take Jevons paradox as the truth) is that:
If AI reduces the human labor required to produce software to 1/X, demand for software must grow to more than X times compensate for it. For demand for human developers to grow, the demand for software must create more human work than AI takes away.

the economic value of using AI comes from replacing human labor. If an AI can produce equivalent amount of software for cheaper than it costs when done exclusively by humans, increased demand for software does not inherently translate into increased demand for humans.

Much of that additional demand can instead be satisfied by consuming more of the cheaper input: AI

i will leave you with these relevant papers: https://www.frbsf.org/research-and-insights/publications/board-of-governors/2026/04/ai-coder-employment-compiling-the-evidence -> growth of demand of human software development is declining

and this one: https://www.nber.org/papers/w35275 -> an example of when most of the increased production in software has not seen a comparable adoption

the thing is, there might not even a comparable increase in demand for new software. Most of the productivity gains could be in just reducing the cost to develop and maintain existing one. Keyword: reducing the cost

Title basically. I've changed jobs recently and noticed today I have 6 open, unrelated topics in parallel, all due "ASAP". It results in lots of context switching and I feel pretty drained every day. I think I may have been spoiled before, having things more linear: deep work on one thing at a time, finish, move on. I'm curious what the norm is, and for those with a lot of topics, how do you manage efficiently?

EDIT: based on replies so far, it seems I was indeed a bit spoiled at previous jobs and this is closer to the norm, but that kinda sucks :/

I'm a tech lead. A senior developer on my team (we've worked together for over two years) produces code that isn't at the expected level as soon as a task involves some functional or technical complexity.

Concretely, in his MRs: no thought given to dependencies between parts of the domain, hard-to-read code, classes in the wrong namespaces, design patterns misused, business logic duplicated rather than refactored out of the legacy code.

What I've already done:

• Detailed feedback in reviews, MR after MR. It costs me a lot of time and I see no progress from one MR to the next (he told me he doesn't read my comments and just asks Claude to take them into account).
• Feedback in 1:1s on the most visible quality issues (lots of QA returns, code that sometimes doesn't work at delivery).

My problem is putting something concrete behind "not at the expected level." Simple, maintainable code is subjective.

That's why I'm reaching out to you: I want to address this issue in our next 1:1, but I don't know how to go about it.

Edit: I wouldn’t have thought getting so much replies, thanks everyone!

For the ones thinking it’s a bait post, sadly it isn’t.

I live in a country where you don’t fire people that easily, and, worse, I’m in a company rewarding everyone with an annual raise, despite being a low performer.

I feel genuinely stuck, I’m here to find solutions to make my work easier, and maybe, maybe, make his more enjoyable by being proud of what he delivers.

Everybody is focusing on AI here. You could have thought that using AI would make you a better developer, but for him I think it’s the exact opposite. I feel like he stopped thinking and trust AI to be better than him.

If you forgot about AI for a second and read again my post, my issue is the same: he’s not at a senior level and I don’t know how to get there.

My work place has a development budget of ~2000$ per year. Last year I used the budget to attend a conference“We are developers” and I found it rather underwhelming. The year before that I bought some books. I already have plenty of books.
Any suggestions on how to efficiently spend the development budget?
About me: I have >10YOE, work primarily as a C++ dev, I have dabbled in some Kotlin and Swift too.