I gave a coding agent the Python scripts I wrote at university, and watching it fix them taught me more than the course did

Published Nov 9, 2026, 12:30 PM EST Anurag is an experienced journalist and author who’s been covering tech for the past 5 years, with a focus on Windows, Android, and Apple. He’s written for sites like Android Police, Neowin, Dexerto, and MakeTechEasier. Anurag’s always pumped about tech and loves getting his hands on the latest gadgets. When he's not procrastinating, you’ll probably find him catching the newest movies in theaters or scrolling through Twitter from his bed. Back at university, I wrote quite a few Python programs as part of my computer science coursework. We were given a problem, wrote a program to solve it, checked whether it produced the expected output, and moved on. As long as the code worked, I rarely had a reason to revisit it or question whether there was a better way to approach the problem. Recently, I decided to dig up some of those old scripts and give them to an AI coding agent to see what it could make of them. I picked three programs covering binary search, stack-based expression conversion, and the Newton-Raphson method. I was surprised by how much I learned from watching it explain and fix mistakes I'd never noticed in the first place. My binary search code had problems I never noticed Passing a few test cases wasn't enough The first script I gave the coding agent was a binary search implementation from my Data Structures and Algorithms coursework. If you're familiar with binary search, you know the idea is pretty simple. You start with a sorted list, check the middle element, and keep narrowing down the search until you find what you're looking for. My implementation used the usual low, high, and mid variables, and from what I remember, it worked perfectly fine. The coding agent started by running the program and testing it with different inputs, and things got interesting when it checked edge cases. The original code had problems with certain boundary conditions, particularly when searching for elements at the beginning or end of the list. It also exposed weaknesses in how the program handled missing elements and empty lists. These were mostly off-by-one errors and issues with how the search boundaries were updated. The agent explained why the loop condition mattered and how updating low or high incorrectly could cause the program to skip an element entirely. It then corrected the implementation and ran the same tests again to verify the fixes. Back at university, I would typically run a program with a handful of inputs and consider the assignment complete once the output matched my expectations. Here, the agent was deliberately looking for inputs that could break the program. It also introduced automated tests, something I hadn't bothered with when writing these assignments. The stack assignment exposed gaps in my understanding I memorized the logic without understanding it The next script was an infix-to-postfix expression converter, another assignment from my Data Structures coursework. The idea is to take a mathematical expression like A+B*C and convert it into ABC*+, where operators come after their operands. You use a stack to keep track of operators and their precedence while processing the expression. I remember this being one of those assignments where I spent more time trying to remember the logic than actually understanding it. My code worked for simple expressions, so I assumed I had implemented the algorithm correctly. However, when the coding agent started testing, it found problems with more complicated expressions involving nested parentheses and operators with the same precedence. Exponentiation was another interesting case — for example, A^B^C should be interpreted as A^(B^C), but my implementation didn't handle that associativity correctly. I also gave it an expression like A*(B+(C-D)) and asked it to walk me through every stack operation. It showed when an operator needed to be pushed, when it should be popped, and why parentheses changed the order of operations. That explanation helped me understand something I'd previously learned mostly by memorizing the algorithm. The agent also cleaned up the implementation and added checks for invalid expressions. The Newton-Raphson script showed me why the formula isn't enough Getting the right answer takes more than math The last script was a square root calculator using the Newton-Raphson method, which was part of my Numerical Methods coursework. It uses an iterative formula to approximate the square root of a number, getting closer to the answer with each iteration until it reaches a specified level of accuracy. My implementation worked well enough for numbers like 25 or 2, but the agent found that things weren't quite right when dealing with very small or large numbers. The problem was partly with how I'd defined the stopping condition. Depending on the input, the program could stop before reaching a sufficiently accurate result or keep running for more iterations than necessary. The agent also pointed out that my script didn't properly account for zero and negative inputs. It introduced input validation, improved the stopping condition, and added a maximum iteration limit to prevent the program from running indefinitely. One thing I found interesting was how it compared the results against Python's built-in math.sqrt() function and explained the differences in accuracy. I had always treated the Newton-Raphson method as a mathematical formula I needed to implement. I hadn't given much thought to how the initial guess, floating-point precision, and stopping conditions could affect the result, even when the formula itself was correct. I wish I'd done this back in university I learned more by questioning the agent's changes and understanding why it made them than I expected. Having access to something like this during university would have made a real difference. I could have spent more time understanding the code I wrote instead of simply completing assignments and moving on.