April 8, 2026 at 12:00 am
Comments posted to this topic are about the item Barely Reviewed Code
April 8, 2026 at 11:09 am
I sure there's someone out there who's already reviewing their AI-generated code changes by feeding those changes into another AI.
And all that I hear running through my head is "GIGO, it's GIGO all the way down."
The AIs are only as good as the data they were trained on, and from some of what I've seen / read, that data isn't all that impressive. I've used the AIs we have access to here and within certain limited situations, they're OK, but they don't really help me speed up my work. We don't (yet) have any of the more developer-focused AIs, so I've not tried to get any code-type improvements out of them (when I have tried, it's been... ugly...)
There's a part of me that would be interested in seeing what happens if you took a couple AIs, gave one the requirements for an application, one requirements to test the code, and one to actually use the app and request changes, and see how long before it implodes. Or, maybe, you'd end up with a usable app at the end. Maybe.
April 8, 2026 at 9:34 pm
Plenty of examples of both. Look online. There are people getting work done with them.
And people failing spectacularly.
They've been helpful to me, but not always.
April 9, 2026 at 9:51 am
I used GitHub Co-Pilot as an initial reviewer, but not an approving reviewer. It would raise points on a pull request that were the sorts of questions that a junior developer would raise. Sometimes good questions, others, not so much.
The important thing was that it had no fear of asking a question that a junior might fear was a stupid question. It would ask as many questions as needed asking. It does so without fear of the recipient taking offence or reacting badly to those questions. Neither does it suffer brain fade.
If juniors are scared to ask questions, then that can indicate cultural problems that need to be addressed.
April 9, 2026 at 5:08 pm
I use AI to help with some code BUT it has a lot of oversight by me. I mostly use it for little scripts here and there and bug fixing scripts I have already written. I find that AI is often confidently wrong when I ask it questions and it usually takes me 4-5 tries for it to get a powershell script correct. Using Copilot mind you, but it being a Microsoft tool, I'd expect it to be a powershell guru.
But even when it spits out a script for me, I copy-paste to notepad then do my own code review, put in any debugging steps I want or comment out any steps I want to avoid during initial test (ie no data changes for first run and lots of noise to the screen to make sure it does what I want) and go from there. Far too often AI will make the scripts too robust for a one-off thing and reading it, understanding it, and fixing it to meet my standards (tabs vs spaces for example as the AI seems to always tell me it did it right and it does it wrong) takes time. BUT if I run a script and take down the company, that's on me not the AI. If I approve a code change that had 1000's of lines of code changed in a few seconds and it takes the company down, that's on me and the developer. That being said, when there are 1000's of lines of code changed AND the developer is known to make good, well tested changes, my reviews are quicker and more focused on the comments and quick glances at the code that changed. When the developer is new or is known to make mistakes, I review more carefully...
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
April 9, 2026 at 6:23 pm
AI can be great for some things. Like putting in the debugging code 😉
April 12, 2026 at 2:38 pm
This is an excellent article, Steve. It reminded me of a similar issue that occurred at work 2 years ago. We were working on bringing a new application online, using what was written by someone else, then improving it. We were using a contractor to assist with this (one of our CIO's former employees from the business he had before becoming our CIO). This guy loves to use what's known as monorepos. I came to hate this approach, because the contractor's MO was to add another application to the repo overnight. He did this at least twice. At the end of business on Friday there would only be some many applications in the monorepo, but by Monday morning he would have added a completely new, fully functioning application to the monorepo. Then he would create a PR and assign it to the most junior developer on the team to review and approve. The junior developer is new, and eager to please, but inexperienced, so he would always just give the PR a quick once over, approve, confirm the commit, and added yet a whole new application to the monorepo. No chance to learn how the application was built. The contractor would just look for an application he'd worked on in previous contracting jobs, change the UI from the previous client to us, and claim that he slaved over it all weekend. And if you've done any GitHub Actions development in monorepos, you know it takes careful consideration to account for a new application which has been added but only needs to be deployed when its code is modified.
OK, bad memories and I've probably taken too much time going over it. Anyway, all the other developers at work don't use monorepos so writing GitHub Actions is simpler. But anyway, I thought that my having to deal with someone adding whole, new applications all in one commit were restricted to only this one guy. But you're right, Steve, AI is going to start throwing whole, complete applications, or at least major additions, to repos. It will be harder for everyone to deal with huge new code being added all at once by AI.
Kindest Regards, Rod Connect with me on LinkedIn.
April 13, 2026 at 3:52 pm
I hate mono repos. I think that's how we often "re-used" code in the past, sometimes with a Windows, Android, and iOS apps in the same repo. (though often no db code).
I prefer dependencies and modern package management where each thing is separate.
I love assigning PRs to junior people. Let's me get more stuff done 😉
April 13, 2026 at 4:33 pm
I hate mono repos. I think that's how we often "re-used" code in the past, sometimes with a Windows, Android, and iOS apps in the same repo. (though often no db code).
I prefer dependencies and modern package management where each thing is separate.
Amen!
I know that it is possible to have different build processes running from a mono-repo. To me, this sounds like a coping strategy for an invented complexity. A mono-repo sounds like a good idea in theory. My experience has been the opposite.
We do have to think carefully about how the repos are separated. If you get it right, then your code base becomes much easier to understand and manage. There's less chance of accidentally deploying something you didn't expect to deploy.
If you don't have a decent README.md, and as long as you have ring-fenced access to Co-Pilot/Claude, etc., I would ask AI to provide a high-level view of the codebase in each repository.
April 19, 2026 at 2:06 pm
I completely agree with you, David!! Properly structuring repos is better than having a monorepo. In my opinion, developers who love monorepos aren't involved in having to write all those YAML files to handle the various independent deployments. Basically, the developer is lazy.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 10 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply