jemiluv8

I remember enjoying myself more as an intern in a fullstack capacity than I did when I was given the job full time about three months later. But that was 7 years ago.

I also remembered the sheer joy of forking enterprise codebases like that of cal.com and highlight.io - just to study and try to understand how large teams worked. I followed issues, I read through PRs and related comments, looked at how some of the comments were resolved. I studied the various moving parts of the app - highlight especially being effectively a log ingestion and aggregation platform, had some rather large infrastructure requirements - kafka, redis, postgresql, clickhouse. It was hard to run with infrastructure directly on your computer. You had to use their docker containers.

I also remembered reading through a tutorial for an sqlite clone in C. It was interesting. I particularly enjoyed typing out the C code and even trying alternate implementation of b-tree operations.

I remember back in 2022 - after I was unemployed for a while - I discovered open source bounties on algora.io (LLMs have since made this platform go bust). I was able to earn roughly $300 per month for a while working on open source issues ranging from $50 to $350. Now most $50 bounties can be one-shot with frontier models. So of course, no one posts open source bounties anymore. If you do, you may just end up with 50 slopped PRs.

Just random thoughts.

I haven’t verified the dates of the tweets. But it is a huge leap from a delayed release to a major conclusion that “the rewrite is not looking good”.

Yet another clickbait making outrageous assertions. Fwiw I don’t think anyone’s reputation is on the line and so far, you’ve offered only anecdotal evidence at best. Things like this should be backed by stats and community surveys and a whole lot more. I didn’t see anything about number of downloads or any of the usual metrics used to judge software these days

Your whole scientific endeavor in this seemed to thrive on the rock solid foundation of tweets.

And all those referencing of the Kelly post makes this even more of a clickbait. All you had was to put all the ingredients of a post that will draw the crowd but offer very little on the subject matter it purported to discuss

Awwww maaaan. I was just reading an upstream patch on the erpnext framework. I was going to do their copy the pr to patch my erpnext v15

Nearly everyone I suppose. There are always outliers I suppose. I’m going for 90%+ using llm in some capacity even if just a single ChatGPT prompt.

This post misses a couple of points

1.”Writing software was never the hard part” - isn’t saying coding was easy. The comparison was against building a viable product. Doing business involves a whole lot more ambiguity than sitting in your room writing code. You could build anything and yet the hard part was building something that matters

2. >> Nobody knows how the AI revolution will play out in the end

I disagree with this statement as far as Software Engineering is concerned. We kinda know. Everyone uses an agent harness to code this days - the only real difference is in how - and that still sets developers apart but most are using similar tools.

This reads more and more like clickbait. Sorry. I always find posts like this outrageous but I suppose that was the author’s intent. Outrage will get you votes. Taking extreme positions in an argument will get you attention. Kuddos

I’d go with a balanced view: you need them both for any non-trivial product. I was recently reviewing a PR that renamed a model, I wanted to understand what happened under the hood. Turns out that mariadb had a rename table operation forever ago and that was used by the orm under the hood. So no need to backup the prod table. Just run migrate and be done with it.

PS: I still exported the table before deploying this fyi.

Glad you gave yak-shaving a proper definition. I was always annoyed at my boss for insisting on a particular arrangement of import statements in typescript files. For him, it was a way of telling us to be more mindful of the code we typed. But mostly I’d have preferred a simple eslint config with autofix on save. This kinda yak shaving is no fun - trust me

Task tracking is now obsolete. Only the slowest most inefficient firms do this. So yes, I am learning as well how tasks are now effectively harder to create than actually implement, I tend to be a bit verbose and sometimes research the codebase for how a feature ought to be executed. All in all my tasks could eventually be done faster by llm’s

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.

I have fond memories of this project. Contributing to it really helped me ramp up my dev skills and was effectively my introduction to monorepo’s in JavaScript. It was the kind of codebase I couldn’t get my hands on while working in my part of the world. Good luck going closed source.

All the author’s reasons for wanting the raw text that wasn’t altered by AI are all the reasons why I like to pass my messages through llms because for most people clarity in thoughts is not a given.

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.

Outsourcing to thinking is exactly what I tell our developers. They are hired to do the kind of thinking I’d rather not do.

This one was just "fire" https://github.com/ghostty-org/ghostty/pull/10270

I was reading the above PR and a couple of others that were rejected primarily because the person making the PR didn't even understand the problem to begin with.

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?

Your setup is interesting. I’ve had my mind on this space for a while now but haven’t done any deep work on a setup that optimizes the things I’m interested in.

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.

I suppose I can understand for accounting purposes to some extent. Once a purchase is done, they receive their cash immediately but perhaps actual revenue is deferred until actual usage since that will end up leading to the "actual" rendering of service by openai. Makes accounting sense.

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

I suppose they are still shipping these things. With mcp integration and bluh, bluh, bluh. I marvel always at how much has changed and also how little has changed in building websites. My verdict: little has changed on the web. We just have too much commercial interest and a bunch of cs grads that need to do something with their theoretical skills.

Too much space. The really old newspapers I remember are crammed.

I have pain points but still like the way the site looks like something from the 1990’s. I’d like to keep it that way. And please write it in arc or some other lisp dialect. The last thing I want to see on this site is JavaScript.

The comment section not being collapsible is my main pain point. Just wished I could skim the top three most voted top level comments and then look at others. Instead I get sucked into this wilderness of a single thread and never quite easily viewing other top level threads

Get ready for hard forks

The mental effort expended when using the newly glassy ui is most noticeable when you use the glass one on phone and then use the old one on another phone. The old UI instantly feels effortless and almost as though it was the update. I'm not upgrading my new phone. Good riddance.

I wrote about this not long ago https://news.ycombinator.com/item?id=45509922

My pet peeves are a bit milder. I've found the new contacts that tries to search both call logs and the actual contact list a bit confusing. Besides these "pet peeves", I just saw the old one again and loved it. I guess you won't know what you're missing until you move on and come back?