8 ms·

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

120 points by written-beyond 9mo ago

atq2119 9mo ago
Having used Claude Code in anger for a while now, I agree that given the state of these agents, we can't stop writing code by hand. They're just not good enough. But that also doesn't mean they're useless. Giving comparatively tedious background tasks to the agents that I check in on once or twice an hour does feel genuinely useful to me today. There's a balance to be found that's probably going to shift slowly over time.
- exegete 9mo ago
  To me the biggest benefit has been getting AI to write scripts that automate some things for me that are tedious but not needed to be deployed. Those scripts don’t have to be production-grade and just have to work.
- amarant 9mo ago
  Similar experience. I just tried Claude for the first time last week, and I gave it very small tasks. "Create a data class myClass with these fields<•••> and set it up to generate a database table using micronaut data" was one example. I still have to know exactly what to do, but I find it very nice that I didn't have to remember how to configure micronaut data, (which tbf is really easy) I just had to know that that's what I wanted to use. It's not as revolutionary as the hype, but it does increase productivity quite a bit, and also makes programming more fun I think. I get to focus on what I want to build, instead of trying to remember jdbc minutiae. Then I just sanity check the generated code, and trust that I will spot mistakes in that jdbc connection. It felt like the world's most intuitive abstraction layer between me and the keyboard, a pretty cool feeling. Just for fun, once I had played a bit with it like that, I just told it to finish the application with some vague Jira-epic level instructions on what I wanted in it and then fed it the errors it got. It eventually managed to get something working but... Let's just say it's a good thing this was a toy project I did specifically to try out Claude, and not something anyone is going to use, much less maintain!
  - fragmede 9mo ago
    > Just for fun, once I had played a bit with it like that, I just told it to finish the application with some vague Jira-epic level instructions on what I wanted in it and then fed it the errors it got. Would you finish the application with "some vague Jira-epic level instructions"? Or, even if you don't formally make tickets in Jira for them, do you go from vague Jira-epic-sized notions to ticket-sized items? If I had a mind-control helmet that forced you to just write code and not let you break down that jira-epic in your thoughts, do you think the code would be any good? I don't think mine would be. So then, why does it seem reasonable that Claude would be any good, given such a mental straight jacket? Use planning mode, the keyword "ultrathink" and the phrase "do not write code", and have it break down the vage Jira epic into ticket-sized items, and then have it break it into sub tickets that are byte-sized tasks, and then have it get to work.
    - amarant 9mo ago
      I mean, I didn't really expect it to work, I just wanted to see what would happen. I'd had pretty good results thus far and wondered how far I could push it. Jira-epic-style prompts was, not surprisingly, pushing it too far. It did manage to get the application working though, with only a couple of "this thing broke, plz fix" style prompts, and it did better than I had thought it would to fulfill my intention, give how vague I was. My point was that if you're going to build an actual product, you should probably not use Claude in that way. Break down the epics to smaller more manageable chunks however, and Claude can do an amazing job! I'll definitely keep experimenting with it this way, it's way better than full-manual coding, or at least that's my initial impression of about a week of experimentation!
felixbecker 9mo ago
Contrary to what most devs belief: Most code is not shipped to hundreds of millions of users and passing the test and actually implementing a feature is worth more that drowning in backlog. The video is spot on for codebases of products that are critical systems: payment, erp etc -> single source of truth. Simple Crud apps/ Frontends for ecom that abstracted away the critical functionality to backend APIs (ERP, shop system, payment etc) benefit from vibe slop vs no shipping cadence
- clintonb 9mo ago
  You're producing technical debt. At some point you will invest more time fixing the vibe slop than it would have cost you to do the work yourself in the first place. A lot of vibe-coding just feels like shifting responsibility and resources from "development" to "incident response".
jgoodhcg 9mo ago
I wonder when I will feel compelled to go back. Right now it just feels too productive for me to let AI write the code.
- barbazoo 9mo ago
  I wonder if I will feel compelled to go back. Right now it just feels too productive for me to not let AI write some of the code.
exegete 9mo ago
I think the points about code ownership and responsibility are spot on. Management wants you to increase velocity with these agents so inevitably there is pressure to ship crappy code. You then will be responsible for the code, not the AI. It’s the idea of being a reverse centaur. I also like the comments on how developers should be frequently reading the entire code and not just the diffs. But again there is probably pressure to speed up and then that practice gets sacrificed.
- 2OEH8eoCRo0 9mo ago
  The rush it out the door mentality of this industry is stupid.
- CharlesW 9mo ago
  If your Management thinks it's acceptable to increase velocity by shipping crappy code, I'm surprised they never thought to do this before AI. From what I've seen, companies using AI well are shipping better code because of all the artifacts (supporting context like Architectural Design Records, project-specific skills and agents, etc.) and tests needed to support that. I understand that many are not using AI well.
  - exegete 9mo ago
    Of course there’s always been that pressure but now with AI tooling the sheer volume of code that can be generated is massive.
- bwat49 9mo ago
  > there is pressure to ship crappy code this is true with or without AI
  - exegete 9mo ago
    Yes but now there is so much more volume of code created in the same amount of time.
mlinhares 9mo ago
While I greatly dislike the hype and don't believe most of what people say is real or that whatever they're building is just bullshi, I can definitely see the improvement of productivity, specially when working with agents. I think the problem is that people: * see the hype; * try to replicate the hype; * it fails miserably; * they throw everything away; I'm on call this week on my job, one of the issues was adding a quick validation (verifying the length of a thing was exactly 15). I could have sat and done that but I just spun an agent, told it where it was, told it how to add the change (we always add feature flags to do that), read the code, prompted it to fix a thing and boom, PR is ready. I wrote 3 paragraphs, didn't have to sit and wait for CI or any of the other bullshit to get it done, focused on more important stuff but still got the fix out. Don't believe the hype but also don't completely discount the tools, they are incredible help and while they will not boost your productivity by 500%, they're amazing.
- shuraman7 9mo ago
  quick validation for which you wrote a 3 paragraphs long prompt? sounds like you've wasted time
  - joenot443 9mo ago
    For plenty of people, writing three paragraphs of prose they're already aware of can easily be <2min of work. This comment took 15s, typing can be very fast.
    - aszen 9mo ago
      I bet writing the code directly could have been even faster, llms aren't magically fast
      - cat-snatcher 9mo ago
        > llms aren't magically fast They literally are.
hajimuz 9mo ago
It’s now ship shit but it’s the right way to do. We need to figure out how to make it ship high quality code as possible as we can. Not just give it up.
returnInfinity 9mo ago
The key word from the video is "responsibility". Who is going to be responsible for the code? AI is definitely not responsible.
mmaunder 9mo ago
Try implementing something that is too hard for you. Usually that'll involve implementing math in a high performance language or with parallelization. Then try going back to "writing by hand".
- pessimizer 9mo ago
  > Try implementing something that is too hard for you. This is almost the only thing I'm against when it comes to LLMs. You have no ability to figure out if it is right, and you will be overly impressed by garbage because you aren't qualified to judge. Has anybody come up with a pithy way to describe Dunning-Kruger for evaluating the output of LLMs, or are people too busy still denying that Dunning and Kruger noticed anything? When it comes to implementing math, the main problem is that the tiniest difference can make the entire thing wrong, often to the degree of inverting it. I wouldn't be in any way comfortable in shipping something I didn't even understand. The LLM certainly didn't understand it; somebody should.
- bendmorris 9mo ago
  Nothing that is possible is "too hard" if you're willing to put in some effort. The only question is whether you will learn to do it, or press a button, hope the LLM did it well, and let it forever remain "too hard." Honestly, without judgment, I think this is just a fundamental difference in how people approach their craft. You either want to be capable yourself or you just want the results.
- Snuggly73 9mo ago
  if it’s too hard for you to write, it’s too hard for you to understand and comprehend. how are you going to take responsibility for that code and maintain it if needed?
dfajgljsldkjag 9mo ago
Recently I've seen coworkers frequently turn what should be a <10 line bugfix into a 500+ line refactor across multiple files. I suspect it's due to AI. There's a time and place for refactoring, but just fixing an isolated bug isn't it. But I've seen that often AI can't help itself from making changes you didn't ask for.
- fragmede 9mo ago
  On the other hand, how do you know what they're prompting? For all you know, the AI proposed the hacky 10 line fix and tour coworker was all hey let's fix this problem better. Before AI, "now" was seen as the wrong place for a refactor because of the time and effort involved, but if the hacky patch of a fix is roughly the same amount of wall clock time as a 500 line proper fix that makes the problem go away forever, what's the argument that the 10 line hack is actually better?
  - dfajgljsldkjag 9mo ago
    Certainly refactoring is better than a hack fix, but what I'm talking about is where the 10 line fix cleanly and fully addresses the bug, and the refactor is just thrown in anyways.
  - 8organicbits 9mo ago
    > if the hacky patch of a fix is roughly the same amount of wall clock time as a 500 line proper fix That only makes sense if the coworker isn't validating the fix and no one is reviewing the code. 500 lines of slop is going to take much longer if you have a human in the loop.
- catlifeonmars 9mo ago
  This is a major annoyance for me. In one PR I reviewed recently, it introduced concurrency where it was not needed and then cascaded to a bunch of synchronization logic everywhere as a result. What could have been 30 lines or so turned into a couple hundred line diff and the submitter did not think to question it. It was harder to review and introduced a potential for data races with zero benefit. These are all competent people I work with, who do good work normally too.
feverzsj 9mo ago
I'm feeling AI is already falling apart dramatically in the first month of 2026, with so many negative news.
- jesse_dot_id 9mo ago
  No.
  - njhnjhnjh 9mo ago
    [dead]
hsaliak 9mo ago
There is a balance to be struck. Not everyone is going to be comfortable with ralph loops. Some are going to be OK with running a single agent, some with advanced code completion or code generation for specific functionality and so on. The tooling is going to change how we do development no doubt, but people are going to find their comfortable spot, and be productive.
treelover 9mo ago
"If you're a software developer and you're worried about your job, you haven't spent enough time actually using these AI agents. Anyone who spent eight hours plus a day over the last year using these agents is not at all scared of these agents taking their jobs. They're not... Your job is not going anywhere." I agree with this take... for now. I wouldn't be surprised if the AI agents improved exponentially (in the next few years) to the point where his statement is no longer true.
- throwup238 9mo ago
  That’s what I said about self driving cars nearly a decade ago! The 80/20 rule is a painful lesson to internalize but it’s damn near a universal constant now. That last exponential improvement that takes LLMs over the finish line will take a lot longer than we think.
  - strange_quark 9mo ago
    I think self driving cars is a good analog. We got lane centering and adaptive cruise control pretty much universally, and some systems are more advanced, but you cannot buy a fully autonomous car. Sure there’s Waymo and others pushing at the edge in very very limited contexts, but most people are still driving their own cars, just with some additional support. I suspect the same will be true for software engineering.
    - fragmede 9mo ago
      You can buy a Tesla with FSD today. It works. Sure there are some corner cases, but it's good enough in enough cases to get in, punch in a destination, and get you there. But you have to buy a Tesla, and they only come in electric. Waymo's are fine too, you just have to live in a supported area. The real gem for self driving, is Comma.ai. It's an aftermarket system, but can be installed in most newish cars with a built in lane guidance system. Even a Corolla. And it's really want we want. It's not self-driving, it'll just take you down the freeway and you don't have to do anything except wait for your GPS to tell you to exit (and then you have to exit). Freeway-grade gurves in the road? Fine. Stop and go traffic? Handled. It's better than Tesla's FSD in two specific ways. One is that because it's not self-driving, it's way easier to trust the system because it's not going to change lanes or anything surprising on you. It's not going to do something fancy, just brake or accelerate or follow the lane or car in front of you left or right. I highly recommend it to anyone who does any amount of freeway driving. If not for the coolness of it then simply the safety aspect. Now, I'm sure everyone here is a better driver than most (though that has a problem, mathematically), but this thing is better than a tired/angry/drunk version of someone else driving. But as you point out, most people are still driving their own cars. Which, I think is where we're going to see the software development industry going. There's gonna be the AI maximalists, who, like Waymo and FSD, will have AI basically do everything. And then there's the pragmatists, for whom AI doesn't do everything, just enough to be useful. Then there's everyone else, still writing their own code. Thing is, an app on your computer isn't a car. It's $20/month if not free if you're a total cheapskate, to get codex or claude or another assistant, vs many thousands of dollars for a self-driving or partially self-driving car. The other difference is in time. The value of a partially self-driving car (FSD or Comma) is in the mental fatigue of driving, and in improved safety, but a 7 hour road trip is still going to take 7 hours even if you're not driving. The only time a self-driving car helps is if you're going cross-city in a Waymo, and you're in the back seat working on your laptop. AI assisted coding though is different. If I take on projects I wouldn't do before with AI, that's a win for me. If I'm able to write software faster and with fewer bugs with AI, that's also a win for me, but also a win for my employer. If, however, it goes the other way and I write more bugs, then that's a loss for me and my employer.
neomantra 9mo ago
I really appreciate all of his message -- responsibility and actual engineering are critical and can't be (deceptively) lost even though Pull Request and CI/CD workflows exist. I hate the term vibe-coding because it seems flippant, and I've leaned into LLM-assistance to frame it better.
- SV_BubbleTime 9mo ago
  I consider vibe coding and LLM-assistance to be distinctively separate things. I am vibe coding, if I needed x, I lay that out task with any degree of specificity, and ask for the whole result. Maybe it’s good, I gave the LLM a lot of rope to hang me. I am using an LLM for assistance if I need something like this file renamed, and all its functions renamed to match, and all the project meta to change, and every comment that mentions the old name to be updated. There is an objectively correct result. It’s a matter of scope.
fibonachos 9mo ago
Multiline autocomplete is still the biggest productivity boost for me. This works well in a familiar codebase with reasonably consistent patterns. After that it’s the “ask” capability when I need to get oriented in unfamiliar and/or poorly documented code. I can often use the autocomplete pretty effectively once I understand the patterns and naming conventions. Similarly, agents are good for a first pass triage and plan when troubleshooting tricky bugs. Still haven’t had a good candidate for going full vibe code. Maybe that’s because I don’t do a lot of greenfield coding outside of work, which seems to be where it shines. Just my experience. It’s new set of tools in the toolbox, but not always the right one for a given task.
- AstroBen 9mo ago
  I'm working on a greenfield project right now and my experience has been 100% in line with the video I think it might be even worse for greenfield work, as that's when you're establishing a lot of patterns. You don't want AI to have any role in that
  - Garlef 9mo ago
    Yes. And AI is bad at design. But that's why you tell the AI to refactor. I've started a greenfield project and went 100% AI for learning purposes (of course it's more like 95%) and my takeaway is: - it's fully possible -- but the AI is of no great help with figuring out what the architecture or interfaces should be - Keep a refactoring backlog -- Spend 30%-40% of your time on refactoring, aligning patterns, improving architecture -- depending on your codebase, this can happen in parallel -- sometimes you need to get your hands dirty and do the cleanup yourself -- ... but usually, you only need to establish the pattern once - once the patterns are established, it becomes easy to talk to the AI in the context of your codebase -- you can reference patterns by name or location
    - fibonachos 9mo ago
      re: your last bullet. This has been very effective in my experience. “See class foo for example implementation “
ajross 9mo ago
The term "vibe coding" is less than a year old!
lombasihir 9mo ago
i am new to llm assisted coding, but i dont like the way it try to add more stuff when fixing thing, instead of going simplest less code possible, it recreate bunch of already coded logic, it also mostly try to code workaround and accumulate spagetti-esque codes. any advise? appreciate it
- catlifeonmars 9mo ago
  Tell it to stop? By this I mean give it precise instructions and ensure the instructions are always included in the context window. You’re responsible for managing the agents effective working memory, if that analogy makes sense. If you don’t tell it the way you want it to act, it’s effectively a blank slate.
Vaslo 9mo ago
All of these “go back to handcoding” posts seem to be done by very experienced coders. The fact that a less than mediocre coder like me can have sql statements or Python ETL written and tested for me in seconds rather than hours is all I need to see.
- clintonb 9mo ago
  How do you know the output is correct?
  - Vaslo 9mo ago
    1) Testing for myself 2) Vibe code testing 3) Team members do work from scratch and try to break 4) can read and reason it out even if I come out with it myself.
dnautics 9mo ago
> "in isolation this code makes a lot of sense"..."what is this junk" I mean I am left with two thoughts: 1. programming language skill issue. Some languages are simply much better at composition than others. I find that yes, this happens, but actually on the order of a day, and once the code is "good", it doesn't really change that much in the grand scheme of things? 2. Even for languages where composition is better, this is exactly what happens with human development too?
- catlifeonmars 9mo ago
  2. tends to happen less with more experienced engineers I think the mistake is assuming you get high quality work with an agent regardless of the driver’s skill level. That doesn’t appear to be the case, but it’s the value prop that is being sold.
  - dnautics 9mo ago
    2 is true even for highly experienced engineers over the long horizon, you keep building and then you realize that there's a better pattern that you should refactor a bunch of stuff for, but it gets tabled because feature XYZ is more important, and then feature YZW, etc. and then one day you're faced with looking down the abyss of committing to a refactor while some JE wants to rewrite everything in rust.
    - catlifeonmars 9mo ago
      And then you realize that most stuff is not worth refactoring if you can’t finish it in one go… it’s like a dunning Krueger roller coaster.
techmetaphorist 9mo ago
From my attempts, still, it takes more time to fix the code than it would if writing it all by hand. BUT! It's getting better and I look at it as just the next abstraction layer we will get used to. Think of it. Back in University I had to write code on PAPER. To think of memory allocation manually! Then came out managed code.. Then huge SDKs.. Then smart IDEs with intellij/intellisense.. And some us even remember riding the CPU with mov rcx, 5. We were just shifting our focus byte by byte from the nits and bolts towards the actual problem we are solving. In other words going less "hard"-ware, more and more "soft"-ware. AI is just continuing this evolution, adding another abstraction layer in soft dev process.
gaigalas 9mo ago
The mistake here was the expectation that LLM code would not be junk. It's the same junk produced by fast-growing startups. It was always here, now there's more of it. I'm convinced that people will continue to use it. Therefore, I need to be able to deal with it, maybe even leverage it somehow (there should be coding skills that I possess that people in that realm of fast-growing startups do not bother to learn).
notepad0x90 9mo ago
it's usually the balance and middle that is most beneficial. you can't deny the value LLM code generation and research provides. But the extreme of using only LLMs or mostly LLMs. or not using LLMs at all is self-harming. So far, LLM generated code hasn't lived up to my standards. I'll use it for things that aren't critical as-is, but mostly I use it as a reference, an example, a starting point. Essentially, where in the past I'd find a code base that does things and I'd try to do something similar, now I let the LLM generate the code base. There are to questions it helps me answer: 1) What are the possible ways of solving problems? 2) What are the pros and cons of each approach? That said, there are people successfully deploying apps that are entirely vibe coded. How many fail or succeed, that I don't know. But there are enough, and you can't deny the evidence.
- Ronsenshi 9mo ago
  Why is not using LLMs self harming? We've been writing code without help of LLMs for many decades just fine.
  - notepad0x90 9mo ago
    This is what I find amusing, we're in tech, how can you ask that? We've been rubbing stones to start fire too, but if you stick to that and refuse to use electricity, that's self-harming because you lose out on all the benefits. You can't keep doing things the same way, that's now how technology as an industry works, the whole point is to come up with newer and better things. If you're a user of technology, then you can think like that and keep using old tech until the natural balance of things forces you. I fully expect LLMs to be obsolete in a few decades, and I'm now wondering if people then will say how LLMs have been serving them fine for a few decades. "just fine" isn't good enough in tech, "better" is always the goal.
    - Ronsenshi 9mo ago
      > that's self-harming because you lose out on all the benefits. This is some big stretch in reasoning. Four years ago we were not harming ourselves by not having AI and writing code ourselves. At most you're hurting your ability to compete with "vibe coders" whose metric so far has been lines of code and $ spend per day running agents, not successful products. Have you considered how relying on AI affects your own programming skills?
jesse_dot_id 9mo ago
Artisanal engineering is the only true way to code. No autocomplete. No linting. No prettifying. No colored brackets, braces, or nesting lines. If you're not instinctually converting your Rust to assembler in your head as you insert it into vi, can you even really call yourself a real developer? I posted this comment using only curl by the way. Don't bother replying because I only engage in bidirectional conversation via SSH tunnel and netcat. I doubt that you could figure it out.
- njhnjhnjh 9mo ago
  [flagged]
  - aerhardt 9mo ago
    Pretty sure the parent comment was being sarcastic but I cannot quite tell if you are, too.
    - jesse_dot_id 9mo ago
      same boat
    - hbogert 9mo ago
      It could well be 2 bots having a laugh
      - jesse_dot_id 9mo ago
        I'm a real boy
- AstroBen 9mo ago
  "You like code that's easy to work with, easy to understand, change and evolve? HAH! Bet you hate colored brackets and prettifying too!"
nprateem 9mo ago
The weekly thread on AI coding. I've been trying Google antigravity. Despite VS code being total dogshit compared to Intellij I'm pretty sure I won't be renewing any more (after 15 years, sorry jetbrains).
- Ronsenshi 9mo ago
  More like X-times daily. Where X is a function of how much money Company Y need to get from investors this week to continue training and running LLM models.
Ronsenshi 9mo ago
"It pases test completely consistently". There are some managers and developers out there who would charge and ship whatever code AI provides no matter what multidimensional horror there is inside. As long as these people point to test and say "look, the checkbox is green" they will sign on it without taking a single look at the codebase. So what if tests don't actually cover important parts of the functionality. Checkbox is green and AI review agent said it's fine - so it must be fine.
nickevante 9mo ago
I've noticed a similar pattern. AI assistants are incredible at kinetic coding i.e. generating boilerplate, refactoring, writing tests. But they are detrimental to potential coding especially at the architectural thinking that happens before you touch the keyboard. Writing by hand (or whiteboarding) forces you to load the entire context into your working memory. AI allows you to be lazy with your working memory. The code gets written faster, but the mental model of the system in my head is significantly weaker.
- acc077877 9mo ago
  Definitely, it's great at making a template but, it's hard to see or continue from what it has generated. I agree that writing by hand sets up that mental model, and because it's written by you, it's easier to branch out from there.
dwa3592 9mo ago
I am trying to log in to my pet insurance's website. The log in used to work just fine about 3 months ago. For MFA, I have been waiting for 10 minutes and have not received the code in my email yet. I have reached the maximum attempts(3) at resending the code. The code is supposed to be expired in 15 minutes. I am pretty sure somewhere some dev using AI has f'ed up and I hate it. Code generation is not hard anymore, keeping a software working through the changing world is hard. I will update here once I have been able to log in.
- dwa3592 9mo ago
  I received multiple codes. Entered the latest one and a pop up message says, "Our dog’s gone off-leash… We’ve run into a problem and are working to fix it as fast as we can. Please try again soon." I am not liking this era of infinite abundance.
  - dwa3592 9mo ago
    I was able to get in after another attempt but I keep receiving the mfa codes after log in. Lol.
sathish316 9mo ago
This is the best summary of everything that’s wrong with: 1. One-shot app development using Lovable with English requirements 2. Spec driven development tools like SpecKit, Kiro that promise English as being sufficient for LLM generated code 3. Using agent swarms with Claude Code and thinking you are making progress and you never have to look at the generated code, when the overall coherence or elegance of the codebase is lost. Loved the analogies in this video: “It looks like an airplane. It flies like an airplane. But when you inspect the code in its full context, it’s a paper plane.” and “It looks like an airplane, walks like an airplane and talks like an airplane. It’s probably an airplane. But it’s not an airplane, it’s a psychedelic airplane …filled with hallucinations” But, still the tools are incredibly helpful when you have the right guardrails and take the time to ensure (somehow) the output matches your taste and code quality expectations.
- AstroBen 9mo ago
  Elegance or "taste" for the codebase is wrong. It's not just a stylistic preference. It's objectively bad code that's going to be slow to iterate on and very easy to introduce bugs to I'm not saying AI has no place, but letting it take the lead in any way is just building your app on sand. Fine if you're building a sandcastle, bad if you're building a bridge. It's not "ohh well I just don't like the way sandcastles look"
nulone 9mo ago
Looks like an airplane, fails under real inspection. Same smell in diffs: bugfix turns into refactor. Review eats the "velocity." Revert rate keeps you honest.
malshe 9mo ago
I will give my perspective as an academic who writes R and Python code for data analysis (including a lot of data cleaning). 1. I find AI written code verbose and inelegant. It makes it difficult to troubleshoot. I take pride in my own code and share it confidently with my doctoral students and coauthors. I can't share AI written/assisted code with the same confidence let alone pride. 2. Often AI takes shortcuts and writes terrible code. This is especially true for Bayesian models. My first check with any Bayesian model is to recover parameters using a simulated dataset. If the code fails to do that, there is no point in going forward. I used Opus 4.5, Gemini 3.0, and GPT 5.2 recently to write rather simple code for random parameters dynamic panel model. There are already papers that have done it. All three failed numerous times. I got it to work after a lot of handholding. 3. AI helps tremendously while creating web apps that make my analysis more actionable. A lot of reviewers now want to see something in action, so using Streamlit or Shiny is the way to go.

120 points by written-beyond 9mo ago

Having used Claude Code in anger for a while now, I agree that given the state of these agents, we can't stop writing code by hand. They're just not good enough. But that also doesn't mean they're useless. Giving comparatively tedious background tasks to the agents that I check in on once or twice an hour does feel genuinely useful to me today. There's a balance to be found that's probably going to shift slowly over time.

exegete 9mo ago
To me the biggest benefit has been getting AI to write scripts that automate some things for me that are tedious but not needed to be deployed. Those scripts don’t have to be production-grade and just have to work.
amarant 9mo ago
Similar experience. I just tried Claude for the first time last week, and I gave it very small tasks. "Create a data class myClass with these fields<•••> and set it up to generate a database table using micronaut data" was one example. I still have to know exactly what to do, but I find it very nice that I didn't have to remember how to configure micronaut data, (which tbf is really easy) I just had to know that that's what I wanted to use. It's not as revolutionary as the hype, but it does increase productivity quite a bit, and also makes programming more fun I think. I get to focus on what I want to build, instead of trying to remember jdbc minutiae. Then I just sanity check the generated code, and trust that I will spot mistakes in that jdbc connection. It felt like the world's most intuitive abstraction layer between me and the keyboard, a pretty cool feeling. Just for fun, once I had played a bit with it like that, I just told it to finish the application with some vague Jira-epic level instructions on what I wanted in it and then fed it the errors it got. It eventually managed to get something working but... Let's just say it's a good thing this was a toy project I did specifically to try out Claude, and not something anyone is going to use, much less maintain!
- fragmede 9mo ago
  > Just for fun, once I had played a bit with it like that, I just told it to finish the application with some vague Jira-epic level instructions on what I wanted in it and then fed it the errors it got. Would you finish the application with "some vague Jira-epic level instructions"? Or, even if you don't formally make tickets in Jira for them, do you go from vague Jira-epic-sized notions to ticket-sized items? If I had a mind-control helmet that forced you to just write code and not let you break down that jira-epic in your thoughts, do you think the code would be any good? I don't think mine would be. So then, why does it seem reasonable that Claude would be any good, given such a mental straight jacket? Use planning mode, the keyword "ultrathink" and the phrase "do not write code", and have it break down the vage Jira epic into ticket-sized items, and then have it break it into sub tickets that are byte-sized tasks, and then have it get to work.
  - amarant 9mo ago
    I mean, I didn't really expect it to work, I just wanted to see what would happen. I'd had pretty good results thus far and wondered how far I could push it. Jira-epic-style prompts was, not surprisingly, pushing it too far. It did manage to get the application working though, with only a couple of "this thing broke, plz fix" style prompts, and it did better than I had thought it would to fulfill my intention, give how vague I was. My point was that if you're going to build an actual product, you should probably not use Claude in that way. Break down the epics to smaller more manageable chunks however, and Claude can do an amazing job! I'll definitely keep experimenting with it this way, it's way better than full-manual coding, or at least that's my initial impression of about a week of experimentation!

felixbecker 9mo ago

Contrary to what most devs belief: Most code is not shipped to hundreds of millions of users and passing the test and actually implementing a feature is worth more that drowning in backlog. The video is spot on for codebases of products that are critical systems: payment, erp etc -> single source of truth. Simple Crud apps/ Frontends for ecom that abstracted away the critical functionality to backend APIs (ERP, shop system, payment etc) benefit from vibe slop vs no shipping cadence

clintonb 9mo ago
You're producing technical debt. At some point you will invest more time fixing the vibe slop than it would have cost you to do the work yourself in the first place. A lot of vibe-coding just feels like shifting responsibility and resources from "development" to "incident response".

jgoodhcg 9mo ago

I wonder when I will feel compelled to go back. Right now it just feels too productive for me to let AI write the code.

barbazoo 9mo ago
I wonder if I will feel compelled to go back. Right now it just feels too productive for me to not let AI write some of the code.

exegete 9mo ago

I think the points about code ownership and responsibility are spot on. Management wants you to increase velocity with these agents so inevitably there is pressure to ship crappy code. You then will be responsible for the code, not the AI. It’s the idea of being a reverse centaur. I also like the comments on how developers should be frequently reading the entire code and not just the diffs. But again there is probably pressure to speed up and then that practice gets sacrificed.

2OEH8eoCRo0 9mo ago
The rush it out the door mentality of this industry is stupid.
CharlesW 9mo ago
If your Management thinks it's acceptable to increase velocity by shipping crappy code, I'm surprised they never thought to do this before AI. From what I've seen, companies using AI well are shipping better code because of all the artifacts (supporting context like Architectural Design Records, project-specific skills and agents, etc.) and tests needed to support that. I understand that many are not using AI well.
- exegete 9mo ago
  Of course there’s always been that pressure but now with AI tooling the sheer volume of code that can be generated is massive.
bwat49 9mo ago
> there is pressure to ship crappy code this is true with or without AI
- exegete 9mo ago
  Yes but now there is so much more volume of code created in the same amount of time.

mlinhares 9mo ago

While I greatly dislike the hype and don't believe most of what people say is real or that whatever they're building is just bullshi, I can definitely see the improvement of productivity, specially when working with agents. I think the problem is that people: * see the hype; * try to replicate the hype; * it fails miserably; * they throw everything away; I'm on call this week on my job, one of the issues was adding a quick validation (verifying the length of a thing was exactly 15). I could have sat and done that but I just spun an agent, told it where it was, told it how to add the change (we always add feature flags to do that), read the code, prompted it to fix a thing and boom, PR is ready. I wrote 3 paragraphs, didn't have to sit and wait for CI or any of the other bullshit to get it done, focused on more important stuff but still got the fix out. Don't believe the hype but also don't completely discount the tools, they are incredible help and while they will not boost your productivity by 500%, they're amazing.

shuraman7 9mo ago
quick validation for which you wrote a 3 paragraphs long prompt? sounds like you've wasted time
- joenot443 9mo ago
  For plenty of people, writing three paragraphs of prose they're already aware of can easily be <2min of work. This comment took 15s, typing can be very fast.
  - aszen 9mo ago
    I bet writing the code directly could have been even faster, llms aren't magically fast
    - cat-snatcher 9mo ago
      > llms aren't magically fast They literally are.

hajimuz 9mo ago

It’s now ship shit but it’s the right way to do. We need to figure out how to make it ship high quality code as possible as we can. Not just give it up.

returnInfinity 9mo ago

The key word from the video is "responsibility". Who is going to be responsible for the code? AI is definitely not responsible.

mmaunder 9mo ago

Try implementing something that is too hard for you. Usually that'll involve implementing math in a high performance language or with parallelization. Then try going back to "writing by hand".

pessimizer 9mo ago
> Try implementing something that is too hard for you. This is almost the only thing I'm against when it comes to LLMs. You have no ability to figure out if it is right, and you will be overly impressed by garbage because you aren't qualified to judge. Has anybody come up with a pithy way to describe Dunning-Kruger for evaluating the output of LLMs, or are people too busy still denying that Dunning and Kruger noticed anything? When it comes to implementing math, the main problem is that the tiniest difference can make the entire thing wrong, often to the degree of inverting it. I wouldn't be in any way comfortable in shipping something I didn't even understand. The LLM certainly didn't understand it; somebody should.
bendmorris 9mo ago
Nothing that is possible is "too hard" if you're willing to put in some effort. The only question is whether you will learn to do it, or press a button, hope the LLM did it well, and let it forever remain "too hard." Honestly, without judgment, I think this is just a fundamental difference in how people approach their craft. You either want to be capable yourself or you just want the results.
Snuggly73 9mo ago
if it’s too hard for you to write, it’s too hard for you to understand and comprehend. how are you going to take responsibility for that code and maintain it if needed?

dfajgljsldkjag 9mo ago

Recently I've seen coworkers frequently turn what should be a <10 line bugfix into a 500+ line refactor across multiple files. I suspect it's due to AI. There's a time and place for refactoring, but just fixing an isolated bug isn't it. But I've seen that often AI can't help itself from making changes you didn't ask for.

fragmede 9mo ago
On the other hand, how do you know what they're prompting? For all you know, the AI proposed the hacky 10 line fix and tour coworker was all hey let's fix this problem better. Before AI, "now" was seen as the wrong place for a refactor because of the time and effort involved, but if the hacky patch of a fix is roughly the same amount of wall clock time as a 500 line proper fix that makes the problem go away forever, what's the argument that the 10 line hack is actually better?
- dfajgljsldkjag 9mo ago
  Certainly refactoring is better than a hack fix, but what I'm talking about is where the 10 line fix cleanly and fully addresses the bug, and the refactor is just thrown in anyways.
- 8organicbits 9mo ago
  > if the hacky patch of a fix is roughly the same amount of wall clock time as a 500 line proper fix That only makes sense if the coworker isn't validating the fix and no one is reviewing the code. 500 lines of slop is going to take much longer if you have a human in the loop.
catlifeonmars 9mo ago
This is a major annoyance for me. In one PR I reviewed recently, it introduced concurrency where it was not needed and then cascaded to a bunch of synchronization logic everywhere as a result. What could have been 30 lines or so turned into a couple hundred line diff and the submitter did not think to question it. It was harder to review and introduced a potential for data races with zero benefit. These are all competent people I work with, who do good work normally too.

feverzsj 9mo ago

I'm feeling AI is already falling apart dramatically in the first month of 2026, with so many negative news.

jesse_dot_id 9mo ago
No.
- njhnjhnjh 9mo ago
  [dead]

hsaliak 9mo ago

There is a balance to be struck. Not everyone is going to be comfortable with ralph loops. Some are going to be OK with running a single agent, some with advanced code completion or code generation for specific functionality and so on. The tooling is going to change how we do development no doubt, but people are going to find their comfortable spot, and be productive.

treelover 9mo ago

"If you're a software developer and you're worried about your job, you haven't spent enough time actually using these AI agents. Anyone who spent eight hours plus a day over the last year using these agents is not at all scared of these agents taking their jobs. They're not... Your job is not going anywhere." I agree with this take... for now. I wouldn't be surprised if the AI agents improved exponentially (in the next few years) to the point where his statement is no longer true.

throwup238 9mo ago
That’s what I said about self driving cars nearly a decade ago! The 80/20 rule is a painful lesson to internalize but it’s damn near a universal constant now. That last exponential improvement that takes LLMs over the finish line will take a lot longer than we think.
- strange_quark 9mo ago
  I think self driving cars is a good analog. We got lane centering and adaptive cruise control pretty much universally, and some systems are more advanced, but you cannot buy a fully autonomous car. Sure there’s Waymo and others pushing at the edge in very very limited contexts, but most people are still driving their own cars, just with some additional support. I suspect the same will be true for software engineering.
  - fragmede 9mo ago
    You can buy a Tesla with FSD today. It works. Sure there are some corner cases, but it's good enough in enough cases to get in, punch in a destination, and get you there. But you have to buy a Tesla, and they only come in electric. Waymo's are fine too, you just have to live in a supported area. The real gem for self driving, is Comma.ai. It's an aftermarket system, but can be installed in most newish cars with a built in lane guidance system. Even a Corolla. And it's really want we want. It's not self-driving, it'll just take you down the freeway and you don't have to do anything except wait for your GPS to tell you to exit (and then you have to exit). Freeway-grade gurves in the road? Fine. Stop and go traffic? Handled. It's better than Tesla's FSD in two specific ways. One is that because it's not self-driving, it's way easier to trust the system because it's not going to change lanes or anything surprising on you. It's not going to do something fancy, just brake or accelerate or follow the lane or car in front of you left or right. I highly recommend it to anyone who does any amount of freeway driving. If not for the coolness of it then simply the safety aspect. Now, I'm sure everyone here is a better driver than most (though that has a problem, mathematically), but this thing is better than a tired/angry/drunk version of someone else driving. But as you point out, most people are still driving their own cars. Which, I think is where we're going to see the software development industry going. There's gonna be the AI maximalists, who, like Waymo and FSD, will have AI basically do everything. And then there's the pragmatists, for whom AI doesn't do everything, just enough to be useful. Then there's everyone else, still writing their own code. Thing is, an app on your computer isn't a car. It's $20/month if not free if you're a total cheapskate, to get codex or claude or another assistant, vs many thousands of dollars for a self-driving or partially self-driving car. The other difference is in time. The value of a partially self-driving car (FSD or Comma) is in the mental fatigue of driving, and in improved safety, but a 7 hour road trip is still going to take 7 hours even if you're not driving. The only time a self-driving car helps is if you're going cross-city in a Waymo, and you're in the back seat working on your laptop. AI assisted coding though is different. If I take on projects I wouldn't do before with AI, that's a win for me. If I'm able to write software faster and with fewer bugs with AI, that's also a win for me, but also a win for my employer. If, however, it goes the other way and I write more bugs, then that's a loss for me and my employer.

neomantra 9mo ago

I really appreciate all of his message -- responsibility and actual engineering are critical and can't be (deceptively) lost even though Pull Request and CI/CD workflows exist. I hate the term vibe-coding because it seems flippant, and I've leaned into LLM-assistance to frame it better.

SV_BubbleTime 9mo ago
I consider vibe coding and LLM-assistance to be distinctively separate things. I am vibe coding, if I needed x, I lay that out task with any degree of specificity, and ask for the whole result. Maybe it’s good, I gave the LLM a lot of rope to hang me. I am using an LLM for assistance if I need something like this file renamed, and all its functions renamed to match, and all the project meta to change, and every comment that mentions the old name to be updated. There is an objectively correct result. It’s a matter of scope.

fibonachos 9mo ago

Multiline autocomplete is still the biggest productivity boost for me. This works well in a familiar codebase with reasonably consistent patterns. After that it’s the “ask” capability when I need to get oriented in unfamiliar and/or poorly documented code. I can often use the autocomplete pretty effectively once I understand the patterns and naming conventions. Similarly, agents are good for a first pass triage and plan when troubleshooting tricky bugs. Still haven’t had a good candidate for going full vibe code. Maybe that’s because I don’t do a lot of greenfield coding outside of work, which seems to be where it shines. Just my experience. It’s new set of tools in the toolbox, but not always the right one for a given task.

AstroBen 9mo ago
I'm working on a greenfield project right now and my experience has been 100% in line with the video I think it might be even worse for greenfield work, as that's when you're establishing a lot of patterns. You don't want AI to have any role in that
- Garlef 9mo ago
  Yes. And AI is bad at design. But that's why you tell the AI to refactor. I've started a greenfield project and went 100% AI for learning purposes (of course it's more like 95%) and my takeaway is: - it's fully possible -- but the AI is of no great help with figuring out what the architecture or interfaces should be - Keep a refactoring backlog -- Spend 30%-40% of your time on refactoring, aligning patterns, improving architecture -- depending on your codebase, this can happen in parallel -- sometimes you need to get your hands dirty and do the cleanup yourself -- ... but usually, you only need to establish the pattern once - once the patterns are established, it becomes easy to talk to the AI in the context of your codebase -- you can reference patterns by name or location
  - fibonachos 9mo ago
    re: your last bullet. This has been very effective in my experience. “See class foo for example implementation “

ajross 9mo ago

The term "vibe coding" is less than a year old!

lombasihir 9mo ago

i am new to llm assisted coding, but i dont like the way it try to add more stuff when fixing thing, instead of going simplest less code possible, it recreate bunch of already coded logic, it also mostly try to code workaround and accumulate spagetti-esque codes. any advise? appreciate it

catlifeonmars 9mo ago
Tell it to stop? By this I mean give it precise instructions and ensure the instructions are always included in the context window. You’re responsible for managing the agents effective working memory, if that analogy makes sense. If you don’t tell it the way you want it to act, it’s effectively a blank slate.

Vaslo 9mo ago

All of these “go back to handcoding” posts seem to be done by very experienced coders. The fact that a less than mediocre coder like me can have sql statements or Python ETL written and tested for me in seconds rather than hours is all I need to see.

clintonb 9mo ago
How do you know the output is correct?
- Vaslo 9mo ago
  1) Testing for myself 2) Vibe code testing 3) Team members do work from scratch and try to break 4) can read and reason it out even if I come out with it myself.

dnautics 9mo ago

> "in isolation this code makes a lot of sense"..."what is this junk" I mean I am left with two thoughts: 1. programming language skill issue. Some languages are simply much better at composition than others. I find that yes, this happens, but actually on the order of a day, and once the code is "good", it doesn't really change that much in the grand scheme of things? 2. Even for languages where composition is better, this is exactly what happens with human development too?

catlifeonmars 9mo ago
2. tends to happen less with more experienced engineers I think the mistake is assuming you get high quality work with an agent regardless of the driver’s skill level. That doesn’t appear to be the case, but it’s the value prop that is being sold.
- dnautics 9mo ago
  2 is true even for highly experienced engineers over the long horizon, you keep building and then you realize that there's a better pattern that you should refactor a bunch of stuff for, but it gets tabled because feature XYZ is more important, and then feature YZW, etc. and then one day you're faced with looking down the abyss of committing to a refactor while some JE wants to rewrite everything in rust.
  - catlifeonmars 9mo ago
    And then you realize that most stuff is not worth refactoring if you can’t finish it in one go… it’s like a dunning Krueger roller coaster.

techmetaphorist 9mo ago

From my attempts, still, it takes more time to fix the code than it would if writing it all by hand. BUT! It's getting better and I look at it as just the next abstraction layer we will get used to. Think of it. Back in University I had to write code on PAPER. To think of memory allocation manually! Then came out managed code.. Then huge SDKs.. Then smart IDEs with intellij/intellisense.. And some us even remember riding the CPU with mov rcx, 5. We were just shifting our focus byte by byte from the nits and bolts towards the actual problem we are solving. In other words going less "hard"-ware, more and more "soft"-ware. AI is just continuing this evolution, adding another abstraction layer in soft dev process.

gaigalas 9mo ago

The mistake here was the expectation that LLM code would not be junk. It's the same junk produced by fast-growing startups. It was always here, now there's more of it. I'm convinced that people will continue to use it. Therefore, I need to be able to deal with it, maybe even leverage it somehow (there should be coding skills that I possess that people in that realm of fast-growing startups do not bother to learn).

notepad0x90 9mo ago

it's usually the balance and middle that is most beneficial. you can't deny the value LLM code generation and research provides. But the extreme of using only LLMs or mostly LLMs. or not using LLMs at all is self-harming. So far, LLM generated code hasn't lived up to my standards. I'll use it for things that aren't critical as-is, but mostly I use it as a reference, an example, a starting point. Essentially, where in the past I'd find a code base that does things and I'd try to do something similar, now I let the LLM generate the code base. There are to questions it helps me answer: 1) What are the possible ways of solving problems? 2) What are the pros and cons of each approach? That said, there are people successfully deploying apps that are entirely vibe coded. How many fail or succeed, that I don't know. But there are enough, and you can't deny the evidence.

Ronsenshi 9mo ago
Why is not using LLMs self harming? We've been writing code without help of LLMs for many decades just fine.
- notepad0x90 9mo ago
  This is what I find amusing, we're in tech, how can you ask that? We've been rubbing stones to start fire too, but if you stick to that and refuse to use electricity, that's self-harming because you lose out on all the benefits. You can't keep doing things the same way, that's now how technology as an industry works, the whole point is to come up with newer and better things. If you're a user of technology, then you can think like that and keep using old tech until the natural balance of things forces you. I fully expect LLMs to be obsolete in a few decades, and I'm now wondering if people then will say how LLMs have been serving them fine for a few decades. "just fine" isn't good enough in tech, "better" is always the goal.
  - Ronsenshi 9mo ago
    > that's self-harming because you lose out on all the benefits. This is some big stretch in reasoning. Four years ago we were not harming ourselves by not having AI and writing code ourselves. At most you're hurting your ability to compete with "vibe coders" whose metric so far has been lines of code and $ spend per day running agents, not successful products. Have you considered how relying on AI affects your own programming skills?

jesse_dot_id 9mo ago

Artisanal engineering is the only true way to code. No autocomplete. No linting. No prettifying. No colored brackets, braces, or nesting lines. If you're not instinctually converting your Rust to assembler in your head as you insert it into vi, can you even really call yourself a real developer? I posted this comment using only curl by the way. Don't bother replying because I only engage in bidirectional conversation via SSH tunnel and netcat. I doubt that you could figure it out.

njhnjhnjh 9mo ago
[flagged]
- aerhardt 9mo ago
  Pretty sure the parent comment was being sarcastic but I cannot quite tell if you are, too.
  - jesse_dot_id 9mo ago
    same boat
  - hbogert 9mo ago
    It could well be 2 bots having a laugh
    - jesse_dot_id 9mo ago
      I'm a real boy
AstroBen 9mo ago
"You like code that's easy to work with, easy to understand, change and evolve? HAH! Bet you hate colored brackets and prettifying too!"

nprateem 9mo ago

The weekly thread on AI coding. I've been trying Google antigravity. Despite VS code being total dogshit compared to Intellij I'm pretty sure I won't be renewing any more (after 15 years, sorry jetbrains).

Ronsenshi 9mo ago
More like X-times daily. Where X is a function of how much money Company Y need to get from investors this week to continue training and running LLM models.

Ronsenshi 9mo ago

"It pases test completely consistently". There are some managers and developers out there who would charge and ship whatever code AI provides no matter what multidimensional horror there is inside. As long as these people point to test and say "look, the checkbox is green" they will sign on it without taking a single look at the codebase. So what if tests don't actually cover important parts of the functionality. Checkbox is green and AI review agent said it's fine - so it must be fine.

nickevante 9mo ago

I've noticed a similar pattern. AI assistants are incredible at kinetic coding i.e. generating boilerplate, refactoring, writing tests. But they are detrimental to potential coding especially at the architectural thinking that happens before you touch the keyboard. Writing by hand (or whiteboarding) forces you to load the entire context into your working memory. AI allows you to be lazy with your working memory. The code gets written faster, but the mental model of the system in my head is significantly weaker.

acc077877 9mo ago
Definitely, it's great at making a template but, it's hard to see or continue from what it has generated. I agree that writing by hand sets up that mental model, and because it's written by you, it's easier to branch out from there.

dwa3592 9mo ago

I am trying to log in to my pet insurance's website. The log in used to work just fine about 3 months ago. For MFA, I have been waiting for 10 minutes and have not received the code in my email yet. I have reached the maximum attempts(3) at resending the code. The code is supposed to be expired in 15 minutes. I am pretty sure somewhere some dev using AI has f'ed up and I hate it. Code generation is not hard anymore, keeping a software working through the changing world is hard. I will update here once I have been able to log in.

dwa3592 9mo ago
I received multiple codes. Entered the latest one and a pop up message says, "Our dog’s gone off-leash… We’ve run into a problem and are working to fix it as fast as we can. Please try again soon." I am not liking this era of infinite abundance.
- dwa3592 9mo ago
  I was able to get in after another attempt but I keep receiving the mfa codes after log in. Lol.

sathish316 9mo ago

This is the best summary of everything that’s wrong with: 1. One-shot app development using Lovable with English requirements 2. Spec driven development tools like SpecKit, Kiro that promise English as being sufficient for LLM generated code 3. Using agent swarms with Claude Code and thinking you are making progress and you never have to look at the generated code, when the overall coherence or elegance of the codebase is lost. Loved the analogies in this video: “It looks like an airplane. It flies like an airplane. But when you inspect the code in its full context, it’s a paper plane.” and “It looks like an airplane, walks like an airplane and talks like an airplane. It’s probably an airplane. But it’s not an airplane, it’s a psychedelic airplane …filled with hallucinations” But, still the tools are incredibly helpful when you have the right guardrails and take the time to ensure (somehow) the output matches your taste and code quality expectations.

AstroBen 9mo ago
Elegance or "taste" for the codebase is wrong. It's not just a stylistic preference. It's objectively bad code that's going to be slow to iterate on and very easy to introduce bugs to I'm not saying AI has no place, but letting it take the lead in any way is just building your app on sand. Fine if you're building a sandcastle, bad if you're building a bridge. It's not "ohh well I just don't like the way sandcastles look"

nulone 9mo ago

Looks like an airplane, fails under real inspection. Same smell in diffs: bugfix turns into refactor. Review eats the "velocity." Revert rate keeps you honest.

malshe 9mo ago

I will give my perspective as an academic who writes R and Python code for data analysis (including a lot of data cleaning). 1. I find AI written code verbose and inelegant. It makes it difficult to troubleshoot. I take pride in my own code and share it confidently with my doctoral students and coauthors. I can't share AI written/assisted code with the same confidence let alone pride. 2. Often AI takes shortcuts and writes terrible code. This is especially true for Bayesian models. My first check with any Bayesian model is to recover parameters using a simulated dataset. If the code fails to do that, there is no point in going forward. I used Opus 4.5, Gemini 3.0, and GPT 5.2 recently to write rather simple code for random parameters dynamic panel model. There are already papers that have done it. All three failed numerous times. I got it to work after a lot of handholding. 3. AI helps tremendously while creating web apps that make my analysis more actionable. A lot of reviewers now want to see something in action, so using Streamlit or Shiny is the way to go.