fullstackchris

I'm building a full event sourcing framework for the IDE to help software creators (myself included) create educational software courses and lessons 100x faster! Hoping to launch the full product by summer:

https://codevideo.io

https://github.com/codevideo

looking at the paper some other agentic models they compared to were named LLaVA... maybe it's just a play on words

Congrats guys! Back in the spring of last year I did an initial spike investigating tools that could evaluate the accuracy of responses in our RAG queries where I work. We used your services (tests and test dashboard) as a little demo.

Baffling. If you're seriously saying package management for python "just works" and for go "always breaks"... I guess your either a troll, or you've never written production software. And I'm not talking some clever Jupiter notebooks used for some internal auditing or whatnot, I'm talking about customer facing software used by _at least_ 100 people. I'm 12 years in the game and Python has always caused me nothing but pain, while Go hasnt ever cost me a second of afterthought, working in multiple environments after nothing more than git clone. But, if you like making "virtual environments", a horrible shim gimmick which wasnt even supported by the language itself originally, be my guest!

Go look at httpclient for .NET core 4.8

I mean, just the star count on GitHub is enough to show what the developer community thinks.

Probably if you are fond of C# you wont like Go. I've always found C# incredibly verbose and full of all sorts of syntax sugar (that they add to yearly) making code everywhere look different, just enough to add a little cognitive overhead... Go on the otherhand, is purposefully opinionated and forces one more or less to write Go in a certain way.

In any node project that basically _must_ be done or your source code will be eclipsed by whatever is in node_modules

I've always thought on the contrary that "code smell" refers much more to the patterns used and not so much how it was formatted. Anyway, choosing a language that has automatic formatting (Go for example) renders about 80% of comments in this thread about "linting" and "formatting" and blah blah blah completely irrelevant.

I agree with what is discussed in this post a lot. Chat is indeed a lossy and at best q/a style system. Yes, of course it can be tweaked and hacked but it's ultimately the wrong UI if you want to leverage the most of AI for code.

However, even with a "docs as spec" pattern, how can you control the actual quality of the code written? How maintainable will it be? If the spec changes (read: it _will_ change constantly), is it easy enough to refactor? What about tests? I also shrink in fear at the complexity of docs that could be _exactly_ captured as code... "well we almost always do it this way, but this one time we do it this way..."

"We don't want a solution! We want to complain about what we are used to and dont have!"

So are you saying you would take on the initial cognitive load of Rust vs. Go for _every_ project?

I've been writing Go for about 5 years now and can confirm cicular dependency issues were typically handled buy a small refactor or considering where the borders of the domain should _really_ be

package main

import "fmt"

// Define an enumeration for status type Status int

const ( Pending Status = iota InProgress Completed Failed )

func (s Status) String() string { return [...]string{"Pending", "InProgress", "Completed", "Failed"}[s] }

func main() { var s Status = InProgress fmt.Println(s) // Output: InProgress }

I have no doubt open source will catch up (it already has, eh?) at the end of the day, it's just creative / new iterations on what is ultimately the transformer architecture... the amount of "secret" moat-like stuff that OpenAI was doing was bound to be figured out or exceeded eventually, like everything in tech...

Not to make fun of OpenAI and the great work they've done but it's kinda like if I went out in the 90s and said I'm going to found a company to have the best REST APIs. You can always found a successful tech company, but you can't found a successful tech company on a technological architecture or pattern alone.

So the conclusion is AI is about to "increase in abilities at an exponential rate", with the only data point being that R1 was sucessfully able to acheive o1 levels as an open source model? In other words, two extremely unrelated themes?

Does this guy know people were writing verbatim the same thing in like... 2021? Still always incredible to me the same repeated hype over and over rise to the surface. Oh well... old man gonna old man

A blend of both? Drop in a React component where needed on a given page! People forget (me included) that even React can be mounted into a single DOM element.

With all this framework nonsense its hard to forget at the end of the days its all just javascript.

Nitpick here: both models are still SaaS, the only difference is the first way was deployed via (desktop?) app and the second via web.

But indeed, web is typically the most flexible option unless you are leveraging something on the OS that would otherwise be cumbersom or impossible via web (not often the case)

I recommend you look at tools like Aider or Codebuff... sure they need to call some LLM at some point (could be your own, could be external), but the key thing that they are doing complex modifications of source code using things like treesitter -> i.e. you don't rely directly on the LLM modifying code, but the LLM using trees to modify the code. See in Aider's sourcecode: https://github.com/Aider-AI/aider/tree/main/aider/queries

Simple copy-pasting of "here's my prompt, give me code" was always doomed from the start to be perfect every time, and DEFINITELY won't work for an agent. We need to start thinking about how to use these LLMs in smarter ways (like the above mentioned tools)

But their _are_ some people who care. I've been busting my ass in the software world for over 10 years, documenting it as I go. Largely everything I give away for free, or at the very least offer a free tier. I cant control what other people do, but I can keep chugging along doing the best that _I_ can do.

Very clear; I like buying music produced by people who play instruments.

Not OP but yes. Electron size vs band gap, computing costs (in terms of electricity) any other raw materials needed for that energy, etc... sigh... its physics, always physics... what fundamental property of physics do you think would let a vertical take off in intelligence occur?

Sure but think of the Higgs... how long that took for just _one_ particle. You think an AGI, or even an ASI is going to make an experimental effort like that go any bit faster? Dream on!

It astounds me that people dont realize how much of this cutting edge science stuff literally does NOT happen overnight, and not even close to that; typically it takes on the order of decades!

Exactly. I continually fail to see how "the entire human economy ends" overnight with another human like agent out there - especially if its confined to a server in the first place - it can't even "go home" :)

Don't wanna be that typical hackernews guy but I couldnt resist... if your app is "quite complex" there is probably a way or ways you can break it down into much simpler parts. Easier for you AND the LLM. It always comes back to architecture and composition ;)

Dangerous? In the sense a bad API is dangerous? If so then I've been in danger consuming catastrophic APIs for at least a decade now

Fantastic post already by the first example. Meanwhile I can think of big brain developers who have laughed at me "because you assigned to a variable what you use once"... good luck with your career

This post is like an examplified grugbrain.dev

The ability to make strange videos as a consumer... it's not inherently good or bad, it'll just be... weird

I'm not talking about Go itself, I'm talking about building an API. All this talk of "string vs type" is not the solution to the root problem - sure, types can be better to return but what if the type changes? You still have breaking changes.

Sure... but this is why we have sem versioning and release notes. It's always nice to try and support all users but sometimes you just need to ship breaking changes...

> good actors

Aha... dont be naïve... what is the definition of "good" in 2024? Take the US population for example... 50% will say your intentions are "good", the other half will not!