I’m an experienced SSE and I’m about to hunt for a new job for the first time in a few years. I’ve so far been able to avoid most AI use, with the exception of testing out some code completion with copilot a couple years ago.

Basically every job listing I’m seeing expects some level of AI adoption (“we’ll set you up with either Claude or Copilot, so much choice!”) so I figured it’s time.

What’s the best way to get an intro to these tools? I’m curious how people are actually using them in their workflows successfully. I want to give it a fair shake and form my first-hand opinion on these things as tools.

EDIT: I’d also like to hear from those downvoting this post.

  • e0qdk@reddthat.com
    7·
    3 days ago

    I can’t give you much advice about Claude or Copilot since I refuse to use either, but I do use open weight models which I can run on my own hardware.

    If you’re interested in exploring LLMs from that angle, download llama.cpp and some models that’ll fit on whatever hardware you’ve got and start poking at it. I got started a few months back, and it’s been an interesting experience. llama-server (which is one of the tools that comes with llama.cpp) includes a web UI. You can also use llama-cli on the command-line (but that gets old pretty quick).

    Gemma and Qwen are the two most popular open weight model families right now since they’re small enough to run on local hardware and give good enough results that they can be useful.

    I’ve found them to be useful for:

    • debugging assistance (e.g. Qwen often points out typos I’ve made in Python scripts that would’ve taken me a while to find otherwise)
    • brainstorming (think: interactive rubber ducky you can bounce ideas off of – set a system prompt telling it NOT to give you code though unless you explicitly ask for it for this use case; they’re too eager to write code otherwise)
    • OCR
    • natural language to JSON data extraction (e.g. here’s an email, here’s a reference table, here’s an example of what I want, extract the data from the email into similar JSON…)
    • prototyping web UIs (e.g. here’s the HTML skeleton for [insert project here], write CSS to style it; here’s a screenshot of how it looks now, fix the bug that causes [issue] in the CSS; iterate)
    • light scripting (e.g. straightforward but tedious tasks that can be handled by a ~100 line or less Python script)
    • quick search/snippet generation for things that I would’ve done by Googling for a link to documentation/stackoverflow a few years ago – this works well enough for webdev questions; YMMV with other subjects
    • answering questions based on reference data buried somewhere in a PDF

    If you try to do batch processing with them, it’s helpful to think about them like a flaky distributed system – i.e. use timeouts, retries, error handling mechanisms that account for invalid output, etc.

    • IceFoxX@lemmy.world
      3·
      2 days ago

      llama/SD/whisper.cpp > lemonade ai ( For comfortable changing between models ) > openwebui/opencode/gaia ai i like this setup (Lemonade ai also comes bundled with llama/sd/whisper.cpp, but I still use my own installations. ) (Although I tend to rely on comfyui for sd.cpp stuff)

    • treadful@lemmy.zipOPEnglish
      4·
      3 days ago

      Thanks for the response.

      llama-server (which is one of the tools that comes with llama.cpp) includes a web UI. You can also use llama-cli on the command-line (but that gets old pretty quick).

      Will check it out. Also came across opencode which is like a TUI for dozens of models, which seems interesting.

      debugging assistance

      Are you just using it like a chatbot in this situation? Like as a rubber ducky like you mentioned? And just paste code into the prompt?

      here’s a screenshot of how it looks now

      How are you giving it things like binary files? Does it actually understand them? Is that a feature of only certain models?

      • e0qdk@reddthat.com
        5·
        3 days ago

        Are you just using it like a chatbot in this situation?

        For short snippets, I usually just paste the code in (e.g. using triple backticks to indicate a codeblock with Markdown if I want distinguish it clearly from other text in my prompt). It’s also possible to drag-and-drop files into the web UI that ships with llama-server, and I also have some of my own custom tooling.

        How are you giving it things like binary files? Does it actually understand them? Is that a feature of only certain models?

        Vision Language Models can work with images. Both Qwen and Gemma can do it. In the web UI, you can just drag and drop images in and they’ll be added as attachments that get processed along with your prompt text. There’s limits to what they can understand – I recommend experimenting with them to get a sense of it – but for things like OCR, they just do it…

        I’ve also implemented handling for passing images into models via code if you’re curious about that as well – basically you just add the file as base64 encoded data in the JSON structure that you POST to the server.

        llama-server’s web UI can process PDFs too, but I’m not sure on what it does for that exactly under the hood.

        • treadful@lemmy.zipOPEnglish
          3·
          3 days ago

          Neat that markdown helps.

          I also have some of my own custom tooling.

          Not asking you to share code or anything, but would you mind explaining some thing(s) you’ve created to help you?

          Thanks again for the responses. They’ve been super helpful.

          • e0qdk@reddthat.com
            4·
            3 days ago

            OK, so there’s a few things I’ve built. First, I want to clarify that there’s the concept of a “tool call” in LLMs. i.e. the LLM generates a specific sort of response which is intended to be interpreted as a request to run a function (either in llama-server [if you enable that] or in your client). The LLM needs to be provided with a list of the tools that are supported (including the name of the tool, the description, and arguments) for it to know that it can call them.

            Basically, you send a prompt, the LLM “thinks” for a bit, it spits out a tool call as the response, the client code sees the tool call, runs the appropriate function, then submits the result back as another prompt to the LLM and it continues on generating a response.

            I’ve built custom tools (in my own custom client) for accessing limited parts of my file system in a particular read only fashion. (I do not trust these things to write to my disk autonomously…)

            For example, I have a find_files tool that LLMs can call with a project name (which I need to provide – restricted to a few specific locations based on a config file) and which basically runs a listdir and returns the results as JSON to the LLM. I also have a read_source_code tool that allows specifying a project and a file and it will return the text of that file.

            This is technically redundant with features that are available out-of-the-box in llama-server but I’d rather run llama-server locked down in a container and provide it access with no more than I want it to have from code I control.

            The custom client I wrote includes my own web UI (which is simpler than the one that comes out of the box with llama-server but is tailored to my specific tastes), and the code to run those custom tool calls. The first pass was also my first serious experiment with vibe coding; I wrote a very simple skeleton by hand and then iterated on it allowing the LLM to write most of the code so I could see what that process was like and how it would go wrong. As you might expect, that turned into a complete mess and I scrapped and rewrote pretty much the whole whole thing after a few weeks, but it was quite educational!