If you could wish for a codebase, which codebase would you wish for?
If you think a second on that question, you’ll realize you probably not wishing for a super feature-rich one, but an easy to understand one, quite close to what you have now. One that is easily to maintain and extend, depending on the upcoming business challenges.
> Code bases that you "work in" (maintain, etc) solve real world problems, and solving those problems should trump cleanliness every time
Only if you value your time more than the users’ time and your fellow developer time. Code are run and read more than they are written. You may need to do some hacky coding, but they should be small in scope, surrounded by warning, and have a ticket filed for properly resolving the issue. Otherwise, it’s not worth it.
Outside of opensource developers do not suggest what code is written.
Sales does.
If the developers say something like "well this will take 3 weeks longer to do correctly". They'll be replaced by the code monkey that can turn a POC over to the customer in 3 days.
You must have worked in some pretty dysfunctional organizations. Nobody just says "it will take 3 weeks longer to do correctly" - they'll say "if we skip X, then it will potentially result in Y; or we can do Z which will take a little longer but will not have this potential business risk".
You gotta use the language that folks speak in order to get your point across.
> “well this will take 3 weeks longer to do correctly".
Well, I haven’t met any experienced developers that say this sentence. It’s career suicide in most cases. More often, an agreement about scope and delivery is reached and workload gets reshuffled. Customer battling with POCs to get their tasks done are soon to be ex-customers.
The swindle goes like this, AI on a good codebase can build a lot of features, you think it’s faster it even seems safer and more accurate on times, especially in domains you don’t know everything about.
This goes in for a while whilst the codebase gets bigger and exploration takes longer and failure rate increases. You don’t want it to be true and try harder so you only stop after it practically became impossible to make any changes.
You look at the code again and there is so much code spaghetti is an understatement it’s the Chinese wall.
You start working…, and you realize what was going on
I deleted 75,000 of 140,000 lines of code and I honestly feel like the 3 months I went hard into agentic coding I wasted and I failed my users by building useless features increasing bugs, losing the mental model of my code and not finding the problems I didn’t know about the kind of hard decisions you only see when you in the code, the stuff that wanders in your mind for days
I find it interesting that this outcome is a surprise. I don't want this to sound smug, I'm genuinely curious what the initial expectations are and where they come from.
They seem to be different for LLMs, because would anyone be surprised if they handed summary feature descriptions to some random "developer" you've ever only met online, and got back an absolute dung pile of half-broken implementation?
For some reason, people seem to expect miracles from some machine that they would not expect of other humans, especially not ones with a proven penchant for rambling hallucinations every once in a while.
I'd like to know, ideally from people who've been there, why they think that is. Where does the trust come from?
LLMs do deliver "miracles", in certain cases, if you've experienced it and have been blown away by their output (one shot functional app from a well manufactured prompt, new feature added flawlessly on a complicated existing codebase, etc.), it can be tempting to reajust your expectations and think this will work consistently and at a much larger scale.
They can assimilate 100s of thousands of tokens of context in few seconds/minutes and do exceptional pattern matching beyond what any human can do, that's a main factor in why it looks like "miracles" to us. When a model actually solves a long standing issue that was never addressed due to a lack of funding/time/knowledge, it does feel miraculous and when you are exposed to this a couple of times it's easy to give them more trust, just like you would trust someone who provided you a helping hand a couple of times more than at total stranger.
I suppose it's difficult to account for the inconsistency of something able to perform up to standard (and fast!) at one time, but then lose the plot in subtle or not-so-subtle ways the next.
We're wired to see and treat this machine as a human and therefore are tempted to trust it as if it were a human who demonstrated proficiency. Then we're surprised when the machine fails to behave like one.
I have to say, I'm still flabbergasted by the willingness to check out completely and not even keep on top of, and a mental model of, what gets produced. But the mind is easily tempted into laziness, I presume, especially when the fun part of thinking gets outsourced, and only the less fun work of checking is left. At least that's what makes the difference for me between coding and reviewing. One is considerably more interesting than the other, much less similar than they should be, given that they both should require gaining a similar understanding of the code.
I've never relied on an LLM to build a large section of code but I can see why people might think it is worth a try. It is incredible for finding issues in the code that I write, arguably its best use-case. When I let it write a function on its own, it is often perfect and maybe even more concise and idiomatic than I would have been able to produce. It is natural to extrapolate and believe that whatever intelligence drives those results would also be able to handle much more.
It is surprising how bad it is at taking the lead given how effective it is with a much more limited prompt, particularly if you buy in to all the hype that it can take the place of human intelligence. It is capable of applying a incredible amount of knowledge while having virtually no real understanding of the problem.
I think I was sold the full agentic coding hype all over the internet. You give it a try and it does write a feature really fast. Impressed you test the boundaries more and more and before you know it this has become your new workflow. Breaking free of this again is harder than you'd think even when you do realize what a mess is generated in the process.
Receiving an absolute dung pile of half-broken implementation is honestly what I expect from most working software engineers. Now the step where they spend even a second thinking about what they are doing has been removed. My job as a principle engineer became doing most of the thinking for people and then providing the only worthwhile code reviews before LLMs became a thing. LLMs just made these people even less useful and my job became even more about reviewing their low quality work that I could have done in less time manually.
LLMs also don't solve the much bigger problem of most software engineers having no ability to work with others to clarify requests or offer alternatives. So now bad and/or misunderstood requests can be implemented faster.
Probably same reason people expected outsourcing to the cheapest firm in India would work: wishful thinking. People wanted it to work and therefore deluded themselves.
Or really the same reason people fall for get rich quick schemes.
> You look at the code again and there is so much code spaghetti is an understatement it’s the Chinese wall.
I don't understand this. A large codebase should be a collection of small codebases, just like a large city is a collection of small cities. There is a map and you zoom into your local area and work within that scope. You don't need to know every detail of NYC to get a cup of coffee.
Its your responsibility to build a sane architecture that is maintainable. AI doesn't prevent you from doing that, and in fact it can help you do so if you hold the tool correctly.
To use your analogy - there's a big difference between the streets of New York and the streets of Boston. In New York if you know you're on 96th and 3rd, then you automatically know how to get to 101st and 5th - it's just a grid. But not every town is like that - many require you to possess knowledge about specific streets and specific landmarks in order to navigate anywhere.
To speak more directly - every codebase has local reasoning and global reasoning. When looking at a single piece of code that's well-isolated, you can fully understand its behavior "locally" without knowing anything about any other part of the code. But when a piece of code is tightly coupled to many other parts of the codebase, you have to reason globally - you have to understand the whole system to even understand what that one piece of code is doing, because it has tendrils touching the whole system. That's typically what we call spaghetti code.
If you leave an AI to its own devices, it will happily "punch holes", and create shortcuts, through your architecture to implement a specific feature, not caring about what that does to the comprehensibility of the system.
I don't think that's a useful mental model for software in general.
There are software that works like this (e.g. a website's unrelated pages and their logic), but in general composing simple functions can result in vastly non-proportional complexity. (The usual example is having a simple loop, and a simple conditional, where you can easily encode Goldbach or Collatz)
E.g. you write a runtime with a garbage collector and a JIT compiler. What is your map? You can't really zoom in on the district for the GC, because on every other street there you have a portal opening to another street on the JIT district, which have portals to the ISS where you don't even have gravity.
And if you think this might be a contrived example and not everyone is writing JIT-ted runtimes, something like a banking app with special logging requirements (cross cutting concerns) sits somewhere between these two extremes.
The GC shouldn't care about all the code it is collecting. I collects garbage, it doesn't care if the garbage is a intermediate value from your tax calculations, or the the previous state image from your UI - either way it is garbage and it is gone. Now in a few cases details of garbage collection matter by enough that it is worth something more invasive for some reason, but the vast majority of code shouldn't care about the other areas.
When on a tiny project it doesn't matter. However when you have millions of lines of code you have to trust that your code works in isolation without knowing the details.
I don't get your comment. The GC is part of the runtime, to it user code is data. But the JIT compiler and other internal details of the runtime are its code, and there are very real cross-cutting concerns, like the JIT compilers output should take into account what memory representation the GC expects, where are barriers, when one is run etc. So I'm talking about a project such as the JVM.
> have millions of lines of code you have to trust that your code works in isolation without knowing the details.
More like hope. This is where good design and architecture helps, as well as strong invariants held up by the language. But given that most applications can't really escape global state (not even internally, let alone external state like the file system), you can never really know that your code will work the way you expect it to - that is, it's not trivially composable to any depth.
I don't work in that area, but I strongly suspect that they do their best to confine the interactions to small places if that is possible. Maybe not though.
They absolutely do their best, but this is not possible in the general case. And as I said, it's also true to a smaller degree for banking and other software as well, but is not even software-specific. A plane also can't be engineered layer-by-layer, component-by-component - there has to be an oversight of the whole, otherwise it won't fly.
> A large codebase should be a collection of small codebases, just like a large city is a collection of small cities.
Oh, great analogy there.
Just like there's almost nothing in common between a large city and a collection of small cities, a large codebase is completely different from a collection of small codebases too.
It's not that you can't "build a sane architecture" as much as it is difficult to justify the time spent to do this when you can "bang out features" in 10 minutes that would take days to do manually. It's about the economics of code generation. When inventing structure and typing it out as code takes time, thinking deeply about architecture first makes sense. There is another factor, as well: "thinking deeply about the architecture" involves experimentation. You might go down a particular path while coding, and then realize some limitations and/or new ideas, etc. You ultimately craft something that will work well and play well with future code, and which may be easily understood. If somebody stops by your desk and says, "you finish that <3 day feature you were just assigned 2 hours ago> yet?", that'll be the last time you think deeply about anything at work.
Rather than arguing about the specifics, it's easier to point to numerous concrete examples, such as a fairly simple system - which should be easy to implement in 8-15k lines of code, depending on certain choices (I've been writing code long enough to estimate this relatively accurately) - being still-incomplete while approaching 150k lines. These kinds of atrocities are usually economically infeasible in hand-written code, for 2 reasons: 1) the cost to produce that much code is very high, and 2) the cost of maintaining that much code is insurmountable.
I guess you could say that AI is great at generating code that only AI can understand and maintain.
I think this is true, but i imagine there's a workflow solution to this which isnt to drop AI.
Eg., treating AI code generated as immediately legacy, with tight encapsulation boundaries, well-defined interfaces etc. And integrating in a more manual workflow.
There's a range from single-shot prompts to inline code generation, that will make more sense depending on the problem and where in the code base it is.
Single-shot stuff is going to make more sense for a protyping phase with extensive spec iteration. Once that prototype is in place, you then prob want to drop down into per-module/per-file generation, and be more systematic -- always maintaining a reasonably good mental model at this layer.
That workflow just sounds exhausting to me. Would I always need to consider how much of a blast radius my AI-generated code might have? Sounds like there’s so much extra management going into these micro decisions that it ultimately defeats the purpose of generating code altogether.
I could see value in using it during the prototyping phase, but wouldn’t like to work like you described for a serious project for end users.
And you have discovered the job of managers! There has always been a lot of hate for managers. Wonder if the robots hate us just as much? (I often feel a weird guilt when I tell an agent to do something I know I am going to throw away but will serve as an interesting exploration...I know if I did that to a human they would be pissed...)
IMO the hate has always been for clueless managers, especially clueless yet demanding managers. Managing an LLM for coding is different, try being clueless and demanding and see how far you get.
So you think "good" management translates? I actually think it very much does. Clear expectations, providing right context and "the why", quick and clear feedback loops, intervening early when they are going off track, not micromanaging too much so they can actually accomplish more. It's all very similar.
Yes it very much does but managing humans is still very different.
Understanding your domain, setting clear expectations and understanding limitations and how much ambiguity your people/robots can handle are all good management techniques, they translate.
But the nature of working with an always-on flattery machine vs humans that can exceed your expectations while also being sources of infinite drama and frustration are still fundamentally different. The blind spot is being subsceptible to the flattery machine and forgetting how much you relied on good people challenging you. The benefit is, of course, not having to deal with humans.
I just don't like to type code anymore. If I can accomplish the same by describing the code, and get the same results as if I typed it myself, I'll opt for not typing so damn much. I've done so much typing in my career, that typing ~80% less to get the same results, makes a pretty big difference in how likely I am to set out to accomplish something.
I care more about code quality now, because typing no longer limits if I feel like it's worth to refactor something or not.
> treating AI code generated as immediately legacy, with tight encapsulation boundaries, well-defined interfaces etc.
This is good advice regardless whether you're using AI or not, yet in real life "let's have well-defined boundaries and interfaces" always loses against "let's keep having meetings for years and then ducttape whatever works once the situation gets urgent".
There comes a realization, to many engineer’s horror, that AI won’t be able to save them and they will have to manually comprehend and possibly write a ton of code by hand to fix major issues, all while upper management is breathing down their back furious as to why the product has become a piece of shit and customers are leaving to competitors.
The engineers who sink further into denial thrash around with AI, hoping they are a few prompts or orchestrations away from everything be fixed again.
But the solution doesn’t come. They realize there is nothing they can do. It’s over.
Were you auto-committing everything without reading the generated code? and if you read it but didn't understand it why not just ask for detailed comments for each output? Knowing that a larger codebase causes it to struggle means the output needs to be increasingly scrutinized as it becomes more complex.
I don’t think it’s about what the code does. I think it’s more about how the code fits in its whole context. How useful it is in solving the overarching problem (of the whole software). How well does it follow the paradigm of the platform and the codebase.
You can have very good diffs and then found that the whole codebase is a collection of slightly disjointed parts.
I haven't had the chance to work on large codebases, but isn't it possible to somehow adapt the workflow of Working Effectively with Legacy Code, building islands of higher quality code, using the AI to help reconstruct developer intention and business rules and building seams and unit tests for the target modules?
AI doesn't necessarily have to increase your throughput, it can also serve as a flexible exploration and refactoring tool that will support either later hand crafter code or agentic implementation.
Yep. I’m approaching the same problem from a different angle: writing code fast means you aren’t being thoughtful about the features you’re building. I started realizing that after I had kids and spent more time thinking about code than writing it and it really improved the quality of my work: https://bower.sh/thinking-slow-writing-fast
Obviously this is all my fault and others might have a better jugdement when using it. I’m just sharing my experience compared to the promises you easily might believe reading X/HN/Anthropic.
I still have a lot of usage for AI: Exploration, Double-checking me, teaching me. But writing code became very tough for me to accept. Nex-edit autocompletes mainly
> I still have a lot of usage for AI: Exploration, Double-checking me, teaching me.
I'm ready to give up on having it even review my code at this point. It's been so frustrating. It hallucinates bugs, especially in places where "best practices" are at odds with reality.
Recently it informed me of a bug where it suggested the line of code in question couldn't possibly do anything because on Linux the specific stdlib behaved in X ways, but it was obvious from the line of code that it was running on Windows which doesn't have this problem at all. Of course, it doesn't actually mention that this is an issue on Linux, just that there is a bug here. It vomits up a paragraph of $WORDS explaining why this was a high-priority bug that absolutely needed to be fixed because it was failing in subtle ways. Yet the line of code in question has been running in production, producing exactly the results it is expected to, for ~3 years.
And this is just one simple example, of the many dozens+ of times it has failed this task this year. In that same review run, the agent suggested 3 additional "bugs" or other issues that should be addressed that were all flatly wrong or subjective. I'm at a point of absolute exhaustion with this sort of shit. It's worse than a junior half of the time because of how strongly opinionated it is. And the solution to this sort of problem is an endless amount of configuration and customization that will be forgotten about by all of us over time, leading to who knows what sort of knock-on effects (especially as we migrate from one model to the next). We have a guy on our team who has ~17,000 words in his agent and instructions files, yet he sees nothing wrong with this. I guess he just really loves YAML and Markdown.
Completely unbased, but I don’t want to have to do anything with bun anymore. It’s just a gut feeling, but I don’t trust them and support them.
They fork Zig to utilize LLM rewrites and build something the Zig team clearly disregarded (non-deterministic compiling)
And now like a whiny baby they LLM rewrite to Rust. There is a very real chance that Zig design philosophy got them to the point where they are now by enforcing to make the tough but precise decisions and the Rust rewrite is the start of the downfall.
It’s purely politics-based not technical, but it seems like bun is full on pampered by Claude. So much that I wouldn’t wonder that the next marketing piece of Anthropic is. Claude Mythos rewrote leading 950k LOC JS Runtime to Rust.
Yeah I also noticed this irony. In addition to accusing the rewrite to being political and not technical, while their whole comment is being political not technical.
Ah, fair enough then, you mean want to clarify that a bit as it can be interpreted both ways. And the whiny baby part seems a bit uncalled for and distracting from the point you’re trying to make.
Don't give them too much credit, they responded to other comments clearly referring to the developers' comments on twitter about his technical motivations. He's just backtracking now due to your comment.
I meant the developers motivation with "whiny baby" and I take the point that this was over the top and I could’ve found better words.
But I meant that my comment is "politics-based and not technical", because the gut feeling is more based on my reading of soft factors than it is from in-depth technical analysis of everything involved.
How can you be so blind? This is all a marketing campaign by anthropic. No more no less. The developers doing the rewrite have no voice at all in this game.
I'm team Zig in most cases but I genuinely think they are better off with Rust. They have had a lot of buffer overruns and segfaults as a result of undisciplined Zig code. I think Rust actually is a better technical choice for them.
I don't think that's going to save them. There are big problems and little problems. RAII+ownership/borrowing solves some memory and file handle issues. But the big problem and this happened before the rewrite, is that they have ceded the system level. Which locks the project into a local minima.
It's not a "your holding it wrong" problem it's a you fundamentally have no idea how your own program works past 1 or 2 level of indentation in most places. If the LLM says that something isn't possible you just have to take it at it's word.
> I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues
There are legit reasons to rewrite a program in a better fitting language, but as a runtime to be "tired of worrying about & spending lots of time fixing memory leaks and crashes and stability" is really borderline to me.
Also there are way more things to it than just compile time and tests: you reset mental model and will lose contributers. There is philosophy, developer skill and more attached to a language.
In this case both compile via LLVM the same and there is no performance benefit given the code is written exactly the same, so it’s developer preference, where the current head seemed to prioritize his own DX over everyone else’s.
I'm not sure if the 50% of people defending the whole rewrite live under a rock with regard to the acquisition or have never worked at a US company or a deliberately naive. Companies give instructions. Nothing of this is accidental or prompted by curiosity.
I agree. From the get-go, Bun was apparent in its design philosophy: we do everything you'd ever want; runtime, bundler, test suite, package manager, all in a new breaking patch each week. With each and every one blowing the established competition out, better, faster and stronger. But it was glaringly obvious that they'd do anything but Keep It Simple Stupid. It was obvious that the only production environment it would see the light of the day in the near future would be YC startups burning one after another at the speed of an accelerant. Now, they're past the point of no return.
I mentioned a similar sentiment 4 days ago in the original discussion about this project, and HN for some reason did not like that I noted Rust is used in production longer and way more than Zig is, including Firefox, CloudFlare's own reverse proxy, Discord, and many other massive effort projects that affect millions if not billions of people.
People are seriously naive about corporate incentives. You think he'll go "Yeah, it being in Zig has put a wrench in our AI usage and that's not a good look now that we're with Anthropic"? No, he'll confirm everyone's biases instead - and it's working as well as expected on this crowd.
I don't have the personal investment that you appear to have with Bun, but why does this matter? Do you scrutinize the rest of your dependencies this way?
Much of working in the JS / NPM ecosystem is already pure faith on un-vetted dependencies, and this appears no different pre or post LLM rewrite. If it satisfies the intended goal and API contract it originally did, is there any difference? Were you carefully reading the original source code before?
Enough to make judgement calls on them based on the individual Twitter posts of each of their developers? Absolutely not!
If I go beyond the initial vetting, that's a minimum of 30+ projects multiplied by however many contributors each. Without even mentioning all of their sub dependencies. It's a pipe dream to think you can ever have a complete picture of the motivations and political machinations of your entire dependency tree.
I have definitely dropped dependencies from production codebases in the past because "lead developer is widely known to be a clown". You don't need to catch everything but it's generally a good idea to have a picture of, like, the twenty most important dependencies in your codebase and the 90th percentile most notorious clowns in the community.
What is your definition of "known to be a clown"? I'm not sure how one would even begin to evaluate that at scale. Or what practical impact that would actually have for anything but the most critical of dependencies that might be too difficult to swap at will.
Hyperbole, yeah, but top 10% undesirable leads is literally thousands of people?
I couldn't imagine following the communities of even the top ten dependencies of one of our (many) projects very deeply. Every single one of them is having divisive conversations in threads like this all the time that never really lead anywhere or sum up to anything meaningful.
Sure, but you need to consider that, in this case we are talking about the language runtime. It isn't just some other library dep. It's basically the base layer of the stack. It has a huge blast radius. It is, imo, a nontrivial decision to swap runtimes. If problems emerge you can't easily plug some other runtime, that's a major technical decision and should be treated as such.
In the past at least you could assume the maintainers of the runtime had some kind of mental model of how it worked. In my view, with the way this rewrite has been approached, you can't assume that at all. It's good the test suite passes, but who knows how this will affect the evolution of the codebase? Do we even know if the code is good? How much is just slop? Tests do not test architecture. Is this new rewrite even going to be maintainable? How is the team going to get up to speed on a new codebase in a new language that the main author presumably doesn't even fully understand?
There are many reasons to be concerned. Treating this as no big deal would make me question one's ability to make assessments of technology. There's a world of difference between relying on gen AI heavily in products and leaf nodes of the stack, using it in a purely assistive way, and using it to drive a massive scale rewrite of a base component in a language the maintains team has an unproven amount of experience with. From a reliability standpoint the way this project was executed is completely preposterous, and it's very clearly a marketing stunt more than a sound technical decision on how to drive a project. It's not about the use of LLMs, it's about thee stupid and blatantly obvious generation of cognitive debt all to help sell claude. I'd have way fewer qualms if they used LLMs to do a rewrite in a way that retained developer understanding (i.e. not driven by one person and in such a short timespan that having a robust mental model, even for that person, is highly unlikely)
You're implying that reckless rewrites within the JS ecosystem are a novel event, or more specifically that surprise language changes over a short period of time are. And yet... I can think of at least six times in which exactly this has happened and little fuss was made because the polarizing element of "AI" was not involved. Not just JS to Typescript, but to Dart, Go, C, Rust, Zig, Nim etc.
From any reasonable perspective, this is business as usual in the house of cards we all operate in. Perhaps the sensationalization would be justified if the lang migration wasn't one of less correct -> enforced correctness by default?
To your point in general about maintainers holding a mental model of the runtime: I would challenge that to say that it is very likely that there is no developer who holds a complete mental model of an entire runtime at any given point. As with anything of this scale you understand individual parts in their entirety and have general assertions about the rest until specifically revisited, even if you are the sole developer. In this case specifically, Bun has been largely AI driven for quite a while anyway so it is even more unlikely that the developers ever had a complete picture in the first place. If you trusted them before, then nothing has changed.
It's not lost on me that code logic can be subtly incorrect even as tests are passing either, but there isn't exactly a lot of grey area in this particular context. Does your code compile or not? If it builds as expected, then your own unit tests will highlight the difference.
Anthropic bought it in a somewhat dumb attempt to solve their "performance" issues (not realizing their horrible code was the issue in the first place).
It probably helped them, simply because they brought in some actually competent developers.
But doing so, Bun went from being a public project to more of an internal tool for Anthropic, spoiled for now with AI money and losing quite a bit of focus.
Let's hope that when the bubble pops, some of the Bun effort could at least be salvaged. I don't see Anthropic maintaining it long term, they are simply not in the business of selling support for a runtime nor have the (Google) scale justifying maintaining one on the side.
Yep, the Anthropic acquisition, this petulant Rust rewrite, and bun's increasingly buggy releases (slop) have caused me to migrate my projects (personal and work) to nodejs+pnpm.
The risks of using bun are no longer just those concerns around a newer tech and "drop-in" replacement for nodejs. Now you have to marry Anthropic, Rust, and a founder with conflicting priorities.
How exactly will waiting a year or two make this effort appear “characterized by impatience and grumpy annoyance”, as opposed to the people right now who are loudly bemoaning an engineer trying something out as an experiment?
> It can take a whole day to find 10 good lines to write.
So we've come full circle to code writing speed being a factor again? :)
In all seriousness, this just feels like a never-ending list of attempts to try to resist any notion that LLMs might accelerate software development, however small the increment. The original article was arguing that organizational and collaboration was the bottleneck and that taking a whole day to think about the code was not.
And sometimes an LLM can find those 10 lines in 10 minutes. Or it can find a 100 and you cut them down to 10 in two hours total. Yes I've seen this in practice. The amount of code an LLM can tirelessly ingest is super human.
Twenty minutes ago Claude digested about a dozen pipeline definitions, a sequence of build files and targets, read the scripts they use, found the variable that I could reuse for my purposes, and made the appropriate change in the right (looking) place, so that I'd be able to achieve my goals.
I could not have done this nearly as quickly. On the other hand, I gave it clear, precise instructions.
The best code is no code. The second-best code is the code I delete.
My favorite JIRAs are the ones I prevent from being worked on in the first place because they were unnecessary.
The ideal prompt is the one I don't fire because it would be a waste.
In an application with an LLM component, the ideal amount of inference is zero.
Ultimately this seems to lead to "the ideal amount of computers in the world is none" but for the sake of my continued employment let's let that one go by. :)
You are speaking out of my soul. Thank you. Great example. I have grinded AI extensively 14 hours a day on my own project for months. I’ve been using AI since GPT-2.
I maxxed out Claude Max $200 subscription and before I justified spending $100/day.
And it was worth it, but not because it wrote me so good code, but because I learnt the lessons of software engineering fast. I had the exact ride you are describing. My software was incredible broken.
Now I see all the cracks, lies and "barking the wrong tree" issues clearly.
NOW i treat it as an untrustworyth search engine for domains I’m behind at. I also use predict next edit and auto-complete, but I don’t let AI do any edit on my codebase anymore.
I didn‘t yet have a good idea on how to utilize it, open to ideas.