> a tool is a tool

> author (pilot?) hasn't generally thought too much about the problem space

I’ve stopped saying that “AI is just a tool” to justify/defend its use precisely because of this loss of thought you highlight. I now believe the appropriate analogy is “AI is delegation”.

So talking to the vibe coder that’s used AI is like talking to a high level manager rather than the engineer for human written code

AIUI this might not be as bigger problem as you’d imagine. Aerodynamics dominate most of the resistance at medium to highway speeds. This was discussed in the recent Rivian R1T cannonball run conversion videos where they doubled the battery capacity (and therefore drastically increased the weight of the vehicle) without substantially affecting efficiency.

Yes, weight alone is not that important for fuel economy at highway speeds. Aerodynamic efficiency of a vehicle is determined by the cross section area + drag coefficient. A 90s Honda Civic has a worse drag coefficient but a vastly smaller cross section than the Rivian, so it needs to move less air out of the way to drive forward. Smaller EVs can go farther with smaller batteries, but the American consumer has decided for one reason or another that cars must be tall, and therefore less aerodynamically efficient.

I currently have a landscape designer planning our yard landscaping. When I see the impressive renderings they produced I immediately thought that it’s some idealized version of how it will look on a sunny day after 10 years of bedding in. I asked them to also produce renders of how it’ll look on a gloomy winter day 6 months after planting everything. Seems they don’t have the tools to produce those images really though

I get stuck on asking “why am I solving this problem” too much. I am surrounded by technical problems that it would give a dopamine hit to solve and I’d feel the pleasure of helping my fellow man, but 99% of them feel like they shouldn’t even exist and solving them doesn’t really lead to any meaningful progress beyond providing me job security and money. (How) do people deal with this?

Deciding which problems should be solved, identifying where there is business value in solving them, is pretty much the definition of business leadership.

I think the only real answer is moving into management, where you can more effectively argue against spending effort on things that aren't worthwhile.

Well that’s not what I wanted to hear! I think you’re right though, you get to choose your challenge: do you want your problem to be possibly working on things that don’t really matter or be responsible (and empowered) to figure out what really matters.

Yeah it sucks but unfortunately this is the conclusion I came to after pondering on this for my own career. I think you phrased it as well as I've ever seen it put though.

And of course there is always the other options. For myself I didn't relish either choice and now I teach programming and CS. But I'm old and this feels like a good way to end my working years.

Thanks for sharing this detail. I've been interested in taking some form of flight training for a long time and finally have the financial means to do it, but I haven't decided whether to go with glider or powered flight. Your comments makes me realize that the time commitment might be larger than I can manage at this stage (two kids 1 and 5) and so may need to wait until a little later in life.

I want so badly to try and talk you into flying gliders, because it's amazing: way, way more fun (IMO) than the overwhelming majority of the power flying you can do as a civilian. And there are people who make it work! But ... probably this is wise, and better to make thoughtful decision.

It seems like this gets easier as the kids get older; I've seen parents of teenagers make it work. For some folks it's a family affair---several kids & one or both parents learning to fly. These families have been uniformly super fun to have at the field! For others I think it's a matter of the kids being old enough to have some independence, + I'm sure a very supportive partner.

So don't give up on gliders forever! I'm expecting times in my life when I can't get out to the field enough to stay proficient & safe, and I'll have to quit flying for a little---but a dearly hope not forever. It's just that, likewise, now's maybe not the right time for you.

It'd be a good way to lose money at the moment. Probably not too far off in the future it would make sense though

LLM-superforecaster parity projected to late 2026 (and LLMs now outperform non-expert public participants) according to https://forecastingresearch.substack.com/p/ai-llm-forecastin...

Would you like to bet on that? :)

I don't really buy into the setup here. Bash is Turing complete. How is calling os.walk in Python more "code-only" than calling find in bash? Would it be more authentically "code only" if you only let the LLM use C?

Because the process is reproducible. A series of bash commands are run as tools and forgotten, it’s hard to replicate that for future testing and verification. If the LLM generates a single bash script then that would be code-only.

No, it doesn't. For example, you could use an AI agent just to aid you in code search and understanding or for filling out well specified functions which you then do QA on.

To do quality QA/code review, one of course needs to understand the design decisions/motivations/intentions (why those exact code lines were added, and why they are correct), meaning it is the same job as one would originally code those lines and building the understanding==quality on the way.

For the terminology, I consider "vibe-coding" as Claude etc. coding agents that sculpts entire blocks of code based on prompts. My use-tactic for LLM/AI-coding is to just get the signature/example of some functions that I need (because documents usually suck), and then coding it myself. That way the control/understanding is more (and very egoistically) in my hands/head, than in LLMs. I don't know what kind of projects you do, but many times the magic of LLMs ends, and the discussion just starts to go same incorrect circle when reflected on reality. At that point I need to return to use classic human intelligence.

And for COBOL + AI, in my experience mentioning "COBOL" means that there is usually DB + UI/APP/API/BATCHJOB for interacting with it. And the DB schema + semantics is propably the most critical to understand here, because it totally defines the operations/bizlogic/interpretations for it. So any "AI" would also need to understand your DB (semantically) fully to not make any mistakes.

But in any case, someone needs to be responsible for the committed code, because only personified human blame and guilt can eventually avert/minimize sloppiness.

You 100% can use it this way. But it takes a lot of discipline to keep the slop out of the code base. The same way it took discipline to keep human slop out.

There has always been a class of devs who throw things at the wall and see what sticks. They copy paste from other parts of the application, or from stack overflow. They write half assed tests or no tests at all and they try their best to push it thought the review process with pleas about how urgent it is (there are developers on the opposite side of this spectrum who are also bad).

The new problem is that this class of developer is the exact kind of developer who AI speeds up the most, and they are the most experienced at getting shit code through review.

> But it takes a lot of discipline to keep the slop out of the code base.

It is largely a question of working ethics, rather than a matter of discipline per se.

This is kind of brilliant. Both the blog post and the idea of managing CBT as a debugging process. There’s some great insights here, e.g.

> As you fix your poverty, you discover the ennui of abundance.

and the idea that the software is running as intended but it was written for urgent needs that are no longer appropriate.

I’m find nutritional guidelines for pasta too sad to live by. It’s just not enough to satisfy me and overall detracts from my enjoyment of the meal.