if this is all ultimately java but with even more steps, its a sign im definitely getting old. it’s just the same pattern of non technical people deceiving themselves into believing they dont need to be technical to build tech and then ultimately resulting in again 10-20 years of re-learning the painful lessons of that.

let me off this train too im tired already

The AI already generated comprehensive README.md files and detailed module/function/variable (as needed) doc comments, which you could read but end up mostly being consumed by another AI, so you can just tell it what you're trying to do and ask it how you might accomplish that in the codebase, first at a conceptual level, then in code once you feel comfortable enough with the system to be able to validate the work.

All the while you're sitting next to another coworker who's also doing the same thing, while you talk about high level architecture stuff, make jokes, and generally have a good time. Shit, I don't even mind open offices as much as I used to, because you don't need that intense focus to get into a groove to produce code quickly like you did when manually writing it, so you can actually have conversations with an entire table of coworkers and still be super productive.

No comment on the political/climate side of this timeline, but the AI part is pretty good when you master it.

It would be helpful if I had a long rambling dialogue with a chat model and it distilled that.

They aren't all Joe Rogan.

I'd caution against using devstral on a 24 gb vram budget. Heavy quantisation (the only way to make it fit into 24gb) will affect it a lot. Lots of reports on locallama about subpar results, especially from kv cache quant.

We've had good experiences with running it fp8 and full cache, but going lower than that will impact the quality a lot.

It's got 7 fingers? Looks fine to me! - AI

So the process becomes: Read PR -> Find fundamental issues -> Update prompt to guide agent better -> Re-run agent.

Then your job becomes proof-reading and editing specification documents for changes, reviewing the result of the agent trying to implement that spec, and then iterating on it until it is good enough. This comes from the belief that better, more expensive, agents will usually produce better code than 5 cheaper agents running in parallel with some LLM judge to choose between or combine their outputs.

In the end, you either concede control over 'details' and just trust the output or you spend the effort and validate results manually. Not saying either is bad.

How do you interact with your projects?

Commands for working with copies of your entire repo in a new folder on a new branch

https://git-scm.com/docs/git-worktree

git worktree add new/path/for/worktree branchname

I now refuse to use git checkout to switch branches, always keep my main branch checked out and updated and always use worktrees to work on features. Love this workflow!

Moral of the story: I found out that I didn't constrain them enough. I now insist that they keep the core logic to a certain size (e.g. 300 lines) and not produce code objects for each concept but rather "fold them into the code".

This improved the output tremendously.

The open source world is one where antirez, working on his own off in Sicily, could create a project like Redis and then watch it snowball as people all over got involved.

Needing a subscription to something only a large company can provide makes me unhappy.

We'll see if "can be run locally" models for more specific tasks like coding will become a thing, I guess.

What does this mean?

Obsidian is my source of truth and Claude is really good at managing text, formatting, markdown, JS, etc. I never let it make changes automatically, I don't trust it that much yet, but it has undoubtedly saved me hours of manual fiddling with plugins and formatting alone.

The kind of person who prefers this setup wants to read (and write) the least amount of code on their own. So their ideal workflow is one where they get to make programs through natural language. Making codebases understandable for this group is mostly a waste of effort.

It's a wild twist of fate that programming languages were intended to make programming friendly to humans, and now humans don't want to read them at all. Code is becoming just an intermediary artifact useless to machines, which can instead write machine code directly.

I wish someone could put this genie back in the bottle.

Having a thing that is interactive and which can answer questions is a very useful thing. A slide deck that sits around for the next person is probably not that great, I agree. But if you desperately want a slide deck, then an agent like Claude which can create it on demand is pretty good. If you want summaries of changes over time, or to know "what's the overall approach at a jargon-filled but still overview level explanation of how feature/behavior X is implemented?", an agent can generate a mediocre (but probably serviceable) answer to any of those by reading the repo. That's an amazing swiss-army knife to have in your pocket.

I really used to be a hater, and I really did not trust it, but just using the thing has left me unable to deny its utility.

<laughs in legacy code>

And fundamentally, that isn't a function of "capital". All code bases are shaped by the implicit assumptions of their writers. If there's a fundamental mismatch or gap between reader and writer assumptions, it won't be readable.

LLMs are a way to make (some of) these implict assumptions more legible. They're not a panacea, but the idea of "just make it more understandable" is not viable. It's on par with "you don't need debuggers, just don't write bugs"

Seniors' attitudes on HN are often quick to dismiss AI assisted coding as something that can't replace the hard-earned experience and skill they've built up during their careers. Well maybe, maybe not. Senior devs can get a bit myopic in their specializations. Whereas a junior Dev doesn't have so much baggage, maybe the fertile brains of youth are better in times of rapid disruption where extreme flexibility of thought is the killer skill.

Or maybe the whole senior/junior thing is a red herring and pure coding and tech skills are being deflated all across the board. Perhaps what is needed now is an entirely new skill set that we're only just starting to grasp.

Oh, it's worse than that. You do that, and they complain that they are underpaid and should earn much, much more. They also think they are great, it's just you, the old-timer, that "doesn't get it". You invest lots of time to work with them, train them, and teach them how to work with your codebase.

And then they quit because the company next door offered them slightly more money and the job was easier, too.

I hope you don't think that what you're paying for an LLM today is what it actually costs to run the LLM. You're paying a small fraction.

So much investment money is being pumped into AI that it's going to make the 2000 dot-com bubble burst look tiny in comparison, if LLMs don't start actually returning on the massive investments. People are waking up to the realities of what an LLM can and can't do, and it's turning out to not be the genie in the bottle that a lot of hype was suggesting. Same as crypto.

The tech world needs a hype machine and "AI" is the current darling. Movie streaming was once in the spotlight too. "AI" will get old pretty soon if it can't stop "hallucinating". Trust me I would know if a junior dev is hallucinating and if they actually are then I can choose another one that won't and will actually become a great software developer. I have no such hope for LLMs based on my experiences with them so far.

Hmm no news about that really

I don't really get this, at the beginning of my career I masquaraded as a senior dev with experience as fast as I could until it was laundered into actual experience

Form the LLC and that's your prior professional experience, working for it

I felt I needed to do that and that was way before generative AI, like at least a decade

Try telling that to companies with quarterly earnings. Very few resist the urge to optimize for the short term.

My M.S. advisor gave me this advice on when I should ask for help, which I've passed on to lots of junior engineers: It's good to spend type struggling to understand something, and depending on the project it's probably good to exert yourself on your own somewhere between an hour and a day. If you give up after 5 minutes, you won't learn, but if you spend a week with no progress, that's also not good.

When/if the underlying model gets good enough to support that pattern. As an extreme example, you aren't ever going to make even a basic agent with GPT-3 as the base model, the juice isn't worth the squeeze.

Models have gotten way better and I'm now convinced (new data -> new opinion) that they are a major win for coding, but they still need a lot, a lot of handholding, left to their own devices they just make a mess.

The underlying capabilities of the model are the entire ballgame, the "use patterns" aren't exactly rocket science.

It's entirely possible for a world changing tech to be created and steered to match a unique problem inside one country, and for that to change job markets everywhere.