There are two camps at work right now.One group swears that AI has made them ten times more productive.The other group tried it, got back a pile of confident nonsense, and quietly turned it off or use it minimally. My honest read is that both of them are correct, and the reason they disagree is that they're measuring different halves of the job.
Almost everything I've learned about working this way fits under a single idea: generating code became cheap, and verifying it did not. Most of the benefits I'll describe come out of the first half of that sentence, and almost all of the problems come out of the second.
The Good parts
The most obvious change is that starting something is nearly free now. A new service scaffold, a migration script, or a CDK module I've written some variation of ten times already used to cost me most of an afternoon in low-value typing. What I didn't anticipate was how much that would change my behavior rather than just my calendar. When the cost of starting reduces, you become willing to try more things, so I'll now build two competing designs before lunch instead of arguing about which one is better in a document for a week.
The bigger unlock, though, is in code I don't already know. I'm thinking of the times I drop into a service another team owns, or a language I touch twice a year, or a build configuration somebody wrote in 2019 before leaving the company. Being able to ask what a module actually does and what calls it, and getting a useful answer in thirty seconds instead of an hour of grepping, is the largest real gain I've been able to measure. The win isn't in writing new code at all. It's in reading old code.
Test writing has improved too, though with a significant asterisk attached. These tools are very good at coverage and fairly useless at judgment, and they will cheerfully produce forty tests that assert the implementation does exactly what the implementation happens to do. You still have to decide what's actually worth asserting, but the ratio of thinking to typing has shifted in a direction I like.
The parts nobody warns you about
Code review has quietly become the bottleneck, and I think most teams walked into that without noticing it happen. Writing code was never the real constraint on a mature codebase; reviewing it and landing it safely was. What we've done is speed up the step that wasn't binding and pour far more volume into the step that was. The symptoms are predictable once you look for them, because pull requests get bigger, review gets shallower, and people start rubber stamping since the diff is eight hundred lines long and it's already Thursday afternoon. If your team adopts these tools and changes nothing about how it reviews, your process is now worse than it was before.
The failure mode that genuinely worries me is subtler than that. When a junior engineer makes a mistake, the mistake usually looks like one, because it's awkwardly written or oddly structured in a way that catches your eye. AI mistakes look like good code instead. They arrive with the right naming conventions, idiomatic style, and confident comments, wrapped around a retry loop with no jitter or an error path that swallows the exception it should have propagated. My instincts as a reviewer were trained on human error patterns, and those instincts simply don't fire here. I do still catch these bugs, but I catch them much later than I should, because nothing about the code makes me suspicious in the first place.
The problem I have no good answer for is what all of this does to junior engineers. The work we used to hand them, meaning small scoped changes, test coverage, glue code, and "go read this and figure out how it works," is precisely the work a model does fastest. That work was never valuable because of the output it produced. It was valuable because it built the engineer. If you give all of it away, you get more throughput this quarter and a hole where your senior engineers should have been in five years.
How I actually work now
The rule that matters most is that nothing lands if I can't explain it to a reviewer myself. That's the entire discipline, and everything below it is really just detail. I keep diffs smaller than I used to rather than larger. If a tool helped me write something, I treat that as a reason to tighten the pull request, not as an excuse to let it sprawl.
I never let a single source write both the implementation and the proof that the implementation is correct. It can draft the test scaffolding, but I write the assertions that actually matter.I lean on it hardest where I'm weakest, and I'm most skeptical of it where I'm strongest. In unfamiliar code it works as a map, and in code I own it's a fast typist while I remain the architect.
Where I landed
"Will AI replace developers" was always the wrong question to be arguing about. What has actually happened is that the value in this job moved away from producing code and toward judging it, which means deciding what should exist, whether a given approach is right, what will break at three in the morning, and what a shortcut will cost the team two years from now. That's a harder job than the one I had before, and it's also a considerably more interesting one.
The people who struggle over the next few years won't be the ones who refused to use these tools. They'll be the ones who used them to skip the part where they learned how to think.
I'd be curious what your version of this looks like, particularly on the review bottleneck, because that's the one I still don't think anybody has actually solved.
Top comments (0)