I probably triggered some PTSD right there.

Was just in a meeting at work, where we listed off everything that makes software development hard and slow. An excersize for the thread would be to replicate that list. It turned out that Claude helps with like 1/5th or less of it....especially in a collaborative environment.

So, the situation we're now encountering is that random business areas can vibe code out something, tell nobody, throw it in AWS, have it become a critical part of a business process that fails when they quit, and nobody even has access to look at what was made.

It gives me comfort that in about 5 years there will be a new surge in demand for programmers to reign in all the rogue applications that need shutdown because of the immense risk to continual operation of a company, from data leaks to broken payroll.

It'll be Y2K all over again.

I've found myself replying to different people about the early 2025 METR study kind of often. So I thought I'd try posting a top level thread, consider it an unsolicitied public service announcement.

You might be familiar with the study because it has been showing up alongside discussions about AI and coding for about a year. It found that LLMs actually decreased developer productivity and so people love to use it to suggest that the whole AI coding thing is really a big lie and the people who think it makes them more productive are hallucinating.

Here's the thing about that study... No one seems to have even glanced at it!

First, it's from early 2025, they used Claude Sonnet 3.5 or 3.7. Those models are no way comparable to current gen coding agents. The commonly cited inflection point didn't happen until later in 2025 with, depending on who you ask, Sonnet 4.5 or Opus 4.5

The study was comprised of 16 people! If those 16 were even vaguely representative of the developer population at the time most of them wouldn't have had significant experience with LLMs for coding.

These are not tools that just work out of the box, especially back then. It takes time and experimentation, or instruction, to use them well.

It was cool that they did the study, trying to understand LLMs was a good idea. But it's not what anyone would consider a representative, or even well thought out, study. 16 people!

But wait! They did a follow up study later in 2025.

This time with about 60 people and newer models and tools. In that study they found the opposite effect, AI tools sped developers up (which is a shock to no one who has used these tools long enough to get a feel for them). They also mentioned:

However the true speedup could be much higher among the developers and tasks which are selected out of the experiment.

In addition they had some, kind of entertaining, issues:

Due to the severity of these selection effects, we are working on changes to the design of our study.

Back to the drawing board, because:

Recruitment and retention of developers has become more difficult. An increased share of developers say they would not want to do 50% of their work without AI, even though our study pays them $50/hour to work on tasks of their own choosing. Our study is thus systematically missing developers who have the most optimistic expectations about AI’s value.

And...

Developers have become more selective in which tasks they submit. When surveyed, 30% to 50% of developers told us that they were choosing not to submit some tasks because they did not want to do them without AI. This implies we are systematically missing tasks which have high expected uplift from AI.

And so...

Together, these effects make it likely that our estimate reported above is a lower-bound on the true productivity effects of AI on these developers.

[...]

Some developers were less likely to complete tasks that they submitted if they were assigned to the AI-disallowed condition. One developer did not complete any of the tasks that were assigned to the AI-disallowed condition.

[...]

Altogether, these issues make it challenging to interpret our central estimate, and we believe it is likely a bad proxy for the real productivity impact of AI tools on these developers.

So to summarize, the new study showed a productivity increase and they estimate it's larger than the ~20% increase the study found. Cheers to them for being honest about the issues they encountered. For my part I know for sure that the increase is significantly more than 20%. The caveat, though, is that is only true after you've had some experience with the tools.

The truth is that we don't need a study for this, any experienced engineer can readily see it for themselves and you can find them talking about it pretty much everywhere. It would be interesting, though, to see a well designed study that attempted to quantify how big the average productivity increase actually is.

For that the participants using AI would need to be experienced with it and allowed to use their existing setups.

I want to add that this is not an attempt to evangelize for AI. I find the tools useful but I'm not selling anything. I'm interested in them and I stay up to date on the conversations surrounding them and the underlying technology. I use them frequently both for my own projects and to help less technical people improve their business productivity.

Whether AI agents are a good thing or not, from a larger perspective, is a very different, and complicated, conversation. The important thing is that utility and impact are two different conversations. There isn't a debate anymore about utility.

I know this probably won't stop people from continuing to derail conversations with the claim that developers are wrong about utility, but I had to try. It's just hard to let it pass by when someone claims the sky is green.

I understand that AI makes people angry and I think they have good reason to be angry. There are a lot of aspects of the AI revolution that I'm not thrilled about. The hype foremost, the FOMO as part of the hype, the potential for increased wealth consolidation really sucks, though I lay that at the feet of systems that existed before LLMs came along.

It's messy, but let's consider giving the benefit of the doubt to professionals who say a tool works instead of claiming they're wrong. Let them enjoy it. We can still be angry at AI at the same time.

I'm currently 20 hours and 4 "episodes" deep into Death Stranding 2 on PC and I don't have the patience to wait til the Monday megathread rolls around again to voice my thoughts. This isn't my first time playing a Kojima game; I've got over 100 hours in the first Death Stranding and I've also finished multiple entries in the Metal Gear series, I've even played Boktai 2 on the GBA (though I didn't know that was a Kojima game til much later). I enjoy the vision, wackiness, flexibility in gameplay, and emphasis on little details that are fairly characteristic of a Kojima game, and those things are definitely very present in this one as well. That said though, there is one thing that only becomes more and more clear as I progress:

Hideo Kojima is terrible at writing dialogue. By that, I don't mean characters fail to express themselves or convey ideas well through a lack of words; rather, they're entirely too reliant on words. In an era of cinema that loves "show, don't tell", Kojima leans more towards "tell, tell, tell some more, and then maybe have a bit more tell as a treat". Any character with a backstory that Kojima wants you to know about will spend a good 10 minutes unloading their life story almost as soon as they meet the main character. Any time there's a new piece of information being revealed, someone will explain it to you in textbook-level depth. I'm not sure if Kojima thinks that it's ok to have so many incredibly long exposition-dumping cutscenes in his game because the ratio of cutscene to game is still fairly low but all I can say is these cutscenes and talking sequences are not good cinema. I don't care which movie star is getting a cameo when the script itself is this absurdly poor, my immersion is shattered and watching has now become a chore.

That said though, it's not like the game is devoid of cinematic moments, they just happen to be entirely outside of the cutscenes themselves. By far the most memorable and impactful moments in this game and the original are those times of solitude during a delivery where you're just quietly traversing through a zone, luggage in tow, and a Low Roar track starts playing. It's during these moments of calm, of pure show and no tell at all, where the player gets truly immersed in the role of the main character and has time to contemplate their journey while taking in the beauty of the nature around them. These aren't accidental or purely player-driven moments, those songs are set to play at a particular place during certain missions and knowing Kojima, he definitely had a major role in directing these as well. So it's not like he doesn't know how to create absolute cinema, but at the same time it's limited purely to gameplay moments where you're not forced to listen to someone deliver a 10 minute monologue in a way that no actual human being talks.

So yeah, thanks for not becoming a movie director, Kojima. Your script writing's terrible but your gameplay ideas are great. I'd suggest you hire an editorial team but you probably already have and ignore them.

Hey guys, I hope this is the right place to post.

So my adhd hyperfixation has recently shifted towards an idea for a game and I want to indulge my ADHD by learning all I can about game development to see if I can achieve this idea to the point that maybe I can put it in "Early Access" to fund even more resources on it.

But I'm not sure where to start. I'm looking into Godot because it's free and open source and has a lot of community resources, but also wanted to see if anyone had any ideas here.

I have some coding experience, a lot of technical experience and pick things up extremely quickly.

The basic idea is that it's a 2D Sidescrolling RPG, but with Match-3 "Candy Crush"-esque mechanics for battles and fighting.

Anyways, I'd love any advice or resources. Or if you'd like to help out or discuss the game idea more I'm up for that too.

I have a bare bones prototype of a game made in twine and I will be honest it needs a lot of work.

The story and main architecture of the game is already planned and I am happy with it. It is the story hooks and pathing that I am looking to improve and for that I would like to give out a early Alpha build for volunteers to critique and provide any dead ends, errors and story beats they find engaging.

Please feel free to send a message if you would like to participate. Thank you for your time.

Edit: Thank you for your interest in the game the final build should be ready for volunteers in one week. I will send links to you directly at that time. Thank you again for your interest this is much better than I hoped for.

I'm still a beginner at Godot. I've been playing with Godot and 3D scenes. It's great finally feeling comfortable enough to navigate the UI from watching the tutorials from Zenva/Humble Bundle.

Recently something that sounds straightforward took a long time for me to figure out: Fading in a 3D mesh. The solution is simple:

@onready var mesh: MeshInstance3D = find_child("body-mesh")

func _ready() -> void:
	_set_material_alpha(0)
	SomeSingleton.some_signal.connect(_fade_in)

func _set_material_alpha(alpha: float) -> void:
	var material: Material = mesh.get_active_material(0)
	if material is StandardMaterial3D:
		material.transparency = BaseMaterial3D.TRANSPARENCY_ALPHA_DEPTH_PRE_PASS
		material.depth_draw_mode = BaseMaterial3D.DEPTH_DRAW_ALWAYS
		material.albedo_color.a = alpha

func _fade_in() -> void:
	var tween = create_tween()
	tween.set_ease(Tween.EASE_IN)
	tween.tween_method(_set_material_alpha, 0.0, 1.0, fade_in_duration_seconds)

The key being setting the material properties and using its albedo color to update transparency. The depth draw mode is needed, otherwise the result is ugly with jagged pixels during the tween.

Getting to the solution was the hard part. Searching forum posts I was led down some rabbit holes like using shaders—overkill for this situation. (There is a cool site though, for when I do end up needing custom shaders: https://godotshaders.com/.) Asking an LLM also didn't help much, probably because my prompt was wrong. I tried again just now and it gave me something closer to a correct solution, but missing some parts like the depth draw mode, which (by trial-and-error and reading the docs) I found is necessary for a good quality render, when using transparency.

Another small pitfall I found was that trying to change the material.transparency caused stutter. I was trying to disable transparency when the mesh was at 100% alpha, since I figured opaque rendering is cheaper. However I speculate the engine recompiles the shader when I turn off transparency, which causes the stutter. So I don't modify the material.transparency beyond that initial setting.

Also thought I'd mention, I'm using free placeholder art assets from https://kenney.nl/ - an amazing resource.

Aside: Shaders

During this I learned that adding shaders to an imported 3D model in Godot is somewhat convoluted:

1. Import the .glb model
2. Clone the auto-created scene to an inherited scene, because I'm not allowed to directly edit that auto-created scene
3. Extract the material (UV colormap image) from the .glb by double-clicking it in the FileSystem tab
4. Apply the extracted material to the mesh under Surface Material Override
5. Add a "Next Pass" material, a ShaderMaterial, to that surface material override
6. Create the shader script
7. Pass in parameter values from the GDScript to the shader script using code like: shader_material.set_shader_parameter("color", Color(1.0, 1.0, 1.0, alpha))

This didn't work so well for me though, because the shader I was using was changing the ALBEDO and turning things white. If I knew anything about 3D programming I'd probably find a way to update the existing color value at each pixel, instead of setting albedo white everywhere. The end result of the shader I was using was that the models were turning too white. So that was a dead end.

Anyway mainly leaving this here as reference for posterity. Feel free to share a story or constructive feedback if there's anything.

Was there ever a write-up on why Tildes was architected the way it was? For example, why Pyramid instead of the usual suspects like Django or Flask? I'd be curious to read the reasoning from the developer(s) themselves.

I am really not sure if this topic belongs in ~tech or ~society or ~talk but I trust the moderators to re-assign accordingly.

So, this is the layout of the "development" team of my companies.

there are 4 "development" teams which reports to the development manager who also occasionally codes.
There is one team, that's the one I am on. 7 people, 6 males.
there is another team, 4 people, 3 males.
there is another team, 5 people, 4 males.
The last team, I don't really consider "development" team. its a team of 4 females. What they are best suited for is QA in the sense of manually testing the product to ensure the experience is sufficient for push to PROD, But because of budget restrictions, they are being forced to learn code and testing suites so they can be the people to develop our testing structure. They are great people and excellent Manual QAers but they really are not developers.

All our tech managers and team leads are men with the exception of the team lead for QA (obviously).

And just to be clear, the culture is friendly and respectful and no complaints. It's just the gender ratio is pathetic.

So our tech gender ratio is really 17 people and 3 women which is 17%.
If you want to consider the QA team a dev team to bump up the numbers, you get 21 with 7, that's still only 33%.

At a recent company meeting, they were talking about how diverse our workforce is and blah blah blah (I tune out most of that stuff as we are fully remote and I spend most of my time coding), but then they showed a slide that claimed our gender ratio for tech roles was like 50% or something.....

I message a colleague at work, being like "where on earth did they get that number??", he was like ":shrug: maybe they are counting the people who use the product we are making?"

To clarify that, the product we work on is rarely used by external customers. Instead we have employees who know how to use our product and correspond on our behalf with external customers. So all these employees are doing is using a webapp the real tech employees develop.

So long story short, my company pulled a number out of nowhere to claim we have gender equity in the tech roles and now I dont know how to trust any stats a company puts out about how equal the gender roles are in their "tech" departments.

A month ago I decided to take a look at Zed. It hasn't hit 1.0 yet so I wasn't sure if I'd like it. But I haven't opened any other code editors since the first launch. It's open source and seems to be cross-licensed with multiple free software licenses.

Beyond the nice GUI performance from their use of native code it's clear that my use of VSCode forks for the last few years has kept me held back. There are lots of little things I love about Zed like how you can edit code within the search results page. Or how you can use your own self-hosted LLM without the outrageous shenanigans required to do so with Cursor.