Personally, since I only do cosmetic changes to PRs like refactoring them to fit into the current codebase and sprinkling some best practices here and there - I haven’t noticed any decrease in coding velocity.

So many features felt flaky. As the team lead who reviews everyones PR and was also in charge of the deployment and monitoring, it created a lot of work for me because I had to fix every hotbug - a case in point was a pagination not working on some page or other.

During some of these fixes, I felt my knowledge of the codebase wasn't as it ought to be especially since I didn't participate as much.

Also, there were a lot of code that was so much more complex that I felt it will be if a human had written it - I felt my review was lacking in some capacity as well.

For a while I struggled reviewing PRs that turned out to be miniature ai slops. And of course, under pressure of meeting deadlines and other things you end up merging PRs that just worked via click-testing without actually reviewing the code.

In the end, I felt the codebased lacked a team member that truly understood all that was going on the way it would've been if we all coded by hand. Since I was the least contributing member of actual code, I decided I will no longer use any coding tools on the codebase - not even autocomplete from copilot.

Since that decision, I've felt my knowledge of the codebase increase and I see the codebase from an entirely different perspective than other developers working on the project. I feel like a non-ai contributor could indeed become an essential member of every development team until agents completely take over to some extent.

Do some of you have a similar experience?

FYI - I use coding tools in my personal projects. But this work project had enough time for us to deliver that AI usage was probably not an economic necessity.

Comments URL: https://news.ycombinator.com/item?id=47780915

Points: 1

# Comments: 2

Often, in formal communication, I find it makes a lot of sense to make it as robotic and to the point as possible because informing my boss about the progress of a project shouldn’t leak any emotions. This is not a romantic or social relationship where emotions need to be expressed.

And I like the idea of setting goals for what I want to convert and having these llms go through the message and let me strip out the fat and ensure there is little room for misinformation and digression.

So yeah, what the author wants probably works more in an informal social setting than in a formal.

LLMs tend to make most people feel like they can write code without understanding the problem at hand. In a lot of cases, they even climb the ladder of ai-suggested designs and end up with what is probably poorly designed but works anyway. That probably fuels their confidence and gets them to continue - I get away with some of these things on most reactive UI frameworks.

When doing systems programming however, it is hard to get away with poorly designed, conceived and executed work. Especially in open source projects where a couple of maintainers have to retain context of the entire project over a long period of time to facilitate their ability to review and make community contributions possible. These people tend to understand the product deeply and tend to also do gate-keeping for the quality of code that is contributed. Without that gate-keeping, open source might just not be sustainable.

Today with all these llm tools, people just get up and feel like they can ai-slop their way to PRs on open source projects. This is a maintenance burden on open source maintainers that I fear will only increase over time.

It is probably time for github to implement a policy of enabling maintainers to ban some users from making a PR?

Comments URL: https://news.ycombinator.com/item?id=46637295

Points: 1

# Comments: 2

I think at a fundamental level, I expect we can produce higher quality software under budget. And I really liked how you were clearly thinking about cost benefits especially in your setup. I’ve encountered far too many developers that just want to avoid as much cognitive work as possible. Too many junior and mid devs also are more interested in doing as they are told instead of thinking about the problem for themselves. For the most part, in my part of the world at least, junior and mid-level devs can indeed be replaced by a claude code max subscription of around $200 per month and you’d probably get more done in a week than four such devs that basically end up using an llm to do work that they might not even thoroughly explore.

So in my mind I’ve been thinking a lot about all aspects of the Software Development LifeCycle that could be improved using some llm or sorts.

## Requirements. How can we use llms to not only organize requirements but to strip them down into executable units of work that are sequenced in a way that makes sense. How do we go further to integrate an llm into our software development processes - be it a sprint or whatever. In a lot of green field projects, after designing the core components of the system, we now need to create tasks, group them, sequence them and work out how we go about assigning them and reviewing and updating various boards or issue trackers or whatever. There is a lot of gruntwork involved in this. I’ve seen people use mcps to automatically create tasks in some of these issue trackers based on some pdf of the requirements together with a design document.

## Code Review - I effectively spend 40% of my time reviewing code written by other developers and I mostly fix the issues I consider “minor” - which is about 60% of the time. I could really spend less time reviewing code with the help of an llm code reviewer that simply does a “first pass” to at least give me an idea of where to spend more of my time - like on things that are more nuanced.

## Software Design - This is tricky. Chatbots will probably lie to you if you are not a domain expert. You mostly use them to diagnose your designs and point out potential problems with your design that someone else would’ve seen if they were also domain experts in whatever you were building. We can explore a lot of alternate approaches generated by llms and improve them.

## Bugfixes - This is probably a big win for llms’ because there used to be a platform where I used to be able to get $50s and $30s to fix github bugs - that have now almost entirely been outsourced to llms. For me to have lost revenue in that space was the biggest sign of the usefulness of llms I got in practice. After a typical greenfield project has been worked on for about two months, bugs start creeping in. For apps that were properly architected, I expect these bugs to be fixable by existing patterns throughout the codebase. Be it removing a custom implementation to use a shared utility or other or simply using the design systems colors instead of a custom hardcoded one. In fact for most bugs - llms can probably get you about 50% of the way most of the time.

## Writing actual (PLUMBING) code . This is often not as much of a bottleneck as most would like to think but it helps when developers don’t have to do a lot of the grunt-work involved in creating source files, following conventions in a codebase, creating boilerplates and moving things around. This is an incredible use of llms that is hardly mentioned because it is not that “hot”.

## Testing - In most of the projects we worked on at a consulting firm, writing tests - whether ui or api was never part of the agreement because of the economics of most of our gigs. And the clients never really cared because all they wanted was working software. For a developing firm however, testing can be immense especially when using llms. It can provide guardrails to check when a model is doing something it wasn’t asked to do. And can also be used to create and enforce system boundaries especially in pseudo type systems like Typescript where JavaScript’s escape hatches may be used as a loophole.

## DEVOPS. I remember there was a time we used to manually invalidate cloudfront distributions after deploying our ui build to some e3 bucket. We’ve subsequently added a pipeline stage to invalidate the distribution. But I expect there are lots of grunt devops work that could really be delegated. Of course, this is a very scary use of llms but I daresay - we can find ways to use it safely

## OBSERVABILITY - a lot of observability platforms already have this feature where llms are able to review error logs that are ingested, diagnose the issue, create an issue on github or Jira (or wherever), create a draft PR, review, test it in some container, iterate on a solution X times, notify someone to review and so on and so forth. Some llms on this observability platform also attach a level of priority and dispatch messages to relevant developers or teams. LLms in this loop simply supercharge the whole observability/instrumentation of production applications

But yeah, that is just my two cents. I don’t have any answers yet I just ponder on this every now and then at a keyboard.

Even though it gives me the vibes of something the fictional " Sirius Cybernetics Corporation", would do.

In my part of the world, that tactic is used by telcos to sell "broadband data". You buy internet bundle of about $1 and they give you expiry of about a week. This drives up the "real" price of these purchases because of the time constraint. Ultimately, if you had 1GB of data left after a week, it is all gone and you have to purchase again - further driving sales. Since this is a third world country we're talking about and telco's tend to be oligopolies and tend to also do some form of price collusion among themselves, it was generally accepted as "just how things were".

But I always found it to be unfair because people should be allowed to take their time consuming whatever product they purchased.

I wonder if this is general practice for all llm apis? Am I missing something? Is this really how things should be? I can't seem to fathom why "purchased" llm credits should have an expiry date - however generous. Especially when the same credits can be used to access any of their available models.

Comments URL: https://news.ycombinator.com/item?id=46230848

Points: 5

# Comments: 14

-> This feels extreme to me because most developer quirks and preferences tend to be about optimising things -> this doesn’t. People like vim because it makes code navigation super fact. Lots of dev’s like keyboard shortcuts a lot because against - faster.

But this preference makes me do a double take and makes me wonder - to what extent are our developer habits or quirks A bit out of “order”?

What are your quirks

Comments URL: https://news.ycombinator.com/item?id=45670101

Points: 2

# Comments: 4

Comments URL: https://news.ycombinator.com/item?id=45586009

Points: 2

# Comments: 0