gregjor

Psychosis means inability to distinguish the real from the not real -- delusion. I don't think the article describes that, at least not in a literal or clinical sense. The author lifted a term usually applied to people who fall in love with chatbots and applied it to the context of software developers not understanding AI coding tools, and the limitations of those tools.

AI coding swept over the software industry faster than most previous trends. OOP and its predecessor "structured programming" took a lot longer. Agile and XP got traction fairly quickly but still took longer than AI -- and met with much of the same kind of resistance and dire predictions of slop and incompetence.

AI tools have led to two parallel delusions: The one Mitchell Hashimoto describes, and the notion that we (programmers) knew how to produce solid, reliable, useful, maintainable code before AI slop came along. As always with tools that give newbs, juniors, managers some leverage (real or imagined) we -- programmers -- get upset and react to the threat with dire warnings. We talk about "technical debt" and "maintainability" and "scalability."

In fact the large majority of non-trivial software projects fail to even meet requirements, much less deliver maintainable code with no tech debt. Most programmers don't know how to write good code for any measure of "good." Our entire industry looks more like a decades-long study of the Dunning-Kruger effect than a rigorous engineering discipline. If we knew how to write reliable code with no tech debt we could teach that to LLMs, but instead we reliably get back the same kind of mediocre code the LLMs trained on (ours), only the LLMs piece it together faster than we can.

With 50 years in the business behind me, and several years of mocking and dismissing AI coding whenever someone brought it up, I got dragged into it by my employer. And then I saw that with guidance and a critical eye, reasonably good specs, guardrails, it performed just as well and sometimes more throroughly than me and almost all of the people I have worked with during my career. It writes better code and notices mistakes, regressions, edge cases better than I can (at least in any reasonable amount of time).

AI coding tools only have to perform better -- for whatever that means to an organization -- than the median programmers. If we set the bar at "perfect" they of course fail, but so do we. We always have. Right now almost all of the buggy, insecure, ugly, confusing software I use came from teams of human programmers who didn't use AI. That will quickly change and I can blame the bugs and crashes and data losses and downtime on AI, we all can, but let's not pretend we're really losing ground with these tools or that we could all, as an industry, do better than the LLMs, because all experience shows that we can't.

Two months ago I would have written the same thing.

I have 50 years experience programming. I have adapted to change over time to stay employable. And I have cultivated programming as a craft, taking pride in my experience and expertise and knowing how to write working code "by hand."

Then a couple of months ago my employer adopted AI, and I saw almost immediately that I couldn't keep up with it. I could mock it, criticize, point out the silly mistakes it makes, but I found it hard to argue with the results. The programmers using AI (Claude Code in our case) got their work done faster, and I couldn't honestly say their work looked any worse than it had before AI -- in fact I noticed more unit tests, fewer regressions, and abilities enhanced even from the more junior programmers. I had to get on the bus or get off, so I learned how to use AI and have seen my own productivity increase at least 3x.

I think we need to distinguish between programming as a craft -- the thing the author says he enjoys and won't give up -- and programming as labor someone else pays for. Anyone who has worked in the software development business for very long understands that our employers and customers don't care about our craft. They don't care about readabiity, maintainability, technical debt, best practices. They care about getting things done that address the business problems they have, or think they have.

For a long time we -- programmers or whatever euphemism you prefer -- have held the upper hand. Our bosses and customers had no alternative but to pay us to write code for them. They have had to put up with shockingly unpredictable processes that lead to chronic schedule and budget overruns. They have paid for low-quality software, then paid us to do it over. Only a fraction of software projects succeed (go into production and/or result in profit or cost savings), and an even smaller fraction get delivered on time and within budget. I don't mean to imply that we have done that on purpose, but programmers do like to pat themselves on the back and talk about best practices and clean code and every other method and tool "stack" we present as silver bullets, but have little to show for it, for decades.

Now AI comes along and the curtain gets pulled back, and we're indignant, threatened, defensive. A mere bot can't possibly write code as good as I can! The AI companies reek of fraud, corruption, environmental destruction.

No matter what happens to the current crop of AI companies, or how much money gets wasted or grifted, or how much pollution they cause, the LLMs and the coding tools they enable won't go away. They work, regardless of their owners and the damage they cause. Programming will look like this from now on whether we like it or not.

We can retreat into our craft, like the guy with hand tools carving tables in his garage. But I know I can't feed myself or my family with my software craftsmanship, because no one will pay for that anymore. Faced with this reality I had to decide to either leave the business (I am at retirement age anyway) or adapt and continue to get paid. We will all have to make that choice.

In my so-far limited but overall good experience with AI programming I think knowing how to program, and having a lot of experience, gives me a significant advantage over a non-technical manager or a newb programmer. I know how to tell the tool what I want it to do in clear unambiguous terms, and I know how to decide among alternative approaches, and how to judge the result. I won't call myself a "prompt engineer" anytime soon but that describes what I do now. The author can wait for this all to blow over and for programming to go back to hand-crafted code, but I don't think that will happen.

I don't think anyone suggested that.

The warp drives in Star Trek seem awesome too, we're just behind schedule.

Starship excels at funneling tax money into Musk's various enterprises. Whether it actually reaches orbit, much less the moon or Mars, merely incidental, the sexy marketing photos for an imaginary island resort.

By the time Starship does actually achieve orbit it will likely get damaged by all of the debris SpaceX has parked around the planet.

In The Art Of Computer Programming, one of the most influential and comprehensive series of books on the subject, Knuth uses a fictional assembly language called MIX in the examples. The reader does "just run the program in their head."

In Software Tools Brian Kernighan and P.J. Plauger describe a pseudo-language called RATFOR (Rational Fortran), and then throughout the book implement RATFOR in itself.

Getting feedback while learning to program has a lot of value, but so does learning to think through code in your head. People old enough to remember when you had to wait a day to run your program and get results back (very slow turnaround) know the value of that skill, we used to call it "desk checking" -- reading through your code and running it in your head and on paper.

I don't either. Come to think of it, few of us know if our jobs will exist in a decade. We adapt or live with our parents.

What's it like?

You don't say what kind of work you would look for, where in the large geography called the Bay Area, or what kind of living standard you expect. So no way anyone can give a meaningful answer, as reflected in the lack of responses.

@dang Thanks for the thoughtful reply. I abandoned all other social media years ago, I stick around on HN largely because of the moderation.

You probably know that I did not actually feel insulted or attacked. One of the few advantages of getting older: I care less and less what people appear to think about me, or what they say. And I don't think you intended insult. I alert at language using forms of "to be," to the annoyance of people who argue with me.

I understand how my comment can read like a personal attack, and I could have interpreted the OP more generously, or kept my mouth shut. I will try to do better. Something about the "I have too many ideas popping into my head" and "I think too fast" -- posted daily in one form or another, or spouted in co-working spaces, sets me off. My problem, which I will blame on cognitive decline and general feeling that I have reached the end of my road in the tech industry.

@dang I appreciate the tireless and thankless work you do in HN, sincerely, but I don't always agree.

Don't be curmudgeonly.

I feel flattered to get identified as a curmudgeon in company with Socrates, Samuel Johnson, Mark Twain, and George Carlin. I might take offense at the implicit ageism but at my age I roll with it. HN teems with unchallenged insults directed at the elderly, grating on us old people, but in line with the HN demographic.

Thoughtful criticism is fine, but please don't be rigidly or generically negative.

No one can "be" those things since that implies an identity. One can write in a negative tone. Accusations of rigidity and genericity would require a large sample. No one who knows me would describe me as "rigid or generically negative" so I will let that go as an ignorant judgment.

please don't cross into personal attack.

Refuting the OP's claims can't count as personal attack, unless we hollow out all argument and rhetoric. I apologize for the Adderall comment, should have left that out.

That is in no way allowed here.

Ironic given the personal nature of the moderator scolding, attacking my age and identity by telling me what not to "be."

[flagged]

Interesting, but should mention article serves as an ad for Datalevin.

Grift of the month. How can anyone take this seriously year after year? Didn't we get promised robots building colonies on Mars by now? Or at least Starship carrying a payload and not exploding?

Wrong level of abstraction. And not the definition of machine.

I might feel awe or amazement at what human-made machines can do -- the reason I got into programming. But I don't attribute human qualities to computers or software, a category error. No computer ever looked at me as interesting or tenacious.

I asked ChatGPT to choose one for me.

I don't understand why anyone finds it interesting that a machine, or chatbot, never tires or gets demoralized. You have to anthromorphize the LLM before you can even think of those possibilities. A tractor never tires or gets demoralized either, because it can't. Chatbots don't "dive into a rabbit hole ... and then keep digging" because they have superhuman tenacity, they do it because that's what software does. If I ask my laptop to compute the millionth Fibonacci number it doesn't sigh and complain, and I don't think it shows any special qualities unless I compare it to a person given the same job.

LLMs do not have grit or tenacity. Tenacity doesn't desribe a machine that doesn't need sleep or experience tiredness, or stress. Grit doesn't describe a chatbot that will tirelessly spew out answers and code because it has no stake or interest in the result, never perceives that it doesn't know something, and never reflects on its shortcomings.

Painful slow grind? I have always found the learning part what I enjoy most about programming. I don't intend to outsource that a chatbot.

You mangled Jefferson a bit. He wrote about education, not news. He didn't imagine the the non-stop firehose of slop and advertising and propaganda we endure and call news. What passes for news today describes the opposite of critical thinking and education.

No evidence supports your sentiment. Find an example of democracy that arose from citizens "being informed about what's happening." The Athenians limited democratic participation to a small educated elite. The American Founders had the same instinct, excluding more people than they included.

Demoracy dies in front of our eyes right now, in the USA, the most media-saturated culture in history. You might blame that on an ignorant and uncritical population. You might call them uninformed, or misinformed. As Jefferson understood the problem doesn't come from people not reading the news, but rather people not educated enough to understand, think critically, or even care.

Why not sell dragon rides in Westeros? What a scam. Starship yet to achieve orbit or carry any payload, and it won't have lots of room inside supposing it ever gets to the moon. This looks like a sure thing to bet against on prediction markets.

What does "chill" even mean? If I saw that on an application... delete.

My biggest roadblocks come from my own certainty that I wrote correct code. That leads me to look in the wrong places for the bug. I have repeatedly looked right at bugs and not seen them because I felt sure that code works as expected.

Have you tried vscode-neovim?

Yes. I don't see the point, though. If I can run full neovim inside VSCode what does VSCode add?

I guarantee if he spent as much time configuring vscode as he did configuring vim he could establish equivalent environments.

Yes, almost. For example you can make VSCode run terminals in tabs like the editor windows. VSCode supports a lot of customizing. But it still runs on Electron with a rather heavy node process on the other end -- a lot heavier than vim or neovim.

I used VSCode for over six months but ended up going back to vim. Nothing specifically wrong with VSCode, I recommend it to people who don't know how to use vim/neovim, or don't want to use those tools. But for those of us who know how to use vim/neovim VSCode feels slow and bloated with features I don't want. Personally I prefer not to use Microsoft products when I can help it, but now with VSCode (and GitHub) increasingly pushy about AI that I don't want I can do without VSCode.

Preach! My thoughts exactly.

Misdirection from previous next big thing failures. Propping up stock prices.

https://harpers.org/archive/2025/12/kicking-robots-james-vin...

Activity is just a small part of how we assess their skills.

Nothing on your web site or in your HN post refers to anything other than analyzing git activity. Crunching commits -- artifacts of the software development process rather than the process itself -- seems the core of GitHired.

< Its more about the projects you've built- how complex they are, their architecture, frameworks etc.

While that may have some value it doesn't work for programmers who have all of their work unavailable in company-owned private repositories. 100% of my work, for example, and a large percentage for every professional programmer I know. Even hiring managers and recruiters understand that public repos and personal private repos mainly represent hobby projects and side hustles.

The whole point is that candidates often tailor their resumes to fit keywords from job descriptions...

True enough, but that happens because of recruiting/screening tooling -- an arms race. Sending out applications, tailored or not, into the automated and so-called "AI" screening/ranking systems describes the least effective way to get a job. Recommendations and reputation work much better, for a reason: a good hiring manager will trust their own experience and instincts, and the opinions of people they trust, more than a dashboard of code commit metrics. Sadly good hiring managers seem even harder to come by than good programmers.

...we cut through all the bs to show what they've actually done, not what they say they can.

So a programmer fresh out of boot camp who knows one language and framework will score higher than a more experienced programmer with broader experience? A person who used PostgreSQL for a year gets ranked higher than the programmer with two decades of Oracle and SQL Server?

Programmers don't succeed or fail because of mastery (or lack of mastery) of specific languages and frameworks. Projects and teams succeed, or fail, mainly because of team dynamics, conceptual integrity (as Brooks called it), and management consistency and support. Learning a language or a framework amounts to a necessary but hardly sufficient part of software development, and not even a key part of the process. Domain expertise counts for much more: I would rather hire someone with years of experience in (for example) enterprise logistics and let them learn a programming language rather than the other way around. You can't infer that kind of expertise, or how a person works in a team, or if they can reliably implement requirements, from git repo activity.

I don't blame you for the degradation and frustration of the tech recruiting and job hunting process. Most of the blame falls on the class of managers and executives who don't know anything about managing people or projects, and nothing about software development. Falling back on some sciency-looking numbers at least lets them continue blaming their shortcomings on something else.

My first reaction: This tool looks at the wrong metrics, or a small subset of possibly relevant metrics. Nothing about git activity correlates to "who can code" (as opposed to who can produce code), much less all of the skills not apparent in git repository that make a developer valuable -- 10X or "cracked" as you put it.

You call tech hiring "broken." Have you considered that trying to reduce programmer skill and value to a simple formula or metric contributes to that? Perhaps the swipe left or right mentality of "tech recruiting," adapted from the also broken dating domain has something to do with it. Recruiters and hiring managers unqualified to talk to and evaluate candidates hiding behind CYA tools -- broken.

Tech hiring does indeed look broken for people who only have their git history to sell themselves.

No employer or customer I have ever worked for would give access to their private repos for data collection. A candidate who did give such access likely broke their NDA and maybe the law. I have no public git repos, consistent with many of the professional programmers and freelancers I know. I only work in private repos owned by a company that has the resources to enforce their IP. Curious how you can assert in comments that your tool analyzes private repos.

Trying to imagine having so little connection with a child to need such an app. I raised three kids, could always tell when they got tired.

My grandparents used cough medicine to reliably "predict" nap time.

Yes, I have. Sometimes it works, sometimes not, like all team organization strategies. Comparing team organization styles proves close to impossible, too many variables and confounding factors.

Projects fail mainly because of interpersonal conflicts and poor/incomplete requirements. Experienced smart people who understand the domain and have authority to make decisions can succeed with any team organization.

You conflate different meanings of "context."

The problem Brooks describes around communication has to do with multiplying the number of paths as the team grows. The "surgical team" approach includes a member in charge of documentation at all stages, to give everyone access to the same context.

A small team may "vibe code" something they call a CRM in a week, but unlikely it will work and stand up to requirements changes. Only someone who doesn't understand the business domain would claim they can coax a solution out of an LLM in a few days.

I have this on a sticky note on my refrigerator.