To me, the thing that stands out about the whole state we're in here is PR review.<p>Yes, in an ideal world, PRs read well, are a joy to review, reflect what you discussed etc etc. We have to be real; there is only so much we can do to that end.<p>I'm not sure how the best teams do PR review, from my perspective it <i>sucks</i>. I'm talking specifically about the UX. I've always hated Github's PR page, so I typically reviewed by pulling down the branch and opening the diff with $EDITOR.<p>These days I think there's really no excuse for the awful UX. Linear (a company that isn't even in the domain of code review) put out a basic PR review feature[0] that is already better than what GH offers. It's simple: point a small model at the PR, group file changes together based on theme, add some commentary and sort by importance (schema changes > openapi spec).<p>Immediately, so much mental load has been reduced without the reviewer or the requester doing anything. This feature is pretty damn basic, and I think there are obvious next steps like generating visualisations which a dedicated product could find the time to implement.<p>Keen to hear others thoughts on why this is the wrong approach, or if there are tools in wide use that solve for this, or why this isnt the right problem to focus on.<p>0 - <a href="https://linear.app/docs/diffs#guides" rel="nofollow">https://linear.app/docs/diffs#guides</a>
blablabla. it reads like self-advertisement and paraphrasing of LeCun's argument.
Not sure what the guy has built himself with AI that went to production, probably not much.
Necessarily, better data is what we need, more importantly, better collaboration and better specialization at all. While the title is a bit misleading and clickbait-y, the message is decent.<p>I disagree with the way that big models are trained on noisy relationships and RL is applied to tone it back down, it represents a stupid amount of compute thrown at this problem at a scale that is often unnecessary.<p>The rest of it is on point.
This is one of the best writeups I've seen of this<p>a lot of the model's constraints come down to how they are RLed. Discussions online would be a lot better if everyone understood how the labs train the models in a high level (or did a lil data labeling)
Wait these arent “software factories” they are strung together ai rube goldburg machines<p>Its crazy to me people write these articles and create standards like this is some kind of engineering standard with years of research and experience<p>This is like calling these folks the experts on aviation: <a href="https://youtu.be/M9Yww9LG3gw?is=xgtA-xMpNy-09Asu" rel="nofollow">https://youtu.be/M9Yww9LG3gw?is=xgtA-xMpNy-09Asu</a><p>Its still so early in the game for de facto standards - engineering teams need to experiment and see what works for their own quality metrics not just parrot “standards and methodologies”<p>This is still the very early days of AI and AI engineering
Dex you aren't part of the slop cannon, you _are_ the slop cannon
<i>> I haven't been able to dig up any definitive data/findings from StrongDM on how that whole dark factory went. The weather-report has a few sparse updates between February and June of this year.</i><p>This was easy to find out I thought. And just with an old-fashioned google search too, no deep research agent needed. See here: <a href="https://diffusion.io/" rel="nofollow">https://diffusion.io/</a><p>Seems like it went pretty well if a consulting company is now being started.<p>I agree with a lot of what Dex Horthy is saying here but on some fronts I feel like he's missing something. Coding well with LLMs, it's not a skill issue, it's an effort/laziness/rigor issue.<p>In order for coding with LLMs to go well, there has to be <i>more</i> rigor, <i>more</i> discipline, <i>more</i> good engineering hard-assedness. To reiterate, the teams seeing the best results with AI were <i>already</i> high-discipline and high-hygiene.<p>AI works on data. The better the data, the better the likelihood of a desirable outcome. Code is data. If you have bad code, no matter how awesome the model you let loose on it, you can't get as good a result as if you had good code to start with. This principle has been well known in AI/ML circles since the 20th century.<p>e.g., if you are doing spec driven development and not seriously investigating formal verification, IMHO you will come up short. Prompts are simply not enough to steer a coding agent to the level of precision needed. Without deep programmatic verification - at all levels, formal verification is just one slice - the solutions the agent produces will always be just slightly (or very) out of true.
Some more context on the consulting company: StrongDM was sold earlier this year, about a year after the dark factory was first announced, and the former CTO moved on to this (presumably) in order to continue the idea.<p>Disclaimer: I'm a former StrongDM employee
“Seems like it went pretty well if a consulting company is now being started.”<p>You interpreted this backwards. Software companies offer consulting when their product cannot stand on its own. See Palantir, Salesforce, etc.<p>They are successful companies, yes, but not successful products. The product needs to be instantiated and maintained by sales engineers and consultants and customized into something so bespoke that it’s hardly the company’s product anymore.
> Prompts are simply not enough to steer a coding agent to the level of precision needed. Without deep programmatic verification - at all levels, formal verification is just one slice - the solutions the agent produces will always be just slightly (or very) out of true.<p>I found this to be exactly right, and in my work I’ve come up with a taxonomy of constraint mechanisms which I keep in mind when guiding agents: generative to constrain the output of the model, interpretive to constrain how the model ‘understands’ code, and elicitative to help it ask the right questions of users.<p>Full write up is here: <a href="https://www.research.autodesk.com/blog/constrain-agent-not-user/" rel="nofollow">https://www.research.autodesk.com/blog/constrain-agent-not-u...</a>