In all fairness: human senior devs see AI-written source code with some disdain, as it usually does not match their stylistic and idiomatic preferences (although being correct and fully working).
I don't think that untested code is the problem here - you can easily measure test coverage and of course. every CI/CD pipeline should run the existing unit and integration tests.
Your job is to deliver code you have proven to work
611–620 of 699 posts
Re: Your job is to deliver code you have proven to work
#612For what it's worth, writing good PRs applies in more cases than just AI generated contributions. In my PR descriptions, I usually start by describing how things currently work, then a summary of what needs to change, and why. Then I go on to describe what exactly is changing with the PR. This high level summary serves to educate the reviewer, and acts as a historical record in the git log for the benefit of those wh…
I often write PR descriptions, in which I write a short explanation and try to anticipate some comments I might get. Well, every time I do, I will still get those exact comments because nobody bothers reading the description. Not to say you shouldn't write descriptions, I will keep doing it because it's my job. But a lot of people just don't care enough or are too distracted to read them.
This is a hill I’m going to die on, but I find 9/10 times people use the pr description for what should have been comments. “Git blame” and following a link to a pr is inferior ux to source code comments.
The North Star of pr review is zero comment approvals. Comments should not be answered in line, but by pushing updates to the code. The next reader otherwise will have the exact same question and they won’t have the answer there.
The exception being comments which only make sense for the sod itself but not the new state of the code. IME that’s ~10%.
I have bought my tombstone.
Re: Your job is to deliver code you have proven to work
#613Earlier quoted context omitted.
Yeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or…
Our leader wrote himself a great prompt to fill up Tickets in jira with useless text too and our boss is happy like if he won the lottery. Now instead of ugly but short useful texts now i have yo read a fucking eassay!!!
Better than dealing with a PM though
Like look, your boss was happy, so the blockade away from your boss that your PM provides is solved
So just write an agent to summarize and read the room like the 200 EQ mastermind that it is, compared to your 0 EQ engineer brain, and move on
AI writing tickets, AI reading tickets, AI writing code from said tickets
only ones affected are middle management and site reliability engineers, poof we can write complex backend scripts too now
Re: Your job is to deliver code you have proven to work
#614Earlier quoted context omitted.
There are always unknown unknowns which a rigorous testing implementation would just hide under the rug (until they become visible on live, that is). > They had 9000+ tests. They were most probably also written by AI, there's no other (human) way. The way I see it we're putting turtles upon turtles hoping that everything will stick together, somehow.
No, those 9,000 tests are part of a legendary test suite built by real humans over the course of more than a decade: https://github.com/html5lib/html5lib-tests
I thought we were talking about human-scale (as in not multi-human) projects, my bad.
Re: Your job is to deliver code you have proven to work
#615> Don’t be tempted to skip the manual test because you think the automated test has you covered already! Almost every time I’ve done this myself I’ve quickly regretted it.
How does this work? When expectations about the program's state vs its observable behavior diverge?
Re: Your job is to deliver code you have proven to work
#616> Don’t be tempted to skip the manual test because you think the automated test has you covered already! Almost every time I’ve done this myself I’ve quickly regretted it. How does this work? When expectations about the program's state vs its observable behavior diverge?
A manual test is often an end-to-end test which are notoriously difficult to automate.
Re: Your job is to deliver code you have proven to work
#617Earlier quoted context omitted.
Unfortunately, junior behavior exists in many with "senior" titles. Especially since "senior" is often given to those 2 years out of school.
I've job hopped a bit. I've gone from junior to senior to lead to mid-level to staff to senior. I have ten years experience. My career trajectory is wild. At this rate I'll be CTO soon, then back to mid-level.
It also doesn’t help that definition of who “staff engineer” is varies wildly by the company.
Re: Your job is to deliver code you have proven to work
#618Hmm. I've never been asked to do formal proofs for my code. Where does he work?
Re: Your job is to deliver code you have proven to work
#619Earlier quoted context omitted.
You know, this is kind of a funny take at some level. Like, for any surgery, you want the doctor who has done the same operation 10 times, not the one who has 10 years of "many hat doctoring" experience. I'm not really arguing anything here, but it is interesting that we value breadth over (hopefully) depth/mastery of a specific thing in regards to what we view as "Senior" in software.
If we extrapolate the Dr example: There is the one doctor who learned one way to do the operation at school, with specific instruments, sutures etc. and uses that for 1000 surgeries. And then there's the curious one who actively goes to conferences, reads publications and learns new better ways to do the same operation with invisible sutures that don't leave a scar or tools that are allow for more efficient operation…
The one with the smaller cemetery.
Re: Your job is to deliver code you have proven to work
#620i don't think this is as much as an AI issue as it is about path of least resistance in a velocity-driven environment.
call me the worst junior dev in the industry, but pre-coding agents, closing tickets was more important than upholding absolute quality. not everybody is dealing with a billion concurrent users with multi-geo deployments. most of the time, a few screenshots or test output for manual validation is enough to go ahead. when pressed with time and without the prerequisites in the infra side, doing the absolute best development and testing is a luxury only for daydreamers.
automated testing can be a double-edged sword. pre-LLM, even test coverage was a number that somehow needed to go up after each PR. this only resulted in shady tactics of pointless test cases that slowly bring up the metric. today it can be very dangerous if both code and its test suite are vibe coded. especially when it can give the appearance of that 90%+ code coverage.
on the other hand, some manual testing to make sure the core functionality works is the bare minimum one does before pushing out code. at least i would like to believe it is.