lol looks like they are using a similar methodology to how we use Claude in house.

Honestly, the code we write with AI is cleaner, better documented, better factored, more maintainable, and less bugs than back in old days before code assistant agents. I think people must be just yoloing it, because it seems a lot like a holding it wrong type problem.

Documentation driven development is your friend.

▲ teravor 18 hours ago | parent | next [-]

with AI, documentation driven development is an understatement, if you take the time not just to document but to also provide lots of examples and potentially even data structures for the implementation (including intermediary data structures if you know them) the output is better than anything you would make in reasonable time.

▲ t-writescode 18 hours ago | parent [-]

If you have done or are doing all of that, why not just use the code you’ve made inside your docs?

Like, are you using languages where data structures are hard to write and/or work with? Typescript, Kotlin, Python and Ruby (via Sorbet or DryStruct) are all really easy to write all those data structures and code.

	▲	teravor 18 hours ago \| parent [-]
		what I meant was dictating the data structures for the code (transformations) the LLM is going to write. `"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."` in my workflow I typically prompt the LLM to carefully consider if the data schema I provided it is not sufficient for whatever task I gave it and to then argue for including additional members, with GPT 5.5 I took notice because of the arguments it provided me, it became clear to me that it's over. they have 130+ IQ. it's just a matter of constructing scaffolds now to have them express the intelligence because due to whatever quirks of training they can do stupid things.

▲ supern0va 19 hours ago | parent | prev | next [-]

Same here. Honestly, there's also a bunch of human friction that goes away. I can tell a junior that a change needs to be significantly refactored (or even thrown away entirely) without the psychological damage of discarding days/weeks of work from them.

Previously, I would need to do the trade-off calculation. How urgently does this need to ship, and do we have time to rework this? What are the deal breakers that need to be addressed, versus what things are best practice/ideal for maintainability? How did their last code review go and do they need a small win right now?

There's no more "nit" comments tagged as nits: just things to fix. It's de-personalized in the sense that we can both at least pretend/have plausible deniability and blame the model for being dumb, as opposed to the person making mistakes. I flat out told someone that a PR was not solving the right problem earlier, and neither of us thought it was a big deal. I could give the technical guidance and suggest a path forward to "help Claude understand better".

▲

dpark 19 hours ago | parent [-]

> It's de-personalized

I had an interesting conversation with a junior engineer who made this observation. She shipped a feature, we gathered data, and based on data we pivoted to a different design. She called out that she wasn’t attached to the code because AI wrote it. Not that she didn’t care about quality or effectiveness of the product, but the personal emotional attachment to the code itself was not there. Probably a healthy thing. I’ve seen senior engineers defend mediocre code because they wrote it and changing it was an ego hit.

▲

supern0va 14 hours ago | parent | next [-]

I have to admit that I'm curious why this is the case. I almost wonder if the pseudo-anthropomorphizing of these models is partially what helps here, similar to how I don't take it personally when I give instructions to a junior engineer and they fuck it up (though, I probably should to at least some degree more than I do).

	▲	dpark 12 hours ago \| parent [-]
		Probably something about the personal time and effort invested in a thing. I would feel much less personally invested if, for example, I created an outline of a story and then paid a ghostwriter to fill it in.

▲

ed_mercer 18 hours ago | parent | prev [-]

So then, why have the junior engineer in the first place?

	▲	supern0va 15 hours ago \| parent \| next [-]
		The same reason we had them before? A few juniors can be productive with oversight and guidance. Half the battle is learning what good work looks like, and figuring out what it is that you should even really be building, and those are skills you develop.
	▲	dpark 4 hours ago \| parent \| prev [-]
		This feels like you just have that retort in your pocket waiting to use it because it didn’t seem relevant here. What does this even mean? Why have the junior engineer if they aren’t irrationally invested in the code the write?

▲ surgical_fire 19 hours ago | parent | prev [-]

Yeah, that's how I've been using it.

Problem is that you can't do a FOMO-fueled hype IPO that gets a trillion dollars if your argument is "this is a tool that can improve the quality of work your employees output".

It needs to be a "we are building a doomsday weapon here, give me money" argument. Even if it is false. Especially if it is false.