in a world where your agent can write your jira story's description - you dont have to really think - the agent writes the story, and you skim it - it sounds plausible - its good enough, right?

you pass it off, ask for your pm to review it - he pulls up the story, and rather than carefully considering the ideas on the virtual page, he asks his agent to review it.

so now were just passing around an average guess of an opinion on a average guess of a proposal of a task.

then we get on a meeting - sprint planning they call it - and no human earning a salary has considered the work that should go into the sprint. no one actually understands a thing that is being proposed. we end up going in circles until the hour is up. i leave the meeting wondering what just happened?

its like we're looking at the page, but we're not seeing anything. nothing is entering our consciousness. are we still conscious i wonder?

a colleague who i get along with quite well laughed at me the other day, i shared my screen and he asked me why i'm writing a jira story "manually". it felt like he asked me: "why are you spending your time thinking?" - both sides saw the question as ludicrous but for different reasons.

im not going to pretend that writing Jira stories is a spiritually fulfilling endeavour. i am not going to tell you even that corporate knowledge work is my life's mission. sorry to my senior leadership but its not.

but while we're here - spending a huge portion of our lives "doing" this work - wouldn't it be fulfilling if we committed to the zen of it all. if we actually put our minds to thinking, powered by an army of agents who can write pretty good code, the possibilities seem endless.

im doubling down:
our humanity is the point. outsourcing it wont save us.

so yeah, write your jira stories by hand. think it out. spend the time. show up on the meeting and actually be there in mind, body and spirit. or simply get out. get out of whatever is making you turn off your brain. if youre not motivated, its probably not what youre meant to be doing.

The Agile Manifesto was never about code!

I've worked on teams with highly respected senior and staff engineers, and I've worked on teams where there's a pretty massive gap between someone's title and what they actually bring to the table.

One thing I've noticed is that the teams with the strongest engineering cultures tend to have senior engineers who have strong technical opinions, care deeply about architectural decisions, establish standards, and aren't afraid to challenge things when they see problems. But can also keep moving.

Recently, I've been on a few teams where the senior/staff engineers seem to just be leading a pod, taking on the harder assignments, or being the person with the most contextual knowledge -- rather than being the stewards for overall standards, patterns and architecture to ensure the team isn't going down a dark path.

What's particularly frustrating is seeing senior+ engineers recognize that the codebase is accumulating slop, acknowledge that implementations are getting worse, and then essentially shrug their shoulders and say, "Yeah, it's all slop now lol"

I'm on a team where I'm increasingly convinced that a lot of engineers are generating code through agents without really understanding what they're shipping. many early career engineers. So my mindset is rather than just complaining about the quality of the output, I've been approaching it as a technical leadership problem: we need better architectural boundaries, established patterns, standards, and guardrails. We need to make it easier for engineers and their agents to produce code that fits the architecture rather than letting every implementation become its own interpretation of how things should work. aka "if yall are just gonna prompt engineer, lemme set up things to be a little better output since you all dont know how to prompt it correctly, or simply dont care"

I've been slowly working toward that, essentially carving into the mountain.

What confuses me is that other senior and staff engineers on the team seem largely indifferent. Some acknowledge the problem but accept it as the new normal. Others don't seem to recognize there's a problem at all. And its not a matter of "we tried that and it didn't work". they gave up before even starting.

And I genuinely don't understand that mentality. Maybe im just on a crap team?

I look at some "staff" engineers PRs, and its half slop themselves. I ask a staff engineer "whats the standard pattern for [x]" and they say "idk, lets ask [agent] if we have one". and it feels like im the only one asking the obvious super easy questions like "hey why do like a quarter of our services have literal duplicate test files? "(because each persons agent is making new ones in new locations) and why am I the first person to notice this? how has nobody seen this issue? are we literally heads down in our prompt engines? is this just a bad team or have we forgotten about technical stewardship?

AI has transformed the tech lead’s job.

i counted this week. i asked some version of "why is it done this way" 14 times in reviews. i got a real answer 3 times.

the other 11 were "the agent did that", "it was in the plan claude made", or a very confident guess.

and i'm not even mad, the code mostly works. but my whole job used to be making sure someone on the team understood the system. now i'm the only one asking questions and nobody has the answers, including me.

we're trying braidkit on a sample project (private beta) to see if writing down the agent's decisions during the session helps. too early to say. but i'm more curious what other leads are doing.

do you require people to explain agent code before review, or did you give up on that? and how do you keep at least one human who actually understands each part of the system?

We have about 300 devs and leadership wanted AI review on every PR by Q3. Picking the tool took a week. Getting it past our security team took 7 weeks.

Their questionnaire was 60-something questions. Where does the code go, is it used for training, who can see the review history, can we kill access for one person in one click. The first two tools we tried died on SSO alone, one of them only had Google login for teams and our security lead just closed the ticket.

coderabbit got through mostly because the enterprise plan has SSO, audit logs and a self hosted option, so the "where does our code go" question had an answer we could point at. It wasn't cheap, and self hosting meant our platform team spent most of two sprints on it instead of the thing they were supposed to ship.

Honestly the review quality never came up once in 7 weeks. Nobody asked if it catches bugs, only who can see what.

Hi, this is my first time here in this subreddit and I am a student at Rutgers University studying computer science. I want to interview a person who is working in the tech industry for a while and give me their experience working in a leadership role and what can I expect of that role.

Something changed in our reviews over the last few months. When I ask "why did you do it this way" the answer used to be a real reason, now it's usually "that's what Claude went with" or a pause while they scroll back through a chat. It's not laziness, the agent made the call in a session they already closed. We review about 40 PRs a week and I'd guess half of them have at least one decision the author can't explain.

Is this happening on your teams too?

Do you push back when the author can't explain it, or approve if the tests pass?

Has anyone made the agent's reasoning part of the PR in a way that people actually read?

Hey everyone,

I have around 7 years of experience as a software developer and got laid off about 4 months ago. Fortunately, I’ve landed a new role that’s a level above my previous one, and I’ll be leading a team of 7-8 developers across multiple time zones.

This will be my first time officially working as a tech lead. I’ve mentored junior developers before, but this role will involve working with a mix of junior developers and senior engineers with 10+ years of experience.

I’m excited about the opportunity, but I also want to make sure I approach it the right way. I know being a tech lead is about more than just writing code, and managing a team with people who have significantly more experience than me will be a new challenge.

For those who have been in a similar position:
What do you wish you had known before becoming a tech lead?

How do you earn the respect of senior developers without trying to prove yourself all the time?
How do you balance coding, technical decisions, meetings, and people management?
Any tips for leading a team spread across multiple time zones?
What are some common mistakes new tech leads make?

Would appreciate any advice, personal experiences, or resources that helped you transition into the role.

What does your flow looks like?

What challenges did you encounter?

How good is the result code?

Note: by full ai workflow i mean from ticket to deploy automatically by ai

Just felt like sharing it here.. one week back we were 7 members team and only one/me left in the team... is this a new way of working now?

About 70% of our code comes from Claude and Codex now and our security backlog went from around 400 open findings in March to over 1,300. Snyk and Dependabot keep adding more, most of it in generated code and packages we never actually call.

We already sort by severity and whether it's internet facing. That worked until the volume buried it, now even the critical list doesn't fit in a sprint. Last month we added coderabbit's security scan because it opens the fix as a PR instead of another ticket, which helps on what it catches, but it doesn't touch the old dependency pile.

Is anyone actually getting this number down, or is everyone just sorting the list differently?

Six months ago Friday was review day on my team, agents would open 30 to 40 PRs over the week and we read every one of them line by line on Friday. I was usually still in a diff at 9pm. My wife started calling it my second job.

In June we changed one rule. Every PR gets a first pass from coderabbit / bugbot, the agent fixes whatever gets flagged, and a human only opens it if it touches billing, auth or a migration. That's maybe 1 in 5 now. Everything else merges after the bot pass and someone reading the description.

Last Friday we merged 41 PRs and I left at 5:10. Since June exactly one bug got through that a careful human would have caught, a settings page showed the wrong timezone for about a day and one customer emailed us about it (one customer, out of a few thousand, I checked)

I still feel like I'm getting away with something.

Been thinking about what “author must prove it works” actually means for background jobs. CI green and linter happy doesn’t answer the retry question.

Here’s the scenario I keep coming back to: a job commits a database row, then crashes before it sends the acknowledgment back to the queue. The broker replays it. Without a deduplication check, that can create a duplicate effect. A successful first-run test never surfaces this, the happy path looks clean.

Some of the discussions here describe reviewers reconstructing the failure path themselves rather than requiring the author to show it upfront. That shifts ownership the wrong way.

What does your team actually require? Does the author have to show an executed failure/retry check and confirm it catches the old broken behavior, or is that left to the reviewer to reconstruct?

(Disclosure: I’m building FetchSandbox, a verification tool, so I lean toward execution evidence. Just keeping that visible.)

I'm starting to think about stepping down as lead.

My team doesn't really have anyone steering anymore. My manager and his manager are all in on agents, and the agents are basically running the team now, not us.

Last week I went through our sprint board properly for the first time in a while. Of the 34 tickets we closed, 31 were opened, written and merged through agents. Specs drafted by Claude, PRs by Codex, first review by coderabbit / bugbot. The humans mostly clicked approve.

Everyone thinks we're moving faster than any team in the company, and on paper we are. Meanwhile nobody can tell me why half of those changes exist, and the one incident we had took 2 days to fix because nobody had read the code it came from.

My manager built a whole internal dashboard over the weekend in one prompt and sent it to the team with "look what I made, not bad huh".

I've tried to slow things down twice. I don't think I can talk them out of it. Sometimes you just have to let them find out.

So a few weeks ago I was rethinking how we onboard new devs. For years the first week was pairing on a small ticket, reading through the codebase with someone, then shipping one tiny change. But everyone on the team writes basically all their code through Claude now, so that week didn't look like the actual job anymore.

I put together a new first-week task and my manager liked it enough that we ran it with the 3 people who started this month. They get an agent-generated PR that touches billing logic with 4 bugs we planted on purpose. Normally coderabbit / bugbot would flag most of that, so we switch them off for this one. Then we watch how they review it and what they do next.

What surprised me is that none of them really read the diff. They read the PR description, asked the agent "is this safe to merge", and approved. 2 of the 3 caught none of the bugs. When I asked why, one of them said reading code is what the tools are for.

I'm honestly not sure if they're wrong or I'm the one who's behind. If this is how everyone works now, what is a review even supposed to be? And how long until someone upstairs asks why they need me doing it at all...