What changes in engineering teams once AI tools "click"?
4 comments
The observation about AI being more useful as a "thinking partner" than a code generator matches my experience exactly. The flip moment for me was when I stopped asking the AI to write code and started asking it to explain unfamiliar codebases, review my architecture decisions, and suggest approaches I had not considered.
The other thing that made a massive difference was investing in project context files. Most teams use AI tools with zero project-specific context — the AI knows nothing about their conventions, patterns, or architecture decisions. It is essentially a smart stranger every session.
When you give the AI a well-written .cursorrules or similar context file that encodes your team's actual patterns — naming conventions, preferred libraries, error handling approach, testing philosophy — the output quality jumps dramatically. Instead of generating generic React code, it generates code that looks like YOUR team wrote it.
I have been maintaining cursor rules across 16 frameworks and the pattern is consistent: teams that invest 30 minutes upfront writing good context files get maybe 3-5x more useful output from AI tools than teams using them out of the box. That initial setup cost is what makes the difference between "neat toy" and "actually changed my workflow."
The social contagion effect you describe (one engineer starts, others follow quickly) is real too. In my experience it usually starts with someone sharing a particularly impressive AI-assisted debug session or refactor, and then everyone wants to know how they set it up.
The other thing that made a massive difference was investing in project context files. Most teams use AI tools with zero project-specific context — the AI knows nothing about their conventions, patterns, or architecture decisions. It is essentially a smart stranger every session.
When you give the AI a well-written .cursorrules or similar context file that encodes your team's actual patterns — naming conventions, preferred libraries, error handling approach, testing philosophy — the output quality jumps dramatically. Instead of generating generic React code, it generates code that looks like YOUR team wrote it.
I have been maintaining cursor rules across 16 frameworks and the pattern is consistent: teams that invest 30 minutes upfront writing good context files get maybe 3-5x more useful output from AI tools than teams using them out of the box. That initial setup cost is what makes the difference between "neat toy" and "actually changed my workflow."
The social contagion effect you describe (one engineer starts, others follow quickly) is real too. In my experience it usually starts with someone sharing a particularly impressive AI-assisted debug session or refactor, and then everyone wants to know how they set it up.
Amazing insights - thank you so much for sharing! What tools are you using and within what environment (monolithic/microservices..). Your approach to asking the AI to "explain' is a real pivotal moment for the engineers...from what I'm seeing in such intensives at least! This was my first post on HN so am delighted for your engagement! Will keep sharing my observations. BTW, the intensive I was observing was with a Series B start-up; post-acquisition so there was a real mix of habits and expectations...just wanted to share in case you or any other readers are in a similar environment. Thanks again!
The skepticism-to-flow pattern you described is something that plays out almost identically across teams — the engineers who resist AI longest are usually the ones who are best at their craft and most aware of where the output is wrong. The flip happens when they stop treating it like a search engine and start treating it like a junior dev they have to review.
The productivity difference between teams who hit that click and those who don't is getting wide enough that it's becoming a hiring signal in both directions. The founders I see getting the most out of it are the ones who understand this enough to ask good questions of their team, even if they can't read the code.
What was the biggest surprise for you watching the experiment — was it which engineers clicked fastest, or something else?
The productivity difference between teams who hit that click and those who don't is getting wide enough that it's becoming a hiring signal in both directions. The founders I see getting the most out of it are the ones who understand this enough to ask good questions of their team, even if they can't read the code.
What was the biggest surprise for you watching the experiment — was it which engineers clicked fastest, or something else?
Thanks for the comment! I think the most surprising thing was how the engineers almost pushed each other to use the agent "better" - write clearer and more defined prompts engineer-style as opposed to open and generic instructions that I might use as a non-engineer. To be the architect and the staff manager of the code.
I loved seeing how they were trying to outdo each other when tasked to build something that they hadn't tried before due to their limited experience with unknown libraries. Was really fun to watch - one guy built a tool to tell users how faraway starts were relative to each other and us, one built a travel diary...I guess seeing them go from "meh" to being engaged and having fun was really cool to see!
I loved seeing how they were trying to outdo each other when tasked to build something that they hadn't tried before due to their limited experience with unknown libraries. Was really fun to watch - one guy built a tool to tell users how faraway starts were relative to each other and us, one built a travel diary...I guess seeing them go from "meh" to being engaged and having fun was really cool to see!
The setup was simple: six engineers spent a few 2 days experimenting with AI in their real development workflows. Nothing theoretical — just trying things directly against their codebase and normal tasks.
A few observations stood out.
1. Initial skepticism was high
Several engineers were openly skeptical at the start. The general sentiment was something like:
“AI coding tools are interesting, but mostly useful for small snippets.” "I wouldn't put my name on code that wasn't 100% mine" was another... one even said "AI is the devil!"
Most of the team had tried assistants before but hadn’t really changed how they worked.
2. The shift didn’t come from code generation
What surprised everyone was that the biggest changes weren’t about generating code faster.
The moments where things “clicked” tended to be things like:
exploring unfamiliar parts of the codebase
debugging tricky issues
quickly testing alternative approaches
generating scaffolding to explore architecture ideas
Once engineers started using AI more as a thinking partner rather than a code generator, workflows changed pretty quickly.
3. Behavior changed very fast once a couple of the engineers started to use libraries they hadn't used due to time taken to understand how to integrate it.
After that, the rest of the team started experimenting with similar approaches.
Within a week the company apparently saw a huge spike in requests for "AI-tool" licenses internally.
4. The interesting part wasn’t the tool
What seemed to matter more was that the engineers had time and space to experiment together.
A lot of teams seem to have access to AI tools now, but they’re still using them in fairly shallow ways.
When people start experimenting with their real workflows, usage patterns seem to change very quickly.
Curious if others have seen something similar inside their teams.
Specifically:
Where have AI tools actually changed engineering workflows for you?
What use cases ended up being more useful than expected?
Did adoption happen gradually, or was there a “flip the switch” moment?
Would be interested to hear how this is playing out in other engineering teams.