From Skepticism to Superpower: How We Transformed Our Engineering Culture with AI

The story of how 25 engineers went from "this feels like a downgrade" to shipping 3x faster and why this transformation isn't optional anymore.

We didn't set out to join the AI hype parade. When we first introduced Cursor to our engineering team at Jit, the initial reaction wasn't excitement – it was friction. "The AI writes like a junior who doesn't understand our style", one developer complained. "Why would we leave JetBrains? Cursor feels like a downgrade", said another.

Fair enough. Cursor, a VSCode fork, was unfamiliar, raw, and didn't immediately "get" our coding style and standards. But here's what we learned: resistance wasn't the enemy. Forcing adoption from the top down was.

Five months later, those same skeptical developers are building, shipping, and thinking with AI fully embedded in their workflow. Now, they won't go back. This is the story of how we got our team to shift from "this is weird" to "we can't live without this" – and why every engineering organization needs to pay attention.

Resistance Wasn’t the Problem. Context Was.

When only 3 out of 25 engineers were willing to try Cursor, it wasn’t laziness or fear. It was misalignment and untapped potential. To date, in research and other R&D activities, AI has shown promise – but often falls short when it lacks knowledge of our entire codebase, standards, and quirks. It felt more like a fresh, though very talented, intern rather than a true teammate.

The real epiphany came when we realized we need to stop treating AI like a plug-and-play tool, and like any other popular and beloved dev tools to build some scaffolding around it. So we got to work building the bridge to AI for it to really work for our team.

We built a robust framework around it to make it fit natively and seamlessly into our workflows:

• Like any boilerplate, style preferences, and other guardrails, we created extensive Cursor rules (both global and per project) to mirror the team’s preferred style guide and company standards.

• Since we are using microservices, we also understood we had to create a workspace in the IDE and include all the relevant repositories for our frontend, backend services, and IaC to make Cursor aware of the full structure and leverage its abilities to create automatically features end-to-end (UI, backend, and infrastructure).

• We also understood that siloes don’t thrive - so we built MCPs to connect them to the rest of our stack (Notion, GitHub, JIRA, even browser tools) for developers to complete their workflows end-to-end without exiting their IDE, reducing significantly contextual overhead.

• Finally, scratchpads were key to providing short and long-term memory to Cursor and ensuring long tasks can be resumed and fully completed, as well as making the AI models learn from their mistakes.

Once we invested in getting Cursor to have sufficient context about our stacks and code, it started clicking: Cursor stopped generating guesswork or partially relevant code, and started behaving like a senior team member who knew exactly how we worked, what we cared about, and how to contribute meaningfully.

The 72-Hour Experiment That Changed Everything

To prove what was truly possible and get the buy-in of the whole Eng team following the famous mantra “show, don’t tell”, we designed a 3-day, AI-first sprint. Like many engineering teams, we had a backlog full of high-potential features – important customer-facing improvements that were perpetually de-prioritized. These weren't simple wins; some were complex features that required research, deep thinking, a lot of code, and, according to rough estimations, from days to weeks to complete… in the ancient pre-AI world. 

We selected nine of them – each one being complex, high-impact, and therefore a perfect test case for our bold experiment.

The challenge: deliver all of them to production end-to-end in 72 hours using Cursor and whatever other AI tools that can accelerate the process. That included everything you can think of – scoping, designing, coding, testing, documenting, and deploying: all with an AI-first mindset from start to finish.

The results weren't just encouraging – they were a wake-up call.

Day 1: Design and Scope – Features were scoped and fully designed with AI assistance, breaking down complex requirements into actionable development tasks.

Day 2: Build – Using the design outcome and the clear tasks from day 1, AI-assisted pair programming accelerated development cycles, with developers and AI collaborating in real-time to implement features – including full test coverage.

Day 3: Ship – Documentation was generated, end-to-end tests were written and executed, and features were deployed to production with AI handling the repetitive coordination tasks.

In three days, every single feature was shipped. Not as prototypes – in production, according to the company standards.

Some simple metrics can tell the story:

• 3x velocity improvement compared to our previous workflow timeframes

• 50% reduction in team size – work that previously required four engineers was delivered by two, allowing us to deliver more features with the same number of developers.

• 100% feature delivery – all planned features shipped successfully

Most importantly, quality didn't suffer. That was a critical point for us, as well as for the whole Engineering team: we didn't use Cursor to cut corners – we used it to cut waste, streamline the process, and work faster. Unnecessary handovers, ticket archaeology, fragmented syncs, and all the invisible coordination overhead that slows teams down vanished thanks to the “magical” prompts.

Beyond Engineering: Rebuilding the Entire Product Delivery Pipeline

But the hackathon wasn't just a proof of concept. It exposed that we weren't working at our full potential – not because our team wasn't capable, but because our systems, procedures, and thinking were outdated.

Once we saw what was possible in engineering, we asked a bigger question: What if we rebuilt the entire product delivery pipeline (product-UX-development) with an AI-first mindset?

We did exactly that.

• UX Revolution: Our Head of UX ditched Figma and started designing directly in Cursor, using real code with the same existing design system, and leveraging MCP servers to export designs straight into Notion. The traditional handoff between design and development began dissolving.

• Documentation Transformation: Specs and architecture docs were written with custom GPTs as well as Markdown documents in Cursor – that could be easily exported to Notion as well – and iterated in real-time, eliminating the documentation debt that typically accumulates in fast-moving teams.

• Automated Workflows: Design, documentation generation, and PR review workflows became automated wherever possible, freeing up cognitive cycles for higher-value work.

We weren't integrating AI into our old systems – we were reimagining processes and rebuilding them around seamless context-sharing between humans and AI agents.

Culture Shift: From Mandate to Momentum

The real transformation wasn't technical – it was cultural. We learned quickly that you don't get transformation from a mandate. You get it from momentum.

We created dedicated Slack channels, ran daily "How To Cursor" workshops, and let developers drive the discovery process. The breakthrough didn't come from a big reveal – it came from dozens of small wins, shared in real-time, that proved this wasn't a gimmick; it was a fundamental gear shift.

The cultural evolution was visible:

• From "AI is guessing" to "AI is learning"

• From "This breaks our flow" to "This is our flow"

• From "It's just code generation" to "It's our context engine"

Through it all, we maintained one North Star: don't automate for automation's sake. Automate the friction so humans can focus where it matters most.

Measuring What Actually Matters

Traditional metrics like DORA scores, PR counts, and cycle times weren't designed for AI-native teams. We stopped chasing them and started measuring what actually indicates flow in an AI-augmented organization:

• Context Readiness: Can a new agent – or human – ramp up and become productive in minutes rather than days?

• Agent Effectiveness: Not just code quality, but meaningful PR reviews, documentation generation, and summaries that actually land with stakeholders.

• Decision Latency: Time from "I spotted the issue" to "It's fixed in production."

• Interrupt Debt: The cost of coordination overhead, meetings, and backscroll archaeology that fragments developer attention.

These became our real signals of organizational flow – and what we optimize for now.

The Reality Check: It's Not Perfect

Cursor (and the underlying AI models powering it) isn't flawless. MCPs occasionally glitch. AI agents may hallucinate, especially with infrastructure-as-code like Terraform. Tasks involving cutting-edge frameworks can be hit-or-miss, since the training data on them is usually quite small or nonexistent. We've learned to hope for the best while expecting the occasional stumble.

But the trajectory is unmistakable. When implemented thoughtfully, with proper context and scaffolding, these tools return the one resource that's always scarce in engineering: developer attention. And with that attention freed up, our people are doing their best work.

The Foundation, Not the Feature

This transformation wasn't about adopting a tool. It was about dropping the pretense that our old workflows still made sense in an AI-powered world.

We didn't go AI-native overnight. We started small, invested heavily in enablement, let results drive buy-in, and most critically, rebuilt our systems around shared context between humans and agents.

We're still evolving every week, but one thing has become crystal clear: this shift isn't either a fad or a nice-to-have competitive advantage. It's a foundational transformation for how software will be built moving forward, and that is here to stay.

The teams that figure this out first won't just ship faster – they'll redefine what's possible. The question, therefore, isn't whether your organization will make this transition; it's whether you'll lead the transition or follow it.