Our Shift CTO Craft Dinner format is built on candor, rather than slides or sponsor pitches. It’s just a group of senior engineering leaders talking about what’s actually happening in their organizations. At our Toronto dinner held on the outskirts of the CTO Craft conference, the theme was AI adoption in engineering

Within the first 5 minutes it was clear we’d spend the evening confirming one uncomfortable truth, similar to the one we heard earlier this spring in London: nobody has truly yet figured it out.

Note: We’ll try to figure it out at our Shift developer conference in September on the beautiful Croatian coast – tickets are on sale!

The free-for-all is over

Two years ago, the mandate was simple: spend on AI, no questions asked. That era is over.

What’s replaced it is a harder conversation, one several participants had clearly been having with their CFOs. The question has shifted from are you using AI to what are you getting for it?

The need for an ROI hasn’t changed. If anything, that window of just spending freely is dwindling. For larger organizations, the expectation is return within 12 months, or sooner.

The challenge, as one participant put it, is that the I in ROI is completely unmanaged. Engineering capacity used to mean headcount, something finance could model. Now it means tokens, and nobody controls how many tokens any individual engineer burns on a given day.

The CFO has no control once they’ve signed the contract over what the actual investment is going to be. And if you can’t tell me the investment, what does projected return even mean?

Several people around the table had run into the same wall: organizations that bought the tools, signed the contracts, and then realized there’s no financial model inside the company to manage what comes next. The comparison kept coming up: early cloud adoption, FinOps before FinOps existed. We’re in that same window. Costs are still a fantasy, usage is still undefined, and the metrics to measure it haven’t been invented yet.

One participant’s take: pushing for ROI too hard right now might mean measuring the wrong things entirely. The smarter move is to establish a baseline first.

I think eventually it will get to a more predictable state where we can say, approximately this many tokens leads to this much feature value. But I don’t think we can predict that yet.

The more pragmatic response, shared by more than one team: stop the free-for-all, start standardizing. This doesn’t mean we’re telling people to use AI less, but nudging from “use everything” to “use the same things, smarter.”

What you’re actually hiring for now

The hiring discussion exposed a split in how people in the room think about what an engineer actually is.

One participant drew a clean line between two different roles that often get conflated: the AI engineer who ships product, and the engineer who owns system design. Language doesn’t matter anymore: Python, Go, Rust, Node. But system design hasn’t changed. Someone still has to think about availability, budgets, and the architectural decisions that AI can’t make for you.

The new software engineer is a product leader. Someone thinking about what the product is, not just how it works. But we still need technical people who think about the design. Those are two different things.

On the interview side, the consensus leaned toward keeping technical fundamentals, but with caveats. One team hadn’t changed their process yet, still testing for systematic thinking, for the ability to break down ambiguous problems. Others were actively rethinking it. The most interesting take came from someone who’d shifted their interviews toward code review rather than coding, precisely because that’s what engineers actually do now.

I changed our interview process to focus on code review, because that’s what we’re actually doing. And implementation is now AI-assisted, however you choose to use your agents.

If your team can generate code faster than it can review it, you have a bottleneck. The constraint is human judgment, not output.

Team reactions and ‘recalibration moments’

Across the table, nobody described a team that was uniformly enthusiastic or uniformly resistant. The reality was messier.

One leader talked about late adopters at his company who finally jumped in after being gently pushed, then hit what he called “recalibration moments“: realizing that whole categories of work that used to take days now take hours, and having to rethink how their schedule works.

Another described something more complicated: an engineer who is highly productive with AI, genuinely good at using it, but also deeply skeptical of AI-generated output.

There’s one person who’s really good at using AI, very productive, but also highly sensitive to anything AI has produced. “This is written by AI.” “Okay, but is it good?” “Yes, it’s good. But it’s written by AI.”

The concern about AI making people stop thinking came up more than once. The counterargument wasn’t a dismissal. It was a reframe: this is a management problem, not a technology problem. The tools make it easy to be lazy. The job of a leader is to make laziness not worth it.

You can choose to make something fast and long and not that good. Or you can use it to iterate and really drill it down to something short. We can all write really long letters now. Whether we should is a different question.

One company ran an anonymous survey and found 90% of engineers at that organization actually want to use AI, higher than expected. What surprised him wasn’t the enthusiasm but what came next: questions about performance management, about promotion criteria, about how individual contribution gets recognized when anyone can now generate code. The adoption had outrun the enablement.

We’re applying AI adoption rapidly, but we haven’t updated the career pathway or rethought the competency matrix. They have every right to ask those questions.

The feature debt problem nobody wants to talk about

AI makes it cheap to write code. That is not the same as it being cheap to ship it, or to maintain it. One participant put it cleanly: cognitive debt is the new technical debt.

The room had seen the same pattern: teams adding features at a pace that would have been impossible two years ago, now dealing with the maintenance overhead that comes with it. Legacy code that was already hard to understand is now harder, because the people who wrote it aren’t being careful. They’re being fast. And internal tools that were never meant to be permanent are now permanent because someone shipped them with three prompts.

Those processes, build or buy, is this worth maintaining long term, were there for a reason. But if you can spin something up in an afternoon, it’s easy to skip them. The problem comes later.

One participant’s response: write whatever you want, but writing it doesn’t mean you’re shipping it. Code is cheap, but launching it isn’t. Keeping that distinction alive in a team is harder than it sounds when management is celebrating every PR.

The concept of a dedicated “technical health team” came up as a structural answer: engineers who ship features and engineers who delete or refactor them, treated as equally valuable work. Getting buy-in for that from a business incentivized by velocity is the actual challenge.

Who should be shipping PRs?

The most spirited part of the dinner: if AI makes it easy for anyone to write code, should product managers be shipping PRs?

The room was divided. Not on the possibility (everyone agreed the tools make it technically feasible) but on whether it’s the right thing to optimize for.

One participant pushed back hard on the narrative of non-engineers shipping to production as a win:

If you’re effectively making engineers into code review monitors, protecting the company from PRs they didn’t write, while the PM gets the credit for shipping, check in on your engineers’ mental health.

Others were more pragmatic. Enabling non-engineers to contribute on smaller, lower-risk tasks reduces the feedback loop for everyone. Designers who can write a component to spec without waiting for an engineer. Product managers who can fix a copy bug without opening a Jira ticket. That has value, as long as the guardrails are right.

The self-driving car analogy landed well: an average AI-assisted non-engineer is probably better than an average unassisted one. But nobody’s comparing them to the engineers who spent years developing the expertise. The comparison only makes sense within a specific complexity range.

If a feature is 80% engineering and 20% product thinking, an engineer can do it. If it’s the reverse, maybe a PM can handle it. What I think is actually happening is that we’re becoming value creators who pick up whatever slice of the work makes sense, regardless of title.

The harder structural question got no clean answer: if anyone can ship, whose job is it to hold everything together? Several people in the room said the only realistic response is radical team autonomy: small groups of three to five people who own their own decisions, with management’s job shifting to alignment rather than gatekeeping.

Code review is the bottleneck. AI might fix it.

One participant had been thinking about this from a CI/CD angle: the problem isn’t that teams can’t generate code, it’s that they can’t review it fast enough. Human review is now the bottleneck, and the solution isn’t more reviewers. It’s smarter triage.

His team had been experimenting with confidence scoring on PRs: using AI to assess the risk of a change and surface only the parts that actually need human eyes. A 15,000-line PR with three lines that need human review isn’t a 15,000-line review problem. It’s a three-line problem, if you can trust the rest.

I honestly think you can have a fifteen thousand line PR and say, I need a human to review these three lines. Everything else here is fine. I don’t know how to do that yet, but I know it has to happen.

The deeper point was about abstraction layers. We don’t read assembly, we trust compilers. The question is whether you can build enough validation infrastructure, feature flags, observability, acceptance tests, mutation testing, to make a similar trust relationship work with AI-generated code.

Nobody in the room claimed they’d solved it. Several said they were pushing as hard as they could in that direction.

One practical suggestion that came out of this: invest in evals now, not later. The cost of building AI features isn’t the hard part. The cost of verification is. If you build a solid eval suite today, you can swap providers, survive model deprecations, or move to open source without starting from scratch.

The cost of building isn’t as high. The cost of verification is high. When the vendor you’re partnering with changes their model, which they do often, you just run that suite of evals and you’re okay.

The vendor you’re betting on

What happens when Anthropic or OpenAI raises prices, goes down, or gets disrupted?

One participant said it plainly: her entire company has a single point of failure on Anthropic. Engineering understands single points of failure. The people in marketing and finance building on top of Claude do not.

So many teams outside engineering are building things, and I don’t think they truly understand what’s underneath it. If all of a sudden we can’t get inference, what happens to marketing? What happens to finance? They’re gonna call engineering.

The counterpoint was that competition will keep pricing in check. Open source models are no longer years behind; they’re a couple of versions back at most. You can’t double your prices when customers have alternatives. But the lock-in concern isn’t really about the model itself. It’s about everything built around it. Skills, tooling, internal workflows — those are much harder to migrate than a model endpoint.

The practical advice: build internal UI wrappers over generic model APIs now, before your teams are locked into specific product interfaces. It’s cheap to do, and it means you can swap the model underneath without rebuilding the interface your teams depend on.

What’s next? Let’s talk about it at Shift

These reflections, reactions and conversations were part of just one of our Shift CTO dinners that we’re organizing as a lead up to our Shift engineering and AI conference in September. All of our dinner participants have been invited – and so are you!

We’re also planning some Engineering leadership programming, but will be talking about topics just like the ones in this article – building AI native engineering teams, growing your developer career, scaling systems – across the conference agenda. I’d love for you to join us – get your tickets and see you in Zadar!

The dinner was held under Chatham House rules. Quotes are used without attribution.

The post CTOs Agree: Cognitive Debt Is the New Technical Debt appeared first on ShiftMag.

Uber engineers aren’t just using AI to write code; they’re rethinking how developers work with it. That shift matters because, despite 93% adoption, productivity gains remain flat.

At the Pragmatic Summit, I listened to Uber’s Director of Engineering, Anshu Chadha, and Principal Engineer, Ty Smith, discuss how one of the world’s largest technology companies is integrating generative AI into its engineering workflow.

Then, they shared:

At Uber, engineers are beginning to assign coding tasks to AI agents much like managers distribute work among their teams.

Say hello to my new colleague – AI

Uber has been using AI for years in systems like its matching platform, but bringing generative AI into the day-to-day work of engineers is a newer step.

According to Anshu, the goal isn’t to replace engineers – it’s to help them get more done.

We’re not pushing for AI to automate all humans in the company. Our goal is to let engineers focus on creative work rather than toil.

Practically speaking, repetitive tasks such as code migrations, upgrades, documentation, and bug fixes are now being handled by AI-powered agents. According to Anshu, it frees engineers to build features and enhance the user experience.

The end of hands-on programming as we know it?

One of the biggest shifts Uber has observed is the transition from traditional AI-assisted coding tools toward agent-based workflows.

Tools like GitHub Copilot made coding faster by helping developers in the moment, but now we’re entering a new era: AI agents that can work independently, tackling tasks without needing someone at the keyboard.

Back in 2022 and 2023, developer velocity saw a modest 10–15% increase. Today, the paradigm has shifted to what we call “peer programming,” where developers can delegate workloads to AI agents and intervene or redirect them as needed.

This approach essentially positions engineers as tech leads directing AI agents. Developers define the goal, while agents execute parts of the work in the background and return results for review.

Uber has built an internal platform that plugs AI agents right into its engineering workflow, mostly on Michelangelo, its machine learning platform. This gives access to models from OpenAI and Anthropic, as well as Uber’s own internal models.

On top of that, they’ve created agent-driven tools that tap into company data (source code, documentation, Jira tickets, Slack) so the AI agents have enough context to actually get work done.

AI tackles toil, but gaining trust is the real challenge

At the conference, a standout demo was Uber’s “Minions” system. Engineers submit a prompt via web, Slack, or command line, and it generates code changes and opens pull requests automatically. Ty says:

You give the agent a prompt and expect a pull request as the output. A few minutes later the system notifies you on Slack that the task is complete and the PR is ready to review.

The platform also helps engineers craft better prompts by suggesting improvements when instructions are unclear, increasing the likelihood that the agent will succeed.

When Uber first rolled out agentic workflows, they found about 70% of submitted tasks were “toil” – repetitive maintenance work developers usually avoid. These predictable tasks are ideal for AI, creating a feedback loop: the more AI handles, the more developers are willing to delegate.

Still, scaling AI isn’t just about technology. Supporting engineers as they adjust from traditional workflows and gain confidence in AI-generated code is an important focus.

Sharing success stories sparks faster AI adoption

Uber found that peer-driven adoption worked better than mandates. Anshu points out:

The most successful tactic has been sharing wins. When engineers see examples from their peers where AI helped them accomplish something impressive, adoption spreads quickly.

But measuring real impact remains tricky.

Uber tracks metrics like developer satisfaction, productivity, and code output, but connecting them to business outcomes is harder. “These are activity metrics, not business outcomes,” Anshu says.

To fix this, Uber is working to track the full development lifecycle (from design to production) to see how AI truly speeds up product delivery.

AI is powerful but EXPENSIVE

Cost is also becoming an issue. Running large language models at scale requires expensive compute resources, and AI infrastructure spending has grown dramatically, Anshu explains:

Since 2024, our costs have gone up at least six times. This technology is amazing, but the cost of AI is too high.

That’s why Uber is investing in AI infrastructure that picks the right model for each task, balancing performance and cost. With the AI landscape changing fast, the company continuously evaluates new tools and updates its stack:

What’s successful this month may be overtaken next month. So we constantly test new tools, gather feedback from developers, and adapt.

This is a fundamentally different approach from the standard coding-assistant model, one that addresses the real constraints. See the broader context: 42% of code is AI-assisted, yet 96% of developers don’t fully trust it.

Uber’s coding agent now writes 1.800 code changes per week

Just one day after we published this article, Praveen Neppalli Naga, Uber’s CTO, shared in a LinkedIn post that agentic software engineering adoption is accelerating rapidly at Uber:

• 1.800 code changes per week are now written entirely by Uber’s internal background coding agent.
• 95% of engineers use AI every month across tracked tools.

Over the past few months, Uber has leaned in heavily, and as Neppalli Naga notes, the results have been phenomenal:

84% of AI users are now working with agent-style workflows, not just tab completion. Usage of Claude Code nearly doubled in two months (32% → 63%), while traditional IDE-based tools have largely plateaued.

He also said that engineers are shifting from accepting suggestions to delegating tasks. Even within traditional IDEs, around 70% of committed code is now AI-generated.

All of this suggests a quiet but significant shift:

Background agents are increasingly writing code autonomously. Uber’s internal coding agent grew from contributing less than 1% of all code changes to 8% in just a few months, with zero human authoring. Engineers review and approve, but the code itself is written entirely by AI.

The post How Uber Engineers Use AI Agents appeared first on ShiftMag.

Honestly, even today, it still sounds a little… absurd.

That is, until I heard directly at the Pragmatic Summit in San Francisco that’s happening right now inside OpenAI.

Vijaye Raji and Thibaut Sottiaux from OpenAI say AI is shifting development from manual coding to guiding AI teams (setting goals and guardrails) while speeding up work and keeping core roles essential.

Close the laptop. Join the meeting. Come back to finished code. 

Raji’s (CTO, Applications, OpenAI) been at OpenAI for only six months, and already he’s seen Codex go from just a tool, to an extension, to an agent… and now it actually feels like a teammate.

Inside OpenAI, they recently launched something called a Codex Box.

Basically, engineers can grab a dev box on the server, fire off prompts, and let the system run things in parallel while they just work from their laptop. Sounds amazing, right?

Some engineers are using hundreds of billions of tokens per week across multiple agents – not for fun, but because that’s just how they build now. Raji said:

Software development inside OpenAI isn’t a single-threaded human loop anymore. It’s parallel. And that is going to become the new normal.

Designers and PMs are writing code. What’s going on?

Sottiaux (Engineering lead for Codex, OpenAI) described how the Codex team works today.

“It changes constantly. Almost week to week,” he said. “We look for bottlenecks, solve them, and then a new one pops up.”

At first, the slowest part was code generation, then it became code review, and now the friction often comes from understanding user needs faster – parsing feedback from Twitter, Reddit, and SDK experiments and turning that into product direction.

Speed up coding, and suddenly reviews become the bottleneck. Fix reviews, and CI/CD slows things down. That rhythm has become normal. Instead of debating every trade-off in design docs and discarding alternatives, teams try multiple implementations in parallel and focus on what actually works.

“Trying things is cheaper,” Sottiaux added. “So we try more things.”

And the rules? They’re blurring. Designers are shipping more code, PMs are writing and testing ideas, and it’s not that roles disappear – everyone’s capabilities are expanding.

Usually the problem is the prompt, not the system

What about long-running, autonomous tasks?

AI coding tools might seem like advanced autocomplete – type a few words, get a few lines back. Helpful, yes, but still reactive. Sottiaux challenged that:

Give the model a meaningful, well-defined objective, and it doesn’t just respond – it runs, for hours.

Inside OpenAI, the model runs on its own for hours, sometimes producing full reports. Engineers review the results, pick what works, and feed it back – this isn’t just suggestions anymore, it’s delegated execution.

There was also an unusually honest anecdote shared during the discussion: a researcher admitted that whenever he thought he was smarter than Codex, it turned out the problem was the prompt, not the system.

The bottleneck isn’t typing speed – it’s defining the goal clearly.

AI tools accelerate work and ahape AI-native engineers

During weekly analytics reviews, teams don’t assign follow-ups, they just trigger Codex threads. “Twenty minutes later, the answers are ready before the meeting even ends,” one leader said.

In high-severity incidents, Codex gets effectively paged into calls to help figure out what went wrong and suggest the fastest recovery. “It’s like having small consultants working quietly in parallel,” they added.

So what does this mean for junior engineers?

OpenAI is hiring new grads and running a strong internship program, believing the next generation will be AI-native and comfortable with these tools from day one.

At the same time, strong foundations, guardrails, and code reviews remain essential. As they put it, “Foundations will never go out of fashion.”

Engineers will guide AI teams, speeding up code without touching every line

Vijaye has spent more than two decades in the industry. He has lived through the rise of developer tools, the shift to higher-level abstractions, the mobile wave, and the social platform era. In his view, none of those transitions felt quite like this one.

What makes the current moment different isn’t just what the technology can do, it’s how quickly it is evolving. The speed of change, he suggested, is on another level entirely.

And Sottiaux expects that pace to accelerate even further.

In the near term, I anticipate another order-of-magnitude jump in development speed, enabled by networks of agents collaborating toward large, shared goals. Instead of a single assistant responding to prompts, entire clusters could work together on complex builds.

As systems get more complex, engineers stop checking every line of code and start setting constraints, guardrails, and validating outputs. It’s less about manual control and more about guiding the system, and working through a single assistant that coordinates all the agents behind the scenes.

Whether this ends up being the smartest leap in the industry or a step we rushed into too quickly, only time will tell.

The post OpenAI Shares How They’re Turning Engineers into AI Team Leads appeared first on ShiftMag.

“If AI can replicate almost anything quickly and cheaply, what’s the point of building anything at all?” Chip Huyen asked at the start of her talk at the Pragmatic Summit.”

And that question carries weight because she isn’t a casual AI observer: she’s an ex-Netflix researcher, former NVIDIA core developer, and an author who explores AI engineering.

She told us a personal story: after building a product, someone recreated it with AI almost immediately.

That moment forced her to confront hard questions – if anything can be copied, where’s the moat, the incentive, or the point of the effort?

“I built a product – and someone copied it with AI”

After she built a product, someone emailed her a clone generated with AI. The message read: “I love what you’ve built. So I used AI to recreate exactly that. And here’s the link.”

She described her reaction bluntly: “I’m flattered. But also, why the f**k?“

That moment crystallized a new reality: if replication requires minimal effort, traditional defensibility weakens. Technical execution no longer guarantees leverage. She framed the shift clearly:

If you can describe a software, then AI can build it for you. The constraint moves upstream. The critical question no longer asks how to build, but what to build.

The real advantage comes from context

But Chip pushed back against the idea that AI erases all opportunities.

Common problems are quickly handled by AI, but challenges with nuance and context remain – and those are where real value lies.

She illustrated this with chatbots: U.S. users expect instant replies, while in parts of Asia, waiting signals respect. These nuances matter. As AI handles common solutions, advantage goes to those who master context (cultural, behavioral, or domain-specific) where generic automation fails.

Engineering culture is changing

Workflows built around humans writing code (pull requests, line-by-line reviews, mentorship) don’t work the same when AI generates large chunks.

Junior developers may disengage, and even seniors wonder “How do I give feedback to my AI?”

The focus moves from polishing code to designing instructions and systems. Mentorship now teaches structured thinking in a human–AI–human loop.

And Chip didn’t have an answers about job displacement or copyright, she acknowledged uncertainty.

I do think it’s a bit scary and I don’t really know what the futures look like but builders still shape tools that affect labor markets, creative industries, and institutions.

When AI acts, who’s accountable?

As AI systems move beyond code editors, the risks grow. Chip drew a hard line: if AI acts in the real world (like a car hitting a pedestrian), mistakes can’t be undone.

The question isn’t if AI can act, but whether it should without strict limits.

Engineers now must build guardrails, monitoring, and escalation paths from the start – autonomy demands containment.

Enjoy building, but choose wisely what to build

Chip closed on a personal note:

Fundamentally, I enjoy building. It just brings me joy.

In an environment where execution becomes cheap, intrinsic motivation gains weight. She compared building to music that creates tension and resolution, and to assembling Lego sets for friends. Not every project requires a moat. Not every product needs revenue logic.

Her final reframing carried strategic weight. If replication becomes trivial, the advantage may belong to those who decide what deserves to exist. Vision, context, and responsibility define the new frontier. Execution follows.

The post Chip Huyen: To Build or Not to Build – When AI Can Do It All? appeared first on ShiftMag.

She presented her latest research, Measuring Developer Productivity & AI Impact, based on three months of data collected through February 1.

The research surveyed 121.000 developers across 450+ companies. A striking 92.6% of them use an AI coding assistant at least once a month, and roughly 75% use one weekly. Clearly, AI isn’t just a side experiment anymore, it’s part of the workflow.

Here are the top takeaways I found most compelling from Laura’s research.

The 10% productivity plateau

The first thing most people think of with AI assistance is saving time. According to the research, developers say they’re saving about 4 hours a week – pretty much the same as Q2 2025, with Q4 2025 numbers sitting around 3.6-3.7 hours.

It looks like the time-saving boost has leveled off. Productivity shows the same pattern: it jumped around 10% when AI first took off, and since then, it’s stayed steady at that level.

What’s really shifting is the amount of “AI-authored code” – that is, code that gets merged into the main repository or production environment with little to no human intervention. Laura breaks this down using the latest data:

Looking at about 4.2 million developers between November 2025 and February 2026, AI-authored code now makes up 26.9% of all production code – up from 22% last quarter. Daily AI users are also hitting a milestone: nearly a third of the code they merge, which passes review and goes into production, is written by AI.

One example Laura loves to highlight is how AI is speeding up the onboarding process:

Looking at the data quarter by quarter, from Q1 2024 through Q4 2025, onboarding time has been cut in half. Specifically, we’re measuring it by the “time to the 10th Pull Request (PR).”

This metric (widely seen as a key sign of successful onboarding) has now been cut in half. Because of that, Laura sees AI as a powerful tool for getting people up to speed, whether it’s new hires, engineers switching projects, or even non-engineers stepping into technical workflows.

The faster someone gets up to speed, the longer the productivity boost lasts, usually for at least two years. This points to a bigger trend: AI is helping developers get up to speed faster, reducing mental load, and making it easier to onboard into complex codebases.

In struggling organizations, AI exposes flaws instead of fixing them

Laura also pointed out a part of the research that looks at how AI impacts company performance. This segment analyzed data from 67.000 developers between November 2025 and February 2026, and the findings are strikingly divided.

Some companies are dealing with twice as many customer-facing incidents, while others see a 50% drop.

The difference comes down to how AI is used: in well-structured organizations, AI acts as a “force multiplier,” helping teams move faster, scale with higher quality, and boost reliability. In struggling organizations, AI tends to highlight existing flaws rather than fix them. Based on this, Laura concludes:

Transformation is uncomfortable. Organizations that were ready to quit their cloud or agile transformations are now giving up on AI transformation, too. It’s difficult to look at an entire organization and realize that something fundamental must change to see a real impact on the bottom line.

According to her, adoption alone doesn’t guarantee results, just using the tools doesn’t automatically improve an organization:

This is really a management problem. The hype made it sound like just trying AI would automatically pay off. But so far, most tools have been used for individual coding tasks. To see real impact, we need to use AI at the organizational level, not just for single tasks.

Laura also touched on the most popular AI tools among developers, specifically highlighting Codex:

The Codex desktop app launched on February 2 and has already topped one million downloads, with a 60% growth rate just last week. They recently rolled out GPT-5.3 Codex. Inside OpenAI, 95% of developers use Codex, and those users submit roughly 60% more Pull Requests each week.

As a real-world example, Laura highlights Cisco, where 18.000 engineers use Codex daily for complex migrations and code reviews. This has cut their code review time in half. But Laura cautions that AI won’t fix deeper organizational issues unless you tackle those problems head-on, and that starts with acknowledging they exist.

Since organizations remain constrained by human and systemic friction, Laura notes:

I am skeptical of any technology’s promise to improve performance without addressing those underlying constraints. If we don’t solve our systemic issues, we’ll just “carry them into space with us.” The real question isn’t how to colonize Mars, but how to achieve actual organizational impact.

DevEx is more important than ever

To wrap things up, Laura revealed the secret to success for those who are “winning” with AI:

1. They set clear goals and measure results.

2. They recognize that Developer Experience (DevEx) matters more than ever.

3. AI succeeds when factors like fast Continuous Integration (CI), clear documentation, and well-defined services are in place.

At the end of the day, getting real organizational results means treating AI as a company-wide challenge. The research shows the barriers aren’t technical, they come down to change management and leadership support. Laura sums it up:

Successful organizations experiment by tackling real customer problems. Exploring Mars sounds exciting, but it’s not sustainable – it’s expensive and distracts from the core business. Focus your experiments on the customer to drive meaningful results. After all, somewhere, something incredible is waiting to be discovered.

The productivity gap isn’t unique. Read why 84% of developers use AI, but most don’t trust it. The trust issue is part of the equation.

The post This CTO Says 93% of Developers Use AI, but Productivity Is Still 10% appeared first on ShiftMag.

“Interviewing is a skill separate from being a good developer”, says Horia Coman, Stripe’s Stripe’s Director of Engineering and Site Leader at their new engineering hub in Bucharest, Romania.

Horia shared with us what non-coding and coding skills engineers should work on if they want to successfully interview at Stripe. He also shares career advice for engineers at big product companies such as Stripe. Spoiler: the secret is in being aligned with the success of the product.

Watch The Whole Interview on Shiftmag’s YouTube Channel

You can continue reading the whole interview below – or watch the interview on our YouTube channel:

How to Prepare for an Interview at Stripe

According to Horia, one of the biggest hurdles engineers face when applying to Stripe is the interview process itself, which requires a specific set of skills beyond just coding. “Interviewing is a skill separate from being a good developer,” he explains. In many regions, particularly in Eastern Europe, engineers may not be accustomed to the rigorous problem-solving focus of interviews at companies like Stripe. “You have to practice this skill if you want to be good at it.”

Stripe’s interviews test not only your ability to code but also your understanding of system design and your problem-solving approach. Horia advises candidates to focus on honing their algorithmic coding skills and be prepared to work in realistic coding environments:

Our interviews are not puzzle-like, but they do test if you can code, debug, and integrate systems. The key is not just technical expertise but how well you handle problem-solving under pressure. Debugging, in particular, can be a stumbling block for many, as most engineers coming out of university don’t have much experience debugging real codebases.

Product-Minded Engineers Need To Be 100% Aligned With Their Product

For those looking to make a lasting impression at global technology companies like Stripe, Horia emphasizes the importance of being “product-minded.” In other words, engineers need to think beyond the technical aspects and focus on the broader success of the product they’re working on. “Being a product engineer means internalizing the mission of making the product successful,” Coman said. This involves not only building the product but also engaging with customers, understanding the business goals, and continuously improving the product based on user feedback.

This approach contrasts with the mindset many engineers adopt in service-based or outsourcing companies that have been common in Romania and Eastern Europe, where the focus is often on delivering to client specifications rather than driving the success of a product:

In a product company, 100% of the time you need to be aligned with the success of the product. This shift in perspective can make a significant difference in an engineer’s career. Once you work like that, there’s no going back.

First-Class Stripe Engineers, Regardless of Location

Stripe’s hiring process is known for being thorough and challenging, but it’s designed to ensure that candidates are the right fit for its product-driven culture. Horia highlighted that Stripe is committed to maintaining high standards for all of its hires, regardless of location. “We didn’t want to say, ‘Hey, these people are different,’ or treat them as second-class engineers. We’re operating at the same level.“

Stripe’s recruitment process typically includes a mix of coding interviews, system design assessments, and integration tasks. For entry-level candidates, the focus is on coding and problem-solving. “You have to be good at turning a problem statement into code,” Horia said, stressing the importance of algorithmic thinking over “puzzle-like” problem-solving. For more experienced candidates, the interview process goes deeper into system design, with an emphasis on how they’ve architected systems and solved complex problems in real-world environments.

Mid-level and senior engineers, in particular, are expected to articulate their design decisions clearly. “Sometimes the most experienced candidates rely too much on intuition and struggle to explain their thinking process,” Horia pointed out. At Stripe, it’s not enough to just know the right answer; engineers need to be able to explain their approach and reasoning.

Eastern European Talent Is Great – And The Cost Isn’t Low Anymore

We spoke to Horia during the largest startup conference in Eastern Europe – How to Web in Bucharest and he admits that adapting to the local recruitment culture was one of the challenges when starting and growing Stripe’s Bucharest office.

Unlike in the U.S. or Western Europe, where engineers actively seek out opportunities, in Romania, companies often have to chase top talent. “Here, you have to go after candidates, convince them to join, and even prepare them for the interviews,” Horia explained. This required Stripe to adapt its approach, working with local recruiters who understood the nuances of the Romanian tech scene.

Despite these challenges, Stripe has maintained its high hiring standards across all its offices. Horia made it clear that Stripe’s Romanian office is not a low-cost alternative. “Eastern Europe is not a low-cost location with so-so talent. The talent is great, and the cost isn’t low anymore.” As Stripe continues to grow its Bucharest team, the company is focused on building an engineering hub that meets the same rigorous standards as its U.S. counterparts.

Career Advice for Engineers: Take Ownership Of Your Work

For those looking to advance their careers, Horia offers some valuable advice: take ownership of your work and invest in your long-term development. He believes that engineers who can align themselves with the success of the products they’re building will find greater fulfillment and career opportunities. “The ideal is that you’re building something you believe in, that you feel you are the owner of, and that you have a big hand in directing for success.”

He also encourages engineers to broaden their skills and not become too narrowly focused on one technology or framework. “You have to either go broad and develop a big toolbox or go really deep and become an expert in a particular technology,” Horia advises. He warns against becoming too specialized without mastering a broader set of skills or achieving expert-level depth. “If you just have this surface understanding, it’s limiting to call yourself an expert.”

Stripe’s Commitment To Giving Back To The Ecosystem

Horia joined Stripe partly because of its strong commitment to university recruitment and training new generations of engineers. Stripe is not just looking for experienced talent—it’s also focused on developing young engineers through internships and graduate programs. “We wanted to build a correct office from the start, with a mix of senior, junior, and mid-level engineers,” he explained.

Stripe’s training programs are designed to offer new engineers valuable learning opportunities, working alongside senior engineers and contributing to real projects. “You get this intergenerational experience of training new generations, and we learn a lot from them as well,” Horia said. Stripe plans to grow its university recruitment efforts, hoping to hire more young talent each year and help shape the local tech ecosystem in Romania.

Engineering Careers Are Long, So Let’s Make The Most Of Them

For engineers looking to join a company like Stripe, the key takeaway from Horia’s interview is clear: take charge of your career and continuously strive to improve your skills:

Our careers are long, and we spend a lot of time on them, so we need to make the most of them!

This means not only preparing for interviews and improving technical skills but also adopting a product-focused mindset that prioritizes long-term success.

For those interested in applying, Horia encourages candidates to explore opportunities on Stripe’s job portal or connect with him directly on LinkedIn. “We’re growing fast, and we’re always looking for great talent to join the team,” he said.

Horia notes they plan to grow the Bucharest office to 70 people by the end of the year, with plans to expand beyond 100 in 2025. Long-term, he mentions the goal is to have hundreds of engineers at the Bucharest office within three to four years.

In essence, if you want to secure a role at Stripe—or any top tech company—it’s not just about your coding skills. It’s about your ability to think strategically, own the success of the product, and continuously adapt to new challenges in a fast-paced, ever-evolving industry. Especially in Eastern Europe, which is moving from being a low-cost engineering hub to a home of product-minded engineers like the ones at Stripe.

The post How to get hired at Stripe as a (Product) Engineer appeared first on ShiftMag.