7 ms·

My experience with the current tools so far: 1. It helps to get me going with new languages, frameworks, utilities or full green field stuff. After that I expe

My experience with the current tools so far: 1. It helps to get me going with new languages, frameworks, utilities or full green field stuff. After that I expend a lot of time parsing the code to understand what it wrote that I kind of "trust" it because it is too tedious but "it works". 2. When working with languages or frameworks that I know, I find it makes me unproductive, the amount of time I spend writing a good enough prompt with the correct context is almost the same or more that if I write the stuff myself and to be honest the solution that it gives me works for this specific case but looks like a junior code with pitfalls that are not that obvious unless you have the experience to know it. I used it with Typescript, Kotlin, Java and C++, for different scenarios, like websites, ESPHome components (ESP32), backend APIs, node scripts etc. Botton line: usefull for hobby projects, scripts and to prototypes, but for enterprise level code it is not there.

jeremywho 1y ago
My workflow is to use Claude desktop with the filesystem mcp server. I give claude the full path to a couple of relevant files related to the task at hand, ie where the new code should hook into or where the current problem is. Then I ask it to solve the task. Claude will read the files, determine what should be done and it will edit/add relevant files. There's typically a couple of build errors I will paste back in and have it correct. Current code patterns & style will be maintained in the new code. It's been quite impressive. This has been with Typescript and C#. I don't agree that what it has produced for me is hobby-grade only...
- taberiand 1y ago
  I've been using it the same way. One approach that's worked well for me is to start a project and first ask it to analyse and make a plan with phases for what needs to be done, save that plan into the project, then get it to do each phase in sequence. Once it completes a phase, have it review the code to confirm if the phase is complete. Each phase of work and review is a new chat. This way helps ensure it works on manageable amounts of code at a time and doesn't overload its context, but also keeps the bigger picture and goal in sight.
  - mnky9800n 1y ago
    I find that sometimes this works great and sometimes it happily tells you everything works and your code fails successfully and if you aren’t reading all the code you would never know. It’s kind of strange actually. I don’t have a good feeling when it will get everything correct and when it will fail and that’s what is disconcerting. I would be happy to be given advice on what to do to untangle when it’s good and when it’s not. I love chatting with Claude code about code. It’s annoying that it doesn’t always get it right and also doesn’t really interact with failure like a human would. At Least in my experience anyways.
    - taberiand 1y ago
      Of course, everything needs to be verified - I'm just trying to figure out a process that enables it to work as effectively as it can on large code bases in a structured way. Committing each stage to git, fixing issues and adjusting the context still comes into play.
- nwatson 1y ago
  One can also integrate with, say, a running PyCharm with the Jetbrains IDE MCP server. Claude Desktop can then interact directly with PyCharm.
- hamandcheese 1y ago
  Any particular reason you prefer that over Claude code?
  - jeremywho 1y ago
    I'm on windows. Claude Code via WSL hasn't been as smooth a ride.
- JyB 1y ago
  That's exactly how you should do it. You can also plug in an MCP for your CI or mention cli.github.com in your prompt to also make it iterate on CI failures. Next you use claude code instead and you make several work on their own clone on their own workspace and branches in the background; So you can still iterate yourself on some other topic on your personal clone. Then you check out its tab from time to time and optionally checkout its branch if you'd rather do some updates yourself. It's so ingrained in my day-to-day flow now it's been super impressive.
risyachka 1y ago
Pretty much my experience too. I usually go to option 2 - just write it by myself as it is same time-wise but keeps skills sharp.
- fpauser 1y ago
  Not to degenerate is really challenging these days. There are the bubbles that simulate multiple realities to us and try to untrain us logic thinking. And there are the llms that try to convice us that self thinking is unproductive. I wonder when this digitalophily suddenly turns into digitalophobia.
  - sciencejerk 1y ago
    It's happening, friend, don't let the AI hype fool you. I'm detecting quite a bit of reluctance and lack of 100% buy-in on AI coding tools and trends, even from your typically tech-loving Software Engineers.
flowerthoughts 1y ago
I predict microservices will get a huge push forward. The question then becomes if we're good enough at saying "Claude, this is too big now, you have to split it in two services" or not. If LLMs maintain the code, the API boundary definitions/documentation and orchestration, it might be manageable.
- fsloth 1y ago
  Why microservices? Monoliths with code-golfed minimal implementation size (but high quality architecture) implemented in strongly typed language would consume far less tokens (and thus would be cheaper to maintain).
- arwhatever 1y ago
  Won’t this cause [insert LLM] to lose context around the semantics of messages passed between microservices? You could then put all services in 1 repo, or point LLM at X number of folders containing source for all X services, but then it doesn’t seem like you’ll have gained anything, and at the cost of added network calls and more infra management.
- urbandw311er 1y ago
  Why not just cleanly separated code in a single execution environment? No need to actually run the services in separate execution environments just for the sake of an LLM being able to parse it, that’s crazy! You can just give it the files or folders it needs for the particular services within the project. Obviously there’s still other reasons to create micro services if you wish, but this does not need to be another reason.
fpauser 1y ago
Same conclusion here. Also good for analyzing existing codebases and to generate documentation for undocumented projects.
- j45 1y ago
  It's quite good at this, I have been tying in Gemini Pro with this too.
johnisgood 1y ago
> but for enterprise level code it is not there It is good for me in Go but I had to tell it what to write and how.
- sdesol 1y ago
  I've been able to create a very advanced search engine for my chat app that is more than enterprise ready. I've spent a decade thinking about search, but in a different language. Like you, I needed to explain what I knew about writing a search engine in Java for the LLM, to write it in JavaScript using libraries I did not know and it got me 95% of the way there. It is also incredibly important to note that the 5% that I needed to figure out was the difference between throw away code and something useful. You absolutely need domain knowledge but LLMs are more than enterprise ready in my opinion. Here is some documentation on how my search solution is used in my app to show that it is not a hobby feature. https://github.com/gitsense/chat/blob/main/packages/chat/widgets/app/components/chat-builder/trees/help/documentation/understanding-your-personalized-ai-search-assistant/1.md https://github.com/gitsense/chat/blob/main/packages/chat/wid...
  - johnisgood 1y ago
    Thanks for your reply, I am in the same boat, and it works for me, like it seems to work for you. So as long as we are effective with it, why not? Of course I am not doing things blindly and expect good results.
jiggawatts 1y ago
Something I’ve discovered is that it may be worthwhile writing the prompt anyway, even for a framework you’re an expert with. Sometimes the AIs will surprise me with a novel approach, but the real value is that the prompt makes for excellent documentation of the requirements! It’s a much better starting point for doc-comments or PR blurbs than after-the-fact ramblings.
viccis 1y ago
I agree. For me it's a modern version of that good ol "rails new" scaffolding with Ruby on Rails that got you started with a project structure. It makes sense because LLMs are particularly good at tasks that require little more knowledge than just a near perfect knowledge of the documentation of the tooling involved, and creating a well organized scaffold for a greenfield project falls squarely in that area. For legacy systems, especially ones in which a lot of the things they do are because of requirements from external services (whether that's tech debt or just normal growing complexity in a large connected system), it's less useful. And for tooling that moves fast and breaks things (looking at you, Databricks), it's basically worthless. People have already brought attention to the fact that it will only be as current as its training data was, and so if a bunch of terminology, features, and syntax have changed since then (ahem, Databricks), you would have to do some kind of prompt engineering with up to date docs for it to have any hope of succeeding.
- pvorb 1y ago
  I'm wondering what exact issue you are referring to with Databricks? I can't remember a time I had to change a line I wrote during the past 2.5 years I've been using it. Or are you talking about non-breaking changes?
  - viccis 1y ago
    They have changed a lot of their DLT (not even called that anymore lol, it's Lakeflow Pipelines now I think) syntax. I tried asking ChatGPT to convert a very simple Python one to Spark SQL, and it gave me a bunch of outdated SQL syntax. Aside from that, if you use their Python connector package, it's a shit show to put it mildly. For example, 15.4 works with serverless but tells you (via deprecation warning) it doesn't and that you need to use 15.1 (which lacks a lot of variant stuff). So then you decide screw it I'm gonna just update to 16, except that serverless (which works on 15.4) doesn't work on 16.0 or 17.0.
alfalfasprout 1y ago
The bigger problem I'm seeing is engineers that become over reliant on vibe coding tools are starting to lose context on how systems are designed and work. As a result, their productivity might go up on simple "ticket like tasks" where it's basically just simple implementation (find the file(s) to edit, modify it, test it) but when they start using it for all their tasks suddenly they don't know how anything works. Or worse, they let the LLM dictate and bad decisions are made. These same people are also very dogmatic on the use of these tools. They refuse to just code when needed. Don't get me wrong, this stuff has value. But I just hate seeing how it's made many engineers complacent and accelerated their ability to add to tech debt like never before.
mnky9800n 1y ago
Yea that’s right. It’s kind of annoying how useful it is for hobby projects and it is suddenly useless on anything at work. Haha. I love Claude code for some stuff (like generating a notebook to analyse some data). But it really just disconnects you from the problem you are solving without you going through everything it writes. And I’m really bullish on ai coding tools haha, for example: https://open.substack.com/pub/mnky9800n/p/coding-agents-provide-lightning-fast?r=2ixmx&utm_medium=ios https://open.substack.com/pub/mnky9800n/p/coding-agents-prov...
pqs 1y ago
I'm not a programmer, but I need to write python and bash programs to do my work. I also have a few websites and other personal projects. Claude Code helps me implement those little projects I've been wanting to do for a very long time, but I couldn't due to the lack of coding experience and time. Now I'm doing them. Also now I can improve my emacs environment, because I can create lisp functions with ease. For me, this is the perfect tool, because now I can do those little projects I couldn't do before, making my life easier.
- zingar 1y ago
  Big +1 to customizing emacs! Used to feel so out of reach, but now I basically rolled my own cursor.
- chamomeal 1y ago
  LLMs totally kick ass for making bash scripts
  - dboreham 1y ago
    Strong agree. Bash is so annoying that there have been many scripts that I wanted to have, but just didn't write (did the thing manually instead) rather than go down the rabbit hole of Bash nonsense. LLMs turn this on its head. I probably have LLMs write 1-2 bash scripts a week now, that I commit to git for use now and later.
    - unshavedyak 1y ago
      Similarly my Nix[OS] env had a ton of annoyances and updates needed that i didn't care to do. My first week of Claude saw tons of Nix improvements for my environment across my three machines (desk, server, macbook) and it's a much more rich environment. Claude did great at Nix, something i struggled with due to lack of documentation. It was far from perfect, but it usually pointed me towards the answer that i could later refine with it. Felt magical.
      - 1y ago
stpedgwdgfhgdd 1y ago
For enterprise software development CC is definitely there. 100k Go code paas platform, micro services architecture, mono repo is manageable. The prompt needs to be good, but in plan mode it will iteratively figure it out. You need to have automated tests. For enterprise software development that actually goes without saying.
dclowd9901 1y ago
It also steps right over easy optimizations. I was doing a query on some github data (tedious work) and rather than preliminarily filter down using the graphql search method, it wanted to comb through all PRs individually. This seems like something it probably should have figured out.
amelius 1y ago
It is very useful for small tasks like fixing network problems, or writing regexp patterns based on a few examples.
- MarcelOlsz 1y ago
  Here's how YOU can save $200/mo!
brulard 1y ago
For me it was like this for like a year (using Cline + Sonnet & Gemini) until Claude Code came out and until I learned how to keep context real clean. The key breakthrough was treating AI as an architect/implementer rather than a code generator. Most recently I ask first CC to create a design document for what we are going to do. He has instructions to look into the relevant parts of the code and docs to reference them. I review it and few back-and-forths we have defined what we want to do. Next step is to chunk it into stages and even those to smaller steps. All this may take few hours, but after this is well defined, I clear the context. I then let him read the docs and implement one stage. This goes mostly well and if it doesn't I either try to steer him to correct it, or if it's too bad, I improve the docs and start this stage over. After stage is complete, we commit, clear context and proceed to next stage. This way I spend maybe a day creating a feature that would take me maybe 2-3. And at the end we have a document, unit tests, storybook pages, and features that gets overlooked like accessibility, aria-things, etc. At the very end I like another model to make a code review. Even if this didn't make me faster now, I would consider it future-proofing myself as a software engineer as these tools are improving quickly
- imiric 1y ago
  This is a common workflow that most advanced users are familiar with. Yet even following it to a T, and being really careful with how you manage context, the LLM will still hallucinate, generate non-working code, steer you into wrong directions and dead ends, and just waste your time in most scenarios. There's no magical workflow or workaround for avoiding this. These issues are inherent to the technology, and have been since its inception. The tools have certainly gotten more capable, and the ecosystem has matured greatly in the last couple of years, but these issues remain unsolved. The idea that people who experience them are not using the tools correctly is insulting. I'm not saying that the current generation of this tech isn't useful. I've found it very useful for the same scenarios GP mentioned. But the above issues prevent me from relying on it for anything more sophisticated than that.
  - brulard 1y ago
    > These issues are inherent to the technology That's simply false. Even if LLMs don't produce correct and valid code on first shot 100% times of the cases, if you use an agent, it's simply a matter of iterations. I have claude code connected to Playwright, context7 for docs and to Playwright, so it can iterate by itself if there are syntax errors, runtime errors or problems with the data on the backend side. Currently I have near zero cases when it does not produce valid working code. If it is incorrect in some aspect, it is then not that hard to steer it to better solution or to fix yourself. And even if it failed in implementing most of these stages of the plan, it's not all wasted time. I brainstormed ideas, formed the requirements, specifications to features and have clear documentation and plan of the implementation, unit tests, etc. and I can use it to code it myself. So even in the worst case scenario my development workflow is improved.
drums8787 1y ago
My experience is the opposite I guess. I am having a great time using claude to quickly implement little "filler features" that require a good amount of typing and pulling from/editing different sources. Nothing that requires much brainpower beyond remembering the details of some sub system, finding the right files, and typing. Once the code is written, review, test and done. And on to more fun things. Maybe what has made it work is that these tasks have all fit comfortably within existing code patterns. My next step is to break down bigger & more complex changes into claude friendly bites to save me more grunt work.
- unlikelytomato 1y ago
  I wish I shared this experience. There are virtually no filter features for me to work on. When things feel like filler on my team, it's generally a sign of tech debt and we wouldn't want to have it generate all the code it would take. What are some examples of filler features for you? On the other hand, it does cost me about 8 hours a week debugging issues created by bad autocompletes from my team. The last 6 months have gotten really bad with that. But that is a different issue.
apimade 1y ago
Many who say LLMs produce “enterprise-grade” code haven’t worked in mid-tier or traditional companies, where projects are held together by duct tape, requirements are outdated, and testing barely exists. In those environments, enterprise-ready code is rare even without AI. For developers deeply familiar with a codebase they’ve worked on for years, LLMs can be a game-changer. But in most other cases, they’re best for brainstorming, creating small tests, or prototyping. When mid-level or junior developers lean heavily on them, the output may look useful.. until a third-party review reveals security flaws, performance issues, and built-in legacy debt. That might be fine for quick fixes or internal tooling, but it’s a poor fit for enterprise.
- bityard 1y ago
  I work in the enterprise, although not as a programmer, but I get to see how the sausage is made. And describing code as "enterprise grade" would not be a compliment in my book. Very analogous to "contractor grade" when describing home furnishings.
- Aeolun 1y ago
  Umm, Claude Code is a lot better than a lot of enterprise grade code I see. And it actually learns from mistakes with a properly crafted instruction xD
  - cube00 1y ago
    >And it actually learns from mistakes with a properly crafted instruction ...until it hallucinates and ignores said instruction.
- typpilol 1y ago
  I've found having a ton of linting tools can help the AI write much better and secure code. My eslint config is a mess but the code it writes comes out pretty good. Although it makes a few iterations after the lint errors pop for it to rewrite it, the code it writes is way better.
therealpygon 1y ago
I mostly agree, with the caveat that I would say it can certainly be useful when used appropriately as an “assistant”. NOT vibe coding blindly and hoping what I end up with is useful. “Implement x specific thing” (e.g. add an edit button to component x), not “implement a whole new epic feature that includes changes to a significant number of files”. Imagine meeting a house builder and saying “I want a house”, then leaving and expecting to come back to exactly the house you dreamed of. I get why, it’s a test of just how intuitive the model can be at planning and execution which drives innovation more than 1% differences in benchmarks ever will. I encourage that innovation in the hobby arena or when dogfooding your AI engineer. But as a replacement developer in an enterprise where an uncaught mistake could cost millions? No way. I wouldn’t even want to be the manager of the AI engineering team, when they come looking for the only real person to blame for the mistake not being caught. For additional checks/tasks as a completely extra set of eyes, building internal tools, and for scripts? Sure. It’s incredibly useful with all sorts of non- application development tasks. I’ve not written a batch or bash script in forever…you just don’t really need to much anymore. The linear flow of most batch/bash/scripts (like you mentioned) couldn’t be a more suitable domain. Also, with a basic prompt, it can be an incredibly useful rubber duck. For example, I’ll say something like “how do you think I should solve x problem”(with tools for the codebase and such, of course), and then over time having rejected and been adversarial to every suggestion, I end up working through the problem and have a more concrete mental design. Think “over-eager junior know-it-all that tries to be right constantly” without the person attached and you get a better idea of what kind of LLM output you can expect including following false leads to test your ideas. For me it’s less about wanting a plan from the LLM, and more about talking through the problems I think my plan could solve better, when more things are considered outside the LLMs direct knowledge or access. “We can’t do that, changing X would break Y external process because Z. Summarize that concern into a paragraph to be added to the knowledge base. Then, what other options would you suggest?”
tonyhart7 1y ago
it depends on model but sonnet is more than capable for enterprise code when you stuck at claude doing dumb shit, you didnt give the model enough context to know better the system after following spec driven development, works with LLM in large code base make it so much easier than without it like its heaven and hell differences but also it increase in token cost exponentially, so there's that
hoppp 1y ago
I used it with Tyopescript and Go, SQL, Rust Using it with rust is just horrible imho. Lots and lots of errors, I cant wait to stop this rust project already. But the project itself is quite complex Go on the other hand is super productive, mainly because the language is already very simple. I can move 2x fast Typescript is fine, I use it for react components and it will do animations Im lazy to do... SQL and postgresql is fine, I can do it without it also, I just dont like to write stored functions cuz of the boilerplatey syntax, a little speed up saves me from carpal tunnel
epolanski 1y ago
I really find your experience strikingly different than mine, I'll share you my flow: - step A: ask AI to write a featureA-requirements.md file at the root of the project, I give it a general description for the task, then have it ask me as many questions as possible to refine user stories and requirements. It generally comes up with a dozen or more of questions, of which multiples I would've not thought about and found out much later. Time: between 5 and 40 minutes. It's very detailed. - step B: after we refine the requirements (functional and non functional) we write together a todo plan as featureA-todo.md. I refine the plan again, this is generally shorter than the requirements and I'm generally done in less than 10 minutes. - step C: implementation phase. Again the AI does most of the job, I correct it at each edit and point flaws. Are there cases where I would've done that faster? Maybe. I can still jump in the editor and do the changes I want. This step in general includes comprehensive tests for all the requirements and edge cases we have found in step A, both functional, integration and E2Es. This really varies but it is generally highly tied to the quality of phase A and B. It can be as little as few minutes (especially true when we indeed come up with the most effective plan) and as much as few hours. - step D: documentation and PR description. With all of this context (in requirements and todos) at this point updating any relevant documentation and writing the PR description is a very short experiment. In all of that: I have textual files with precise coding style guidelines, comprehensive readmes to give precise context, etc that get referenced in the context. Bottom line: you might be doing something profoundly wrong, because in my case, all of this planning, requirements gathering, testing, documenting etc is pushing me to deliver a much higher quality engineering work.
- mcintyre1994 1y ago
  You’d probably like Kiro, it seems to be built specifically for this sort of spec-driven development.
  - epolanski 1y ago
    How would it be better than what I'm doing with Claude?

jeremywho 1y ago

My workflow is to use Claude desktop with the filesystem mcp server. I give claude the full path to a couple of relevant files related to the task at hand, ie where the new code should hook into or where the current problem is. Then I ask it to solve the task. Claude will read the files, determine what should be done and it will edit/add relevant files. There's typically a couple of build errors I will paste back in and have it correct. Current code patterns & style will be maintained in the new code. It's been quite impressive. This has been with Typescript and C#. I don't agree that what it has produced for me is hobby-grade only...

taberiand 1y ago
I've been using it the same way. One approach that's worked well for me is to start a project and first ask it to analyse and make a plan with phases for what needs to be done, save that plan into the project, then get it to do each phase in sequence. Once it completes a phase, have it review the code to confirm if the phase is complete. Each phase of work and review is a new chat. This way helps ensure it works on manageable amounts of code at a time and doesn't overload its context, but also keeps the bigger picture and goal in sight.
- mnky9800n 1y ago
  I find that sometimes this works great and sometimes it happily tells you everything works and your code fails successfully and if you aren’t reading all the code you would never know. It’s kind of strange actually. I don’t have a good feeling when it will get everything correct and when it will fail and that’s what is disconcerting. I would be happy to be given advice on what to do to untangle when it’s good and when it’s not. I love chatting with Claude code about code. It’s annoying that it doesn’t always get it right and also doesn’t really interact with failure like a human would. At Least in my experience anyways.
  - taberiand 1y ago
    Of course, everything needs to be verified - I'm just trying to figure out a process that enables it to work as effectively as it can on large code bases in a structured way. Committing each stage to git, fixing issues and adjusting the context still comes into play.
nwatson 1y ago
One can also integrate with, say, a running PyCharm with the Jetbrains IDE MCP server. Claude Desktop can then interact directly with PyCharm.
hamandcheese 1y ago
Any particular reason you prefer that over Claude code?
- jeremywho 1y ago
  I'm on windows. Claude Code via WSL hasn't been as smooth a ride.
JyB 1y ago
That's exactly how you should do it. You can also plug in an MCP for your CI or mention cli.github.com in your prompt to also make it iterate on CI failures. Next you use claude code instead and you make several work on their own clone on their own workspace and branches in the background; So you can still iterate yourself on some other topic on your personal clone. Then you check out its tab from time to time and optionally checkout its branch if you'd rather do some updates yourself. It's so ingrained in my day-to-day flow now it's been super impressive.

risyachka 1y ago

Pretty much my experience too. I usually go to option 2 - just write it by myself as it is same time-wise but keeps skills sharp.

fpauser 1y ago
Not to degenerate is really challenging these days. There are the bubbles that simulate multiple realities to us and try to untrain us logic thinking. And there are the llms that try to convice us that self thinking is unproductive. I wonder when this digitalophily suddenly turns into digitalophobia.
- sciencejerk 1y ago
  It's happening, friend, don't let the AI hype fool you. I'm detecting quite a bit of reluctance and lack of 100% buy-in on AI coding tools and trends, even from your typically tech-loving Software Engineers.

flowerthoughts 1y ago

I predict microservices will get a huge push forward. The question then becomes if we're good enough at saying "Claude, this is too big now, you have to split it in two services" or not. If LLMs maintain the code, the API boundary definitions/documentation and orchestration, it might be manageable.

fsloth 1y ago
Why microservices? Monoliths with code-golfed minimal implementation size (but high quality architecture) implemented in strongly typed language would consume far less tokens (and thus would be cheaper to maintain).
arwhatever 1y ago
Won’t this cause [insert LLM] to lose context around the semantics of messages passed between microservices? You could then put all services in 1 repo, or point LLM at X number of folders containing source for all X services, but then it doesn’t seem like you’ll have gained anything, and at the cost of added network calls and more infra management.
urbandw311er 1y ago
Why not just cleanly separated code in a single execution environment? No need to actually run the services in separate execution environments just for the sake of an LLM being able to parse it, that’s crazy! You can just give it the files or folders it needs for the particular services within the project. Obviously there’s still other reasons to create micro services if you wish, but this does not need to be another reason.

fpauser 1y ago

Same conclusion here. Also good for analyzing existing codebases and to generate documentation for undocumented projects.

j45 1y ago
It's quite good at this, I have been tying in Gemini Pro with this too.

johnisgood 1y ago

> but for enterprise level code it is not there It is good for me in Go but I had to tell it what to write and how.

sdesol 1y ago
I've been able to create a very advanced search engine for my chat app that is more than enterprise ready. I've spent a decade thinking about search, but in a different language. Like you, I needed to explain what I knew about writing a search engine in Java for the LLM, to write it in JavaScript using libraries I did not know and it got me 95% of the way there. It is also incredibly important to note that the 5% that I needed to figure out was the difference between throw away code and something useful. You absolutely need domain knowledge but LLMs are more than enterprise ready in my opinion. Here is some documentation on how my search solution is used in my app to show that it is not a hobby feature. https://github.com/gitsense/chat/blob/main/packages/chat/widgets/app/components/chat-builder/trees/help/documentation/understanding-your-personalized-ai-search-assistant/1.md https://github.com/gitsense/chat/blob/main/packages/chat/wid...
- johnisgood 1y ago
  Thanks for your reply, I am in the same boat, and it works for me, like it seems to work for you. So as long as we are effective with it, why not? Of course I am not doing things blindly and expect good results.

jiggawatts 1y ago

Something I’ve discovered is that it may be worthwhile writing the prompt anyway, even for a framework you’re an expert with. Sometimes the AIs will surprise me with a novel approach, but the real value is that the prompt makes for excellent documentation of the requirements! It’s a much better starting point for doc-comments or PR blurbs than after-the-fact ramblings.

viccis 1y ago

I agree. For me it's a modern version of that good ol "rails new" scaffolding with Ruby on Rails that got you started with a project structure. It makes sense because LLMs are particularly good at tasks that require little more knowledge than just a near perfect knowledge of the documentation of the tooling involved, and creating a well organized scaffold for a greenfield project falls squarely in that area. For legacy systems, especially ones in which a lot of the things they do are because of requirements from external services (whether that's tech debt or just normal growing complexity in a large connected system), it's less useful. And for tooling that moves fast and breaks things (looking at you, Databricks), it's basically worthless. People have already brought attention to the fact that it will only be as current as its training data was, and so if a bunch of terminology, features, and syntax have changed since then (ahem, Databricks), you would have to do some kind of prompt engineering with up to date docs for it to have any hope of succeeding.

pvorb 1y ago
I'm wondering what exact issue you are referring to with Databricks? I can't remember a time I had to change a line I wrote during the past 2.5 years I've been using it. Or are you talking about non-breaking changes?
- viccis 1y ago
  They have changed a lot of their DLT (not even called that anymore lol, it's Lakeflow Pipelines now I think) syntax. I tried asking ChatGPT to convert a very simple Python one to Spark SQL, and it gave me a bunch of outdated SQL syntax. Aside from that, if you use their Python connector package, it's a shit show to put it mildly. For example, 15.4 works with serverless but tells you (via deprecation warning) it doesn't and that you need to use 15.1 (which lacks a lot of variant stuff). So then you decide screw it I'm gonna just update to 16, except that serverless (which works on 15.4) doesn't work on 16.0 or 17.0.

alfalfasprout 1y ago

The bigger problem I'm seeing is engineers that become over reliant on vibe coding tools are starting to lose context on how systems are designed and work. As a result, their productivity might go up on simple "ticket like tasks" where it's basically just simple implementation (find the file(s) to edit, modify it, test it) but when they start using it for all their tasks suddenly they don't know how anything works. Or worse, they let the LLM dictate and bad decisions are made. These same people are also very dogmatic on the use of these tools. They refuse to just code when needed. Don't get me wrong, this stuff has value. But I just hate seeing how it's made many engineers complacent and accelerated their ability to add to tech debt like never before.

mnky9800n 1y ago

Yea that’s right. It’s kind of annoying how useful it is for hobby projects and it is suddenly useless on anything at work. Haha. I love Claude code for some stuff (like generating a notebook to analyse some data). But it really just disconnects you from the problem you are solving without you going through everything it writes. And I’m really bullish on ai coding tools haha, for example: https://open.substack.com/pub/mnky9800n/p/coding-agents-provide-lightning-fast?r=2ixmx&utm_medium=ios https://open.substack.com/pub/mnky9800n/p/coding-agents-prov...

pqs 1y ago

I'm not a programmer, but I need to write python and bash programs to do my work. I also have a few websites and other personal projects. Claude Code helps me implement those little projects I've been wanting to do for a very long time, but I couldn't due to the lack of coding experience and time. Now I'm doing them. Also now I can improve my emacs environment, because I can create lisp functions with ease. For me, this is the perfect tool, because now I can do those little projects I couldn't do before, making my life easier.

zingar 1y ago
Big +1 to customizing emacs! Used to feel so out of reach, but now I basically rolled my own cursor.
chamomeal 1y ago
LLMs totally kick ass for making bash scripts
- dboreham 1y ago
  Strong agree. Bash is so annoying that there have been many scripts that I wanted to have, but just didn't write (did the thing manually instead) rather than go down the rabbit hole of Bash nonsense. LLMs turn this on its head. I probably have LLMs write 1-2 bash scripts a week now, that I commit to git for use now and later.
  - unshavedyak 1y ago
    Similarly my Nix[OS] env had a ton of annoyances and updates needed that i didn't care to do. My first week of Claude saw tons of Nix improvements for my environment across my three machines (desk, server, macbook) and it's a much more rich environment. Claude did great at Nix, something i struggled with due to lack of documentation. It was far from perfect, but it usually pointed me towards the answer that i could later refine with it. Felt magical.
    - 1y ago

stpedgwdgfhgdd 1y ago

For enterprise software development CC is definitely there. 100k Go code paas platform, micro services architecture, mono repo is manageable. The prompt needs to be good, but in plan mode it will iteratively figure it out. You need to have automated tests. For enterprise software development that actually goes without saying.

dclowd9901 1y ago

It also steps right over easy optimizations. I was doing a query on some github data (tedious work) and rather than preliminarily filter down using the graphql search method, it wanted to comb through all PRs individually. This seems like something it probably should have figured out.

amelius 1y ago

It is very useful for small tasks like fixing network problems, or writing regexp patterns based on a few examples.

MarcelOlsz 1y ago
Here's how YOU can save $200/mo!

brulard 1y ago

For me it was like this for like a year (using Cline + Sonnet & Gemini) until Claude Code came out and until I learned how to keep context real clean. The key breakthrough was treating AI as an architect/implementer rather than a code generator. Most recently I ask first CC to create a design document for what we are going to do. He has instructions to look into the relevant parts of the code and docs to reference them. I review it and few back-and-forths we have defined what we want to do. Next step is to chunk it into stages and even those to smaller steps. All this may take few hours, but after this is well defined, I clear the context. I then let him read the docs and implement one stage. This goes mostly well and if it doesn't I either try to steer him to correct it, or if it's too bad, I improve the docs and start this stage over. After stage is complete, we commit, clear context and proceed to next stage. This way I spend maybe a day creating a feature that would take me maybe 2-3. And at the end we have a document, unit tests, storybook pages, and features that gets overlooked like accessibility, aria-things, etc. At the very end I like another model to make a code review. Even if this didn't make me faster now, I would consider it future-proofing myself as a software engineer as these tools are improving quickly

imiric 1y ago
This is a common workflow that most advanced users are familiar with. Yet even following it to a T, and being really careful with how you manage context, the LLM will still hallucinate, generate non-working code, steer you into wrong directions and dead ends, and just waste your time in most scenarios. There's no magical workflow or workaround for avoiding this. These issues are inherent to the technology, and have been since its inception. The tools have certainly gotten more capable, and the ecosystem has matured greatly in the last couple of years, but these issues remain unsolved. The idea that people who experience them are not using the tools correctly is insulting. I'm not saying that the current generation of this tech isn't useful. I've found it very useful for the same scenarios GP mentioned. But the above issues prevent me from relying on it for anything more sophisticated than that.
- brulard 1y ago
  > These issues are inherent to the technology That's simply false. Even if LLMs don't produce correct and valid code on first shot 100% times of the cases, if you use an agent, it's simply a matter of iterations. I have claude code connected to Playwright, context7 for docs and to Playwright, so it can iterate by itself if there are syntax errors, runtime errors or problems with the data on the backend side. Currently I have near zero cases when it does not produce valid working code. If it is incorrect in some aspect, it is then not that hard to steer it to better solution or to fix yourself. And even if it failed in implementing most of these stages of the plan, it's not all wasted time. I brainstormed ideas, formed the requirements, specifications to features and have clear documentation and plan of the implementation, unit tests, etc. and I can use it to code it myself. So even in the worst case scenario my development workflow is improved.

drums8787 1y ago

My experience is the opposite I guess. I am having a great time using claude to quickly implement little "filler features" that require a good amount of typing and pulling from/editing different sources. Nothing that requires much brainpower beyond remembering the details of some sub system, finding the right files, and typing. Once the code is written, review, test and done. And on to more fun things. Maybe what has made it work is that these tasks have all fit comfortably within existing code patterns. My next step is to break down bigger & more complex changes into claude friendly bites to save me more grunt work.

unlikelytomato 1y ago
I wish I shared this experience. There are virtually no filter features for me to work on. When things feel like filler on my team, it's generally a sign of tech debt and we wouldn't want to have it generate all the code it would take. What are some examples of filler features for you? On the other hand, it does cost me about 8 hours a week debugging issues created by bad autocompletes from my team. The last 6 months have gotten really bad with that. But that is a different issue.

apimade 1y ago

Many who say LLMs produce “enterprise-grade” code haven’t worked in mid-tier or traditional companies, where projects are held together by duct tape, requirements are outdated, and testing barely exists. In those environments, enterprise-ready code is rare even without AI. For developers deeply familiar with a codebase they’ve worked on for years, LLMs can be a game-changer. But in most other cases, they’re best for brainstorming, creating small tests, or prototyping. When mid-level or junior developers lean heavily on them, the output may look useful.. until a third-party review reveals security flaws, performance issues, and built-in legacy debt. That might be fine for quick fixes or internal tooling, but it’s a poor fit for enterprise.

bityard 1y ago
I work in the enterprise, although not as a programmer, but I get to see how the sausage is made. And describing code as "enterprise grade" would not be a compliment in my book. Very analogous to "contractor grade" when describing home furnishings.
Aeolun 1y ago
Umm, Claude Code is a lot better than a lot of enterprise grade code I see. And it actually learns from mistakes with a properly crafted instruction xD
- cube00 1y ago
  >And it actually learns from mistakes with a properly crafted instruction ...until it hallucinates and ignores said instruction.
typpilol 1y ago
I've found having a ton of linting tools can help the AI write much better and secure code. My eslint config is a mess but the code it writes comes out pretty good. Although it makes a few iterations after the lint errors pop for it to rewrite it, the code it writes is way better.

therealpygon 1y ago

I mostly agree, with the caveat that I would say it can certainly be useful when used appropriately as an “assistant”. NOT vibe coding blindly and hoping what I end up with is useful. “Implement x specific thing” (e.g. add an edit button to component x), not “implement a whole new epic feature that includes changes to a significant number of files”. Imagine meeting a house builder and saying “I want a house”, then leaving and expecting to come back to exactly the house you dreamed of. I get why, it’s a test of just how intuitive the model can be at planning and execution which drives innovation more than 1% differences in benchmarks ever will. I encourage that innovation in the hobby arena or when dogfooding your AI engineer. But as a replacement developer in an enterprise where an uncaught mistake could cost millions? No way. I wouldn’t even want to be the manager of the AI engineering team, when they come looking for the only real person to blame for the mistake not being caught. For additional checks/tasks as a completely extra set of eyes, building internal tools, and for scripts? Sure. It’s incredibly useful with all sorts of non- application development tasks. I’ve not written a batch or bash script in forever…you just don’t really need to much anymore. The linear flow of most batch/bash/scripts (like you mentioned) couldn’t be a more suitable domain. Also, with a basic prompt, it can be an incredibly useful rubber duck. For example, I’ll say something like “how do you think I should solve x problem”(with tools for the codebase and such, of course), and then over time having rejected and been adversarial to every suggestion, I end up working through the problem and have a more concrete mental design. Think “over-eager junior know-it-all that tries to be right constantly” without the person attached and you get a better idea of what kind of LLM output you can expect including following false leads to test your ideas. For me it’s less about wanting a plan from the LLM, and more about talking through the problems I think my plan could solve better, when more things are considered outside the LLMs direct knowledge or access. “We can’t do that, changing X would break Y external process because Z. Summarize that concern into a paragraph to be added to the knowledge base. Then, what other options would you suggest?”

tonyhart7 1y ago

it depends on model but sonnet is more than capable for enterprise code when you stuck at claude doing dumb shit, you didnt give the model enough context to know better the system after following spec driven development, works with LLM in large code base make it so much easier than without it like its heaven and hell differences but also it increase in token cost exponentially, so there's that

hoppp 1y ago

I used it with Tyopescript and Go, SQL, Rust Using it with rust is just horrible imho. Lots and lots of errors, I cant wait to stop this rust project already. But the project itself is quite complex Go on the other hand is super productive, mainly because the language is already very simple. I can move 2x fast Typescript is fine, I use it for react components and it will do animations Im lazy to do... SQL and postgresql is fine, I can do it without it also, I just dont like to write stored functions cuz of the boilerplatey syntax, a little speed up saves me from carpal tunnel

epolanski 1y ago

I really find your experience strikingly different than mine, I'll share you my flow: - step A: ask AI to write a featureA-requirements.md file at the root of the project, I give it a general description for the task, then have it ask me as many questions as possible to refine user stories and requirements. It generally comes up with a dozen or more of questions, of which multiples I would've not thought about and found out much later. Time: between 5 and 40 minutes. It's very detailed. - step B: after we refine the requirements (functional and non functional) we write together a todo plan as featureA-todo.md. I refine the plan again, this is generally shorter than the requirements and I'm generally done in less than 10 minutes. - step C: implementation phase. Again the AI does most of the job, I correct it at each edit and point flaws. Are there cases where I would've done that faster? Maybe. I can still jump in the editor and do the changes I want. This step in general includes comprehensive tests for all the requirements and edge cases we have found in step A, both functional, integration and E2Es. This really varies but it is generally highly tied to the quality of phase A and B. It can be as little as few minutes (especially true when we indeed come up with the most effective plan) and as much as few hours. - step D: documentation and PR description. With all of this context (in requirements and todos) at this point updating any relevant documentation and writing the PR description is a very short experiment. In all of that: I have textual files with precise coding style guidelines, comprehensive readmes to give precise context, etc that get referenced in the context. Bottom line: you might be doing something profoundly wrong, because in my case, all of this planning, requirements gathering, testing, documenting etc is pushing me to deliver a much higher quality engineering work.

mcintyre1994 1y ago
You’d probably like Kiro, it seems to be built specifically for this sort of spec-driven development.
- epolanski 1y ago
  How would it be better than what I'm doing with Claude?