stitched2gethr

I'm a bit torn. My first thought was "If the current state of the art LLMs made the mistakes it's unlikely an LLM would be able to correct them." But I'm not sure that's true if the support LLM (chat bot) is given very specific instructions so as to limit the possible answers. Still I think that's gonna break down pretty quick for other reasons.

Maybe the chat bot can recognize a botched request and even suggest a fix but what then? It certainly won't be able to convert the user's next request into a working application of even moderate complexity. And do you really want a chat bot to be the first interaction your customers have.

I think this is why we haven't seen these things take off outside of very large organizations who are looking to save money in exchange for making customers ask for a human when they need one.

I'm not saying you're wrong, but I get a whole lot done in 8 hours.

I'm a fan of Teenage Engineering. I think they make some really cool products but they have a few that really makes me wonder, who is this for?

Yes, but often density is at odds with readability.

If I may try to counter this point.

You are right, but there's ideal state and there's the real world. When on call most of my time is spent trying to make on call better. Reducing noise, providing more context when the alert and logs are lacking, and of course fixing the real issues that alerts have identified. That said there is a period of time in between receiving non-actionable alerts and classifying them as such, and more context without using brain power is always welcome. I think I'll give it a shot.

Interestingly enough much simpler models can write an accurate function to give you the answer.

I think it will be a while before we get there. An LLM can lookup knowledge but can't actually perform calculations itself, without some external processor.

Agreed. It feels like shared dependencies are akin to globals in your language of choice. Sharing dependency instances among components creates problems. A uses b and c, both of which want to use different versions of d. The simple answer, which is understandably difficult for existing languages to solve, is to just keep 2 copies of d.

In this case I think you're on the right path.

> The single most impactful technological choice when building payments is the programming language.

Got it. So why was Python chosen again? Call me crazy but I want things that touch my money to be rock solid.

I've found this is one case where LLMs are very helpful.

I would ask you to watch the demo on SoundHound.com. It does less, yes, but it's so crucially fit for use. You'll notice from the shown gpt-4 demo they were guiding the LLM into chain of reasoning. It works very well when you know how to work it, which aligns with what you're saying. I don't mean to degrade the achievement, it's great, but we often inflate the expectations of what something can actually do before reaching real productivity.

I would honestly think it doesn't matter. Students, like professionals, should be given the world and all of it's resources to generate a solution. If I can just punch the question into AI and get a valid answer then maybe the question should be modified.

No. It's just faith in modern crypto.

Speedscale | https://speedscale.com/ | Front End Engineer | Atlanta, GA (Hybrid)

Speedscale is an innovative startup which uses traffic capture and replay to validate and load test applications as they evolve. We work with big companies you've heard of and are actively growing. Come own the front end of our customer application and grow with us.

Apply at https://speedscale.com/careers/position/front-end-engineer/

Yes, some people will do this. I just read the whole project, it's actually a pretty simple program.

I'm installing it now and the best part is if I don't like something I can change it. OSS FTW.

This may be the wrong way around. If the example use case is that a colleague asks how something works and I respond via Slack with Prosona, shouldn't they have just asked Prosona or something like it? Why am I in the loop now? If they need a status update, how will Prosona have access to information which is not in my head, but also not accessible to my colleague?

I do appreciate exploration of AI in different settings, but I feel like any tool that only works in one of my screens isn't going to be what wins 10 years down the line.

Seconded. And might I suggest a smaller company. Smaller companies (like startups) are about about solving the problems at hand quickly. As companies grow there is a larger risk that any one mistake can lose the company money, which will generally continue to flow if they do nothing, and so they intentionally put in a lot of road blocks.

I'm often surprised and intrigued by what makes it to the front page.

As a counterpoint I kinda liked it. It doesn't continue down the page but I thought it was a nice touch.

You would because you can without a subscription. If no code tools were free we might see different uses, but I really can't see people who can code paying for tools like this.

I think a big part of it is just enjoying your time.

We're both driving cross country, following the speed limits. We'll both arrive at roughly the same time but maybe I'll enjoy my time more if I'm driving a stick shift.

This is in general of course. Me personally, I save tens of minutes a year by using vim.

I'm not sure it is.

Some of us have evaluated several approaches based on their merits and tried to makes decisions that are best for our specific organization.

I use Notion for general docs and it's... fine. It has basically everything I want from a general document manager without getting in the way.

Agreed though, code docs should be in the code. With the code or in well placed READMEs.

At our startup we go out of our way to get customer / potential customer feedback. We give away Yeti mugs and gift cards so yeah, any feedback is greatly appreciated, even for companies that have already "made it".

Enter the terminal. Don't leave. It's basically the same everywhere.

In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this. Especially considering how often we're wrong even when we define sprint boundaries and point all the stories.

This argument comes up a lot but this is a very narrow case. Neither you nor I are building software for the super bowl, and if we were building something with such high stakes we should start way, way early and concentrate on core functionality first. There's no real deadline for the feature we decided we needed last week.

> I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.

Of the software I use (slack, cloud infra, vim, Jira) exactly none of them tell me precisely when a feature will be delivered. They work hard on it and release it when it's ready.

A deadline like "in a few weeks" is acceptable. A deadline like "in 17 days" is asking to be missed.

For me, TDD has been much more about making sure the code works the first time and to the spec and much less about the structure of it.

Which ones are you contributing to?