If it was a GPT wrapper, it wouldn't require an A100/H100 GPU; the container has a model wrapper, sure, but also it has the wrapped, standalone model, as well; its not calling OpenAI's model.
Canada "uncovered" fake colleges and worker scams only after it became socially acceptable to question official immigration policies. Now that the Indian government is literally murdering Canadian citizens, it's a become a huge issue.
I don't see I or any other developer would abandon their homebrew agent implementation for a "standard" which isn't actually a standard yet.
I also don't see any of that implementation as "boilerplate". Yes there's a lot of similar code being written right now but that's healthy co-evolution. If you have a look at the codebases for Langchain and other LLM toolkits you will realize that it's a smarter bet to just roll your own for now.
You've definitely identified the main hurdle facing LLM integration right now and it most definitely isn't a lack of standards. The issue is that the quality of raw LLM responses falls apart in pretty embarrassing ways. It's understood by now that better prompts cannot solve these problems. You need other error-checking systems as part of your pipeline.
The AI companies are interested in solving these problems but they're unable to. Probably because their business model works best if their system is just marginally better than their competitor.
Maybe. Sort of. Skill hints at the problem, but it's more of an experience issue. More experienced developers can give pretty reliable estimates for work they've already done. The catch is, how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it.
So where does that leave us? Well, developers who've seen a lot of different problems recognize when a new problem they see rhymes with a problem they've solved before. That can allow for a very good estimate. But even then, engineers tend to think in terms of best case, or maybe even typical case. I saw a study on this a few years ago, and it showed how often engineers tended to cluster around the median time for solutions. But, since really long tasks, with big error bars have a tendency to really skew timelines, the solution averages was much farther from these median times.
Believe it or not, lawyers have this problem too. They are taught in law school to come up with an estimate based on expected effort, then they apply a formula similar to: double the estimate, then increase the time units. So a 5 hour task becomes 10days. A 2 week task becomes 4 months. Mind you, this isn't the amount of billable hours they're predicting, it's the amount of calendar time that a given task will take until it's complete. This ends up taking into account a lot of variables that lawyers have no control over. Things like court scheduling, or communication delay. I suspect it also takes into account blind spots we humans have around time estimates in isolation. Like, 1 task, if you can focus on it can be done in so many hours. But if you have to do 5 similarly sized tasks, it takes more than 5 times as long, simply because it's easy to expend resources like brain power, and the estimate ignores the refractory periods necessary once the task is completed. (BTW this was one of the problems with the very first stop watch study in the rail yard, where the rail workers didn't work at their sustainable pace, but worked at their depletion pace).
> how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it
I heard someone summarize this as saying, a surgeon may perform the same surgery over and over for decades, while if a programmer does something more than a few times, it becomes an app (or library, etc).
In a sense, unless we are building the same thing we've built before, we are, by definition, always operating at the limit of our abilities.
Yes I think you're right about it being based on experience.
It's still a "skill issue" but it's more about knowing how long it will take you or your team. If you don't have the relevant experience with the tech or with the team, you can't really gauge how long something will take.
Before I estimate larger projects I always ask who will be on my team. The estimate is very different depending on the answer.
You're correct to a degree, but IME it's a discipline issue, not a skill issue as such.
What makes software hard to estimate is not so much the work, but how much requirements, priorities and resourcing change on the fly. I've worked in places that did quite strict scrum: once the sprint was planned and agreed to, we pushed back hard on our business area if they wanted to change anything. For practical reasons we didn't outright ban it, but for example, if they wanted something new done "right now" they had to choose something of roughly the same scope to be removed. If they couldn't do that, we'd cancel and re-plan the sprint. They hated having to make that choice, so most things just ended up at the top of the backlog for the next sprint.
The other part was our own management wanting to take people out of the team mid-sprint to work on something else. We never said no, but did say "this means we have to cancel and re-plan the sprint (and tell our business area)".
Basically, we made the people making the changes take responsibility for the impact on deadlines. Our estimates in that scenario were quite good (within the bounds of the sprint, at least).
Of course, the longer the estimation window the less well this works. The only way to estimate accurately is to constrain scope and resources, which is not actually what management/business want.
It's literally impossible to know what you don't know. Sometimes you discover things in the process of your work that couldn't have reasonably been accounted for on first estimate, and it is not good practice to always give an estimate that assumes a 5x difficulty multiplier for some unforeseen reason.
Yes, if this is an "every time experience" then there could be a skill issue or possibly some other undiagnosed or unrecognized systemic factor
When I cut open my ceiling to fix a plumbing issue I didn't know what I was going to find exactly, but I had a pretty good idea of the possibilities. My estimate for how long the fix would take was pretty close.
Software is the same thing. There are unknowns but there aren't unlimited possibilities.
It's a great analogy, but I think it's the kind of analogy that works on the surface and not in the details most of the time due to a) much more codification of practice in construction and b) more "fixed" knowledge of what's likely based on location and build era of the home, whereas software is much more dynamic and often subject to individual whims of developers or management.
If you're hiring architects and engineers to design and build your home, you might already have a pretty good idea of the home you want. The people you've hired provide estimates on cost and timing based on solidly known quantities. They've put in a basement like that before. They've worked with your weird materials. Their vendors report on material status daily.
Software development is not surrounded by this sort of infrastructure or codification. My discovery process establishes these lines of communication, and I have no idea when I'll uncover a black box or when one will be imposed upon me.
I guess I just don't buy that software is full of unknowns whereas construction is not.
Contractors have to plan for surprises as well. The thing is they've done enough similar work to understand the risks and account for them in budget and timelines.
I think a lot of software engineers, possibly because of the classical world they inhabit, are reluctant to look at things as probabilistic. Your estimate can take into account unknowns you just need to estimate the likeliness of encountering certain snags and the penalty they will impose.
You're framing the problem in terms of mathematical expected value (probability and penalty/reward), but the business environment in which software operates is fundamentally complex (see below).
There is a spectrum of complexity: simple, complicated, complex. These can be framed in terms of ergodicity and you can search for Barry O'Reilly residuality theory if you want to go down this rabbit hole.
In a simple system we can easily predict the future states based on knowledge of past states. In a complicated system, we can also predict future states based on past, but it requires expert knowledge, though it's still fundamentally able to be understood (e.g. SpaceX rockets). These are both ergodic systems. Complex systems are non-ergodic.
Construction is a complicated system that exists within a complicated environment.
Software is a complicated system that exists within a complex environment.
Complex environments can be wrangled along three dimensions: constraining the environment until we can treat it as "only complicated", evolutionary survivorship via random stress and remediation, and avoiding commoditization.
Construction benefits from all three. Environments are constrained to enable the things we build to operate (cars work mostly on paved roads). There is a history of evolutionary survivorship spanning millennia. And construction is less easily commoditized (people typically do the same thing they did yesterday, and repeat for decades). All of this contributes to the ability to a better ballpark estimate.
Software primarily only attempts to constrain the computing environment in which the software runs: If you build your app to run in a container that can tolerate getting yanked and reincarnated elsewhere, you're golden, i.e. cloud computing is an example of constraining a complex environment until it can be treated as "only complicated". But the business environment remains complex and largely unconstrained. We attempt to constrain it via "give us your requirements", but that's more of an anchoring or negotiating technique than actually addressing the complex business environment. Software doesn't have millennia of evolutionary battle testing. And software is more easily commoditized, meaning if you do the same thing you did yesterday on repeat, that turns into a library or an app, so fundamentally you're always being pushed into novel territory, which therefore is less battle tested by evolutionary survivorship. All of this contributes to less clear estimates in software.
No, it is a funding issue. Nobody wants to pay software engineers for actually doing prestudies to learn enough to do a proper estimate. They want a good estimate but do not want to pay for it.
Nonsense. Code is copy-pasteable; other things are not.
One can give very accurate estimates of how long it takes to build a brick wall because building brick walls takes time and labor. You can make highly accurate estimates of how long it takes based on how long it has taken to do the exact same task in the past.
But suppose I laid one brick and then could copy-paste it, then copy-paste that into four bricks, then eight, until I have a wall. Then I can copy-paste the entire wall. Once I have a building I can copy-paste the entire building in five seconds.
The ability to copy and paste an entire building is very valuable but how long does it take to create that copyable template? No one knows because it has never been done before.
Building brick walls is easy to estimate not because it is physical labor but because the company has done it many times before. Ask a construction company to estimate a unique one-off job and they will most likely fail. And that is despite them getting a lot of resources for investigating and planning which software engineers almost never get.
Is that a cause, though? I can see both as being consequences of the sheer amount of money sloshing around in the Silicon Valley. It generally helps things because there’s just so much resources to tap. It also helps employees getting poached with better salaries and compensation. But it does not mean that it can be replicated that way in another country.
You're right. It's not that disloyalty necessarily enables better software but that, apparently, loyalty is not a requirement.
It can also be true that the work culture in Japan stymies effective modern software development. I've heard anecdotes to this effect but it doesn't seem like something you could easily measure.
This seems like a really cool idea that would help with a scenario I encounter a lot with conflicts related to auto-formatting. Sometimes a small change can lead to a lot of whitespace changes below (in functional chains in js, for example).
Can this also detect some scenarios where semantic conflicts (but not line conflicts) arise, usually due to moved code?
I don't know the exact circumstances when this happens, but occasionally you can have e.g a function defined twice after two branches both move the same function elsewhere.
Funny how so many middle-aged tech workers, who were almost certainly using some primitive social media themselves as teenagers, are now in support of a full ban.
I don't like the outcomes we see with modern social media, but this feels like we're punishing the victim instead of the perpetrator.
Social media that tech workers in the 30s and 40s were exposed to was never any more intense than a bulletin board or a chat room.
Social media now is a very different beast. It's designed to be addictive, and it generates engagement through polarization.
Is banning social media for children a punishment for the child? Some parents would argue the opposite, that it's a good thing that the child isn't developed enough to realise yet.
> this feels like we're punishing the victim instead of the perpetrator.
Wouldn't placing the limits on the social media companies potentially prevent them for operating at a profit? I don't think you're wrong, but I question if you're not removing social media for child and teenagers regardless, the difference is if there will be social media for them to use later in life.
Banning social media for those under 16 (or 18) or killing off social media in general do to restrictions in how they operate doesn't really matter to me, even if the latter seems like a bigger win for society in general.
Social media was an interesting and at times fun experiment, but it might be time accept that it's not working out as we had hoped.
One big difference is that LiveJournal, Inc. weren't a parasitic company who sought to embrace addiction and analyzing the hell out of their users with algorithms. They had every chance to because the data about interests and friends were just as open as they are on other services - perhaps even more so - but they didn't.
I can't speak for the other big companies of the time, like MySpace and Xanga, because I never used them.
Same happened with the Drug War. The generation that spend their entire teenage years in the 60s in a haze of MJ smoke became the fiercest prohibition advocates during the 80s and 90s.
Actually this could be a really good analogy on many levels.
For example: Comparing the THC levels of the 60s to the THC levels today, and the potency social media of the 90s to the social media today seems appropriate. I mean one can only do so much social media over a slow modem on a home that has a single shared phone line.
> middle-aged tech workers, who were almost certainly using some primitive social media themselves as teenagers, are now in support of a full ban
How many people do that becasue they have thought about what they perhaps look back on posting on MySpace or Bebo or whatever and think "thank god that's disappeared from the internet"?
40-50 year olds did not grow up with social media. Myspace didn’t even exist when they were in high school.
People in their early to mid 30s had Facebook come into popularity during high school. I’d wager the majority of that age group would happily ban social media for children having experienced youth both with and without modern social media.
The Facebook we had back then was completely different than what it is today. 100% of the content on the page was contents directly created or shared by one of your friend. No suggested posts, no ads, no news, no "influencers", no politicians, no algorithm, no tracking, etc. Being invite-only at first also means everyone you see on the site are friends or friends of friends, no parents, no teachers, no cops, no media organizations, no companies, etc.
You would login and see what your friends were up to, in chronological order.
reply