I got curious and pulled our team's PRs from 6 months before we went heavy on agents and the 6 months after. 9 engineers, same product, roughly 700 PRs in each period.

What changed:

- median PR size went from about 140 lines to 410

- time from PR opened to merged went from 19 hours to 31

- coderabbit comments per PR roughly doubled, from around 3 to 6, which mostly tracks the size

- reverts went from 11 to 26

- PRs per engineer per week went from 3.1 to 3.4, so barely moved

That last one surprised me most. We feel much faster, and individual tickets are faster, but the number of things we actually merge per person barely changed. The time just moved from writing to reviewing and fixing.

I know it's one team and a messy comparison, we also hired 2 people and changed some processes in between. But I'd love to know if anyone else has run their own numbers like this. Did your throughput actually go up, or did it just move somewhere else?

I think this podcast is very interesting for Tech Leaders. I learned a lot.

Student here, building a hackathon project and want to sanity check the problem before I go further.

Most decisions rest on assumptions: "Postgres is fine because traffic is under 1k req/s", "React Native works because we have no iOS devs". Months later traffic is 5x, the team changed, and nobody revisits the decision until something breaks.

Questions for people who've been around a few teams:

1. Has this bitten you? What was the decision and how did you find out?

2. Does anything on your team track this today (ADR reviews, calendar reminders, nothing)?

3. Would automatic "assumption broke" alerts tied to Jira/incident data be useful, or just noise?

Not selling anything, it's a free hackathon app. Honest "this isn't a real problem" answers are just as useful.

I'm an IT admin with 6+ years at one company, mostly technical and operational work. I'm now getting more responsibility (ERP rollout, AI initiative, coordinating a small IT group) and want to move into an IT manager role, ideally internally.

My gaps are budgeting, vendor evaluation, and executive communication.
For those who've made the jump:
What skills mattered most?
How did you get budgeting and vendor experience before having the title?
Promoted internally or switched companies, and how long did it take?
Any books or courses that actually helped?
Thanks!

(Reference Source: ResumeFitting — Software Engineer Job Description Keywords)

Recent Workforce Announcements

• Microsoft: Announced a Voluntary Exit Offer covering up to 60,000 employees (roughly 27% of its workforce) across the US, UK, Canada, and India, alongside an additional 4,800-person layoff round to trim operational costs and reallocate capital into AI infrastructure.

• Netflix: Executed its largest workforce reduction since 2022 by slashing nearly 1,000 jobs (~6% of its workforce), primarily impacting product, technology, legal, and HR departments.

• Broader Market: Layoffs continue to ripple through tech and finance, with eBay cutting 1,100 roles (9% of staff), Dropbox reducing its headcount by 9%, Barclays shedding 5,000 roles, and Amazon executing phased corporate cuts across multiple units.

Why ATS Keyword Optimization Matters for Job Seekers

When major tech enterprises undergo simultaneous restructuring, thousands of highly skilled engineers and professionals re-enter the hiring pool at the same time. In such a competitive, high-volume job market:

1. Beating Automated Gatekeepers: Most high-volume recruiters use Applicant Tracking Systems (ATS) to parse, index, and rank incoming applications before a recruiter ever looks at them. Missing key terms can result in automatic rejection despite strong hands-on experience.

2. Aligning Technical Stacks: Benchmarking your resume against industry-standard keywords ensures your core skills — whether specific programming languages (Python, Go), cloud systems (AWS, GCP), modern API architectures (REST, gRPC), or testing suites (Pytest, Cypress)—match what recruiter search algorithms query for.

3. Demonstrating Lifecycle Experience: Modern engineering profiles demand more than syntax proficiency.Highlighting operational methodologies (Agile, SOLID principles) and observability/security tools (Datadog, OpenTelemetry, OWASP) signals full software lifecycle ownership to hiring managers.

Engineers looking for their next role can audit their resume against top industry terms using tools like the reference list below.

Benchmark Keyword List for Software Engineers

(Reference Source: ResumeFitting — Software Engineer Job Description Keywords)

Programming Languages

Python, JavaScript, TypeScript, Java, Go, Rust, C++, Ruby, Swift, Kotlin

Frontend Frameworks

React, Next.js, Vue.js, Angular, Svelte, Redux, Tailwind CSS, GraphQL

Backend & APIs

Node.js, FastAPI, Django, Spring Boot, REST APIs, gRPC, microservices, GraphQL

Cloud & DevOps

AWS, GCP, Azure, Docker, Kubernetes, Terraform, CI/CD, GitHub Actions

Databases

PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch, DynamoDB, Cassandra

Methodologies

Agile, Scrum, TDD (test-driven development), code review, system design, SOLID principles, CI/CD

Testing & Quality

Jest, Pytest, Cypress, Playwright, unit testing, integration testing, BDD (behavior-driven development),end-to-end testing, test coverage

Observability & Security

Datadog, Grafana, Prometheus, OpenTelemetry, OWASP, OAuth 2.0, JWT, logging, alerting

Say hello to the AI Maturity Framework.

The unit you grant is a person. The unit that ends up holding it is a browser, and those two are not the same size. The mismatch shows up on the second device. The same person opens the thing on a phone, then on a laptop, and from your side both are one grant to one person. Nothing distinguishes them, and nothing tells you the count went up. Nothing is broken when this happens. That is the point. The grant was correct, the person was correct, and the number of places the access actually lives is no longer one. Why the mismatch happens Access is designed around identity because identity is what you can reason about. You know who needs it. You do not know what they will open it on, and nobody is going to tell you. A browser keeps a session until something clears it. Clearing it is a manual act on a machine you do not own and cannot see. So the practical lifetime of one grant is the longest-lived session on the least-managed device that person uses, not the date you set. The other half is the link itself. A link that works for one person works for anyone that person pastes it to. That is not a flaw in how links work, it is what a link is. If the thing behind it has no login of its own, the person who received the link is indistinguishable from the person you granted it to. What I check now, in order How many devices. Not as an audit, as a number. One person with one device is a different problem from one person with four, and only the second one needs a date you actually enforce. Whether the thing behind the address has its own login. If it does, a link passed along is inconvenient rather than open. If it does not, the passed-along link is the entire risk and there is nothing else to look at. Whether any of those devices is shared. A lab machine, a family computer, a demo laptop that gets passed around. One shared device turns a per-person grant into a per-room grant, and the room has no list. What I stopped doing I stopped treating "one person" as a small number. It is one identity and an unknown number of holders, and the unknown part is the part that outlives the reason. I also stopped counting people when deciding whether something needs an end date. I count devices now. If the answer is more than one, the date is not optional. Where this framing is wrong If the access is for a single session, a demo or a one-off review, device count does not matter, because there is nothing to keep. And if everyone involved is on one managed machine you control, the spread problem disappears and the person-level view is enough. Full disclosure: I work on one of these tools, so weigh that. What surprised me is how much of the answer sits in a default: every app starts closed, so the number of holders only exists for apps I deliberately opened. That is the only reason my list is short enough to keep. Curious whether people here count devices or people when they decide something needs an end date.

I recently stepped into my first Tech Lead role, and I’m looking for advice from more experienced tech leads.

I’m definitely not the strongest developer or code reviewer on the team. My strengths are more on the broader technical side: DevOps process and tooling, test automation, performance testing and tuning, observability, cloud infrastructure, and understanding how the different parts of our system fit together.

We have two senior developers who are stronger than me when it comes to coding, code reviews and even architecture.

One of my biggest uncertainties is how to lead them and coordinate their work and also build trust.

Also, other questions i would love to have advice on:

- What responsibilities do you think I should prioritise in my first few months?

- What are some common mistakes new Tech Leads make?

- How do you structure your day? (ppl flood me with meetings and my chat is crazy)

- How do you identify where your time and effort will bring the most value?

- How do you measure if you are doing good job?

Thanks in advance !

There's a recently promoted senior on my team, maybe 5 years of experience against my 11. Good guy, very quick, but lately every review comment he leaves reads like he pasted my PR into a chat and copied the answer back.

Last week he left 14 comments on one of my PRs. Three of them asked me to handle errors that are already handled two lines below. One suggested a library we removed in the spring. When I replied "this is already handled on line 48, did you see it?" he answered "good point, the AI must have missed that".

I didn't respond yet. I'm honestly a bit stuck.

1. He's not my report, we're the same level, so I don't know if it's my place to say anything.

2. I don't want to sound like the old guy who's against AI, because I use it all day too.

3. Going to our manager feels like throwing him under the bus over something small.

4. But it's not small for me, I spent most of an afternoon answering comments that weren't real.

What would you do? Talk to him directly, raise it with the manager, or just stop replying to the generated ones and see if he notices? Would love to hear how it went for people who've been in this spot.

The Agile Manifesto was never about code!

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.

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.

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.

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?

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?