We interviewed 2 engineering managers on how AI changed their jobs. Feel like this is a good read and might sound familiar to waterlogged EMs. Their closing advice? Knowing what not to work on.
TL;DR As a code quality platform, we're seeing first hand the changing processes inside dev teams. We noticed that the "meaningful" point of change is happening more and more at the local level, not at the repo level, where a team used to come together to review changes. With more teams waving past code reviews, the typical quality infrastructure that used to ensure code maintainability, security, reduce tech debt, etc, is breaking apart.
If you're a dev who cares about this, the new quality and security enforcement infrastructure needs to happen alongside the agents, locally. The tools to address this are still in early stages - meaning, a tool that isn't the same model reviewing itself - but they're starting to surface and it's worth keeping an eye on them.
We wrote about how AI-assisted development changes the economics of code review and how good ole SAST does actually have a meaningful role to play today.
Hey folks, I've identified 3 different stages of AI coding adoption: autocomplete, prompting, loop engineering.
The autocomplete stage is basically a throwback to 2024 and is mostly harmless - the traditional SAST and code review practices handle it.
Prompting agents to build whole features, which is where most people are today, comes with some security and maintainability concerns, but there are already solutions in place.
The problem is that most teams are also starting to explore loop engineering with autonomous agents. This currently has no guardrails in place, which is a recipe for disaster, as the video explains.
If you're exploring loop engineering, this is for you.
Agreed the move is AI reducing what you review, not adding to it. What's also needed is a process for classifying changes by risk so the low risk PRs get the automated gates while a human looks only at the high risk one that actually need it. And then enforcing that the same way across every repo.
Looking into Slite now to check. With OpenKnowledge, the content is just markdown files on-disk, so there shouldn't be anything exclusionary about it. Not sure how/if Slite handles markdown files. Will take a look.
reply