Live data from Hacker News

Believe the Checkbook

robertgreiner.com

31–40 of 83 posts

Re: Believe the Checkbook

#31
post #15

The bun acquisition is driven by current AI capabilities. This argument requires us to believe that AI will just asymptote and not get materially better. Five years from now, I don't think anyone will make these kinds of acquisitions anymore.

> This argument requires us to believe that AI will just asymptote and not get materially better. It hasn't gotten materially better in the last three years. Why would it do so in the next three or five years?

Deep learning and transformers have given step functions in AI's capabilities. It may not happen, but it's reasonable to expect another step-function development soon.

Re: Believe the Checkbook

#32
post #30

How do I know they didn't buy them just to make sure their competitors couldn't?

Can anyone tell me the leading theory explaining the acquisition?

I can’t see how buying a runtime for the sake of Claude Code makes sense.

Re: Believe the Checkbook

#33

> The bottleneck isn’t code production, it is judgment. It always surprises me that this isn't obvious to everyone. If AI wrote 100% of the code that I do at work, I wouldn't get any more work done because writing the code is usually the easy part.

Lots of people have good judgement but don't know the arcane spells to cast to get a computer to do what they want.

Re: Believe the Checkbook

#34
post #22
post #11

Earlier quoted context omitted.

I don't understand this thinking. How many hours per week did you spend coding on your most recent project? If you could do something else during that time, and the code still got written, what would you do? Or are you saying that you believe you can't get that code written without spending an equivalent amount of time describing your judgments?

All you did was changing the programming language from (say) Python to English. One is designed to be a programming language, with few ambiguities etc. The other is, well, English. Speed of typing code is not all that different than the speed of typing English, even accounting for the volume expansion of English -> . And then, of course, there is the new extra cost of then reading and understanding whatever code the…

Exactly. LLMs are faster for me when I don't care too much about the exact form the functionality takes. If I want precise results, I end up using more natural language to direct the LLM than it takes if I just write that part of the code myself.

I guess we find out which software products just need to be 'good enough' and which need to match the vision precisely.

Re: Believe the Checkbook

#35

Earlier quoted context omitted.

I'll stare at a blank editor for an hour with three different solutions in my head that I could implement, and type nothing until a good enough one comes to mind that will save/avoid time and trouble down the road. That last solution is not best for any simple reason like algorithmic complexity or anything that can be scraped from web sites.

No shade on your skills, but for most problems, this is already false; the solutions have already been scraped . All OSS has been ingested, and all the discussion in forum like this about it, and the personal blog posts and newsletters about it; and the bug tracking; and theh pull requests, and... and training etc. is only going to get better and filtering out what is "best."

A vast majority of the problems I’m asked to solve at work do not have open-source code I can simply copy or discussion forums that already decided the best answer. Enterprise customers rarely put that stuff out there. Even if they did, it doesn’t account for the environment the solution sit in, possible future integrations, off-the-wall requests from the boss, or knowing that internal customer X is going to want some other wacky thing, so we need to make life easy on our future selves.

At best, what I find online are basic day 1 tutorials and proof on concept stuff. None of it could be used in production where we actually need to handle errors and possible failure situations.

Re: Believe the Checkbook

#36

> The bottleneck isn’t code production, it is judgment. It always surprises me that this isn't obvious to everyone. If AI wrote 100% of the code that I do at work, I wouldn't get any more work done because writing the code is usually the easy part.

At my company doubling the writing-code part of software projects might speed them up 5%. I think even that’s optimistic.

Imperfectly fixing obvious problems in our processes could gain us 20%, easy.

Which one are we focusing on? AI. Duh.

Re: Believe the Checkbook

#37
post #14

Earlier quoted context omitted.

"Writing code" is not the goal. The goal is to design a coherent logical system that achieves some goal. So the practice of programming is in thinking hard about what goal I want to achieve, then thinking about the sort of logical system that I could design that would allow me to verifiably achieve that goal, then actually banging out the code that implements the abstract logical system that I have in my head, then i…

The actual act of typing code into a text editor and building it could be the least interesting and least valuable part of software development. A developer who sees their job as "writing code" or a company leader who sees engineers' jobs as "writing code" is totally missing where the value is created. Yes, there is artistry, craftsmanship, and "beautiful code" which shouldn't be overlooked. But I believe that beauti…

Raising the question: Where is the beautiful machine-generated code?

Re: Believe the Checkbook

#38
post #15

The bun acquisition is driven by current AI capabilities. This argument requires us to believe that AI will just asymptote and not get materially better. Five years from now, I don't think anyone will make these kinds of acquisitions anymore.

An Anthropic engineer was getting some attention for saying six months: https://www.reddit.com/r/ClaudeAI/comments/1p771rb/anthropic...

I assume this is at least partially a response to that. They wouldn't buy a company now if it would actually happen that fast.

Re: Believe the Checkbook

#39

Earlier quoted context omitted.

I'll stare at a blank editor for an hour with three different solutions in my head that I could implement, and type nothing until a good enough one comes to mind that will save/avoid time and trouble down the road. That last solution is not best for any simple reason like algorithmic complexity or anything that can be scraped from web sites.

No shade on your skills, but for most problems, this is already false; the solutions have already been scraped . All OSS has been ingested, and all the discussion in forum like this about it, and the personal blog posts and newsletters about it; and the bug tracking; and theh pull requests, and... and training etc. is only going to get better and filtering out what is "best."

The point is that the best solution is based on specific context of my situation and the right judgment couldn't be known by anyone outside of my team/org.

Re: Believe the Checkbook

#40

> The bottleneck isn’t code production, it is judgment. It always surprises me that this isn't obvious to everyone. If AI wrote 100% of the code that I do at work, I wouldn't get any more work done because writing the code is usually the easy part.

I think it depends on the sort of work you do. We had some hubspot integration which hadn't been touched for three years break. Probably because someone at hubspot sunset their v1 api a few weeks too early... Our internal AI tool that I've build my own agents on updated our data transfer service to use the v3 api. It also added typing, but kept the rather insane way of delivering the data since... well... since it's worked fine for 3 years. It's still not a great piece of software that runs for us. It's better now than it was yesterday though and it'll now go back to just delivering business value in it's extremely imperfect form.

All I had to do was a two line prompt, and accept the pull request. It probably took 10 minutes out of my day, which was mostly the people I was helping explaining what they thought was wrong. I think it might've taken me all day if I had to go through all the code and the documentation and fixed it. It might have taken me a couple of days because I probably would've made it less insane.

For other tasks, like when I'm working on embedded software using AI would slow me down significantly. Except when the specifications are in German.

Post reply on HN