Regardless of the minimal time with LLMs, I think he hit major points on importance of clarity of abstractions, unreliability, shipping more features and working harder than even and losing touch with the underlying implementation.

I'm using Github copilot and I ran out of requests before the end of the month; this happens from time to time. But last month was the first time I decided to try the cheap models that were still accessible to me just to see what they were capable of. They're dumb as rocks.

I just don't know how many people have an overly negative opinion on AI assisted coding because they've just used the poor versions of these products given out for cheap/free. A similar critique is basing one's opinion on AI based on summary that Google provides for free in their search.

I still use LLMs in a "no-vibe coding" way. Essentially I use a combination of the typical auto-complete and asking it to generate tests or individual structs/classes that I then heavily modify. But no line of code goes unread and unvetted by me.

People have a very strong tendency to go "current gen technology cant achieve x, therefore its impossible for this class of technology to ever achieve x"

Many many many of the problems with current gen ai will go away.

> Acting like LLM use is a spectrum between doing everything manually or handing control over to the LLM and vibecoding everything is a tired strawman argument.

But isn't the strawman here was that it wasn't a spectrum. That they couldn't just use it some, but all or nothing.

I'm doing agentic coding with Claude Max, and it's like giving methamphetamine to a software developer.

When I run out of tokens, I pay for extra. It doesn't feel good, but I do it because I didn't write the codebase - the drug dealer did. Just one more "fix" and the code should be good to ship. Oh no, out of tokens again? Just one more "fix", and another.

And the code that the AI writes is sprawling and almost incomprehensibly complicated. Overly complicated. It's like a tweaker wrote it, on methamphetamine.

I can make this comparison because many years ago I once had an ex that put methamphetamine (I didn't realize they had an addiction) in one of my vitamin capsules "as a joke", and I was up for 36 hours straight writing convoluted code, and then writing voluminous notes about the code I had yet to write. I had never done that drug before, or since (why they are an ex). I don't even drink. After that episode I re-read what I had written and it was quite scattershot.

And now I get the same exact feeling when using AI to write code, or have it write tickets, or plan out something, etc.

I use these tools daily, and it's like putting a drug dealer between me and the code. Sure it writes a lot more code than I could write without it, but at what cost? I really don't like where this is headed. And I don't think most software developers using AI realize what is happening.

LLM usage has costs that are open ended and rising. The author describe how he relates to that as a relentless cheapskate. This isn't supposed to be a directly applicable lesson to most, just a point of reference for further consideration. How much higher will costs go? How realistic will simple finishing off an odd idea be if the tools are charging professional rates? Much of the logic now seems to be can therefore do without much reference to costs or risks.

Imagine being disappointed that an article is NOT clickbait :|

I have the opposite experience:

* https://repo.autonoma.ca/repo/treetrek/tree/HEAD/render/rule... - syntax highlighting for 40 languages and file formats in ~10 minutes

* https://shufflenblues.com/expenses/ - real-time expenses progress updates with payment vendor API in ~30 minutes

* https://repo.autonoma.ca/repo/treetrek/tree/HEAD/git - real-time, cache-free raw Git reader implementation with cloning in ~5 days

* https://repo.autonoma.ca/repo/notanexus - PDFjs integration in ~3 days

However, these are likely not the "hard" problems you've mentioned. I feel like I can architect solutions at a higher-level now, without having to be completely caught up in many technical nuances. I'd rather not learn the extensive PDFjs API, for example, because it would take weeks of effort to understand.

Developers were not solving hard problems. The last decade was brutal—mainly frameworks, libraries, configurations, etc. The hard problems were in research.

And regarding the gym, sure, you might enjoy lifting dumbbells and solving puzzles to sharpen your brain. But that is not what engineers are hired for; they are hired to deliver a system using the best tools available. You can choose to farm by hand while the industry moves to using tractors, but sooner or later, you will be left behind.

And lastly, moving higher in abstraction allows us to tackle even more complex problems—I'd argue much more complex than the narrow puzzles we were facing before. Part of the resistance is simply an avoidance of facing higher-level complexity once the lower tier is automated.

I'm not paying someone to dig by hand if a machine makes the job quicker.

You're going to get picked apart by people who live within walking distance or public transport distance of their office and don't understand why everyone else uses cars.

If you can walk to your office and the temperature is always between 50 and 70 degrees F you would probably think cars are crazy, too.

Which, funnily enough, proves the point even further. Some people get so comfortable in their bubble that they become unable to even comprehend why other people make other choices in other situations.

Checked all five except "caring for my horse" is "tinkering with my bicycle".

Life without a car is not an exotic luxury at all, far from it, and all your points are just proving the point. Cars are a luxury, from the amount of taxes paid towards car infrastructure to the social costs associated with “the car culture” (insurance, public health, climate change, etc.). There are countless examples of urban and rural areas where alternative modes of transportation (LRT, bus, bicycle, ferries) are the norm and where cars are barely necessary/used. Not every place in the world is Anywhere, USA…

Yes everyone that lives in a major city that doesn't use a car is... not participating in the real economy.

There are many trainfuls of people who still write code using traditional syntax-based IDE completion.

But it is not a real economy is it? Vast sums of money are being spent subsidizing token processing with little to no tangible business benefit for the end user.

For those of us lucky enough to have the choice, the best bet is to sit it out for a year or so until it all comes crashing down, then re-engage with what's left of the software industry.

Is this bait? What are you talking about? I just use public transport to go to work. Basically, all of those points about cars are correct, except for the last one because here you almost always get stuck in traffic during rush hours. Often buses get to a destination faster than cars because of Bus Rapid Transit.

EDIT: Oh, you are talking just about the US. Then your comparison doesn't make any sense because LLMs are available worldwide.

People write "i dont" when they mean "i cant"

Tbh. Those are all good reasons not to drive. I my self would add:

- They dangerous both to me as a driver, my passengers, and other road users, including pedestrians and bicyclists.

- They ruin cities which constantly have to accommodate ever increasing number of cars by destroying previously walkable neighborhoods to make room for roads and parking.

- They destroy our climate

- They are loud.

- Busses are nicer and I can read a book while riding the bus.

if you are serious about building a startup the best choice you could make is to learn to use these tools intelligently. ESPECIALLY if what you are building is an app…

virtually everyone building a startup uses these tools to automate a huge chunk of the work. you have no real chance otherwise.

my advice is to get on the cheap claude code sub and to check out the superpowers plugin.

the idea of the plugin is to help you create a “design” plan which promotoes to an “implementation” plan.

the former is a high level architecture decisions which YOU TAKE and use the agent to browse different approaches that might work.

the latter is the concrete steps the agent will take after you click execute. every file change documented, every migration required, etc. very easy to oversee it

just my 2 cents (as someone working on startups)

>but this was really wonderfully written

That's because AI wrote it to deter other AI from taking it's job

Yep. If it weren't for cheap / freely available tools (and their limitations) I wouldn't be where I am today. I think about this every time I make a tool of my own.

It does seem like a sort of virtue signaling these days right?

Wait what's wrong with the Criterion Channel??

I think that's just to have the domain complete their name.

I was already spending a lot of time reviewing other people's code. It makes no difference to me if it's coming from an agent or a person.

I can pick and choose which parts of the problem deserve my attention and which can be done by the LLM with me just keeping an eye on it while I mostly work on something else. I don't have metrics but I feel like I am doing higher leverage work with less friction.

Setting up the systems around the LLM itself is fun too. Hacking on harnesses and trying to improve the UX or the metrics is fun. Playing with different workflow topologies across agents is fun. Diving deep into context strategies, memory systems, prompting is fun. Trying to marry ideas from the past with what LLMs enable now is fun.

I don't see how this is soulless or unbearable but granted I'm not at a place that is demanding I maximize throughput. That would suck.

"painting is just procrastination that gets in the way of implementing your ideas."

"woodwork is just procrastination that gets in the way of implementing your ideas."

We can find plenty of others, but my main point is that industrializing a process doesn't make it "procrastinating". There are plenty of jobs that are done by machines but are still practiced by humans for multiple reasons. If we think of coding as a means to create, then we have plenty of examples of good reasons to have both the industrialized process and the 'handmade' one.