How I program with LLMs

> That he says LLMs make him more productive at all as a hands-on developer, especially around first drafts on a new idea, means a lot to me personally.

There is likely to be a great rift in how very talented people look at sharper tools.

I've seen the same division pop up with CNC machines, 3d printers, IDEs and now LLMs.

If you are good at doing something, you might find the new tool's output to be sub-par over what you can achieve yourself, but often the lower quality output comes much faster than you can generate.

That causes the people who are deliberate & precise about their process to hate the new tool completely - expressing in the actual code (or paint, or marks on wood) is much better than trying to explain it in a less precise language in the middle of it. The only exception I've seen is that engineering folks often use a blueprint & refine it on paper.

There's a double translation overhead which is wasteful if you don't need it.

If you have dealt with a new hire while being the senior of the pair, there's that familiar feeling of wanting to grab their keyboard instead of explaining how to build that regex - being able to do more things than you can explain or just having a higher bandwidth pipe into the actual task is a common sign of mastery.

The incrementalists on the other hand, tend to love the new tool as they tend to build 6 different things before picking what works the best, slowly iterating towards what they had in mind in the first place.

I got into this profession simply because I could Ctrl-Z to the previous step much more easily than my then favourite chemical engineering goals. In Chemistry, if you get a step wrong, you go to the start & start over. Plus even when things work, yield is just a pain there (prove it first, then you scale up ingredients etc).

Just from the name of sketch.dev, it appears that this author is of the 'sketch first & refine' model where the new tool just speeds up that loop of infinite refinement.

I have also many years of programming experience and find myself strongly "accelerated" by LLMs when writing code. But, if you think at it, it makes sense that many seasoned programmers are using LLMs better. LLMs are a helpful tool, but also a hard-to-use tool, and in general it's fair to think that better programmers can do a better use of some assistant (human or otherwise): better understanding its strengths, identifying faster the good and bad output, providing better guidance to correct the approach...

Other than that, what correlates more strongly with the ability to use LLMs effectively is, I believe, language skills: the ability to describe problems very clearly. LLMs reply quality changes very significantly with the quality of the prompt. Experienced programmers that can also communicate effectively provide the model with many design hints, details where to focus, ..., basically escaping many local minima immediately.

> [David, Former staff engineer at Google ... CTO of Tailscale,] doesn't need LLMs. That he says LLMs make him more productive at all as a hands-on developer, especially around first drafts on a new idea, means a lot to me...

Don't doubt for a second the pedigree of founding engs at Tailscale, but David is careful to point out exactly why LLMs work for them (but might not for others):

   I am doing a particular kind of programming, product development, which could be roughly described as trying to bring programs to a user through a robust interface. That means I am building a lot, throwing away a lot, and bouncing around between environments. Some days I mostly write typescript, some days mostly Go. I spent a week in a C++ codebase last month exploring an idea, and just had an opportunity to learn the HTTP server-side events format. I am all over the place, constantly forgetting and relearning.

  If you spend more time proving your optimization of a cryptographic algorithm is not vulnerable to timing attacks than you do writing the code, I don't think any of my observations here are going to be useful to you.

That approach sounds similar to the Idris programming language with Type Driven Development. It starts by planning out the program structure with types and function signatures. Then the function implementation (aka holes) can be filled in after the function signatures and types are set.

I feel like this is a great approach for LLM assisted programming because things like types, function signatures, pre/post conditions, etc. give more clarity and guidance to the LLM. The more constraints that the LLM has to operate under, the less likely it is to get off track and be inconsistent.

I've taken a shot at doing some little projects for fun with this style of programming in TypeScript and it works pretty well. The programs are written in layers with the domain design, types, schema, and function contracts being figured out first (optionally with some LLM help). Then the function implementations can be figured out towards the end.

It might be fun to try Effect-TS for ADTs + contracts + compile time type validation. It seems like that locks down a lot of the details so it might be good for LLMs. It's fun to play around with different techniques and see what works!

I am not a genius but have a couple of decades experience and finally started using LLMs in anger in the last few weeks. I have to admit that when my free quota from GitHub Copilot ran out (I had already run out of Jetbrains AI as well!! Our company will start paying for some service as the trials have been very successful), I had a slight bad feeling as my experience was very similar to OP: it's really useful to get me started, and I can finish it much more easily from what the AI gives me than if I started from scratch. Sometimes it just fills in boilerplate, other times it actually tells me which functions to call on an unfamiliar API. And it turns out it's really good at generating tests, so it makes my testing more comprehensive as it's so much faster to just write them out (and refine a bit usually by hand). The chat almost completely replaced my StackOverflow queries, which saves me much time and anxiety (God forbid I have to ask something on SO as that's a time sink: if I just quickly type out something I am just asking to be obliterated by the "helpful" SO moderators... with the AI, I just barely type anything at all, leave it with typos and all, the AI still gets me!).

I have been using LLM to generate functional code from *pseudo-code* with excellent results. I am starting to experiment with UML diagrams, both with LLM and computer vision to actually generate code from UML diagrams; for example a simple activity diagram could be the prompt on LLM 's, and might look like:

Start -> Enter Credentials -> Validate -> [Valid] -> Welcome Message -> [Invalid] -> Error Message

Corresponding Code (Python Example):

class LoginSystem:

    def validate_credentials(self, username, password):
        if username == "admin" and password == "password":
            return True
        return False

    def login(self, username, password):
        if self.validate_credentials(username, password):
            return "Welcome!"
        else:
            return "Invalid credentials, please try again."

I think what you're describing is basically "interface driven development" and "test driven development" taken to the extreme: where the formal specification of an implementation is defined by the test suite. I suppose a cynic would say that's what you get if you left an AI alone in a room with Hyrum's Law.

> His post reminds me of an old idea I had of a language where all you wrote was function signatures and high-level control flow

Regardless of language, that's basically how you approach the design of a new large project - top down architecture first, then split the implementation into modules, design the major data types, write function signatures. By the time you are done what is left is basically the grunt work of implementing it all, which is the part that LLMs should be decent at, especially if the functions/methods are documented to level (input/output assertions as well as functionality) where it can also write good unit tests for them.

>> where all you wrote was function signatures and high-level control flow, and maybe some conformance tests around them

AIUI that’s where idris is headed

> designed around filling in the implementations for you. 20 years ago that would have been from a live online database

This reminds me a bit of PowerBuilder (or was it PowerDesigner?) from early 1990s. They sold it to SAP later, I was told it's still being used today.

Isn't that the idea behind UML? Which didn't work out so well, however, with the advent of LLMs today, I think that premise could work.

I knew he was a world-class engineer the moment I saw that his site didn't bother with CSS stylesheets, ads, pictures, or anything beyond a rudimentary layout.

The whole article page reads like a site from the '90s, written from scratch in HTML.

That's when I knew the article would go hard.

Substantive pieces don't need fluffy UIs - the idea takes the stage, not the window dressing.

he is using llm for coding. you don't become staff engineer by being a badass coder. Not sure how they are related.

[dead]

Being a dev at a large company is usually the sign that you're not very good though. And anyone can start a company with the right connections.

I think your biggest takeaway should be that they person writing the blog post is extremely well-known versed in programming and has labored over code for hours, along with writing tests, debugging, etc. He knows what he would like because it's second nature. He was able to get the best from the LLM because his vision of what the code should look like helped craft a solid prompt.

Newer people into programming might not have as good of a time because they may skip actually learning something fundamentals and rely on LLMs as a crutch. Nothing wrong with that, I suppose, but there might be at some point when everything goes up in smoke and the LLM is out of answers.

No amount of italic font is going to change that.

That seems like a wild restriction.

You can give them more latitude for things you know how to check.

I didn't know how to setup the right gnarly typescript generic type to solve my problem but I could easily verify it's correct.

That's the wrong approach.

I use chat for things I don't know how to do all the time. I might not know how to do it, but I sure know how to test that what I'm being told is correct. And as long as it's not, I iterate with the chat bot.

"Trust but verify" is still useful especially when you ask LLMs to do stuff you don't know. I've used LLMs to help me get started on tasks where I wasn't even sure of what a solution was. I would then inspect the code and review any relevant documentation to see if the proposed solution would work. This has been time consuming but I've learned a lot regardless.

I'd like to rephrase as, "don't deploy LLM generated code if you don't know how it works (or what it does)"

This means, it's okay to use LLM to try something new that you're on the fence about. Learn it and then once you've learned that concept or the idea, you can go ahead to use same code if it's good enough.

IMO this is a bad take. I use LLMs for things I don’t know how to do myself all the time. Now, I wouldn’t use one to write some new crypto functions because the risk associated with getting it wrong is huge, but if I need to write something like a wrapper around some cloud provider SDK that I’m unfamiliar with, it gets me 90% of the way there. It also is way more likely to know at least _some_ of the best practices where I’ll likely know none. Even for more complex things getting some working hello world examples from an LLM gives me way more threads to pull on and research than web searching ever has.

You can ask the LLM to teach it to you step by step, and then you can validate it by doing it as well as you go, still quicker than learning it and not knowing how to debug it.

Learning how something works is critical or it's far worse than technical debt.

How you use the LLM matters.

Having an LLM do something for you that you don't know how to do is asking for trouble. An expert likely can off load a few things they aren't all that important, but any junior is going to dig themselves into a significant hole with this technique.

But asking an LLM to help you learn how to do something is often an option. Can't one just learn it using other resources? Of course. LLMs shouldn't be a must have. If at any point you have to depend upon the LLM, that is a red flag. It should be a possible tool, used when it saves time, but swapped for other options when they make sense.

For an example, I had a library I was new to and asked copilot how to do some specific task. It gave me the options. I used this output to go to google and find the matching documentation and gave it a read. I then when back to copilot and wrote up my understanding of what the documentation said and checked to see if copilot had anything to add.

Could I have just read the entire documentation? That is an option, but one that costs more time to give deeper expertise. Sometimes that is the option to go with, but in this case having a more shallow knowledge to get a proof of concept thrown together fit my situation better.

Anyone just copying an AI's output and putting it in a PR without understanding what it does? That's asking for trouble and it will come back to bite them.

I completely agree. In graphics programming, I love having it do things that are annoying but easy to verify (like setting up frame buffers in WebGL). I also ask it do more ambitious things like implementing an algorithm in shader code, and it will sometimes give a result that is mostly correct but subtly wrong. I only have been able to catch those subtle errors because I know what to look for.

>>f you can look at the solution and immediately know what's wrong with it, they are a time saver otherwise...

Indeed getting good at writing code using LLMs demands being very good at reading code.

To that extent its more like blitz chess than autocomplete. You need to think and verify in trees as it goes.

> ... don't use them for anything you don't know how to do ... I find chat for search is really helpful (as the article states)

Not really. I often use Chat to understand codebases. Instead trying to navigate mature, large-ish FOSS projects (like say, the Android Run Time) by looking at it file by file, method by method, field by field (all to laborious), I just ask ... Copilot. It is way, way faster than I and are mostly directionally correct with its answers.

Exactly, you have to (vaguely) know what you’re looking for and have some basic ideas of what algorithms would work. AI is good at helping with syntax stuff but not really good at thinking.

Don't use them for anything you don't know how to test. If you can write unit tests you understand and it passes them all (or visually inspect/test a GUI it generated), you know it's doing well.

My experience is the opposite. I find them most valuable for helping me do things that would be extremely hard or impossible for me to figure out. To wit, I just used one to decode a pagination cursor format and write a function that takes a datetime and generates a valid cursor. Ain’t nobody got time for that.

I have a similar approach, but the mess can be contained by asking for optimizations and refactors very frequently and only asking for very granular features.

> The code can get messy quickly. There's often a lot of redundancy and after a few iterations it can be quite daunting to modify.

i forsee in the future an LLM that has sufficient context length for (automatic) refactoring and tech debt removal, by pasting large portions of these existing code in.

>The biggest downside, however, is the rapid accumulation of technical debt.

Is that really related to the LLM?

Even in pre-LLM times, anytime I've scrapped together some code to solve some small immediate problem it grows tech debt at an amazing rate. Getting a feel for when a piece of code is going to be around long enough that it needs to be refactored, cleaned up, documented, etc. is a skill I developed over time. Even now it isn't a prefect guess, as there is an ongoing tug of war between wasting time today refactoring something I might not touch again with wasting time tomorrow having to pick up something I didn't clean up.

> The biggest downside, however, is the rapid accumulation of technical debt. The code can get messy quickly. There's often a lot of redundancy and after a few iterations it can be quite daunting to modify.

What stops you from using o1 or sonnet to refactor everything? It sounds like a typical LLM task.

Is there a model you prefer to use?

There's an art to cost-effectively coaxing useful answers (useful drafts of code) from an LLM, and there's an art to noticing the most productive questions to put to that process. It's a totally different way of programming than having an LLM looking over your shoulder while you direct, function by function, type by type, the code you're designing.

If you feel like you're wasting your time, my bet is that you're either picking problems where there isn't enough value to negotiate with the LLM, or your expectations are too high. Crawshaw mentions this in his post: a lot of the value of this chat-driven style is that it very quickly gets you unstuck on a problem. Once you get to that point, you take over! You don't convince the LLM to build the final version you actually commit to your branch.

Generating unit test cases --- in particular, generating unit test cases that reconcile against unsophisticated, brute-force, easily-validated reference implementations of algorithms --- are a perfect example of where that cost/benefit can come out nicely.

My technique is to feed it a series of intro questions that prepare it for the final task. Chat the thing into a proper comfort level, and then from there, with the context at hand, ask to help solve the real problem. Def feels like a new kind of programming model because its still very programming-esque.

> "Chat-based LLMs do best with exam-style questions" really speaks to me, however I find that constructing my prompts in such a way where the LLM does what I want uses just as much brainpower as just programming the thing my self.

It speaks to me too because my mechanical writing style (as opposed to creative prose) could best be described as what I learned in high school AP English/Literature and the rest of the California education system. For whatever reason that writing style dominated the training data and LLMs just happens to be easy to use because I came out of the same education system as many of the people working at OpenAI/Anthropic.

I’ve had to stop using several generic turns of phrase like “in conclusion” because it made my writing look too much like ChatGPT.

I’ve found that everything just works (more or less) since switching to Cursor. Agent based composer mode is magical. Just give it a few files for context, and ask it to do what you want.

It's interesting that you find it useful for optimization. I've found that they're barely capable of anything more than shallow optimization in my stuff without significant direction.

What I find useful is that I can keep thinking at one abstraction level without hopping back and forth between algorithm and codegen. The chat is also a written artifact I can use the faster language parts of my brain on instead of the slower abstract thought parts.

The same way responsible enterprise class companies rely on "trust us bro" EULAs for financial systems, customer databases, payroll, and all the other systems it would be very expensive and error prone to build custom for every business.

Your company could locally host LLMs; you wont get chatGPT or Claude quality, but you can get something that would have been SOTA a year ago. You can vet the public inference codebases (they are only of moderate complexity), and you control your own firewalls.

The vast majority of fortune 500’s have legal frameworks up for dealing with internal AI use already because the reality is employees are going to use it regardless of internal policy. Assuming every employee will act in good faith just because a blanket AI ban is in place is extremely optimistic at best, and isn’t a good substitute for actual understanding.

What's the realistic attack scenario? Will Sam Altman steal your company's code? Or will next version of GPT learn on your secret sauce algorithms and then your competitors will get them when they generate code for their tasks and your company loses its competitive advantage?

I'm actually sure that there are companies for which these scenarios are very real. But I don't think there's a lot of them. Most of the code our industry works on has very little value outside of context of particular product and company.

So, you're asking how enterprise class companies are using github for repos and gmail for all the enterprise mail? What's next, zoom/teams for meetings?

Local LLMs for code aren't that out of the question to run.

Even for not code generation, but even smaller models only for programming to weigh on different design approaches, etc.

Does your company develop software overseas where legal action is difficult? Or where their ip could be nationalized or secretly stolen? Where network communications are monitored and saved?

> I’m not sure how a responsible enterprise class company could rely on “trust us bro” EULAs or repo readmes.

Isn't that what we do with operating systems, internet providers, &c. ?

Just curious, how does your company host its email? Documents? Files?

> proprietary code outside the network

Thought exercise: what would seriously happen if you did let some of your proprietary code outside your network? Oddly enough, 75% of the people writing code on HN probably have their companies code stored in GitHub. So there already is an inherent trust factor with GH/MSFT.

As another anecdote - Twitch's source code got leaked a few years back. Did Twitch lose business because of it?

You can run pretty decent models on your laptop these days. Works in airplane mode.

https://ollama.com/

Palo Alto networks provides security product "AI access security" which claims to solve the problem you mentioned - access control, data protection etc. I don't personally use it neither does my org. Giving here just in case it is useful for someone.

You can get models that run offline. The other risk is copyright/licensing exposure; e.g. the AI regurgitates a recognisably large chunk of GPL code, and suddenly you have a legal landmine in your project waiting to be discovered. There's no sane way for a reviewer to spot this situation in general.

You can ask a human to not do that, and there are various risks to them personally if they do so regardless. I'd like to see the AI providers take on some similar risks instead of disclaiming them in their EULAs before I trust them the way I might a human.

Seems like only working on open source code has its benefits.

I mean, we host our code on Github. What are they going to do with Copilot code snippets?

I found myself doing this with o1 recently for software architecture.

I will evaluate design ideas with the model, express concerns on trade-offs, ask for alternative ideas, etc.

Some of the benefit is having someone to talk to, but with proper framing it is surprisingly good at giving balanced takes.

The new video and screen-share capabilities in ChatGPT and Gemini should make rubber-ducking smoother.

I feel like I've worn out my computer’s clipboard and alt-tab keys at this stage of the LLM experience.

I'm an avg dev, I was never into LLMs/co-pilot etc mocking prompt engineering but... my current job is working with an LLM framework so idk... future proofs me I guess. I do like computer vision and ML on dataset eg. training hand writing IMU by gestures that's cool.

The embeddings I feel like there is something there even if it doesn't actually understand. My journey has just begun.

I scoff every time someone says "this + AI". AI is this thing they just throw in there. Last time I didn't want to work with some tech I quit my job was not a good move not being financially independent. Anyway yeah I'll keep digging into this. I still don't use co-pilot right now but I'm reading up more on the embedding stuff for cross training or some case like RAG.

I think there's a big selection bias on hackernews that you wouldn't get elsewhere. There's still "elite" software developers I see who really aren't into the whole LLM tooling space. I found use in the autocomplete and search workflows that the author mentioned but I stopped using these tools, out of curiosity for things were before. It turns out I don't need it to be productive and I too probably enjoy working more without it.

The autocomplete is mostly a nusance and maybe low percentage of the time it does right.

I had to turn autocomplete off. I value it when I want it, but otherwise it's such a distraction that it both slows me down, and actively irritates me.

Perhaps I'm just an old man telling the LLM to get off my lawn, but I find it does bad things to my ability to concentrate on hard things.

Having a good sense of when it would be useful, and invoking it on demand seems to be a decent enough middle ground for me. Much of it boils down to UX - if it could be present but not actively distracting, I'd probably be ok with it.

Both autocomplete and chat are half-way UX solutions. Really what I need is some kind of mix of in-place chat with completion.

For context, very often I have to put some comment before the line for completion to set an expectation context.

Instead editor should allow me to influence completion with some kind of in-place suggestion input available under keyboard shortcut. Then I could type what I want into such input and when I hit Enter or Tab the completion proposal appears. Even better if it would let me undo/modify such input, and have shortcuts like "show me different option", "go back to previous".

I’ve never used it, simply because I hate autocomplete in emails.

Gmail autocomplete saves me maybe 2-5s per email: the recipients name, a comma, and a sign off. Maybe a quarter or half sentence here or there, but never exactly what I would’ve typed.

In code bases, I’ve never seen the appeal. It’s only reliably good at stuff that I can easily find on Google. The savings are inconsequential at best, and negative at worst when it introduces hard-to-pinpoint bugs.

LLMS are incredible technology, but when applied to code, they act more like non-deterministic macros.

It's also available in emacs with packages like gptel which let you send the content of any buffer to your LLM of choice.

I think emacs + LLM is a killer feature: the integration is super deep, deeper than any IDE I've seen, and it's just available... everywhere! Any text in emacs is sendable to a LLM.

LLMs contexts are fast to overload, as the article states. That's why he writes smaller, specific packages, one at a time, and uses a web UI instead of something like cursor.

I had the same issue as you a few days ago. By separating the problem in smaller parts and addressing each parts one by one it got easier.

In your specific case I would try to fully complete the business logic one side. Reset the context. Then provide the logic to a new context and ask for an interface. Difficulty will arise when discovering that the logic is wrong or not suited to the UI, but i would keep using the same process to edit the code. Maybe two different contexts, one for logic, one for UI?

How did you do?

My first program ever was a windows calculator. My roomates would sit down and find bugs after I thought I perfected it. I learned so much spending weeks trying to get that damn thing working.

I'm not too optimistic about the future of software development if juniors are turning to AI to do those early projects for them.

Yeah, you wanna use Claude for code. That's the problem. Try Cursor or Bolt.

One of my tricks is to paste the docs right into the context so the model can’t fuck it up.

Though I still wonder if that means I’m only tricking myself into thinking the LLM is increasing my productivity.

I have found LLMs to be 95% useful on documented software, from everything eg Uniswap smart contracts to plugins in cordova to setting up Mac or Linux administrative tools.

The problem for a regular person is that you have to copypasye from chat. That is “the last mile”. For terminal commands that’s fine but for programming you need a tool to automate this.

Something like refactoring a function, given the entire context, etc. And it happening in the editor and you seeing a diff right away. The rest of the explanatory text should go next to the diff in a separate display.

I bet someone can make a VSCode extension that chats with an LLM and does exactly this. The LLM is told to provide all the sections labeled clearly (code, explanation) and the editor makes the diff.

Having said all that, good libraries that abstract away differences are far superior to writing code with an LLM. The only code that needs to be written is the interface and wiring up between the libraries.

If you don’t mind me asking: which popular LLM(s) have you been using for this and how are you providing the code base into the context window?

Aider commits to git with each command, making it easy to back out changes, and also squash them into discrete chunks later (and reorder them with interactive rebase).

I think the full agent mode context is actually often hard to see, but there’s a list somewhere. The list of files in your chat dialog is not the full context (it adds open files too). I find that if I reduce the context size Cursor gives me much better results.

3. New programming languages will face a big economical hurdle to take off.

I bet the opposite. I’ve written a number of DSLs and tooling around them over the last year as LLMs have allowed me to take on much bigger projects.

I expect we see an explosion of languages over the next decade.

That's why open research (which "open" ai has never really contributed to!) and foundational models that everyone can contribute to are essential.

This stuff is a pretty neat magical evolution and it should not be the domain of any single company.

Also a lot of the hardware and so on has/is being paid for. AWS gcloud, etc aren't taking massive losses on their H100 and other compute services. This bubble is no different than any prior bubble ultimately, and bankruptcy will recycle useful assets into new companies and new purposes.

Which btw why the US is still a huge winner and will continue to be -> robust and functioning bankruptcy laws and courts.

It's really bad, much less useful than even the first public version of chatgpt. Even once you manage to log in, most of the time it doesn't even give something that compiles, it calls functions/variables which don't exist. The first line of the main had 2 errors...

My codebase is relatively greenfield (started working on it early last year) but it’s up to ~50k lines in a mixed C++/Rust codebase with a binding layer whose API predates every LLM’s training sets. Even when I started ChatGPT/Claude weren’t very useful but now the project requires a completely different strategy when working with LLMs (it’s a QT AI desktop app so I’m dogfooding a lot). I’ve also used them in a larger codebase (~500k lines) and that also requires a different approach from the former. It feels a lot like the transition from managing 2 to 20 to 200 to 2000 people. It’s a different ballgame with each step change. A very well encapsulated code base of ~500k lines is manageable for small changes but not for refactoring, exploration, etc, at least until useful context sizes increase another order of magnitude (I keep trying Gemini’s 2M but it’s been a disappointment).

I have a lot of documentation aimed at the AI in `docs/notes/` (some of it written by an LLM but proofread before committing) and I instruct Cursor/Windsurf/Aider via their respective rules/config files to look at the documentation before doing anything. At some scale that initial context becomes just a directory listing & short description of everything in the notes folder, which eventually breaks down due to context size limits, either because I exceed the maximum length of the rules or the agent requires pulling in too much context for the change.

I’ve found that there’s actually an uncanny valley between greenfield projects where the model is free to make whatever assumptions it wants and brownfield projects where it’s possible to provide enough context from the existing codebase to get both API accuracy (hallucinations) and general patterns through few-shot examples. This became very obvious once I had enough examples of that binding layer. Even though I could include all of the documentation for the library, it didn’t work consistently until I had a variety of production examples to point it to.

Right now, I probably spend as much time writing each prompt as I do massaging the notes folder and rules every time I notice the model doing something wrong.

Logically this makes sense: every model has a context size and complexity capacity where it will no longer be able to function properly. Any usage of said model will accelerate the approach to this limit. Once the limit is reached, the LLM is no longer as helpful as it was.

I work on full blown legacy apps and needless to say I don't even bother with LLMs when working on these most of the time.

I used AI code completion from GitHub copilot on a 20 year old project. You still have to create new classes, new test, refactor etc.

Yes, it's just harder the larger the pre-existing code base.

Yeah, it sucks. LLMs are not great with a big context yet. I hope that is being worked on. I need the LLM to read my whole project AND optimally all related slack conversations, the wiki and related libraries.

I didn’t believe it could be so good until I actually used it. It’s a shame some of their models are proprietary because that means I can’t use it for work. Would love if the thing worked purely with Copilot Chat (like Zed does), or if Zed added a similar composer mode.

But you're not really writing python right? You're instructing a tool to generate python. Kinda like saying I'm writing bytecode while I'm actually just typing Java.

I would speculate that for learning unknown codebases, fine-tuning might work better than relying on context window size.

Love the token joke!

Google gets money from showing you ads, not because you pay them for quality search results.

When you have to come over and over, and visit more pages to finally find what you needed, they get much more cash from advertisers than when you get everything instantly.

Says who? I've been in the industry for nearly 25 years and have heard auto complete throughout but not once have I heard fill in the middle.

Stop taking these blogs as oracle's of truth, they are not. These AI articles are full of this nonsense, to the point where it would appear to me many responses might just be Nvidia bots or whatever.

Assuming I know roughly what it will generate, I usually prepend my chats with previsions against this kind of thing

"Add tabs here, assume the rest of the page will work with no futher modification, limit your changes so that any existing code keeps working"

I also do stuff like "Project is using {X} libraries, keep dependencies minimal

Generate a method takes {Z} parameters, return {Y}, using {A}, {B} and {C} do {thing}"

I'll add stuff like Language version, frameworks or specific requests based on this, but then I just reuse the setup , So I like to keep the first message with as much context as possible, ideally separating project context from specific request

Worth a look: https://github.com/feenkcom/gt4llm If you load this in GT, you'll get a Lepiter book with interactive tutorials.

Unless your network is poor, I’d imagine (but definitely could be wrong in your case!), the bottleneck is the LLM speed, not the latency to the data center its running in.

https://www.continue.dev/

I joke about once per month here that half of hn is basically "not invented here syndrome". And generally poor reimplementations of existing erlang features ;)

https://lovable.dev

https://bolt.new

https://v0.dev

Never used them myself but have seen them mentioned on Reddit and Twitter.

> LLMs are, at their core, search tools.

Fundamentally, no they're not. That is why you have cases like the Air Canada chatbot that told a user about a refund opportunity that didn't exist, or the lawyer in Mata v Avianca who cited a case that didn't exist. If you ask an LLM to search for something that doesn't exist, there's a decent chance it will hallucinate something into existence for you.

What LLMs are good at is effectively turning fuzzy search terms into non-fuzzy terms; they're also pretty good at taking some text and recasting into an extremely formulaic paradigm. In other words, turning unstructured text into something structured. The problem they have is that they don't have enough understanding of the world to do something useful that with structured representation that needs to be accurate.

> LLMs are, at their core, search tools.

This is the wrong take. Search tools are deterministic unless you purposely inject random weights into the ranking. With search tools, the same search query will always yield the same search result, provided they are designed too and/or the underlying data has not changed.

With LLMs, I can ask the exact same question and get a different response, even if the data has not changed.

Half of the problems are people treating them as searchers when they aren't. They're absolutely not ngram indexes of existing data, either.

I'm losing track of the number of different things the Hacker News commenters claim LLMs are "at their core".