Comment by dools | Hacker News Reader

Comment by dools | Hacker News Reader

Parent Full thread

I don't read the code my LLM produces unless I am investigating the code. I actually don't know Kotlin, or React.

My version of "code review" is "test failure investigation" and I have a hard rule in my repos that agents never modify existing tests while they're implementing features. This means that when I run the tests after they do a bunch of stuff, I see all the tests break. Mostly they're stale assertions and we patch them up. Sometimes they're regressions and we patch those up, and sometimes I notice something dumb and dive deep into a facet of the architecture that can be improved, spend some time exploring it then get the agent to implement.

I think it's a better approach than trying to read everything and catch bugs or improve quality because you wind up focusing the things that actually matter in the real world rather than the things you think might matter.

This is how I've always approached working with offshore devs too. Focus on testing for quality control, not "code quality". After all, you're going to look at the code you wrote 5 years ago and think it's shit anyway right? So all your code is shit.

Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.

I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)

>Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.

That only describes a happy path though -- I also had many instances where there's an issue and just describing it to an agent immediately identifies a fix and it all goes faster compared to me having to "load up" the flow of codebase into my brain first. But I also still have instances where it thinks it identifies an issue correctly, spits a fix which doesn't work and looks wrong. You point out that it does not make sense because of X, it agrees and spits out a new fix, which is also wrong and you start out on these back and forth wild goose chases, at this point I usually give up and do it the old fashioned way by understanding what is actually happening. If it is within an agent loop, there may be no back-and-forth to waste your time but then you pay with wasted tokens when it will eventually gives up or you stop it.

>I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)

I would question the last part. In my mind the more you let go of control over your codebase the more likely that it will drift way from a place where it is still comprehensible to you, and also your comprehension skills atrophy, and with that, your ability to ask good questions and to prod your agent in a correct directions weakens, leading to more wild goose chases and burned tokens. This is all keeping in mind that for throw away or small applications, maintainability is not that of important of a value so this doesn't affect all codebases.

I dunno, I've built a production billing system for my small telecom company, a first version of a Multiplatform app with some novel technical features, and multiple internal tools for a company I work for, which replace a bunch of tools that were strung together using various off the shelf tools. I've been working with agents for about a year. I haven't noticed any cognitive or comprehension decline. I've built things that would have taken a team of offshore devs multiple months on my own in 4 - 6 weeks, including my own coding agent harness which runs an LLM gateway and has mobile, desktop and web apps which is now in use by non-technical colleagues to build and maintain apps on the same platform.

I don't know any more about KMP, Kotlin, Compose, Bash or React than I did a year ago. I'm not that familiar with any of those technologies (well, I am pretty familiar with bash but not to the level at which it's coded by agents), and I have never run into a situation where I felt like it would be better or faster for me to learn them and go hunting through the code to find some problem or other.

Maybe I'm heading towards a cliff somewhere in the future, but based on my experience of building software for 20+ years I'm not feeling anything but optimism so far.

Fair, but based on your experience surely you would agree that 1 year is not really enough time to start seeing codebase design issues from accumulated cruft, misaligned intents and other maintainability issues, this app is still in the honeymoon phase.

Haha I’ve seen apps that never got RELEASED because of code base design issues. As I said maybe there’s a cliff somewhere but I’ve managed enough teams where I wasn’t reading the code to have an understanding of what unsalvagable looks like. I’m not seeing any red flags!

> I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly.

:blinks: The architecture of your service relied on customer clocks being correct? That is, you built a distributed service without a clock synchronization primitive that relied on the clocks being sychronized?

I’m not sure that deploying a custom clock synchronisation system would be warranted to show a countdown timer on the screen. The fix is to accept that the interface may be potentially inaccurate by a few seconds and send the relative time rather than the expiry time. Also probably to make the expiry UI stable (ie. have a “try again” button rather than flipping back to the start screen when the timer expires).

I also think that expecting that a computer connected to the internet in 2026 has the correct time isn’t too much of a long shot and things like 2fa QR codes rely on correct timing anyway.

I don't know man, even AWS gives you cryptic errors if you have a drifting clock and try to perform some operations. Feels like a pretty forgivable mistake.

Reply on news.ycombinator.com