We got 30+ tech leaders together for our second Tech Leader Exchange. First we defined the traits that matter now more than ever. Then we went deeper: what actually changes when a next-gen engineer joins your team?
As one tech leader put it: "The code takes 30 minutes to write. I don't mind if we spend three hours on a call defining the spec. That's good time spent."
The bottom line: AI is making way for engineers who build, think, and decide, not just execute.
How Have Engineering Workflows Changed Because of AI?
Standups, tickets, code reviews: none of that has gone away. But what's happening inside those steps looks pretty different.
Engineers are showing up to planning sessions with prototypes already built. Designers and developers are working side by side instead of throwing things over a fence. And the engineer who just waits for a ticket is increasingly the odd one out.
1. Planning is more detailed
Engineers are spending more time defining the problem before writing a single line of code. Tickets are more structured, specs are more thorough, and the problem is better understood before AI is even involved.
The reason is simple: a well-defined spec fed to an AI can produce working code in 30 minutes. A vague one produces something that needs to be rebuilt.
2. Engineers are arriving with more options
Because spinning up a working prototype now takes hours instead of weeks, engineers are coming to discussions with multiple approaches already tested.
One leader described the shift: "It's moved from what can I do with my knowledge, to what do I want to achieve and finding different ways to get there. Engineers are now coming to me and saying, I think we should try this."
3. Time is moving upstream
With code taking a fraction of the time it used to, hours are shifting into defining the problem and aligning on the spec. As one participant put it: "The code takes 30 minutes to write. I don't mind if we spend three hours on a call defining the spec. That's good time spent."
4. Reviewing is replacing writing
For some engineers, the job has fundamentally shifted from writing code to reviewing it.
One leader in the payments space shared that he hasn't written a line of code since April last year but he reviews every single line AI generates. In a high-stakes data environment, that's non-negotiable. As he put it: "I've reviewed every line since then. It's probably 50% of my job now." One bad line of AI-generated code in his context could mean reprocessing terabytes of data from scratch.
5. And for the review itself, AI goes first
Before a human even looks at a pull request, several teams are now running it through AI tools like Claude and Code Rabbit.
Security issues, bugs, and code quality problems get caught at the first pass before they reach a senior engineer. One leader noted it has freed up significant time for planning and strategy that previously went into routine review work.
6. Standups are getting shorter and more async
Some teams have moved away from traditional daily standups entirely.
One leader described their approach: "We do written standups in the morning and a check-in at 3pm. That meeting takes two to three minutes. Most days it's just no issues, everything's on track." The live meeting is now reserved for when something has genuinely deviated from plan.
7. The handoff model is breaking down
The old ticket-based handoff between designers and developers is losing its appeal. Designers and engineers are sitting together, building together, and sorting out problems on the spot.
As one leader put it: "Our designer sits with an engineer and they peer code the front end changes together. While they're working, if something isn't working, they figure it out on the spot." Nobody has time for the back and forth anymore.
8. Engineers are moving closer to the customer
Beyond design, engineers are showing up in customer meetings, weighing in on product decisions, and taking ownership of outcomes that used to sit with a PM or designer.
As one leader put it: "Give me the problem. Because I can think in all these fantastic ways. I can lift the whole building up and move the table in front of you. Don't tell me exactly how to move it." The engineers thriving in this environment are the ones who want that context, not just the ticket.
What Is Spec-First Development and Why Does It Matter Now?
Spec-first development is the practice of fully defining what needs to be built – in writing, in detail – before any code gets written. It's not a new concept, but AI has made it significantly more valuable.
A well-written spec fed into an AI tool can produce working code in under 30 minutes. The quality of the output is directly tied to the quality of the input.
Why documentation-first teams have a significant advantage
Companies that already had strong documentation cultures are reaping the rewards.
One leader whose team embeds documentation directly into their repositories put it simply: "We're always asking, whenever we solve a problem, can we write this down so we don't have to do this again? We're compounding that knowledge back into the repository so we don't need to care about it next time." For teams that haven't built that habit yet, now is a good time to start.
How meetings are becoming instruction files
Several leaders described a new practice of transcribing meetings and running a prompt over the transcript to extract learnings directly into instruction files within their codebase. The meeting itself becomes an input into the system rather than a productivity cost.
As one leader put it: "Meetings aren't unproductive anymore. They feed directly into better instruction files in the repository, so the next time we prompt something, the guardrails are already in place."
Why estimation has become the hardest problem
The one area where spec-first development has created a new challenge is estimation. Leaders with decades of experience said their gut feel for how long things take is no longer reliable.
As one put it: "My 18 years of gut feel for knowing how long things take has become useless. I need to retrain how I estimate entirely." The equation has changed and nobody in the room claimed to have solved it yet.
How Are Engineering Teams Being Restructured Around AI?
The way engineering teams are set up is changing. Squads are getting smaller, management layers are coming out, and engineering managers are writing code again.
The move toward leaner, more senior teams
Some companies are starting to experiment with smaller, more senior squads of around four people. One leader described the thinking behind it: "We're moving to four-person squads. Same number of people overall, but significantly smaller teams. You don't need as much guidance when the team is more senior." The reasoning being that with AI handling more of the execution, you need fewer people and more judgement.
But not everyone agreed. Several leaders are deliberately going in the opposite direction, hiring juniors precisely because they come without predefined ways of working and are more open to building AI-first habits from day one. As one leader put it: "We don't want to bring in people with predefined ways of doing things. People that are mouldable come in and they've fallen in directly." They've hired five juniors and said they'd been proven right every time.
The common thread across both approaches is intentionality. The leaders having the most success are building their teams around a specific vision of how they want to work, rather than defaulting to how things have always been done.
How the role of the engineering manager is changing
Engineering managers are spending less time managing and more time building again.
One leader described what that looks like in practice: "We're moving from 100% people management to 80% coding, 20% people management. It makes more sense. The squads are smaller, they're more senior, they don't need much guidance."
The layer of management that existed mainly to shield and protect teams is thinning out as teams become more capable of running themselves.
Catch our AMA with Gregor Ojstersek, Author of Engineering Leadership, on what AI really means for middle management.
Ready to be part of the next conversation?
The engineering leaders who are thriving aren't waiting for the industry to figure this out: they're in the room, sharing what's working and what isn't.
If you want a seat at the next Tech Leader Exchange, join the waitlist.