>> Skeptical of using because it's not clear whether this was just an exercise or a real product they are going to ship and maintain.
> It’s a real product that we plan to maintain.
29,684 commits in a repository less than a month old does not instill confidence in this being a "real product." That is roughly 1,000 accepted commits per day.
The numbers that are on every check I’ve ever written? I presume that info is public knowledge, and that if there’s any fraud, my bank will reverse it.
It would be if pos were dereferenced in that state. However, since the postfix decrement operator is used in the inequality test, pos pointing to an undefined location is never used.
>> The Hacker News Community (hah) needs to lobby hard to pass a law (what boostrapping!) to require the https://en.wikipedia.org/wiki/Office_of_the_Law_Revision_Cou... to maintain the repo as part of their duties, and do it retroactively for the entire history of the US Code.
> I want to see a practical benefit to maintaining this with public funds versus the usual redlines.
The US government works for the people and, as such, changes made to the US Code over time must be traceable, discoverable, and therefore justifiable by or condemnable to those who are responsible for said changes without fear or favor.
> The point is that previously, changing code in a major way might take months of refactoring.
> Now, the kinds of changes that were simply unrealistic before are now entirely realistic. A refactor/migration that would have taken 6 months before, you can now get a working version done in a day, and another few days of QA.
Significantly changing a system implementation is a function of understanding, not time.
Given a starting solution state being A and a desired functionality state of A', the tooling used to codify the A -> A` delta is largely irrelevant. Specifically, in order to successfully deliver major product realignment requires awareness of what exists currently and understanding of what needs to be.
Code is neither stone nor clay.
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
> Significantly changing a system implementation is a function of understanding, not time.
> Specifically, in order to successfully deliver major product realignment requires awareness of what exists currently and understanding of what needs to be.
And this is exactly what agentic coding brings to the table in spades.
Agentic coding does not create understanding in the people tasked with altering a product to provide significantly different functionality.
In order for agentic coding to be a net positive, the instructions given to the AI offering must be from people who understand what a system currently does as well as what functionality a product needs to provide in its future desired state.
Agentic coding does not solve these fundamental concerns.
I don't disagree with wanting people to understand the product they're altering.
But whether or not this is actually needed or not now, I'm not so sure. LLMs are very good at parsing a codebase, discovering what needs to be changed to provide different functionality, suggesting any architecture changes that would be needed to do so, and ultimately implementing those changes within the bounds of an existing test suite.
I sadly suspect that if it's a choice between throwing a person or an LLM on an existing large and complex codebase cold, it's now safer and faster to use an LLM in many instances. Much better still to have someone with knowledge and understanding of the codebase work with an LLM, of course. But we're getting to the point that you can do a lot with little to no human knowledge at all.
(LLMs are also very good at bringing you up to speed with a large and complex codebase. A model can absolutely help create understanding in the person overseeing these changes, provided that person deigns to ask for it.)
> The problem is, baking something and sharing it with others brings people together ...
Honestly, I don't see how this is a problem.
> Which in the end is kinda the point of it.
Absolutely.
> Like your post says, with programming, it's mostly just a race to what achieves the goal ...
Unless the joy of whatever programming one does is found in the path taken.
> I started learning ARM assembly so I could make a lisp implementation in it. It will be useless, no one will use it, and an AI could bang one out in a few minutes ...
Who cares if anyone uses it or if some other tooling could replicate what you choose to do if, in doing so, you enjoy it.
Much like the "damn good croissants" you make, it doesn't matter what others could make. You make damn good croissants.
Your happiness is yours. Enjoy the path you take to find it.
They’re saying the problem is that programming doesn’t result in bringing people together. The problem is that the value of baking is not easily recreated in all hobbies.
> They’re saying the problem is that programming doesn’t result in bringing people together.
Why can't it?
People get together to do a ton of "worthless" things together for no good reason other than for the enjoyment of it. Like chess, basketball, book clubs, board games, video games, popdarts, etc.
Reverse-engineering was seen as a challenging hobby where people would deeply collaborate to decipher machine language. People got to know each other pretty well like they were good neighbors thanks to the process. Questions would get asked about patterns people couldn’t resolve on their own which gave opportunities for others to pitch in or relay knowledge. A network would get established.
Now a vibecoded tool gets introduced and it eliminates both the challenge and the need to collaborate. There’s no longer any bragging rights, learning hand-in-hand, pride in completing a project started months ago, nor competition to see how fast someone can complete a project. A tool is now available to all and does the work for them.
To your point, there’s no reason the introduction of the new tools won’t bring people together. The reverse-engineering communities will probably undergo an identity crisis with an exodus of participants and the creation of a new type of challenge. Those who were in it for collaborative work will probably leave and not return. Those who just enjoyed witnessing the end results might stay to discuss and learn from what the tools produce. The discussion content would be different and may draw in a completely different crowd.
I mean, if the introduction of Excel made accounting less tedious by completing previously-manual actions and somehow resulted in a massive global community which holds an annual competition for complex workbook design, then perhaps reverse engineering communities won’t vanish overnight as feared. Time will tell.
> I still prefer TypeScript since I do a lot of frontend work and prefer to use the same language across the stack.
If you perfer using the same language for both frontend and backend work, yet would like to have one more semantically rich than TypeScript, consider Scala.
Were this a common managerial philosophy, and not an exception, many efforts would have better outcomes.
The funny thing about Servant Leadership[0] is that it demands a leader see themselves as an equal with those whom they lead. Thus requiring acknowledgement that the title a person has does not establish their value, no matter what an org chart proclaims.
> It’s a real product that we plan to maintain.
29,684 commits in a repository less than a month old does not instill confidence in this being a "real product." That is roughly 1,000 accepted commits per day.
reply