6 ms·

+1 I’ve been driving Claude as my primary coding interface the last three months at my job. Other than a different domain, I feel like I could have written thi

by yojo 6mo ago

+1 I’ve been driving Claude as my primary coding interface the last three months at my job. Other than a different domain, I feel like I could have written this exact article. The project I’m on started as a vibe-coded prototype that quickly got promoted to a production service we sell. I’ve had to build the mental model after the fact, while refactoring and ripping out large chunks of nonsense or dead code. But the product wouldn’t exist without that quick and dirty prototype, and I can use Claude as a goddamned chainsaw to clean up. On Friday, I finally added a type checker pre-commit hook and fixed the 90 existing errors (properly, no type ignores) in ~2 hours. I tried full-agentic first, and it failed miserably, then I went through error by error with Claude, we tightened up some exiting types, fixed some clunky abstractions, and got a nice, clean result. AI-assisted coding is amazing, but IMO for production code there’s no substitute for human review and guidance.

ffsm8 6mo ago
Fwiw, the article mirrors my experience when I started out too, even exactly with the same first month of vibecoding, then the next project which I did exactly like he outlined too. Personally, I think it's just the natural flow when you're starting out. If he keeps going, his opinion is going to change and as he gets to know it better, he'll likely go more and more towards vibecoding again. It's hard to say why, but you get better at it. Even if it's really hard to really put into words why
- devmor 6mo ago
  [flagged]
  - ffsm8 6mo ago
    really? have you ever learned a skill? Like carving, singing, playing guitar, playing a video game, anything? It's easy to get better at it without understanding why you're better at it. As a matter of fact, very very few people master the discipline enough to be able to grasp the reason for why they're actually better Most people just come up with random shit which may or may not be related. Which I just abstained from.
    - devmor 6mo ago
      You can get better at something without understanding why, but you should be able to think about it and determine why fairly easily. This is something everyone who cares about improving in a skill does regularly - examine their improvement, the reasons behind it, and how to add to them. That’s the basis of self-driven learning.
      - ffsm8 6mo ago
        Not really. I can obviously say something, like you learn which features the models are able to actually implement, and you learn how to phrase and approach trickier features to get the model too do what you want. And that's not really explainable without exploring specific examples. And now we're in thousands of words of explanation territory, hence my decision to say it's hard to put it into words.
        devmor 6mo ago
        I think you’re handwaving away vague, ungrounded intuition and calling it learning. For instance, if I say “I noticed I run better in my blue shoes than my red shoes” I did not learn anything. If I examine my shoes and notice that my blue shoes have a cushioned sole, while my red shoes are flat, I can combine that with thinking about how I run and learn that cushioned soles cause less fatigue to the muscles in my feet and ankles. The reason the difference matters is because if I don’t do the learning step, when buy another pair of blue shoes but they’re flat soled, I’m back to square one. Back to the real scenario, if you hold on to your ungrounded intuition re what tricks and phrasing work without understanding why, you may find those don’t work at all on a new model version or when forced to change to a different product due to price, insolvency, etc.
        deleted 6mo ago
        [deleted]
        eszed 6mo ago
        You're always free to stop at the level of abstraction at which you find a certain answer to be satisfying, but you can also keep digging. Why are flat shoes better? Well, it's to do with my gait. Ok, but why is my gait like that? Something-something musculoskeletal. Why is my body that way? Something-something genetic. OK, but why is that? And so on. Pursued far enough, any line of thought will reach something non-deterministic - or, simply, That's The Way It Is - however unsatisfying that is to those of us who crave straightforward answers. Like it or not, our ground truth as human beings ultimately rests on intuition. (Feel free to say, "No, it's physics", or "No, it's maths", but I'll ask you if you're doing those calculations in your head as you run!)
- snovv_crash 6mo ago
  Given how addictive vibecoding is, I think it's very hard to be objective about the results if you are involved in the process.
  - delusional 6mo ago
    It's a little like asking a cokehead how the addiction is going for him while he is high. Obviously he's going to say it's great because the consequences haven't hit him. Some percentage of addicts will never realize it was a problem at all. Its not random that AI happens to be built by the very same people that turned internet forums into the most addictive communication technology ever.
- 59nadir 6mo ago
  > he'll likely go more and more towards vibecoding again I think "more and more" is doing some very heavy lifting here. On the surface it reads like "a lot" to many people, I think, which is why this is hard to read without cringing a bit. Read like that it comes off as "It's very addictive and eventually you get lulled into accepting nonsense again, except I haven't realized that's what's happening". But the truth is that this comment really relies entirely on what "more and more" means here.
figassis 6mo ago
My process: start ideating and get the AI to poke holes in your reasoning, your vision, scalability, etc. do this for a few days while taking breaks. This is all contained in one Md file with mermaid diagrams and sections. Then use ideation to architect, dive into details and tell the AI exactly what your choices are, how certain methods should be called, how logging and observability should be setup, what language to use, type checking, coding style (configure ruthless linting and formatting before you write a single line of code), what testing methodology, framework, unit, integration, e2e. Database, changes you will handle migrations, as much as possible so the AI is as confined as possible to how you would do it. Then, create a plan file, have it manage it like a task list, and implement in parts, before starting it needs to present you a plan, in it you will notice it will make mistakes, misunderstand some things that you may me didn’t clarify before, or it will just forget. You add to AGENTS.md or whatever, make changes to the ai’s plan, tell it to update the plan.md and when satisfied, proceed. After done, review the code. You will notice there is always something to fix. Hardcoded variables, a sql migration with seed data that should actually not be a migration, just generally crazy stuff. The worst is that the AI is always very loose on requirements. You will notice all its fields are nullable, records have little to no validation, you report an error when testing and it tried to solve it with an brittle async solution, like LISTEN/NOTIFY or a callback instead of doing the architecturally correct solution. Things that at scale are hell to debug, especially if you did not write the code. If you do this and iterate you will gradually end up with a solid harness and you will need to review less. Then port it to other projects.
- irishcoffee 6mo ago
  I find it very interesting that you assume this method would branch out to other projects. I find it even more interesting that you assume all software codebases use a database, give a damn about async anything, and that these ideas percolate out to general software engineering. Sounds like a solid way to make crud web apps though.
  - klardotsh 6mo ago
    GP is clearly providing examples of categories of tasks. Sure, not all languages do “async fn foo()”, but almost all problem domains involve some sort of making sure the right things happen at the right times, which is in a similar ballpark. Holier than thou “yeah well I work on stuff that doesn’t use databases, checkmate!” doesn’t really land - data still gets moved around somehow, and often over a network!
camdenreslink 6mo ago
I’ve found that LLMs will frequently do extremely silly things that no person would do to make typescript code pass the typechecker.
- akdev1l 6mo ago
  You need to very specific and also question the output if it does something insane
  - justonceokay 6mo ago
    This decade’s version of “works on my box”
  - mexicocitinluez 6mo ago
    I've found it's less about specificity and more about removing the # of critical assumptions it needs to make. Being too specific can be a hindrance in it's own regard. And that's also a decent barometer for what it's good at. The more amount of critical assumptions AI needs to make, the less likely it is to make good ones. For instance, when building a heat map, I don't have to get specific at all because the amount of consequential assumptions it needs to make is slim. I don't care or can change the colors, or the label placement.
- dpkirchner 6mo ago
  I caught it using Parameters<typeof otherfn>[2] the other day. It wanted to avoid importing a type, so it did this nonsense. (I might have the syntax slightly wrong here, I'm writing from memory.) But it's not all bad news. TIL about Parameters<T>.
- 9rx 6mo ago
  Yeah, I've found LLMs cannot write good Typescript code period. The good news is that they are excellent at some other languages.
  - darkstarsys 6mo ago
    I can't agree here. https://pelorus-nav.com/ https://pelorus-nav.com/ (one of my side projects) is 95-98% written by Claude Opus 4.6, all in very nice typescript which I carefully review and correct, and use good prompting and context hygiene to ensure it doesn't take shortcuts. It's taken a month or so but so worth it. And my packing list app packzen.org is also pretty decent typescript all through.
theshrike79 6mo ago
> On Friday... This should be done on day one with a company-wide skill or project template that defines hard limits and processes for the Agent. Strict linters, formatters and code quality checks are essential to de-slopify the code as much as possible. That doesn't fix bad design though, that's still on humans.

by yojo 6mo ago

ffsm8 6mo ago

Fwiw, the article mirrors my experience when I started out too, even exactly with the same first month of vibecoding, then the next project which I did exactly like he outlined too. Personally, I think it's just the natural flow when you're starting out. If he keeps going, his opinion is going to change and as he gets to know it better, he'll likely go more and more towards vibecoding again. It's hard to say why, but you get better at it. Even if it's really hard to really put into words why

devmor 6mo ago
[flagged]
- ffsm8 6mo ago
  really? have you ever learned a skill? Like carving, singing, playing guitar, playing a video game, anything? It's easy to get better at it without understanding why you're better at it. As a matter of fact, very very few people master the discipline enough to be able to grasp the reason for why they're actually better Most people just come up with random shit which may or may not be related. Which I just abstained from.
  - devmor 6mo ago
    You can get better at something without understanding why, but you should be able to think about it and determine why fairly easily. This is something everyone who cares about improving in a skill does regularly - examine their improvement, the reasons behind it, and how to add to them. That’s the basis of self-driven learning.
    - ffsm8 6mo ago
      Not really. I can obviously say something, like you learn which features the models are able to actually implement, and you learn how to phrase and approach trickier features to get the model too do what you want. And that's not really explainable without exploring specific examples. And now we're in thousands of words of explanation territory, hence my decision to say it's hard to put it into words.
      - devmor 6mo ago
        I think you’re handwaving away vague, ungrounded intuition and calling it learning. For instance, if I say “I noticed I run better in my blue shoes than my red shoes” I did not learn anything. If I examine my shoes and notice that my blue shoes have a cushioned sole, while my red shoes are flat, I can combine that with thinking about how I run and learn that cushioned soles cause less fatigue to the muscles in my feet and ankles. The reason the difference matters is because if I don’t do the learning step, when buy another pair of blue shoes but they’re flat soled, I’m back to square one. Back to the real scenario, if you hold on to your ungrounded intuition re what tricks and phrasing work without understanding why, you may find those don’t work at all on a new model version or when forced to change to a different product due to price, insolvency, etc.
        deleted 6mo ago
        [deleted]
        eszed 6mo ago
        You're always free to stop at the level of abstraction at which you find a certain answer to be satisfying, but you can also keep digging. Why are flat shoes better? Well, it's to do with my gait. Ok, but why is my gait like that? Something-something musculoskeletal. Why is my body that way? Something-something genetic. OK, but why is that? And so on. Pursued far enough, any line of thought will reach something non-deterministic - or, simply, That's The Way It Is - however unsatisfying that is to those of us who crave straightforward answers. Like it or not, our ground truth as human beings ultimately rests on intuition. (Feel free to say, "No, it's physics", or "No, it's maths", but I'll ask you if you're doing those calculations in your head as you run!)
snovv_crash 6mo ago
Given how addictive vibecoding is, I think it's very hard to be objective about the results if you are involved in the process.
- delusional 6mo ago
  It's a little like asking a cokehead how the addiction is going for him while he is high. Obviously he's going to say it's great because the consequences haven't hit him. Some percentage of addicts will never realize it was a problem at all. Its not random that AI happens to be built by the very same people that turned internet forums into the most addictive communication technology ever.
59nadir 6mo ago
> he'll likely go more and more towards vibecoding again I think "more and more" is doing some very heavy lifting here. On the surface it reads like "a lot" to many people, I think, which is why this is hard to read without cringing a bit. Read like that it comes off as "It's very addictive and eventually you get lulled into accepting nonsense again, except I haven't realized that's what's happening". But the truth is that this comment really relies entirely on what "more and more" means here.

figassis 6mo ago

My process: start ideating and get the AI to poke holes in your reasoning, your vision, scalability, etc. do this for a few days while taking breaks. This is all contained in one Md file with mermaid diagrams and sections. Then use ideation to architect, dive into details and tell the AI exactly what your choices are, how certain methods should be called, how logging and observability should be setup, what language to use, type checking, coding style (configure ruthless linting and formatting before you write a single line of code), what testing methodology, framework, unit, integration, e2e. Database, changes you will handle migrations, as much as possible so the AI is as confined as possible to how you would do it. Then, create a plan file, have it manage it like a task list, and implement in parts, before starting it needs to present you a plan, in it you will notice it will make mistakes, misunderstand some things that you may me didn’t clarify before, or it will just forget. You add to AGENTS.md or whatever, make changes to the ai’s plan, tell it to update the plan.md and when satisfied, proceed. After done, review the code. You will notice there is always something to fix. Hardcoded variables, a sql migration with seed data that should actually not be a migration, just generally crazy stuff. The worst is that the AI is always very loose on requirements. You will notice all its fields are nullable, records have little to no validation, you report an error when testing and it tried to solve it with an brittle async solution, like LISTEN/NOTIFY or a callback instead of doing the architecturally correct solution. Things that at scale are hell to debug, especially if you did not write the code. If you do this and iterate you will gradually end up with a solid harness and you will need to review less. Then port it to other projects.

irishcoffee 6mo ago
I find it very interesting that you assume this method would branch out to other projects. I find it even more interesting that you assume all software codebases use a database, give a damn about async anything, and that these ideas percolate out to general software engineering. Sounds like a solid way to make crud web apps though.
- klardotsh 6mo ago
  GP is clearly providing examples of categories of tasks. Sure, not all languages do “async fn foo()”, but almost all problem domains involve some sort of making sure the right things happen at the right times, which is in a similar ballpark. Holier than thou “yeah well I work on stuff that doesn’t use databases, checkmate!” doesn’t really land - data still gets moved around somehow, and often over a network!

camdenreslink 6mo ago

I’ve found that LLMs will frequently do extremely silly things that no person would do to make typescript code pass the typechecker.

akdev1l 6mo ago
You need to very specific and also question the output if it does something insane
- justonceokay 6mo ago
  This decade’s version of “works on my box”
- mexicocitinluez 6mo ago
  I've found it's less about specificity and more about removing the # of critical assumptions it needs to make. Being too specific can be a hindrance in it's own regard. And that's also a decent barometer for what it's good at. The more amount of critical assumptions AI needs to make, the less likely it is to make good ones. For instance, when building a heat map, I don't have to get specific at all because the amount of consequential assumptions it needs to make is slim. I don't care or can change the colors, or the label placement.
dpkirchner 6mo ago
I caught it using Parameters<typeof otherfn>[2] the other day. It wanted to avoid importing a type, so it did this nonsense. (I might have the syntax slightly wrong here, I'm writing from memory.) But it's not all bad news. TIL about Parameters<T>.
9rx 6mo ago
Yeah, I've found LLMs cannot write good Typescript code period. The good news is that they are excellent at some other languages.
- darkstarsys 6mo ago
  I can't agree here. https://pelorus-nav.com/ https://pelorus-nav.com/ (one of my side projects) is 95-98% written by Claude Opus 4.6, all in very nice typescript which I carefully review and correct, and use good prompting and context hygiene to ensure it doesn't take shortcuts. It's taken a month or so but so worth it. And my packing list app packzen.org is also pretty decent typescript all through.

theshrike79 6mo ago

> On Friday... This should be done on day one with a company-wide skill or project template that defines hard limits and processes for the Agent. Strict linters, formatters and code quality checks are essential to de-slopify the code as much as possible. That doesn't fix bad design though, that's still on humans.