Live data from Hacker News

After two years of vibecoding, I'm back to writing by hand

atmoio.substack.com

611–620 of 652 posts

Re: After two years of vibecoding, I'm back to writing by hand

#611
post #270

Earlier quoted context omitted.

I've had success across quite a few languages, more than just python and js. I find it insanely hard to believe you can write code faster than the LLM, even if the LLM has to iterate a couple times. But I'm thankful for you devs that are giving me job security.

And that tells me you're on the dev end of the devops spectrum while I'm fully on the ops side. I write very small pieces of software (the time it takes to type them is never the bottleneck) that integrates in-house software with whatever services they have to actually interact with, which every LLM I've used does wrong the first fifteen or so times it tries (for some reason rtkit in particular absolutely flummoxes e…

I pretty well span the devops spectrum from building/maintaining services to running/integrating/monitoring them in prod. LLMs are definitely better at the dev side than the ops side, no doubt about that. And when it comes to firewalld and many other sysadmin tools I agree it can often be faster to just hand type than to have the LLM do it. Even just writing Dockerfiles it's often faster to do it by hand than the LLM because the LLM will screw it up 6 to 12 times before getting it right, and usually "getting it right" is because I told it something like, "dude you can't mount, you need to copy." It's especially insanely stupid when it comes to rootless podman.

But that said, there are still plenty of ops-y situations where AI can be very helpful. Even just "here's a 125k lines of prod logs. Can you tell me what is going wrong?" has saved me lots of time in the past, especially for apps that I'm not super familiar with. It's (sometimes) pretty good at finding the needle in the haystack. The most common workflow I have now is to point an agent at it and while it's griding on it I'll do some hand greps and things. I've gotten to the bottom of some really tricky things much faster because of it. Sometimes it points me in the wrong direction (for example, one time it noticed that we were being rate-limited by the Cloudflare API, and instead of adding a single flag to the library calls it wrote it's own very convoluted queue system. But it was still helpful because at least it pinpointed the problem).

The other "small pieces of software" I find it very helpful for are bash functions or small scripts to do things. The handwritten solution is usually quick, but rarely as resilient/informative as it could be because writing a bunch of error handling can 5x or 10x the handwritten time. I will usually write the quick version, then point AI at it and have it add arg passing/handling, error handling, and usage info/documentation. It's been great for that.

Re: After two years of vibecoding, I'm back to writing by hand

#612

Earlier quoted context omitted.

They are more effective then on the ground in your face evidence largely because people who are so against AI are blind to it. I hold a result of AI in front of your face and they still proclaim it’s garbage and everything else is fraudulent. Let’s be clear. You’re arguing against a fantasy. Nobody even proponents of AI claims that AI is as good as humans. Nowhere near it. But they are good enough for pair programmin…

If you want to be any good at all in this industry, you have to develop enough technical skills to evaluate claims for yourself. You have to. It's essential. Because the dirty secret is a lot of successful people aren't actually smart or talented, they just got lucky. Or they aren't successful at all, they're just good at pretending they are, either through taking credit for other people's work or flat out lying. I'v…

Let me just list all of these people:

Steve Yegge (Veteran engineer, formerly Google and Amazon): A leading technical voice who describes vibe coding as acting as an orchestrator. He maintains that engineers who do not master "agentic engineering" and AI-driven workflows will be left behind as the industry moves toward "hyperproductivity".

Patrick Debois (Founder of DevOps): Often called the "godfather of DevOps," Debois now advocates for the "AI native developer". He views vibe coding as a high-level abstraction where the engineer's role shifts from a "producer" of lines of code to a "supervisor" of complex automated systems.

Simon Willison (Co-creator of Django): Recognized for his highly technical workflows that use AI to handle mechanical implementation while he focuses on rigorous documentation, tool coverage, and validation—a process often cited as the professional gold standard for vibe coding.

Stephen Blum (Founder/CTO of PubNub): A technical leader who has integrated generative coding into production-scale architecture. He characterizes the 2026 developer's role as directing agents for everything from database migrations to security audits rather than manually performing these tasks.

Gene Kim (Renowned DevOps researcher and author): Co-author of The Phoenix Project, Kim has publicly championed vibe coding as one of the most enjoyable technical experiences of his career, citing how it allows him to build sophisticated prototypes in minutes rather than days.

Patrick Debois (Founder of DevOps): Often referred to as the "godfather of DevOps," Debois advocates for "AI-native engineering". He views vibe coding as a mature abstraction layer where elite engineers focus on "system orchestration" rather than producing individual lines of code.

Geoffrey Huntley (Founder of the "Vibe Coding Academy"): A highly technical engineer known for pushing the boundaries of AI-driven development. He is a primary source for experimental techniques that use agents for everything from infrastructure to core logic.

Boris Cherny (Author of Programming TypeScript): An authority on type systems and engineering rigor, Cherny now provides deep technical guidance on how to integrate high-level intent with reliable, production-ready source code using tools like Claude Code.

Stephen Webb (UK CTO at Capgemini): A key industry figure declaring 2026 as the year "AI-native engineering goes mainstream". He supports vibe coding as a legitimate method for rewriting legacy systems and refactoring entire modules autonomously.

Linus Torvalds (Creator of Linux and Git): In a significant endorsement for the paradigm, Torvalds reported in early 2026 that he used Google Antigravity to vibe code a Python visualizer for his AudioNoise project. He noted in the project's documentation that the tool was "basically written by vibe-coding".

Theo Browne (Founder of Ping.gg, T3.gg): Known for his deep technical influence on the web development community, Browne is a primary educator for tools like Claude Code. He advocates for vibe coding as a way to bypass the "boring parts" of development, allowing engineers to focus on higher-level architecture and product logic.

McKay Wrigley (Developer and AI educator): A leading technical figure focused on structured tutorials and advanced workflows for agentic programming. He is widely followed by senior engineers seeking to move beyond simple chat interfaces into full-scale autonomous software generation.

Charlie Holtz (Software engineer and infrastructure specialist): Known for building advanced infrastructure tools, Holtz is recognized as an engineer "pushing the boundaries" of what can be built using vibe coding for complex, back-end systems.

Cian Clarke (Principal Engineer at NearForm): A veteran in the Node.js ecosystem who has transitioned toward spec-driven development. He advocates for "AI native engineering" where specialized agentic roles (such as security or performance agents) are orchestrated to build and refactor large-scale enterprise systems.

IndyDevDan (Senior developer and educator): A highly technical voice advocating for "deep mastery" of AI-assisted engineering. He focuses on teaching developers how to maintain rigorous engineering standards while leveraging the speed of vibe coding.

Mitchell Hashimoto (Founder of HashiCorp, Creator of Terraform): Now focused on his terminal project Ghostty, Hashimoto has become a leading voice on "pragmatic AI coding." In 2026, he detailed his workflow of using reasoning models (like o3) to generate comprehensive architecture plans before writing a single line of code. He argues this "learning accelerator" approach allows him to build outside his primary expertise (e.g., frontend) while maintaining strict engineering rigor by reviewing the output line-by-line.

Kent C. Dodds (Renowned Web Development Educator & Engineer): A highly influential figure in the React community, Dodds has fully embraced the paradigm, stating in 2026 that he has "never had so much fun developing software." He advocates for a "problem elimination" mindset where AI handles the implementation details, allowing senior engineers to focus entirely on user experience and application architecture.

Guillermo Rauch (CEO of Vercel, Creator of Next.js/Socket.io): Rauch has been a vocal proponent of vibe coding as the bridge between business logic and shipping software. He argues that vibe coding solves the "execution gap," enabling technical founders and engineers to ship complex products without getting bogged down in boilerplate, effectively treating the AI as a "junior engineer with infinite stamina" that requires high-level direction.

DHH (David Heinemeier Hansson) (Creator of Ruby on Rails & CTO at 37signals): Historically a skeptic of industry hype, DHH has acknowledged the "tipping point" in 2026, noting that agentic coding has become a viable tool for experienced developers to deliver on specs rapidly. His shift represents a major endorsement from the "craftsman" sector of the industry, validating that AI tools can coexist with high standards for code quality.

Rich Harris (Creator of Svelte): Harris has spoken about how AI-driven workflows liberate developers from "code preferences" and syntax debates. He views the 2026 landscape as one where the engineer's job is to focus on the "what" and "why" of a product, while AI increasingly handles the "how," allowing for a renaissance in creativity and shipping speed.

Addy Osmani (Engineering Manager for Chrome Web Platform): While deeply embedded in the browser ecosystem, Osmani has published extensively on his "AI-augmented" workflow in 2026. He characterizes the modern senior engineer not as a typist but as a "Director," whose primary skill is effectively guiding AI agents to execute complex engineering tasks while maintaining architectural integrity.

The above is just a smattering of individuals. I can keep going.

Re: After two years of vibecoding, I'm back to writing by hand

#613

Earlier quoted context omitted.

My 2c: there is a divide, unacknowledged, between developers that care about "code correctness" (or any other quality/science/whatever adjective you like) and those who care about the whole system they are creating. I care about making stuff. "Making stuff" means stuff that I can use. I care about code quality yes, but not to an obsessive degree of "I hate my framework's ORM because of ". So, vibe coding is great, be…

My other 2c: There are Engineers who are concerned by the long-term consequences of their work e.g. maintainability. In real engineering disciplines, the Engineer is accountable for their work. If a bridge you signed off collapses, you're accountable and if it turns out you were negligent you'll face jail time. In Software, that might be a program in a car. The Engineering mindset embodies these principles regardless…

The industry cares about reasonable results not perfection.

If vibe coding delivers in one day, + an additional 2 days to solve stupid bugs, what you deliver with utter perfection in 3 months, then the industry doesn't give a shit about slop.

Is it maintainable? Well it's AI that's going to maintain it.

I think the future will turn into one where source code is like assembly code. Do you care about how your automated compiler system is spitting out assembly? Is the assembly code, neat and organized and maintainable? No. You don't care about assembly code. The industry is shifting in the direction where they don't care about ALL source code.

Re: After two years of vibecoding, I'm back to writing by hand

#614
post #452

Earlier quoted context omitted.

> Obviously, I would never use it for data interchange (e.g. SOAP) anymore. Well, those comments were arguing about how it is the absolute best for data interchange. > I still use it from time to time for config files that a developer has to write. Even back when XML was still relatively hot, I recalled thinking that it solved a problem that a lot of developers didn't have. Because if, for example, you're writing Pyt…

> if, for example, you're writing Python or Javascript or Perl, it is dead easy to have Python or Javascript or Perl also be your configuration file language. Sure. Like C header files. It's the easiest option - no arguments there. But there are considerations beyond being easy. I think there's a case to be made that a config file should be data, not code.

Sure, it really depends on the use-case.

If people are really technical, then a language subset is fine.

If they're not really technical, then you might need a separate utility to manipulate the config file, and XML is OK if you need a separate utility. There are readers/writers available in every language, and it's human readable enough for debugging, but if a non-technical human mistakenly edits it, it might take some repair to make it usable again.

Even if you've decided on a separate config language, there are a lot of reasons why you might want to use something other than XML. The header/key/value system (e.g. the one that .gitconfig and a lot of /etc files use) remains popular.

I could be wrong, but it always seemed to me that XML was pushed as a doc/interchange format, and its use in config files was driven by "I already have this hammer and I know how to use it."

Re: After two years of vibecoding, I'm back to writing by hand

#615
post #64
post #27

Earlier quoted context omitted.

It’s like weightlifting: sure you can use a forklift to do it, but if the goal is to build up your own strength, using the forklift isn’t going to get you there. This is the ultimate problem with AI in academia. We all inherently know that “no pain no gain” is true for physical tasks, but the same is true for learning. Struggling through the new concepts is essentially the point of it, not just the end result. Of cou…

I like this analogy along with the idea that "it's not an autonomous robot, it's a mech suit." Here's the thing -- I don't care about "getting stronger." I want to make things, and now I can make bigger things WAY faster because I have a mech suit. edit: and to stretch the analogy, I don't believe much is lost "intellectually" by my use of a mech suit, as long as I observe carefully. Me doing things by hand is probab…

>Here's the thing -- I don't care about "getting stronger."

Let's not mince words here, what you mean is that you don't care to learn about a craft. You just want to get to the end result, and you are using the shiny new tool that promises to take you from 0 to 100% with little to no effort.

In this way, I'd argue what you are doing is not "creating", but engaging in a new form of consumption. It used to be you relied on algorithms to present to you content that you found fun, but the problem was that algorithm required other humans to create that content for you to later consume. Now with LLMs, you remove the other humans from the loop, and you can prompt the AI directly with exactly what you wish to see in that moment, down to the fine grained details of the thing, and after enough prompts, the AI gives you something that might be what you asked for.

You are rotting your brain.

Re: After two years of vibecoding, I'm back to writing by hand

#616

Earlier quoted context omitted.

> people used to get strong naturally because they had to do physical labor I think that's a bit of a myth. The Greeks and Romans had weightlifting and boxing gyms, but no forklifts. Many of the most renowned Romans in the original form of the Olympics and in Boxing were Roman Senators with the wealth and free time to lift weights and box and wrestle. One of the things that we know about the famous philosopher Plato…

> I think that's a bit of a myth. Why do you think that? It's definitely true. You can observe it today if you want to visit a country where peasants are still common. From Bret Devereaux's recent series on Greek hoplites: > Now traditionally, the zeugitai were regarded as the ‘hoplite class’ and that is sometimes supposed to be the source of their name > but what van Wees is working out is that although the zeugitai…

> > Many of the most renowned Romans in the original form of the Olympics and in Boxing were Roman Senators

> In the original form of the Olympics, a Roman senator would have been ineligible to compete, since the Olympics was open only to Greeks.

I did debate how to word that mixing of Greek and Roman things in the same sentence. I had emotional context I wanted to convey and considered a word like Decathlon there as more technically correct, but then fought the modern context that of the people that even know what the Decathlon is they know it in the context of it being a smaller event in the modern Olympics, from which perspective Olympics remains more technically correct as the modern English word for both.

As to the text you are quoting, I think it as much supports my claims as you think it doesn't. Ignoring the subject change from "weightlifting" (and sports more generally) to farming and soldiering, it mostly describes the general state of armies and feudalism in general through much of time: you have the rank and file from blue collar classes, and you have the officer corps from white collar classes. The wealthier class is fewer, but given more charge and importance. The lower class does more of the grunt work. The Romans had rich Officers and blue collar "enlisted".

The myth that I was referring to was that weightlifting is somehow a new invention because no one labors physically anymore. There have always been leisure classes that needed to lift weights as a hobby to get good at sports (and that class was also more often awarded medals in sports or important commands in armies, if we want to also connect to the blog post you quoted). As far as I'm aware there was never a period in recorded history where "everyone" was equally fit from physical labor and there was no such thing as training and gyms and needing leisure time to do that.

[Further tangent: Even "pre-history" and the modern (mis)conception of the "paleo ideal" idea of tribes of equally buff hunter-gatherers starts to fall apart when you ask questions about family units or what they think the "gatherer" side of the equation meant (and manage to divorce it from modern ideas of agriculture being highly intense labor) or what those societies would look like if more people lived to old age or how those societies survived things like the Ice Age (fattier and more hibernatory, because we are a mammalian species, we cannot escape that).]

Re: After two years of vibecoding, I'm back to writing by hand

#617

Earlier quoted context omitted.

Non sequitor. You don't have to be bad at coding to use LLMs. The argument was specifically about thinking that LLMS can be great at accomplishing complex tasks (which they are not)

Wtf are you talking about. Great programmers use LLMs for complex tasks. That was the point of my comment

And my point is that what you think are complex tasks are not really complex.

The simple case is that if you ask an agent to do a whole bunch of modifications across a large number of files, it often loses context due to context windows.

Now, you can make your own agents with custom mcp servers to basically improve its ability to do tasks, but then you are basically just building automation tools in the first place.

Re: After two years of vibecoding, I'm back to writing by hand

#618

Earlier quoted context omitted.

I graduated about 15 years ago. In that time, I’ve formed the opposite opinion. My degree - the piece of paper - has been mostly useless. But the ways of thinking I learned at university have been invaluable. That and the friends I made along the way. I’ve worked with plenty of self taught programmers over the years. Lots of smart people. But there’s always blind spots in how they approach problems. Many fixate on to…

I think it depends on how they were self taught. If they just went through a few tutorials on YouTube and learned how to make a CRUD app using the shiny tool of the week, then sure. (I acknowledge this is a reduction in self-teaching — I myself am self-taught). But if they actually spent time trying to learn architecture and how to build stuff well, either by reading books or via good mentorship on the job, then they…

> But if they actually spent time trying to learn architecture and how to build stuff well, either by reading books or via good mentorship on the job, then they can often be better than the folks who went to school.

Yeah I just haven’t seen this happen. I’ve seen plenty of people graduate who were pretty useless. But … I think every self taught programmer I’ve worked with had meaningful gaps in their knowledge.

They’d spend a week in JavaScript to save them from 5 minutes with C or bash. Or they’d write incredibly slow code because they didn’t know the appropriate algorithms and data structures. They wouldn’t know how to profile their program to learn where the time is being spent. (Or that that’s even a thing). Some would have terrible intuitions around how the computer actually runs a program, so they can’t guess what would be fast or slow. I’ve seen wild abstractions to work around misunderstandings of the operating system. Hundreds of lines to deal with a case that can’t actually ever happen, or because someone missed the memo on a syscall that solves their exact problem. There’s also hairball nests of code because someone doesn’t know what a state machine is. Or how to factorise their problem in other ways. One guy I worked with thought the react team invented functional programming. Someone else doesn’t understand how you could write programs without OO inheritance. And I’ve seen so many bugs. Months of bugs, that could be prevented with the right design and tests.

I’ve worked with incredibly smart self taught programmers. Some of the smartest people I’ve ever worked with. But the thing about blind spots is you don’t know you have them. You say you’re self taught, and self taught people can be better than people who went to school. In limited domains, yeah. Smart matters a lot. But you don’t know what you don’t know. You don’t know what you missed out on. And you don’t know what problems in the workplace you could have easily solved if you knew how.

Re: After two years of vibecoding, I'm back to writing by hand

#619

AI is incredibly dangerous because it can do the simple things very well, which prevents new programmers from learning the simple things ("Oh, I'll just have AI generate it") which then prevents them from learning the middlin' and harder and meta things at a visceral level. I'm a CS teacher, so this is where I see a huge danger right now and I'm explicit with my students about it: you HAVE to write the code. You CAN'…

I haven't done long division in decades, am probably unable to do it anymore, and yet it has never held me back in any tangible fashion (and won't unless computers and calculators stop existing)

I haven’t had the need to in decades either but I can still do it. Similarly with the standard algorithms for multi-digit addition, subtraction, and multiplication.

I think learning these algorithms was useful not because we use these tools ourselves but because it taught us useful concepts: very practical step-by-step algorithms, and a hands-on introduction to decimal places and powers of ten.

There are other ways to learn these things but I learned them in elementary school by doing hundreds of arithmetic problems over 4-5 years. That knowledge stays with me even if I don’t pull out long division for anything practical.

Re: After two years of vibecoding, I'm back to writing by hand

#620

Earlier quoted context omitted.

How many more appeal-to-authority counter arguments are going to be made in this thread

They are more effective then on the ground in your face evidence largely because people who are so against AI are blind to it. I hold a result of AI in front of your face and they still proclaim it’s garbage and everything else is fraudulent. Let’s be clear. You’re arguing against a fantasy. Nobody even proponents of AI claims that AI is as good as humans. Nowhere near it. But they are good enough for pair programmin…

Just to be more pedantic, there is more nuance to all of that.

Nobody smart is going to disagree that LLMs are a huge net positive. The finer argument is whether or not at this point you can just hand off coding to an LLM. People who say yes simply just haven't had enough experience with using LLMs to a large extent. The amount of time you have to spend prompt engineering the correct response is often the same amount of time it takes for you to write the correct code yourself.

And yes, you can put together AGENT.md files, mcp servers, and so on, but then it becomes a game of this. https://xkcd.com/1205/

Post reply on HN