221–230 of 234 posts
Earlier quoted context omitted.
Most of us work for business and on teams where performance matters.
You should not treat it as fact that "performance" of an individual, not a team is a thing that actually exists in any way that matters and is measurable.
It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around. Before 2025, the underperformers/coasters were at least relatively identifiable by the paucity of their contributions. Now all of the sudden every single engineer is filing PRs, code reviews, technical design documents, and every other artifact under…
There are also people who think AI is magic. I have often heard - "we want to use AI to automate processes but we don't have full documentation about the processes, we hope AI can help". Despite being told that no one can create outputs from thin air - every AI topic turns into the same discussion. Often the solution to create those document to feed into these AI automations? Use AI. Its like ouroboros. Create docs u…
1. add tools to be able to do the job 2. work through the process using the agent interactively many times 3. have an llm read back through the session histories to create the full agent definition 4. run it and review
works fairly well, and does use llms for most of the steps
Earlier quoted context omitted.
The under-performers and coasters just don’t read their code, in my experience thus far it’s been pretty transparent. PRs aren’t a perfect gate, but they’re one of the only ones we have right now, and it’s pretty clear who’s putting in the effort and who isn’t.
How is it clear though? It can be really hard to tell.
It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around. Before 2025, the underperformers/coasters were at least relatively identifiable by the paucity of their contributions. Now all of the sudden every single engineer is filing PRs, code reviews, technical design documents, and every other artifact under…
I think it depends a little on how and where you work. In the energy industry of Europe where we are extremely regulated AI has been writing some excellent and maintainable code. Of course we can't do any of that CLEAN SOLID DRY stuff, or any abstraction and implicity really, and I imagine that AI would struggle with that. Though you have to wonder if any of those religions ever really worked when you consider that t…
Until the bureaucrats start using AI to create a flood of new rules.
> Those are not code problems. They are evaluation problems. > Code becomes precious when it is the only place knowledge lives. Reading AI code all day is _agonizing_. Just, a horrible way to live, and it melts people's brains at the moment you need them to be the most capable. Manual programming has this really productive and gratifying feedback loop, where you read the code, write the code, and fix it until it comp…
"Reading AI code all day is _agonizing_. Just, a horrible way to live, and it melts people's brains at the moment you need them to be the most capable." I think it's very similar to dealing with large offshore teams. Every day you get a huge pile of code to review. It's really exhausting. I prefer dealing with AI because at least it tends to follow rules once I write them down. Not so much with a lot of offshore guys…
> What happened in 2025 was this: the economics of code production were turned upside down . Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight. I've been thinking about this a whole lot recently. So much of my int…
Except measuring the value of an individual piece of code is still very difficult if not impossible.
> It was reasonable to be skeptical the first time
It's still reasonable to be skeptical. A few weeks ago a post was discussed here on HN [1] that asked:
> What would have to be true for us to ‘check English into the repository’ instead of code?
to which I replied:
> Code is already the cheapest path to working, correct software. LLMs do not change the calculus because figuring out what to make is the expensive part, not coding it up. Skipping code makes the specification of what to make even more expensive and throws away the tools that keep precision affordable. Programming in English would be more expensive than just using a programming language. [2]
[1] https://annievella.com/posts/finding-comfort-in-the-uncertai...
[2] https://www.slater.dev/2026/05/why-english-will-never-be-a-p...
Earlier quoted context omitted.
"Reading AI code all day is _agonizing_. Just, a horrible way to live, and it melts people's brains at the moment you need them to be the most capable." I think it's very similar to dealing with large offshore teams. Every day you get a huge pile of code to review. It's really exhausting. I prefer dealing with AI because at least it tends to follow rules once I write them down. Not so much with a lot of offshore guys…
I do wonder what all this means for offshore development. What's the point of sending the work to another continent with different time zones and languages when your AI can do the same job directly.
AI can give you 80-90% of the quality, but the feedback loop is hours or days, not weeks.
This means the inevitable iteration of "no make that a bit greener, move that there, that is the wrong style for this scene" can be done faster, which means cheaper.
Earlier quoted context omitted.
I wonder if the reception is so variable due to differing exposure to 1) infra as code and 2) engineering teams that don't produce any artifacts outside of their code. > When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and w…
Talking to an LLM is often still a lower quality result than asking the lead engineer themselves or the collaborators they left behind. You're making a tradeoff between time taken and result quality. Even the most AI-positive teams prefer human discussion when things get that tough. Given enough time, things will "click" for humans. LLMs don't work that way. Even a team of all-new unfamiliar devs forced to study an o…
So if your whole process is "just ask the lead eng" and you keep hiring new people, everyone keeps asking the lead and the lead quits beause nobody wants to do that.
If you write shit down, the new hires can ask your company internal AI system that has access to all of the docs and get the answer - with direct links to official decision documents telling the "why".
At the very least the lead engineer should write the answers down every time they're asked something and reply with RTFM after that =)