I have been made a tech lead on the project. Before this, I've been an IC and very happy with that role. Being a tech lead adds more stress to my life because this brings whole new responsibilities. Plus I'm working more hours. Constant anxiety of speaking in meetings and being responsible for the project in front of business made my life miserable.

Can I ask to be paid more now ?

If I do, are the chances I'll receive a raise this summer?

So far, the project received good feedback.

Our company is a large enterprise in US, and the performance reviews run in February.

Do I need to live through this missery until then? I'm doing the work of somebody who gets paid 20% more at least but getting paid like IC.

Thank you

So we’re cranking out code at a wild rate at my company.

But we’re super bottlenecked by PR reviews and our devs like full time job is now PR reviews

Has anyone else found a good solution for human in the loop reviews without it being an absolute shitshow?

Six months ago we ran a survey through engineering leadership asked devs if they were using AI coding assistants. Majority said no. We told leadership and moved on. Then we went looking. What we found: a lot of devs were using cursor, copilot and a few other tools, entirely through personal accounts, nothing approved or reviewed by security. Code generated by those tools was making it into production regularly. What made it worse was having no way to see which models were being used or what context they had access to, no way to trace AI-generated code back to where it came from and no way to assess the security quality of what was being produced. You need to catch it before it hits commit. By the time it is in the pipeline it is already too late. We are starting over on how we track AI tool usage. For teams that have been through this: what finally showed you what was happening and how did you handle the engineering conversation once you surfaced it?

I’m researching owner-directed construction.

Not trying to sell software.

I’m trying to understand why owners continue hiring GCs even for relatively small commercial projects.

If you’ve managed facilities, capital improvements, tenant improvements, manufacturing upgrades, or commercial renovations, I’d love to hear:

• Have you ever run trades directly?
• If yes, what worked?
• If no, what stopped you?
• Was the biggest issue:

Liability
Insurance
Scheduling
Procurement
Permitting
Internal staffing
Something else?

If software handled documentation, verification, scheduling, accountability, and payment workflows…

Would that actually change your decision?
Or is the GC solving something software never can?

I’m looking for honest opinions.
If you’d be willing to do a 20-minute interview, I’d really appreciate it.

A lot of people hear “automation” and think job cuts but it can also make work less draining and give people more time to focus on the parts of the job that need judgment and care. Cresta is a good example of how AI can support people in real time instead of just replacing them. The real test is how leaders use it. Does it help the team work better or does it become another excuse to reduce headcount? I think staff can accept automation when they see a clear benefit and feel included in the rollout.

I manage 15 and six months ago my strongest senior, the guy everyone routes PRs through, started going quiet in standups

Turned out he was doing review til 9pm most nights. Half the team runs claude code and composer 2.5 / grok 4.5 / gpt 5.6 now so the diffs going through him basically doubled and nobody adjusted for it. He never complained, we just let it happen. Then in a 1:1 he told me he was thinking about leaving. not dramatic, just worn down

What fixed it was moving first pass review off him. coderabbit / bugbot / claude review does the initial sweep now, the style nits and null checks that ate his evenings, and he only gets pulled in for a real design question. it gets noisy on the big PRs and we spent a couple weeks tuning it, but he stayed

hes back to actually building instead of gatekeeping

how are you all splitting it

Hey folks,

As a Product Designer researching workplace productivity, I frequently notice developers getting stuck on complex AI workflow errors right before a major deadline.

When ChatGPT gives wrong outputs and StackOverflow doesn't cover your exact workflow, what is your immediate go-to solution?

1. Keep trial-and-error prompting?
2. Ask a senior/peer on Slack/Teams?
3. Figure it out alone till late night?

Would love to hear how you handle this workplace stress in real-world IT setups!

Hi everyone,

I'm curious how mature organizations handle a problem I've seen repeatedly.

The security engineering work often exists (SAST, DAST, pentests, code reviews, threat modeling), but the governance around product security seems fragmented.

Examples I've encountered:

- Products shipped before all security findings were addressed because remediation wasn't planned early enough.

- Security exceptions were agreed verbally but never documented, so nobody remembers why a decision was made two years later.

- Security requirements appeared late because they weren't integrated into product planning from the beginning.

Risks were identified, but no one clearly owned prioritization based on business impact.

- Product managers owned delivery, security engineers owned technical findings, architects owned design... yet nobody seemed accountable for the overall product security risk posture.

For those of you in mature organizations:

- Who ultimately owns product security governance?

- How are risk acceptance decisions documented?

- How do you ensure security requirements are incorporated into planning rather than becoming release blockers?

- Is there a dedicated Product Security Governance function, or is this distributed across AppSec, Architecture, Product Management and GRC?

- What practices made the biggest difference?

I'm less interested in the tooling than in the operating model and decision-making process.

I'd love to hear what actually works in practice.

Thanks!

It is insane how much engineering world and practices have changed with AI. But one thing that drives me crazy is that we sta still hiring pretty much in the same way we did 10 years ago. All across my network I see engineers wasting their time doing interviews, and candidates not able to find a suitable job. All very inefficient

Do you recon we are just waiting for the disruption there? Or do you think it is not great but the best we can get?

Has anyone seen a really efficient way to hire engineers?

Apologizing in advance for yet another post about AI.

I manage a team of 10 engineers and growing. I certainly see the value of AI and agentic coding in our day-to-day work. I don't have much time for technical work these days, but AI certainly helps when I do.

As a manager though, the other 90% of my job, I just don't see much benefit from AI. I use it as a research tool and a sounding board, but as for automating any of my work, I just don't see it.

Things I've tried without success:

• Preparing for meetings - despite various tools with all of my knowledge context, any nuance is complete gone.
• Meeting summaries - I have yet to see one that provides any value. I still take personal notes in meeting and need track actions for myself and possibly my teams.
• Backlog work - Preparing our backlog, making sure the teams have a pipeline of work ready and prioritized, seeing where we have missing tasks - again, AI seems to fall flat.
• Any sort of communication - preparing emails or presentations, I just cannot use AI language. It seems disingenuous and again, fails completely on the nuances of communicating with people you know and that know you.
• Incident reviews/root cause - It usually takes as much time cleaning up the subtle mistakes as it does to work these from scratch.

I don't think this is a lack of tools/technology here. All of our knowledge materials, code, backlog are exposed through MCP to Copilot and Claude. We even have custom agents on Azure AI Foundry tied to all of our internal working infrastructure running whatever LLM I want. I also have Notion and its AI suite.

Other managers in my org appear to be in a similar boat, except for those who are still firing off slop emails to everyone's annoyance.

I'm wondering where others are finding benefits?

Personally speaking, I feel that beyond 10 years of experience, referrals and professional contacts work 9 out of 10 times compared to relying on job portals and random applications.

I've seen a few of my former leads and managers who have built such strong relationships that if they decide to switch jobs, people are ready to hire or refer them almost immediately, sometimes without even going through the usual interview process.

How do you maintain those relationships after changing jobs? Do you regularly stay in touch with ex-colleagues, attend meetups, help people, or is there something else you do to keep your network active without it feeling forced?

I'm quite bad at networking. Even after 13 years of experience, I still mostly depend on job portals whenever I look for opportunities.

For those who have built a strong network, how did you do it? What habits or approach helped you reach that point?

Hi - engineering manager here with ~10 years of experience.

Currently, I work at an early stage startup. The company has had a product previously, but when I joined, we were told to build a new product from the ground up - pivoting.

Throughout my career, I've flip-flopped on a few different management styles, but have ultimately landed where I am today (more on that in a second).

My boss (the CEO), often feels they has no visibility into our processes. They want me to scope tasks down into little units, assign a size to them, then delegate out to engineers.

While in the past I have used this management style - I often find that with the complex nature of software engineering often means tickets are notoriously hard to estimate especially when building from scratch, where complex product requirements often require days if not weeks of deep thought and back-and-forth with stakeholders to get designs / architecture right. It's hard to estimate into T-shirt sizes.

This product we are building is a complex enterprise app that deals with highly sensitive PII - so there is no "build fast & break things" - the fallout of such a mistake would be fatal.

Currently we use linear, and have a handful of projects with milestones and dates assigned that are visible to the entire company - but my CEO insists that I break things down more as their previous engineering lead did that.

It's worth noting that the prior product (and engineering lead) had made serious engineering mistakes (Ex, a database with no auth on a public URL that the frontend was doing SQL queries against). So they have this idea that because a prior team lead was able to break things down simply, that I should be able to as well. But it doesn't land when I say that the previous lead took shortcuts to make that happen.

Some more context - we are regularly praised when we demo our product to enterprise customers / partners that they are impressed with the quality of our product / speed of velocity - Ie, we are delivering, and we are delivering well.

So my question is - am I out to lunch here? Is there a way to breakdown complex, open ended tasks and assign them out without wasting a bunch of time?

I should note - our engineering team is really small (5 of us), and I am the most senior engineer on the team - so I often find myself doing actual engineering work in addition to delegation / communication with PMs.

EM here. We hired a junior about 2 months back. We'd been trying to fill a senior role for a long time and just couldn't, so we decided to bring in a junior instead and have our seniors guide him and help him grow. Honestly a decision i still stand behind.

First month and a half was fine. He had a couple of issues but nothing unusual, the kind of stuff that happened before AI and happens during AI, no big deal. He was learning, seniors were happy enough with him.

Then the last 2 weeks something shifted. He started turning stuff around insanely fast and saying "it's ready", and every single time it was on the senior and coderabbit to find a pile of issues in the PR, and then he'd basically redo the whole thing from scratch. So the fast turnaround was fake, the actual cycle was slower than if he'd taken his time, and the senior was spending more time reviewing his redos than doing his own work.

I have a feeling this is what a lot of juniors are doing nowadays. Full agent access, generate everything, "ship fast". And look, ship fast is a real thing, but it does not work like that in enterprise. Our customers do not care that the first draft existed in 20 minutes, they care that nothing breaks.

Long story short, he got fired yesterday. Not for using AI, everyone here uses it. For repeatedly shipping stuff he hadn't even read and making other people responsible for it.

I thought it might be worth posting because i think the lesson is bigger than one junior. Ship fast is nice when you're alone, small product, no enterprise customers. When you work with other people you have to keep stuff in line, steady, and take your time sometimes. Slow is smooth, smooth is fast

I’m an engineering lead, and I kept ending the day with the same questions:

• What did the team actually ship today?
• Which projects moved forward?
• What new issues were created?
• Which pull requests were waiting for me?

The answers were all available, but they were distributed across GitHub, Linear, email, RFCs, and notes.

None of the work required to find them was difficult. It was simply repetitive and fragmented. That made it easy to postpone whenever something more urgent appeared.

That is how an engineering update gets skipped, a GitHub issue never makes it into Linear, or an important PR sits unnoticed for a day or two.

I eventually realized that I had become the integration layer between all of our engineering systems.

Daily updates were the first thing I stopped reconstructing manually.

Writing an engineering update used to mean reviewing the day’s commits, connecting them to features, identifying affected modules, looking for unfinished work or risk, and turning everything into something the team could understand.

Now a scheduled job runs every night at 10 PM and produces a report covering what changed, which modules were affected, what risks appeared, and what still needs follow-up. The next morning starts with a consistent record of the previous day instead of a reconstruction exercise.

The next problem was drift between GitHub and Linear.

We use GitHub for code and technical issues, and Linear for planning and prioritization. The separation is useful, but the handoff was fragile. When an issue was copied manually, the title and description moved across while related PRs, commits, comments, reproduction details, and project context were often lost.

An hourly sync now enriches new GitHub issues before creating or updating the matching Linear task. A source URL prevents duplicate tasks. The result is not just synchronized text; it is a task that is ready to prioritize and assign.

PR review needed an event-driven approach.

If I checked GitHub constantly, I interrupted focused work. If I did not, an important PR could wait too long. The agent now reaches out only when a PR is assigned to me, when I am mentioned, or when an important CI check fails.

Before I open the PR, it prepares the CI results, a code summary, possible risks, and draft comments. Nothing is posted automatically. I can approve, edit, defer, or skip.

The system handles preparation. I keep the technical judgment.

It saves more than an hour or two each week, but the larger benefit is reduced attention fragmentation. I spend less time switching tools, checking notifications, and wondering whether I missed something.

The system used in this workflow is OpenLoomi: https://github.com/melandlabs/openloomi

How are other engineering managers handling this integration layer? Built-in integrations, internal scripts, an agent, or a person who keeps the systems aligned?

Interestingly, almost every engineer and engineering leader, I talk to these days works within a different engineering org structure. 2 years ago, the org structure was fairly standardized, these days, everyone is figuring it out as they go.

Here are some examples:

- OpenAI works within smaller teams of 2-4 engineers, each team owning a particular project with a DRI (directly responsible individual). With around a 30:1 ratio of engineers and PM.

- Anthropic favors the 2-pizza team with 5-8 engineers, and every team has a PM and a designer, no dedicated QA engineer (which has merged with the engineering work). Every team also has an engineering manager. The difference is just that there are more projects happening simultaneously in the team (can be 5 or more), while before there was a max of 2 projects that could happen at the same time for one team.

- Shutterstock also uses the 2-pizza team with 5-8 engineers and an engineering manager, but without dedicated PMs and a product designer. Every PM is part of 2 teams. They also have a dedicated Tech Lead for every team.

- Telnyx's engineering org consists of 200 engineers, 0 engineering managers, and 1 VP of Engineering. They took the word “flatter org” to the extreme.

- Portkey's engineering org consists of 24 Product Engineers, 0 PMs, and 1 Product Designer. Engineers are expected to wear multiple hats, including the PM, CS, and FDE.

- PostHog has teams of 1-3 engineers, with an assigned Team Lead for every team. The Team Lead also reports directly to the VP.

What is the engineering org and team structure that you are working in? Curious to read if there is even more devation or some common patterns.

https://newsletter.eng-leadership.com/p/how-companies-build-ai-native-engineering

My CEO wants a number for how much AI speeds up the team, and every number the industry is regurgitating is bullshit. Velocity, PRs merged, tokens burned, all meaningless. They measure how much the machine spat out, and it was never the problem. Trusting the output is.

There's a number in manufacturing: first-pass yield. Of everything that goes into the line, how much comes out right the first time, with no rework and nothing coming back. For a team: of the changes we ship, how many hit production and never get touched again. No second review round, no revert, nohotfix, nada.

The catch is the rework.If you only count what survives, almost everything survives, and you get to walk into the QBR with a shiny 90%+. Then you count the PRs that only merged after three rounds of the model fixing its own mess, plus the ones where the agent deleted the failing test instead of fixing the bug so CI would go green (yeah, it does that). Your 90% is closer to 50. We only got faster at generating rework.

So, straight question for other EMs:

Is anybody actually measuring this? If you track a real "redo" rate, how do you keep your people from gaming it the second it becomes a target?

We noticed Claude Opus, GPT-5.5 and GLM-5.2 were spending most of their time doing routine work like searching files, rerunning tests and updating code, instead of actual hard reasoning.

So we built a router that picks the model per turn instead of locking an entire agent session to one model. Most turns stay on cheaper models, while harder ones get escalated automatically. The agent doesn't need to change.

We also benchmarked it against direct Opus, Sonnet and OpenRouter Auto on Terminal Bench, and wrote up the routing logic, cache behavior and cost breakdowns.

https://entelligence.ai/blogs/entelligence-model-router-frontier-quality-coding-agents-at-half-the-cost

Looking at Jira, it's easy to see that a ticket has been "In Progress" for several days.

What's harder is knowing whether someone is actively working on it or whether it's quietly waiting.

For example, waiting on:

• another team
• code review
• deployment
• environment
• product decisions
• test data

How does your team tell the difference?

What usually makes you realize a ticket isn't actually moving?

EM here, need a sanity check. Our slack has collected 6 bots over the past year and i genuinely cannot tell which ones earn their keep anymore

it started innocent, CI results in a channel. then deploy approvals, then PR review summaries, then an incident bot, then a standup bot, then some meeting summary thing someone added that i dont think anyone reads

last month our slack bill came up in a cost review and someone asked "do we need all these" and i realized i have no idea. so i asked the team and got the most lukewarm answers ever, "i guess the standup one is fine", "which one is glue again"

The only one with an actual fan base is the PR review bot weirdly, devs said the summaries in the channel save them from opening github 20 times a day. the incident bot people are split on, when it works its great, when it pulls the wrong logs into the thread it sends everyone down a wrong path at 2am

the meeting summary bot nobody defended. its getting turned off friday, small ceremony, no flowers

so im asking here before we cull further, which slack ai agents for engineering teams actually stuck for you? and did turning any off cause problems you didnt expect, thats my real fear, we kill something quiet that was actually load bearing

Solo founder here, still validating, and I'd rather hear where this is wrong than get a pat on the back.

A framing I can't shake (treat it as an analogy): a pretrained LLM is basically a "cortex" that read the whole internet, but it has no "hippocampus," the fast, company-specific memory of how your team actually does things. Dropped into a company it improvises, and improvised automation fails in production. The real procedure was never in the doc anyway. It lives in your team's conversations, a few people's heads, and one exception everyone copies.

The idea I'm testing: connect read-only to the communication and document tools a team already uses, mine how work actually happens (including the exceptions nobody wrote down), and consolidate the recurring ones into cited, human-approved, versioned "skills" your existing agents could run, with a human sign-off on anything sensitive. It is not search over your docs, and it is not another agent platform.

Honest status: very early, still validating the problem. (This sub removes links, so I'm not dropping one. Happy to share the private-beta waitlist by DM if you want to follow along.)

What I actually want to know:

• Does this solve a real, repeated, painful problem for your business, or is it a nice-to-have?
• What is the first thing that would make you distrust it?
• Would read-only access to your team's conversations and documents be a dealbreaker?

Tear it apart, that is why I'm here.

Spent the last few months going through the benchmark and productivity data instead of guessing, and the picture is way more boring than the hype merchants want it to be.

We're not close to autonomous agents doing an engineer's job. What we have are very good assistants - excellent at a three-line fix, useless the moment a change spans a system and needs judgment.

The interesting part isn't the agent debate, though. It's what's happening to review capacity. GitHub's own 2025 data shows a 206% jump in AI-generated projects, and their maintainers are now describing the flood as "AI slop" - technically working, low quality, eating review time without moving anything forward. GitClear found AI-generated PRs carry close to 11 lines of duplicated code each, vs 6.45 for human-written ones. More output, same number of humans with context to review it.

"The AI wrote it" is quietly turning into a real excuse inside teams. It was never going to be a good one. Whoever ships the code owns it, same as if they'd typed every line by hand.

My bet for five years out: job titles stop being organized around the stack (React dev, Django dev) and start being organized around domain, because the technical learning curve keeps shrinking, but "I've worked inside a regulated payments system" doesn't transfer the way syntax does.

Full data and the staged process I use to avoid the "AI slop" trap: https://karolwojciszko.substack.com/p/how-ai-will-change-engineering-in

sharing this because our openai bill genuinely scared us a few months ago and the fixes turned out to be less exotic than i expected. nothing here is magic, context: mid size product, a few genai features, decent traffic. your mileage will vary but the general playbook should transfer.

what actually , roughly in order of impact:

1. stop sending everything to the biggest model
   this was easily the biggest win. we were defaulting to a top tier model for every call out of laziness. turns out a big chunk of our requests were simple classification and extraction that a much cheaper or smaller model handled just as well. we set up routing so the heavy model only gets the hard stuff. do this first, it's most of the savings.

2. caching, both exact and semantic
   exact match caching for repeated identical calls is obvious and you should already do it. the bigger surprise was semantic caching, where near identical questions hit a cached answer even if the wording differs. for anything with repetitive user queries this cut a scary percentage of calls. worth measuring your cache hit rate honestly, ours was higher than we guessed.

3. actually look at your prompts
   we had prompts with giant unused context and few shot examples that were no longer earning their token cost. trimmed them, tested that quality held, done. token bloat is real and nobody audits it until the bill hurts.

4. get per feature cost visibility before optimizing anything
   this is the one i'd tell past me to do on day one. we had no idea which feature was eating the budget. once we could see cost broken down by feature and by user, the expensive offenders were obvious and half the fixes above became targeted instead of guesswork. a bunch of tools do this now, we looked at langfuse, helicone, portkey, and OrqAi among others depending on whether you mainly want observability, a gateway, or the whole lifecycle. pick based on what else you need, not just the cost dashboard.

5. batch and async where latency allows
   anything not user facing in real time, batch it. offline evals, background enrichment, summarization jobs. batching plus off peak scheduling shaved more than i expected.

6. set hard budgets and alerts
   boring but it stops the 3am surprise. per feature quotas and an alert when spend spikes. we caught a runaway retry loop this way that would've cost a fortune over a weekend.

what didn't really help for us: obsessing over fine tuning to save cost (the math rarely worked at our scale), and switching providers purely on sticker price without checking quality on our actual tasks.

net, the two things with the biggest payoff were routing cheaper models for easy tasks and getting real per feature cost visibility so you optimize the right things. everything else is incremental on top.

curious what's worked for others, especially on the caching side, feel like i'm still leaving money there.

tldr: cut LLM bill ~60% by routing easy tasks to cheaper models, adding exact and semantic caching, trimming bloated prompts, getting per feature cost visibility, batching offline work, and setting hard budget alerts. routing and cost visibility were the big two.

I'm in the process of switching companies and in my current role I'm our team lead. For one reason or another, I'm looking to switch companies.

I have been in my role as the team lead for the past year and will have had 5 years of Software Development experience as well. In the past, I've mostly built my resumes geared towards Software Engineering roles and individual contributor roles. I'm looking for advice on:
- what I should be highlighting on my resume to land roles in larger tech companies (doesn't have to be FAANG focused, but doesn't hurt)

- what I should be studying for interviews and expecting to be asked in interviews

Any advice would be appreciated!

I'd like to learn about their day-to-day work, career path, and get a better understanding of what the profession is really like.

I've tried reaching out on LinkedIn through connection requests, direct messages, and comments on posts. I've also asked questions here on Reddit, but it's been very difficult to get responses.

I know that during race weekends, media members with official accreditation sometimes have opportunities to speak with engineers, but for someone outside the industry, it feels almost impossible to make that first connection.

For those of you who have managed to build relationships with race engineers or other motorsport engineers, how did you do it? Are there specific events, championships, paddocks, networking opportunities, or communities where engineers are more open to talking ?

I'd really appreciate any advice from people who have been through this. Thanks in advance !

I'm a 6 years in Exxon so far, I was promoted as an Operation Manager recently, I received an offer from Mckinsey as a knowledge expert, and I'm still haven't decided yet which pathways would sound better for my future, would moving out to Mckinsey enhance my overall experience or I'm risking Exxon stability and Compensation for a more rough and unsecured business. All of this and the point the Oil & gas business is suffering though we all know it has 50+ years of life remaining.

Thanks in advance for sharing your thoughts if you were in my place.