I thought this was going to be an article about intelligent use of LLM tools without vibecoding, but it's actually entirely against LLMs altogether. The person who wrote it used a free trial of some tool (most likely not a frontier model) and then gave up forever when the trial ran out.
> I then tried using one of the AI tools to analyze my code in a project and a few other small tasks before it all came to an awkward halt. The system informed me that I had just run out of credits and I would need to provide a credit card to purchase more tokens I wanted to keep going.
> So you must believe me that the idea of paying a service in perpetuity so I could think just seemed so laughably absurd and horrific that I didn’t even bother giving them my card. I closed the laptop. I uninstalled the IDE and went back to using Emacs even.
I wholly support their personal choice. I am tired of articles from people who haven't used LLMs preaching about how it's all vibecoding, though.
Acting like LLM use is (EDIT: I meant is not) a spectrum between doing everything manually or handing control over to the LLM and vibecoding everything is a tired strawman argument.
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.
Yeah there has to be a middle ground. Agentic engineering you could say is that middle ground, you know your code base and inspect it often. Isn't vibe coding treating your code as a black box where your prompts are the only interface? Sometimes I vibe code if the task is simple, if I'm doing serious work then I'm inspecting the code often. I don't think I will ever do "pure" coding ever again unless I'm in an env that is too secure to trust an agent to exist there.
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.
This article comes from a niche of people who read a lot of news articles about LLMs (links scattered throughout) but have also avoided learning about the tools directly.
Like you said, the models available on free trials are usually toys compared to what developers use. Even Opus and GPT-5.5 are available on $20/month plans and you can buy a single month to try it out. The way they write about paying for a tool seeming "absurd and horrific" says it all about the level of actual research that went into their understanding. It's entirely based on news headlines.
So the free trial, designed to convince you that it's worth paying, doesn't well? That isn't the users' fault, that is the companies' fault. If a free trial sucks it's perfectly rational to not pay just in case the paid version doesn't suck.
Certainly if the user gets a bad impression from the free version that's on the provider but if you're writing about it then you shouldn't get to be that ignorant.
Which models did you try? Open weight ones like Qwen and DeepSeek are getting pretty good, you just need the right harness, via OpenCode or Pi. I use Qwen 3.6 27B on my laptop with Unsloth Studio (Unsloth releases a lot of good quantizations and has great support for the latest features, recently released MTP support which can 2x token generation speed with no loss of accuracy).
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.
Ah, the classic "But just you wait, the next version will be better!" fallacy.
It's a fallacy because the reality is often not that…in fact sometimes the reality ends up worse. (See "enshittification", a process whereby technology gets worse over time, not better.)
> 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.
That won't really change anything, and in fact make the problem worse. It would be like "getting high on your own supply". Or just making meth at home so you can do it all the time. There's still a "drug dealer" in between you and the code. And you're going to have to pay $$$$ for hardware good enough to not slow you down. I've tried local models on an nVidia 4060 and it's pretty slow.
If I wanted to spend a lot of time reading the code and figuring out what part actually needs changing, sure... but in this case it's faster to pay for more tokens and get the AI to do it.
For code I wrote, it's typically faster for me to modify it than to get the AI to do it.
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.
Talking about LLM without harness/environment engineering is like talking about children on a playground without safety measurements.
Managing agents is a lot like managing children. They will outsmart you 99% of the time. If your agentic environment isn't built for good sandboxing, you won't succeed.
If you build an environment that can represent mutual cooperation (e.g. helping an agent by doing the tool calls yourself if it was stuck) then it's soooo much better than just trying to rephrase the ruleset of the engagement.
Don't optimize for retries. Optimize for sandboxing and strong agent to agent communication that you can also observe, modify, and summarize.
This is like reading an article "I Don't Drive Cars" that goes on like
- They're too expensive
- My buddy's 1995 Accord breaks down a lot
- Walking is healthier, plus you can stop and smell the roses
- I enjoy caring for my horse
- Sometimes you can get stuck in traffic
Fine if that's the way you want and can afford to live your life. But it is an exotic luxury belief. For those of us who are participating in the economy for real, the preference to not drive cars is not realistic.
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.
I almost always walk to the office. The temperature range is a lot bigger (freezing in winter to uncomfortably hot in summer), and it's like 3 km, which many people wouldn't dream of walking. When my work was farther I used to cycle.
Most people can easily get to work without a car. Just depends on goals and motivations. Car is definitely the laziest way.
[Edit:] That wasn't very helpful of me, let me expand: I live in a city of 400,000 people. It can be crossed on foot in an hour, faster by bicycle. For people who can't or don't want to, the public transport is good. And yet there are traffic jams everywhere.
I used to live in Amsterdam, which is a bigger place. I cycled around 13 km each way, which isn't entirely unusual.
I stand by my point that most people can easily get to work without a car. Most are just too lazy to walk/cycle/use public transport. If you have any data showing otherwise, I'd be delighted to see!
Unless you were making a statement about your city, it's not true that most people could easily get to work without a car.
> I stand by my point that most people can easily get to work without a car.
This probably feels true if you're in a bubble where everyone is like you: Presumably healthy, younger, not having to drop kids off at school(s) and then pick them up with your work day in between, and the weather is walkable.
It's cool that you could bike 13km each way to work. I bike a lot and could do that in my sleep. However I'm not going to start throwing out accusations that everyone is lazy and unmotivated, because I know everyone has different circumstances.
I had a 35 minute commute at 65mph for a while and there was not much traffic. I had no choice. The office was relocated and I had to make the drive until I found another job. Not possible to walk that distance. If I biked it I would have been biking for hours every day with no chance to see the kids before school or pick them up.
Your generalizations are why I said people who make these claims live in a bubble: If you think most people could easily ditch their car for work, you don't understand the diversity of how people live.
> The average one-way commute in the United States is 27 minutes
A bubble right there.
> Unless you were making a statement about your city, it's not true that most people could easily get to work without a car.
It appears you're making a claim about the US, while I was making a general claim, not necessarily specific to the US.
And I'm not claiming everyone can get by without a car, I'm claiming most of the world population could easily commute without a car, if they wanted to.
Many people just don't want to.
> you don't understand the diversity of how people live.
Respectfully, if you think most people can't but drive a car to work, you're the one who doesn't understand diversity. This is further supported by your US-centric worldview.
You are picking at the analogy rather than engaging with the point. In the US, excluding areas with substantial public transportation infrastructure (realistically just a few major cities), car ownership is nearly universal. You can choose to not own a car as a lifestyle choice but you will be making concessions in other areas (the types of jobs and homes you have access to), similar to how refusal to use AI in software engineering at this point will substantially limit your options and ability to participate in the sector.
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…
If you do not live in one of the handful of areas in the US with public transportation infrastructure and also do not own a car you are an extreme outlier. Likewise, if you do not use AI tools to code, outside of some highly niche and specialized areas where perhaps they are still not effective, you are also an extreme outlier and are going to making significant tradeoffs to continue that practice.
If they want to continue that practice that's fine but they will quickly find that it severely limits their options for participating in the software industry.
If you've all been reduced to vibe coding and hoping for the best I'd suggest that you aren't really participating in the software industry either mate.
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.
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.
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.
You're welcome to feel that way but it's a luxury belief. In reality, outside of a few (one?) major city in the US with public transportation infrastructure, you need a car. 92% of people own a car, higher if you exclude the dense urban areas I'm talking about.
People only need cars because people have cars and cars make cities worse for everyone outside of one. If nobody owned cars everyone would get by just fine. It's a race to the bottom.
Sure, but that doesn't change the fact that today people need cars. In an ideal world I'd also love a European or Asian city model but American cities are not like that.
Most American cities have decent enough public transit where it is viable (or even a preferable) alternative to driving. I can think of Seattle, New York, Chicago, San Francisco, etc. Not every city in America is like El Paso or Phoenix. But even in cities like El Paso or Phoenix, the hostility towards public transit is a political choice and an alternative policy is available if politicians want it.
I my self live close to the good American cities and even though my community is rather rural (I literally live across the street from a dairy farm) I still prefer biking to town. And when I go to the city, I rarely bring my car with me, as I prefer the bus over waiting in the ferry line and dealing with parking in the city.
Car ownership is lowest in the lowest income brackets, and public transit ridership is highest among the lower income brackets. I really don‘t understand how you can reach your conclusion that not driving is a luxury. Data would suggest the exact opposite.
EDIT: To clarify on the public transit usage. The data is by-modal. Lower income levels are by far more likely to use road based public transit (such as busses), but high earners are more likely to live near a rail station and use rail based transit: https://cepr.org/voxeu/columns/public-transit-access-and-inc...
This is so good and almost exactly expresses my own thoughts. There's a narrow window where it's capable and fits a need of tedious work (mostly around automating tasks it would take me a bit to remember all the arguments and commands I'd have to chain together to do it). But a lot of it is the stuff I actually WANT to be doing. And solving the hard problems makes me a better developer just as training in the gym makes your body stronger.
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.
Dependency-free, performance, FORTRAN, and it would take me more than ten minutes to find and integrate a highlighter that works across all of my code bases.
I searched for PHP-based Git libraries. All of them either invoked "git" using a system call or offered write abilities to the repo. I wanted a pure PHP solution that did not write to any files or invoke executable files (for security purposes). Maybe I didn't search long enough; at some point it becomes faster to tell the LLM what's wanted than to find a solution that fits.
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've been in the field for 20 years, and I do think the situation is analogous. We might not like it or we might deny it, but the fact is, LLMs do automate the mechanical part of thinking. Some people might not accept that, but that is the reality given my subjective experience and the experience of many others who are using the tool.
Indeed. But my argument is that a lot of those hard problems were, in fact, already solved; some people made a career out of solving the same problems over and over again. The fact that we have a tool to automate the lower tier of problem-solving doesn't mean we are no longer solving problems—it just means we are being asked to solve higher-order problems.
But it also means we solve the same problems as before but faster, meaning less time is given to planning and thinking about what to actually build. This is a real problem where I work. Everyones grasp of what we are building and how it is connected is markedly worse nowadays.
We as a collective must learn the skill to put these new abilities to good use instead of just aiming to accelerate as much as possible.
Indeed, I solve hard problem for a living, but those are mostly design. The actual engineering often decomposes to gluing things together with limited need for new primitives.
There are hard problems at every level of abstraction. TAGE predictor optimization up to handling data-center failover.
I don't really have a challenge for people like the OP, I get it. I too dragged my feet, even mourned the death of a type of work I had grown fond of. Then I got over it and realized I might prefer the romance of riding a horse into town, but I also like that there's semi-trucks delivering fresh produce to my grocery store year round. The leverage available right now is frankly insane. The one thing an "old dev" [as he self-labeled] can be sure of is that the younger generations will not share these hang-ups to the same degree and it's those people who will inherit the burden of maintaining and furthering the digital world.
After 20 years of coding, I do understand the grief and the sense of loss—I felt it deeply myself. But as an engineer, I was also captivated by the capabilities of the new systems. Watching these systems mechanize the thinking I had been doing for years, struggle in areas I used to struggle with, and even outperform me in some areas is nothing short of a magical experience, leaving all the anxiety about the job aside. Personally, I chose to focus on that magic, to see how far we can push these tools and discover what their limits are.
What is also interesting is that what our brains perceive to be hard is mainly because we didn't evolve to deal with these kinds of problems. But as it turns out, automating logical problems is much easier than folding clothes.
In this analogy most people are already using an excavator, however some people are using an expensive driverless excavator which sometimes digs the wrong hole, and your boss is wondering why they are paying you to prompt the excavator when they know just as well as you how to prompt the machine to dig big holes.
I'm getting tempted to because I have so much work to do for my "startup" and after my 8hr day job I'm burnt. It's not even that I don't know what to do it's a lot of work... swift iPhone app, the api, the web app and gcp. get that feeling of being overwhelmed and also end of day brain just feels like shit, thinking I'll drink more caffeine after gym eg. 6:30 PM will see if I can sleep.
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
> virtually everyone building a startup uses these tools to automate a huge chunk of the work. you have no real chance otherwise.
Huh? Do you mean people "building a startup" without any experience at all? The list of tasks in the comment you're replying to are well within the skillset of any software engineer that has that old job description classic "3 to 5 years experience".
Not to be rude, but if the code is the hard part for anyone, they never had a chance at the rest of it either.
Where did I say that you didn't need to already have the skillset in order to build something with it? It's just a force multiplier. And learning to use these tools effectively is a skill of it's own.
I'll never understand why folks on here look at this tech in such black and white. Of course it has no concept of logic or understanding. But if you do, you can bring out whatever is in your head out into code at 10x the speed.
When building startups you need to move quickly because usually you have quite a bit of competition. If you think you can build a startup by being slow and thorough and take years to produce an MVP go for it :) i don't think you will succeed
I taught myself linux/coding/servers because there was a long period of time where all I had was a chromebook for school, but I still wanted to explore this thing called "pure data" that i'd heard about, and thought I could make art with it. I distinctly remember being continually amazed at how you could get so many things for free, if you know where to look. And yeah.. once I found emacs it was all over. To this day I am definitely going to always go "the hard way" where I can instead of pay any SaaS even $5 a month. In my head its like: "I am a mechanic, or at least, I can get by as one, why would I take my car to the shop and pay money??"
I know its not rational, but it would be pretty darn terrible in my brain to pay for an IDE. Even more unimaginable to me to pay $100 a month for something...
All to say, "cheapskate"-ness from TFA really resonated with me, I don't see the sentiment around a lot.
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.
Likewise. I avoided programming for years when I was young because the only way to get into it was to spend money on development suites like Borlund or Visual Studio. As a poor kid growing up in rural Michigan, that wasn't gonna happen.
The internet changed all that, because every net connected platform was built on platforms that cost nothing to learn or work in. I wrote my first HTML in freaking MS-DOS Edit. I learned JavaScript by copying code from View Source into an unregistered copy of BBEdit.
Do I have dev software I pay for? Of course! But not many (even fewer today than before everything switched to subscription pricing), and every one can be replaced with something that costs nothing.
The top thread on this post is people discrediting the author because they only used cheaper/free models, as if we should just accept and embrace the commoditization and enshitification of software development, even while it actively deskills us and creates codebases that cannot be maintained without the services that built them.
> However, the process was far more important than the product (again!). Not every whimsy needs to become a reality.
I mean, I get it, there's different kinds of people out there with different motivations, goals, spare time, etc.
But there's also a process of product design that I think the author is overlooking.
Lately I've been working and iterating on a number of DSLs, projects that might be a total waste of my time because they end up being poorly conceived or not very useful compared to a general purpose language!
I'm also working on a video game that is basically Magic: The Gathering meets StarCraft with Civilization style hex-grid conflict. It could be a total bust and entirely no fun to play (it's hard to tell if it's fun by itself because I enjoy working on the game while testing out the play patterns). It would suck to spend a couple of years on this if it's no good.
I very much enjoy the process of trying to figure out the best syntax and semantics for a new DSL or the process of iterating on gameplay elements when working on a game. The destination is also less important. I don't really expect anyone to use my DSLs or play my video games. I'm ultimately doing it for my own enjoyment.
Saying this, I am interested in the overall architecture and I've definitely learned from my mistakes, especially with creating DSLs. Like, having a TypeScript language server with a Rust runtime has some issues. It's kind of better to build the language server into the runtime so you're not maintaining multiple parsers, and depending on the language features, an additional pseudo-runtime in the language server.
It's a really interesting PoV, and one I'm in polar opposition to.
Context engineering is allowing me to do things I've always wanted to do but don't have the time/energy. I'm writing in C++, assembly, Rust, Go. I'm fucking with boot loaders and all kinds of things.
It's brought me a far greater understanding of how cryptography, GPUs, CUDA, Apple Metal - all topics I have a vague interest in but have no time to work on.
The current raft of LLM models are genius children. It's like that 15 year old at college. But I have 30 years of experience and a genius child is pure power in my hands.
And it's a genius child that never gets tired. For a few hundred bucks a month I can have 3 geniuses working on my ideas through the night. Last night they wrote 20 different research theses on a topic and benchmarked them all. Then combined them into a best of breed algorithm better than anything that has been done before. It's an amazing world we live in.
I don't write this to throw mud at OP - they are entitled to their opinion. Merely to point out the contrast.
The parent is joking, they know that, the joke is that a lot of domains "abuse" the TLD, as they're generally meant for countries, e.g. many Rust related sites use .rs which is Serbia.
To experienced devs. Why are you enjoying vibecoding? It is soulless and the job is really becoming unbearable having to discuss with an agent that alternates between “good at” and totally consensual and low iq.it feels miserable to have a few turns then seeing the tool
Became so bad and so low iq that you stuck in doing things garder than if you did it by yourself
I get the conversational aspect and value of it I just dont get people saying “I dont code anymore I manage agents” - besides obviously people selling AI
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.
nothing is really fun in trying to hack around a model to make him do things you want knowing that its barely patching it until the next disease shows up. its painful.also it is probably a temporary step before everything close up behind closed software and closed API (like anthropic tries to) and the harness wont be yours it will be on a remote cloud server. then you will just spend the time review llm generated code. also the scale and ambition of a LLM generated piece of code can be daunting. the most basic pattern since LLM can code well is overdoing. docs are longer, blogs are longer, ppt are longer, PR are longer while quality naturally drop because more people can produce this kind of content now
but it's not fun for everyone. reviewing code for people vs agents is a massive difference for me. with people i can teach them. with LLMs i can't. it makes me feel helpless. just like i feel helpless using broken non-free apps. i can tolerate the same bugs in FOSS application, because i potentially can fix them even if i don't actually do it. i don't feel helpless, i feel like i have a choice. with LLMs i don't get that choice.
most of the other things you mention feel tedious to me. i like diving into the code, understanding how to solve a problem, figuring out how to make the code structure look elegant and readable. find and comment on a clever short-cut, even if it means that i may not be clever enough to debug it later.
i don't get any of that with LLM generated code. i'd spend more time to clean up and fix the LLM code than i would writing it from scratch. to use LLM code efficiently, i'd have to give up all that. but i don't want to do that.
using LLM to code feels like gambling. every time i put in a prompt, its like rolling the dice. am i going to get a useful solution this time? and then reroll until i get a useful result rather than building up the application one step at a time.
Yeah I can kind of see that and if you don't like them you don't like them. Not all tools are for all people.
I personally draw the line at plugins that try to set up entire workflows and take the human completely out of the loop. Those are next to useless imo for an engineer who knows what they are doing and are exactly how you end up with crappy code/products.
But to give my thoughts to your points I guess I just don't really care that I can't teach LLMs? It doesn't bother me because I do also still teach people, it's not one or the other.
On what you like about coding. I like that too, I still do it where I want to or where it is needed.
I agree with you on what parts are enjoyable but I guess I don't feel that I'm giving them up? I get to pick the problems I work on that way now. The only disagreement there is around 'clever' shortcuts. I get pleasure out of making things debuggable and traceable for humans.
I wish my odds at gambling were as high as they are with LLM generated code lol.
I do run into the whole 'this session was a waste, need to restart', but like once in a blue moon? Not nearly enough to turn me off from using LLMs daily.
On the teaching point again, my learnings around coding standards, architecture -> problem mapping, how to debug, are applied at the system prompt level and around a few key skill files, so when I say "implement ..." or "I'm seeing this behavior, where in the codebase is the most likely root cause? Why?" It does so close to how I would've done it.
I cannot speak for people who are using these things raw in the harnesses provided by the companies, or god forbid in the browser but you can definitely increase the odds of a good roll enough to be productive by changing the environment around the llm and to me that is the opposite of feeling helpless when it comes to LLMs.
I feel enabled to get more done, at my standards, on my time.
"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.
I thought this was going to be an article about intelligent use of LLM tools without vibecoding, but it's actually entirely against LLMs altogether. The person who wrote it used a free trial of some tool (most likely not a frontier model) and then gave up forever when the trial ran out.
> I then tried using one of the AI tools to analyze my code in a project and a few other small tasks before it all came to an awkward halt. The system informed me that I had just run out of credits and I would need to provide a credit card to purchase more tokens I wanted to keep going.
> So you must believe me that the idea of paying a service in perpetuity so I could think just seemed so laughably absurd and horrific that I didn’t even bother giving them my card. I closed the laptop. I uninstalled the IDE and went back to using Emacs even.
I wholly support their personal choice. I am tired of articles from people who haven't used LLMs preaching about how it's all vibecoding, though.
Acting like LLM use is (EDIT: I meant is not) a spectrum between doing everything manually or handing control over to the LLM and vibecoding everything is a tired strawman argument.
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.
Yeah there has to be a middle ground. Agentic engineering you could say is that middle ground, you know your code base and inspect it often. Isn't vibe coding treating your code as a black box where your prompts are the only interface? Sometimes I vibe code if the task is simple, if I'm doing serious work then I'm inspecting the code often. I don't think I will ever do "pure" coding ever again unless I'm in an env that is too secure to trust an agent to exist there.
If you are vibecoding an app without talking to anyone, those are problems.
This is still missing the point that LLM use isn't a binary choice between YOLO vibecoding or complete abstinence from LLM use.
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.
This article comes from a niche of people who read a lot of news articles about LLMs (links scattered throughout) but have also avoided learning about the tools directly.
Like you said, the models available on free trials are usually toys compared to what developers use. Even Opus and GPT-5.5 are available on $20/month plans and you can buy a single month to try it out. The way they write about paying for a tool seeming "absurd and horrific" says it all about the level of actual research that went into their understanding. It's entirely based on news headlines.
So the free trial, designed to convince you that it's worth paying, doesn't well? That isn't the users' fault, that is the companies' fault. If a free trial sucks it's perfectly rational to not pay just in case the paid version doesn't suck.
Not free trials, free versions.
Certainly if the user gets a bad impression from the free version that's on the provider but if you're writing about it then you shouldn't get to be that ignorant.
Which models did you try? Open weight ones like Qwen and DeepSeek are getting pretty good, you just need the right harness, via OpenCode or Pi. I use Qwen 3.6 27B on my laptop with Unsloth Studio (Unsloth releases a lot of good quantizations and has great support for the latest features, recently released MTP support which can 2x token generation speed with no loss of accuracy).
Get your company to pay for it (points to head)
Oh they do. And I could get them to pay even more but with the changes to copilot licensing, I'm not sure we will continue with it.
Is claude code any better for the value
Codex is the best value for money now in my usage.
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.
This is healthy but what about the economics - what about when the prices rise? At what point do you become more thoughtful about spend?
Open weight models are getting good.
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.
Ah, the classic "But just you wait, the next version will be better!" fallacy.
It's a fallacy because the reality is often not that…in fact sometimes the reality ends up worse. (See "enshittification", a process whereby technology gets worse over time, not better.)
> 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 think they meant "binary" rather than "spectrum".
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.
The future is local LLMs. So still methamphetamines but open source, free and an unlimited supply.
That won't really change anything, and in fact make the problem worse. It would be like "getting high on your own supply". Or just making meth at home so you can do it all the time. There's still a "drug dealer" in between you and the code. And you're going to have to pay $$$$ for hardware good enough to not slow you down. I've tried local models on an nVidia 4060 and it's pretty slow.
Right my example was meant to illustrate this cost benefit issue.
> I do it because I didn't write the codebase - the drug dealer did.
.... are you saying that you can't just open up a file "written" by spicy autocomplete and add/change parts of it?
If I wanted to spend a lot of time reading the code and figuring out what part actually needs changing, sure... but in this case it's faster to pay for more tokens and get the AI to do it.
For code I wrote, it's typically faster for me to modify it than to get the AI to do it.
So what you're saying is, you don't really know what spicy autocomplete is generating because you aren't reading it.
Great stuff champ. Really dispelling the idea that vibe coders have no idea what slop is being churned out. Top marks.
[dead]
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.
Talking about LLM without harness/environment engineering is like talking about children on a playground without safety measurements.
Managing agents is a lot like managing children. They will outsmart you 99% of the time. If your agentic environment isn't built for good sandboxing, you won't succeed.
If you build an environment that can represent mutual cooperation (e.g. helping an agent by doing the tool calls yourself if it was stuck) then it's soooo much better than just trying to rephrase the ruleset of the engagement.
Don't optimize for retries. Optimize for sandboxing and strong agent to agent communication that you can also observe, modify, and summarize.
Imagine being disappointed that an article is NOT clickbait :|
This is like reading an article "I Don't Drive Cars" that goes on like
- They're too expensive
- My buddy's 1995 Accord breaks down a lot
- Walking is healthier, plus you can stop and smell the roses
- I enjoy caring for my horse
- Sometimes you can get stuck in traffic
Fine if that's the way you want and can afford to live your life. But it is an exotic luxury belief. For those of us who are participating in the economy for real, the preference to not drive cars is not realistic.
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.
> by people who live within walking distance or public transport distance of their office
So, the vast majority of people living in cities?
> the temperature is always between 50 and 70 degrees F
More like between -15°C and 35°C (though the upper range does depend on humidity).
What a weird analogy.
I almost always walk to the office. The temperature range is a lot bigger (freezing in winter to uncomfortably hot in summer), and it's like 3 km, which many people wouldn't dream of walking. When my work was farther I used to cycle.
Most people can easily get to work without a car. Just depends on goals and motivations. Car is definitely the laziest way.
> Most people can easily get to work without a car.
This is statistically very false.
It does a good job of proving my point that people within this bubble have a hard time understanding what the rest of the world is like.
You're the one in a bubble.
[Edit:] That wasn't very helpful of me, let me expand: I live in a city of 400,000 people. It can be crossed on foot in an hour, faster by bicycle. For people who can't or don't want to, the public transport is good. And yet there are traffic jams everywhere.
I used to live in Amsterdam, which is a bigger place. I cycled around 13 km each way, which isn't entirely unusual.
I stand by my point that most people can easily get to work without a car. Most are just too lazy to walk/cycle/use public transport. If you have any data showing otherwise, I'd be delighted to see!
> You're the one in a bubble.
The average one-way commute in the United States is 27 minutes. Source https://www.census.gov/newsroom/press-releases/2021/one-way-...
Unless you were making a statement about your city, it's not true that most people could easily get to work without a car.
> I stand by my point that most people can easily get to work without a car.
This probably feels true if you're in a bubble where everyone is like you: Presumably healthy, younger, not having to drop kids off at school(s) and then pick them up with your work day in between, and the weather is walkable.
It's cool that you could bike 13km each way to work. I bike a lot and could do that in my sleep. However I'm not going to start throwing out accusations that everyone is lazy and unmotivated, because I know everyone has different circumstances.
I had a 35 minute commute at 65mph for a while and there was not much traffic. I had no choice. The office was relocated and I had to make the drive until I found another job. Not possible to walk that distance. If I biked it I would have been biking for hours every day with no chance to see the kids before school or pick them up.
Your generalizations are why I said people who make these claims live in a bubble: If you think most people could easily ditch their car for work, you don't understand the diversity of how people live.
Usonians...
> The average one-way commute in the United States is 27 minutes
A bubble right there.
> Unless you were making a statement about your city, it's not true that most people could easily get to work without a car.
It appears you're making a claim about the US, while I was making a general claim, not necessarily specific to the US.
And I'm not claiming everyone can get by without a car, I'm claiming most of the world population could easily commute without a car, if they wanted to.
Many people just don't want to.
> you don't understand the diversity of how people live.
Respectfully, if you think most people can't but drive a car to work, you're the one who doesn't understand diversity. This is further supported by your US-centric worldview.
You are picking at the analogy rather than engaging with the point. In the US, excluding areas with substantial public transportation infrastructure (realistically just a few major cities), car ownership is nearly universal. You can choose to not own a car as a lifestyle choice but you will be making concessions in other areas (the types of jobs and homes you have access to), similar to how refusal to use AI in software engineering at this point will substantially limit your options and ability to participate in the sector.
I live in Southwestern Ontario and I think cars are crazy.
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…
Checked all five except "caring for my horse" is "tinkering with my bicycle".
Yes everyone that lives in a major city that doesn't use a car is... not participating in the real economy.
If you do not live in one of the handful of areas in the US with public transportation infrastructure and also do not own a car you are an extreme outlier. Likewise, if you do not use AI tools to code, outside of some highly niche and specialized areas where perhaps they are still not effective, you are also an extreme outlier and are going to making significant tradeoffs to continue that practice.
There are many trainfuls of people who still write code using traditional syntax-based IDE completion.
If they want to continue that practice that's fine but they will quickly find that it severely limits their options for participating in the software industry.
If you've all been reduced to vibe coding and hoping for the best I'd suggest that you aren't really participating in the software industry either mate.
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.
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.
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.
You're welcome to feel that way but it's a luxury belief. In reality, outside of a few (one?) major city in the US with public transportation infrastructure, you need a car. 92% of people own a car, higher if you exclude the dense urban areas I'm talking about.
People only need cars because people have cars and cars make cities worse for everyone outside of one. If nobody owned cars everyone would get by just fine. It's a race to the bottom.
Sure, but that doesn't change the fact that today people need cars. In an ideal world I'd also love a European or Asian city model but American cities are not like that.
Most American cities have decent enough public transit where it is viable (or even a preferable) alternative to driving. I can think of Seattle, New York, Chicago, San Francisco, etc. Not every city in America is like El Paso or Phoenix. But even in cities like El Paso or Phoenix, the hostility towards public transit is a political choice and an alternative policy is available if politicians want it.
I my self live close to the good American cities and even though my community is rather rural (I literally live across the street from a dairy farm) I still prefer biking to town. And when I go to the city, I rarely bring my car with me, as I prefer the bus over waiting in the ferry line and dealing with parking in the city.
Car ownership is lowest in the lowest income brackets, and public transit ridership is highest among the lower income brackets. I really don‘t understand how you can reach your conclusion that not driving is a luxury. Data would suggest the exact opposite.
EDIT: To clarify on the public transit usage. The data is by-modal. Lower income levels are by far more likely to use road based public transit (such as busses), but high earners are more likely to live near a rail station and use rail based transit: https://cepr.org/voxeu/columns/public-transit-access-and-inc...
'For those of us americans who are participating in the economy for real, the preference to not drive cars is not realistic.'
Fixed that for you.
People write "i dont" when they mean "i cant"
This is so good and almost exactly expresses my own thoughts. There's a narrow window where it's capable and fits a need of tedious work (mostly around automating tasks it would take me a bit to remember all the arguments and commands I'd have to chain together to do it). But a lot of it is the stuff I actually WANT to be doing. And solving the hard problems makes me a better developer just as training in the gym makes your body stronger.
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.
Why reinvent the wheel? Syntax highlighting, git. I'm pretty sure there are PHP libraries to do that.
Your syntax highlighting is very basic as well. Just ask LLMs to provide tests where it would fail to render correctly.
The first thing that comes to mind after looking at it: print("# not a comment")
> Why reinvent the wheel?
Dependency-free, performance, FORTRAN, and it would take me more than ten minutes to find and integrate a highlighter that works across all of my code bases.
I searched for PHP-based Git libraries. All of them either invoked "git" using a system call or offered write abilities to the repo. I wanted a pure PHP solution that did not write to any files or invoke executable files (for security purposes). Maybe I didn't search long enough; at some point it becomes faster to tell the LLM what's wanted than to find a solution that fits.
> print("# not a comment")
Works correctly?
https://i.ibb.co/chgVkTz4/not-a-comment.png
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.
These comparison don’t capture reality at all… wish people would stop doing them.
Which part of reality does it not capture?
I've been in the field for 20 years, and I do think the situation is analogous. We might not like it or we might deny it, but the fact is, LLMs do automate the mechanical part of thinking. Some people might not accept that, but that is the reality given my subjective experience and the experience of many others who are using the tool.
Some developers solve hard problems and some don't. It depends entirely on your specific work.
Indeed. But my argument is that a lot of those hard problems were, in fact, already solved; some people made a career out of solving the same problems over and over again. The fact that we have a tool to automate the lower tier of problem-solving doesn't mean we are no longer solving problems—it just means we are being asked to solve higher-order problems.
But it also means we solve the same problems as before but faster, meaning less time is given to planning and thinking about what to actually build. This is a real problem where I work. Everyones grasp of what we are building and how it is connected is markedly worse nowadays.
We as a collective must learn the skill to put these new abilities to good use instead of just aiming to accelerate as much as possible.
Indeed, I solve hard problem for a living, but those are mostly design. The actual engineering often decomposes to gluing things together with limited need for new primitives.
There are hard problems at every level of abstraction. TAGE predictor optimization up to handling data-center failover.
I don't really have a challenge for people like the OP, I get it. I too dragged my feet, even mourned the death of a type of work I had grown fond of. Then I got over it and realized I might prefer the romance of riding a horse into town, but I also like that there's semi-trucks delivering fresh produce to my grocery store year round. The leverage available right now is frankly insane. The one thing an "old dev" [as he self-labeled] can be sure of is that the younger generations will not share these hang-ups to the same degree and it's those people who will inherit the burden of maintaining and furthering the digital world.
I agree, and this matches my experience as well.
After 20 years of coding, I do understand the grief and the sense of loss—I felt it deeply myself. But as an engineer, I was also captivated by the capabilities of the new systems. Watching these systems mechanize the thinking I had been doing for years, struggle in areas I used to struggle with, and even outperform me in some areas is nothing short of a magical experience, leaving all the anxiety about the job aside. Personally, I chose to focus on that magic, to see how far we can push these tools and discover what their limits are.
What is also interesting is that what our brains perceive to be hard is mainly because we didn't evolve to deal with these kinds of problems. But as it turns out, automating logical problems is much easier than folding clothes.
I'm not paying someone to dig by hand if a machine makes the job quicker.
In this analogy most people are already using an excavator, however some people are using an expensive driverless excavator which sometimes digs the wrong hole, and your boss is wondering why they are paying you to prompt the excavator when they know just as well as you how to prompt the machine to dig big holes.
There comes a time in every not-so-young developer's life where he or she becomes anti-anti-AI.
I'm getting tempted to because I have so much work to do for my "startup" and after my 8hr day job I'm burnt. It's not even that I don't know what to do it's a lot of work... swift iPhone app, the api, the web app and gcp. get that feeling of being overwhelmed and also end of day brain just feels like shit, thinking I'll drink more caffeine after gym eg. 6:30 PM will see if I can sleep.
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)
> virtually everyone building a startup uses these tools to automate a huge chunk of the work. you have no real chance otherwise.
Huh? Do you mean people "building a startup" without any experience at all? The list of tasks in the comment you're replying to are well within the skillset of any software engineer that has that old job description classic "3 to 5 years experience".
Not to be rude, but if the code is the hard part for anyone, they never had a chance at the rest of it either.
Where did I say that you didn't need to already have the skillset in order to build something with it? It's just a force multiplier. And learning to use these tools effectively is a skill of it's own.
I'll never understand why folks on here look at this tech in such black and white. Of course it has no concept of logic or understanding. But if you do, you can bring out whatever is in your head out into code at 10x the speed.
When building startups you need to move quickly because usually you have quite a bit of competition. If you think you can build a startup by being slow and thorough and take years to produce an MVP go for it :) i don't think you will succeed
least suspicious account lol
Not sure what you mean by this, I've had this account for years, just never commented.
I taught myself linux/coding/servers because there was a long period of time where all I had was a chromebook for school, but I still wanted to explore this thing called "pure data" that i'd heard about, and thought I could make art with it. I distinctly remember being continually amazed at how you could get so many things for free, if you know where to look. And yeah.. once I found emacs it was all over. To this day I am definitely going to always go "the hard way" where I can instead of pay any SaaS even $5 a month. In my head its like: "I am a mechanic, or at least, I can get by as one, why would I take my car to the shop and pay money??"
I know its not rational, but it would be pretty darn terrible in my brain to pay for an IDE. Even more unimaginable to me to pay $100 a month for something...
All to say, "cheapskate"-ness from TFA really resonated with me, I don't see the sentiment around a lot.
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.
Likewise. I avoided programming for years when I was young because the only way to get into it was to spend money on development suites like Borlund or Visual Studio. As a poor kid growing up in rural Michigan, that wasn't gonna happen.
The internet changed all that, because every net connected platform was built on platforms that cost nothing to learn or work in. I wrote my first HTML in freaking MS-DOS Edit. I learned JavaScript by copying code from View Source into an unregistered copy of BBEdit.
Do I have dev software I pay for? Of course! But not many (even fewer today than before everything switched to subscription pricing), and every one can be replaced with something that costs nothing.
The top thread on this post is people discrediting the author because they only used cheaper/free models, as if we should just accept and embrace the commoditization and enshitification of software development, even while it actively deskills us and creates codebases that cannot be maintained without the services that built them.
I don't agree with the overall conclusion of avoiding AI tooling but this was really wonderfully written
>but this was really wonderfully written
That's because AI wrote it to deter other AI from taking it's job
> However, the process was far more important than the product (again!). Not every whimsy needs to become a reality.
I mean, I get it, there's different kinds of people out there with different motivations, goals, spare time, etc.
But there's also a process of product design that I think the author is overlooking.
Lately I've been working and iterating on a number of DSLs, projects that might be a total waste of my time because they end up being poorly conceived or not very useful compared to a general purpose language!
I'm also working on a video game that is basically Magic: The Gathering meets StarCraft with Civilization style hex-grid conflict. It could be a total bust and entirely no fun to play (it's hard to tell if it's fun by itself because I enjoy working on the game while testing out the play patterns). It would suck to spend a couple of years on this if it's no good.
I very much enjoy the process of trying to figure out the best syntax and semantics for a new DSL or the process of iterating on gameplay elements when working on a game. The destination is also less important. I don't really expect anyone to use my DSLs or play my video games. I'm ultimately doing it for my own enjoyment.
Saying this, I am interested in the overall architecture and I've definitely learned from my mistakes, especially with creating DSLs. Like, having a TypeScript language server with a Rust runtime has some issues. It's kind of better to build the language server into the runtime so you're not maintaining multiple parsers, and depending on the language features, an additional pseudo-runtime in the language server.
So brave to post this in a place filled with weird AI apologists.
It's a really interesting PoV, and one I'm in polar opposition to.
Context engineering is allowing me to do things I've always wanted to do but don't have the time/energy. I'm writing in C++, assembly, Rust, Go. I'm fucking with boot loaders and all kinds of things.
It's brought me a far greater understanding of how cryptography, GPUs, CUDA, Apple Metal - all topics I have a vague interest in but have no time to work on.
The current raft of LLM models are genius children. It's like that 15 year old at college. But I have 30 years of experience and a genius child is pure power in my hands.
And it's a genius child that never gets tired. For a few hundred bucks a month I can have 3 geniuses working on my ideas through the night. Last night they wrote 20 different research theses on a topic and benchmarked them all. Then combined them into a best of breed algorithm better than anything that has been done before. It's an amazing world we live in.
I don't write this to throw mud at OP - they are entitled to their opinion. Merely to point out the contrast.
I'm vegan. I only watch PBS and the Criterion Channel. I'm atheist. Now it's "I don't vibe code."
It does seem like a sort of virtue signaling these days right?
Wait what's wrong with the Criterion Channel??
This is what I call trad coding.
> As someone who grew up in a city on the East Coast
Since this blogsite has a .is domain I must assume they mean Egilsstaðir a lovely city with a population of around 2500 people.
I think that's just to have the domain complete their name.
The parent is joking, they know that, the joke is that a lot of domains "abuse" the TLD, as they're generally meant for countries, e.g. many Rust related sites use .rs which is Serbia.
To experienced devs. Why are you enjoying vibecoding? It is soulless and the job is really becoming unbearable having to discuss with an agent that alternates between “good at” and totally consensual and low iq.it feels miserable to have a few turns then seeing the tool Became so bad and so low iq that you stuck in doing things garder than if you did it by yourself
I get the conversational aspect and value of it I just dont get people saying “I dont code anymore I manage agents” - besides obviously people selling AI
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.
nothing is really fun in trying to hack around a model to make him do things you want knowing that its barely patching it until the next disease shows up. its painful.also it is probably a temporary step before everything close up behind closed software and closed API (like anthropic tries to) and the harness wont be yours it will be on a remote cloud server. then you will just spend the time review llm generated code. also the scale and ambition of a LLM generated piece of code can be daunting. the most basic pattern since LLM can code well is overdoing. docs are longer, blogs are longer, ppt are longer, PR are longer while quality naturally drop because more people can produce this kind of content now
- building a reliable enough system out of unreliable parts is pretty fun for me. It's a different kind of puzzle.
- pi-agent or code your own harness, it is not hard.
- codex for now allows you to use it in any harness but if they ever don't open models are catching up
- Reject low quality PRs the same as before. If management doesn't enable to you do that then that's a different problem.
but it's not fun for everyone. reviewing code for people vs agents is a massive difference for me. with people i can teach them. with LLMs i can't. it makes me feel helpless. just like i feel helpless using broken non-free apps. i can tolerate the same bugs in FOSS application, because i potentially can fix them even if i don't actually do it. i don't feel helpless, i feel like i have a choice. with LLMs i don't get that choice.
most of the other things you mention feel tedious to me. i like diving into the code, understanding how to solve a problem, figuring out how to make the code structure look elegant and readable. find and comment on a clever short-cut, even if it means that i may not be clever enough to debug it later.
i don't get any of that with LLM generated code. i'd spend more time to clean up and fix the LLM code than i would writing it from scratch. to use LLM code efficiently, i'd have to give up all that. but i don't want to do that.
using LLM to code feels like gambling. every time i put in a prompt, its like rolling the dice. am i going to get a useful solution this time? and then reroll until i get a useful result rather than building up the application one step at a time.
Yeah I can kind of see that and if you don't like them you don't like them. Not all tools are for all people.
I personally draw the line at plugins that try to set up entire workflows and take the human completely out of the loop. Those are next to useless imo for an engineer who knows what they are doing and are exactly how you end up with crappy code/products.
But to give my thoughts to your points I guess I just don't really care that I can't teach LLMs? It doesn't bother me because I do also still teach people, it's not one or the other.
On what you like about coding. I like that too, I still do it where I want to or where it is needed.
I agree with you on what parts are enjoyable but I guess I don't feel that I'm giving them up? I get to pick the problems I work on that way now. The only disagreement there is around 'clever' shortcuts. I get pleasure out of making things debuggable and traceable for humans.
I wish my odds at gambling were as high as they are with LLM generated code lol.
I do run into the whole 'this session was a waste, need to restart', but like once in a blue moon? Not nearly enough to turn me off from using LLMs daily.
On the teaching point again, my learnings around coding standards, architecture -> problem mapping, how to debug, are applied at the system prompt level and around a few key skill files, so when I say "implement ..." or "I'm seeing this behavior, where in the codebase is the most likely root cause? Why?" It does so close to how I would've done it.
I cannot speak for people who are using these things raw in the harnesses provided by the companies, or god forbid in the browser but you can definitely increase the odds of a good roll enough to be productive by changing the environment around the llm and to me that is the opposite of feeling helpless when it comes to LLMs.
I feel enabled to get more done, at my standards, on my time.
programming is just procrastination that gets in the way of implementing your ideas.
"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.
Where does this evolution really lead?
"Thinking is just procrastination that gets in the way of your opinions"? ;-)
> Where does this evolution really lead?
probably that nothing really matters, so I guess do whatever makes you happy. If programming makes you happy then you should do it.
I find programming Advent of Code fun so I do it, but I don't find writing yet another web interface fun, so I have Claude do it.