I disagree with the premise. Never trust a piece of code, document or statement written by a human or AI
You weren’t reviewing properly before. You were slack. You let problems through. Now you have to review properly and oh no it’s slower than just clicking approve
We got faster, but what we got faster at doing was creating busy work for each other. So the volume of work is higher but the signal to noise ratio is lower.
creating busy work for each other
Welcome to the regulated service economy. We’ve got all the food and structure and infrastructure production we need, idle hands are the devils’ workshop, so keep the people busy making work for other people.
Inevitable conclusion: “Ah, reading the code is expensive. It’s probably fine to trust it, right???”
“We’re going faster by passing the slow part (the reading, the actual understanding) to whoever comes next”
sounds like my boss, no docs, no procedure XD
What I have found is: if the AI operator cares, they can tell it to make the instructions, or summary, or whatever it is, whatever length they want it to be. Just summarize the most important parts to half a page, or go into extreme depth on every section. Target 300-400 words, or 3500-4000… whatever you feel is appropriate for the topic and the target audience.
Not strictly about AI, when I write something explaining something technical for my manager (who is technical and can understand it all, but rarely has the time to) what I often find myself doing is getting to the end, then going back and writing a 25 words or less summarization of what he actually wants to know to communicate this up the line to his managers - then leaving the 3-5 pages of technical regurgitation of details that led me to that conclusion as reference for the one or two little details he’ll possibly be interested in for his own curiosity.
The problem I have with short instructions is: you never know what details you’re leaving out that are going to matter in the future until people start using your instructions and making bad assumptions because you didn’t over-emphasize a point - like: writing an instruction that says “accept all the defaults” - well, apparently our colleagues in the overseas office weren’t capable of following that particular instruction without an additional big bold NOTE: hitting them over the head to emphasize: no, really, you’re going to regret all the extra work you have to do if you don’t accept the default options.
It’s an iterative process, and should be the same whether or not you’re using an AI agent to do the writing for you. Try, fail. Try again, fail again, fail better next time.
This article I think shares my thoughts on it, Arguably I don’t know if the devs even got faster… Like its a nice resource but, there’s so much trial and error involved now, and every prompt now requires essentially relearning a new codebank.
Like sure immediate result got faster… but you lose all that with the extended time taken learning how it works and why it works.
I work as a glorified code monkey. It feels faster, sort of, in fits and starts.
When I start working on a task, the AI tooling almost feels like it’s doing the job for me. It picks out the relevant part of the code base, makes changes in the right places, and even updates tests.
Assuming that part all went well, the waiting game begins.
Either run the “git” AI prompt or do it by hand. The prompt way has some nice bells and whistles in how it formats commit messages , but
It’s
Just
So
Slow!
Then, either way, my commit goes. Now I wait for the auto build and test pipeline, the code scanner job, and copilot’s review pass. Sometimes it brings up helpful things, sometimes it raises silly objections.
Then, ok, I think it looks good. I need approval from a busy coworker to actually click merge, so I send a link to the chat and hope someone isn’t too busy.
Once I get that approval, it’s wait again for a build agent to deploy my changes.
Now, hours later (sometimes the next day), I can load it up and see my change reflected in our test environment.
The wheels sure are spinning, but I can’t say for sure that we’re going any faster.
CI/CD is overflowing as the bottleneck for us, and AI isn’t making running tests faster. It’s making it slower, with more (truly good, useful, productive) unit tests and product features added every day than human teams could
But that adds a square increase on CI/CD time and load… And what do you do while waiting for your test run? Make and submit more PRs of course!
I can assure I work much faster. Maybe it is a bit different since I work in research and that’s indeed different from working on a large established codebase. Most of my projects are greenfield.
However, recently using Claude code I started many different projects I’d never have approached since I knew it would have taken me months to complete correctly. We are talking about porting file format readers and writers to new languages, then implementing novel algorithms to process such data and optimize it to work on different GPU architectures. Getting a working software takes about a week of work. A publishable cleaned up codebase 2/3 weeks. No way I could do this myself alone in such span of time.
On the other hand, I have students working with me, using AI is definitely not helping them to learn how to code and how to reason. In several occasions I had them showing me a novel huge equation which apparently worked, but then looking at it properly was just over fitting data and they had no way to explain why such an equation should be used.
For coding tasks I treat A.I. as a fresh intern that doesn’t really know what they’re doing but you can just ask them to do that horribly tedious task and just do a code review later. As you said, something like “rewrite this in Rust”, or “create unit tests for this function”. Then you fix all it’s mistakes. I’d never let it touch an actual algorithm or anything important though.
To be fair, it is fairly good at selecting and optimizing algorithms; as long as you set up a set of correctness tests and performance benchmarks it can use to evaluate if it’s doing well. The other day in about half an hour I got a 26,000% improvement in performance on a specific algorithm which I had implemented as it was published in the original paper. Same results under all conditions, but it decided to rearrange the formula to use a few matrix tricks and optimized for SIMD instructions. That is the kind of things I’d never do myself: I don’t care if such calculation takes 3 weeks using 256 cores and 200 GB of memory, if I have to optimize for SIMD instructions that will likely take me one or two weeks and I don’t have time for that. I’d rather burn compute. If it takes me a couple hours I’m very happy to bring down a computation which would take weeks to an hour or so.
Nights of winter turn me cold
Fears of dying, getting old
We ran the race, the race was won
By running slowlyExcellent analysis.
