Comment by submeta

1 day ago

I went from Emacs to VS Code, then to Cursor, next to Claude Code, which is so good that I feel like I am having half a dozen junior devs at my fingertips, 24/7.

Since Claude Code is cli based, I reviewed my cli toolset: Migrated from iTerm2 to Ghostty and Tmux, from Cursor to NeoVim (my God is it good!).

Just had a 14h workday with this tooling. It’s so good that I complete the work of weeks and months within days! Absolutely beast.

At this point I am thinking IDEs do not reflect the changing reality of software development. They are designed for navigating project folders, writing / changing files. But I don’t review files that much anymore. I rather write prompts, watch Claude Code create a plan, implement it, even write meaningful commit messages.

Yes I can navigate the project with neovim, yes I can make commits in git and in lazygit, but my task is best spent in designing, planning, prompting, reviewing and testing.

I'm curious to see what you've built with all that extra productivity.

  • I work at a company with over 700 employees. And there are tons of use cases where a simple CRUD app is sufficient. Or where glue code needs to be written / changed for legacy systems. Or where an OS system like Camunda is deployed and needs to be configured, workflows developed, etc

    The reality of companies out there is much simpler than the challenges of a startup that needs to build systems that are state of the art, scale for millions of users, etc There are companies out there that make millions, in areas you‘ve never heard of, and their core business does not depend on software development best practices.

    In our company we have an IT team with the median age of fifty, team members who never have developed software, just maintain systems, delegate hard work to expensive consultants.

    Now in that setting someone coming from a startup background is like someone coming from the future. I feel like a wizard who can solve problems in days, instead of weeks or months waiting for a consultant to solve.

    • Fair enough. There are valid use cases for vibe coding scripts and simple CRUD apps, which current AI tools are fairly competent at producing.

      The thing is that those don't typically take weeks and months to build with conventional tooling. And I find it hard to believe that all you're doing is this type of integration work. But I suppose there are companies that need such roles.

      > There are companies out there that make millions, in areas you‘ve never heard of, and their core business does not depend on software development best practices.

      That is true.

      I do think that this cowboy coding approach is doing these companies a disservice, especially where tech is not their main product. It's only creating more operational risk that on-call and support staff have to deal with, and producing more technical debt that some poor soul will inevitably have to resolve one day. That is, it all appears to work until one edge case out of thousands brings down the entire system. Which could all be mitigated, if not avoided, by taking the time to understand the system and by following standard software development processes, even if it does take longer to implement.

      What you describe isn't new. This approach has existed long before the current wave of AI tooling. But AI tools make the problem worse by making it easier to ship code quickly without following any software development practices that ensure the software is robust and reliable.

      So, it's great that you're enjoying these tools. But I would suggest you adopt a more measured approach and work closely with those senior and junior engineers, instead of feeling like a wizard from the future.

    • Who's reviewing all the code you are churning out with ai? If everyone is used to maintaining not developing software it doesn't sound like they'd be best suited to have to review lots of complex pull requests.

      It sounds like you are moving very fast and probably have people just clicking "approve".

      Good luck for the future to who ever owns your company!

      8 replies →

  • No one ever shares their great and shipped products. AI built slop is for generating hype not revenue or users.

    • Man, who sucked the joy out of your life. Just try the damn thing. I have the staunchest anti-hypsters in my org and even they are using these tools heavily now.

      I build most of not all of my stuff for work, and I ain't sharing that.

      It's no panacea, but is there something to be had there? Abso-fucking-lutley. All of this would have been complete scifi at the beginning of this decade.

      2 replies →

    • Not the OP but this is smth I've vibecoded using cursor: https://bestphoto.ai/ MRR ~$150. It basically started as a clone of my other site: https://aieasypic.com (MRR 2.5k, 5-8k/mo rev) since I was having trouble keeping code context in mind and claude was pretty bad at doing full features with the tech stack I used for that site(Django BE, NextJS FE) making adding new features a pain, so I completely switched to a stack that claude is very good at NextJS fullstack(trpc BE) and now it can basically one-shot a feature request.

      Just putting this here because a lot of times AI coding seems to be dismissed as smth that can't do actual work ie generate revenue, while its more like making money as a solo dev is already pretty rare and if you're working in a corp. instead you're not going to just post your company name when asked for examples on what you're using AI for.

      8 replies →

    • The other day someone was gloating they'd created a 30k LoC code base in a few weeks with a similar setup.

      I'd consider that a liability, not an asset, but they were pretty happy with it.

    • That's not always the case.

      AI is often used to pump out sites and apps that scam users, SEO spam, etc. So there is definitely a revenue stream that makes scammers and grifters excited for AI. These tools have increased the scope and reach of their scams, and provide a huge boost to their productivity.

      That's partly why I'm curious about OP's work. Nobody who's using these tools while following best software engineering practices would claim that they're making them that much more productive. Reviewing the generated code and fixing issues counteracts whatever time is saved by generating code. But if they're vibe coding and don't even look at the code...

> But I don’t review files that much anymore.

Say no more.

  • I review PRs/commits, not files. Given the right cage to lock the agent inside, and guardrails built around, and conventions and guidelines, and agentic flows so it can pull in what's needed.. the need to look at every line and file during implementation is significantly lessened. So then I review the final output (which is a unit of work/task wrapped in a PR).

> I don’t review files that much anymore

You don't review the code? Just test it works?

  • At work we’re encouraged to use AI, so I do. For me the one thing that works well is using it to write one off scripts that do stuff and would be a chore to write.

    Usually in 2-3 prompts I can get a python or shell script that reads some file list somewhere, reads some json/csv elsewhere. Combines it in various ways and spits out some output to be ingested by some other pipeline.

    I just test this code if it works it’s good.

    Never in my life would I put this in a critical system though. When I review these files they are full of tiny errors that would blow up in spectacular manner if the input was slightly off somewhere.

    It’s good for what it is. But I’m honestly afraid of production code being vibe coded by these tools.

When generating code that is often wrong and needing to review it, and IDE is demonstrably better, this isn't an argument

  • > But I don’t review files that much anymore.

    they don't review files anymore though.

Curious - how did moving from iTerm2 to Ghostty help? I currently use iTerm2 and have never used Claude Code

  • Ghostty is gpu accelerated. It’s super fast, and tmux in it is a joy to use. That combined with NeoVim gives me an increadibly smooth dev experience in the terminal, something I had never have with iTerm2 and emacs.

Try again. No self respecting Emacs user would ever call vim “good”.

  • Haha :) I lived inside Emacs, used orgmode for everything, have written tons of Elisp, used org-roam as my second brain, used vanilla Emacs shortcuts instead of Evil (with a special keyboard settup using Karabiner Elements), did even my googling from Emacs, used emacs calc instead of my calculator, but in the end I spent more time tinkering my Emacs setup than doing real work. Emacs was a lifestyle. At some point I realized: Unix and the terminal are what Emacs try to be: It tries to be a one-stop shop offering you everything: Surfing the web, writing emails, word processor, calculator, planner, terminal. Unix and the terminal offer me all of that. Plus any scripting language. Why miss all the beautiful apps, just to be an Emacs zealot? The editor in emacs is just one usecase. Neovim does it just as well, if not better.

    But relax, noone is taking your Emacs from you :) I still like it, but am not a disciple anymore ;)

IDEs were a crutch, and now that crutch has been replaced by a semi-autonomous bot that can fetch and carry.

> It’s so good that I complete the work of weeks and months within days

and yet you're pulling 14 hour workdays..

  • Well you can't risk Claude quitting overnight. It forgets everything it did the day before and now you have to start over ... must ... finish ... tonight ... within ... context ... window.

    • Fortunately LLMs are stateless thus not affected by passage of time - your context stays exactly as it was while the tool maintaining it is running.

      (Prompt caches are another thing; leaving it for the night and resuming the next day will cost you a little extra on resume, if you're using models via API pay-as-you-go billing.)

  • So half a dozen junior devs plus 14h workday. That's a ton of surplus value right there. Hope he's getting a cut!

yes vibecoding is addicting like that. but if you are not reviewing any code and simply vibing then in my expreience you'll eventually get stuck in "its still not working" loops beause you have no other context or insight to provide it other than that. Then you have either accept what you have or throw the whole thing out and/or actually read the code . kind of rules out last option because code is now just too far gone with too many special cases hardcoded because AI sucks at abstraction or real software engineering.