camdenreslink

The original post said “in college”. It might be true for PhD candidates halfway through their program, but that’s like 0.5% of college students. The vast majority of students are leagues behind their instructors in domain knowledge.

People game benchmarks for fake internet points to get their favorite web framework to the top of the list. I'm pretty sure they will do it for billions of dollars.

Even Python is very old (in programming terms), version 1.0 was released in 1994. Many here weren't born yet.

Why would you create a homegrown port of Docker? Docker the container software, or Dockerhub the image repository? This is just confusing. If you didn't want to use Docker there is a perfectly good well tested alternative called Podman with wide adoption.

> Any eng that is only using Claude Code or Codex or whatever, is frankly not entitled to talk about AI's limits since they are using the most basic harnesses. They literally don't know better.

I really doubt big tech has much better harnesses than are publicly available. Definitely not "catapult vs space travel". They have the same base models we all have access to.

> Let's not pretend that someone with prior software skills will be able to produce larger scale and/or higher quality work compared to someone with no experience.

This seems like a really confident prediction. It isn't true right now, why do you think it will be true in the future? Right now having knowledge and experience is a huge benefit to steering the LLM (it makes dumb decisions all the time still).

If an email address with a + symbol doesn't work then that is a bug because that is a valid email address.

This hasn’t been my experience. State of the art models available to the public still do all sorts of bandaids and bad hacks. Putting code where it doesn’t belong. Stapling types onto variable (in TypeScript) when abstractions/types already exist to use. I use it to generate code, but still have to review every line and have corrections/steering basically every time.

Maybe you have access to some other model?

There are some really obvious things that are definitely bugs. If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work, then that is a bug. It isn’t “indistinguishable from a feature”. If clicking a button in your accounting software consumes all the RAM on your computer and causes it to crash, then there is no universe or agreed upon definition that would consider that a feature instead of a bug.

There are a lot of instances where you don't want to create an abstraction that will tie two disparate areas of the code together even if they happen to be using a similar pattern you want to copy. For example, when you expect their implementations to diverge in the future.

I have experienced enterprise codebases that have been DRY'd to the point they become ossified.

Gell-Mann Amnesia effect in action

I believe they also excluded stock-based compensation from their calculation, which could easily tip them in the non-profitable direction.

The low budget marketing channels that worked in the past are harder in this post-LLM world. SEO seems to have changed a lot, email marketing now involves trying to escape the Promotions tab, organic social media marketing is much harder too (I suspect the large social networks want you to buy ads, not get organic reach as a person/business promoting a product or service). Marketing something like a self published book online has changed dramatically.

Yea, what the heck.

If you were using Python, then probably not.

If the AI slop software managed to get a user base, then you can't just throw it away and completely start over. You need to modify it in a way that is seamless for your users. If all code becomes single use, are users generating it for themselves? Do you think a dentist office will vibe code their own scheduling software?

The AI note summaries in meetings I'm in are frequently totally inaccurate. They are actually inaccurate in two ways: they fabricate things that were never said (but always kind of close to something that was said), and they emphasize the totally wrong thing (e.g. acting like the entire conversation was about one topic when that was just a very small part).

I sincerely hope these aren't used in court.

Writing tests against a bad implementation usually doesn't work well. In this scenario I would have an LLM look at the changes in the branch and try to create a markdown document of the changes, why it thinks they were made, etc. and then review that doc with the manager and do a new implementation from scratch after aligning.

If you work on a product that has an existing user base that has an expectation that things will still work then you definitely still need to read the code. LLMs frequently break things or introduce subtle incompatibilities.

Maybe on projects with no users you can yolo things.

Total volume of usage is not an advancement, it’s orthogonal.

No? Can an AI examine a patient in the physical world?

Dotnet core was also a move in that direction with large portions being open source.

I don't think strong development teams are still letting SQL injection vulnerabilities through by manually concatenating strings to build queries with user-provided data. Not in the year 2026.

The problem is in validating the prototype. Whether the users are consumers or enterprises or internal stakeholders, they aren’t going to try 10 different prototypes. They will try one or two.

Most business software isn’t complicated to implement (i.e. it doesn’t require multiple prototypes to determine which technical approach is best). Usually for most apps you approximately know the technical implementation. What requires taste, experience, or whatever you want to call it, is the user experience and if your software actually solves a real problem. You can’t really just churn on prototypes to solve that. You will lose the patience of your user base.

Why will Anthropic be able to do that? That assumes there won't be competition and switching costs will be high. That doesn't seem to be the case to me.

Are vehicles usually on a 20 year depreciation schedule?

I question the premise that faster iteration on prototypes leads to better revenue or business outcomes.

Well, that is still having the LLM write code which is more like my second scenario. I use SOTA LLMs for coding literally every day. I don't think my knowledge is "outdated by at least a year".

If you are using an LLM to actually fetch that data, combine it, and present it to you in an ad hoc way (like you run the same prompt every month or something), I wouldn't trust that at all. It still hallucinates, invents things and takes short cuts too often.

If you are using an LLM to create an application to grab data from heterogeneous sources, combine it and present it, that is much better, but could also basically be the excel spreadsheet they are describing.

I am also curious about the correlation between more PRs getting merged faster and actual business outcomes.

My impression has always been it's more important the build the correct thing (what the customer needs/wants) rather than more stuff faster.