Live data from Hacker News

GitHub Copilot Workspace: Technical Preview

github.blog

211–220 of 333 posts

Re: GitHub Copilot Workspace: Technical Preview

#211

Earlier quoted context omitted.

The hardest part of software development is not writing code, full stop. It never has been and it never will be. The hard part is designing, understanding, verifying, and repairing complex systems. LLMs do not do this, even a little bit.

I guess my worst fear is not "no more jobs because AI can code" but "no more junior jobs because AI can code under the supervision of a senior". SWE jobs will exist, but only seniors will have them and juniors are never hired. Maybe the occasional "apprentice" will be brought on, but in nowhere near the same amount. Where my blind hope lies more specifically is in networking into one of those "apprentice" roles, or m…

A tough pill to swallow that I think a lot of students and very junior engineers fail to realize is that bringing on a new grad and/or someone very junior is quite often a drain on productivity for a good while. Maybe ~6 months for the "average" new grad. Maybe AI exacerbates that timeline somewhat, but engineering teams have always hired new grads with the implicit notion that they're hiring to have a productive team member 6 months to a year down the line, not day one.

Re: GitHub Copilot Workspace: Technical Preview

#212
post #206

Earlier quoted context omitted.

Thanks for trying it! So far, the the testing and validation stage has been left to the developer. While this could change in the future, my experience has been the models aren't quite good enough yet to make an auto-test/auto-fix loop like you've described the default behavior. You end up with a lot of tire-spinning where you're burning a lot of tokens to fix issues that a human can resolve trivially. I think it's b…

Out of interest, what kind of cost ranges are you seeing users spend on the OpenAI API using Plandex? (if only anecdotally)

There's a pretty huge range. It's a function of how much you load into context and how long the task is. So if you dump an entire directory with 100k tokens into context and then proceed to do a task that requires 20 steps, that will cost you a lot. Maybe >$10. But a small task where you're just making a few changes and only have a few small files in context (say 5k tokens) won't cost much at all, maybe like $0.10.

I haven't done too much digging into exactly how much people who are using Plandex Cloud are spending, but I'd say the range is quite wide even among people who are using the tool frequently. Some are doing small tasks here and there and not spending much--maybe they're on track for $5-10 per month, while I'd guess some other heavy users are on track to spend hundreds per month.

Re: GitHub Copilot Workspace: Technical Preview

#213

Earlier quoted context omitted.

The hardest part of software development is not writing code, full stop. It never has been and it never will be. The hard part is designing, understanding, verifying, and repairing complex systems. LLMs do not do this, even a little bit.

I guess my worst fear is not "no more jobs because AI can code" but "no more junior jobs because AI can code under the supervision of a senior". SWE jobs will exist, but only seniors will have them and juniors are never hired. Maybe the occasional "apprentice" will be brought on, but in nowhere near the same amount. Where my blind hope lies more specifically is in networking into one of those "apprentice" roles, or m…

> I guess my worst fear is not "no more jobs because AI can code" but "no more junior jobs because AI can code under the supervision of a senior

You're posting under a thread where many seniors are discussing how they don't want this because it doesn't work.

You cannot make a model understand anything. You can help a person understand something. You can accomplish that with a simple conversation with a junior engineer.

I will never make GPT-4 or whatever understand what I want. It will always respond with a simulacrum that looks and sounds like it gets what I'm saying, but it fundamentally doesn't, and when you're trying to get work done, that can range from being annoying to being a liability.

Re: GitHub Copilot Workspace: Technical Preview

#214
post #209

I'm not sure why they insist on code spaces instead of running this inside vs code? Setups/working looks pretty similar to aider [1] that I've been using and liking, Aider is smaller steps than plandex, but plandex went into some kind of loops a couple of times so I stoped using it for now. [1] https://github.com/paul-gauthier/aider

We definitely intend to explore a VS Code extension in the not too distant future. And we decided to build a web client + integrated cloud terminal, simply because that allowed us to create an experience that is one-click away from an issue, and could be accessed from anywhere and any device (i.e. we’ve deeply optimized CW for mobile, and I do quite a bit of code thinking in that modality).

In the meantime, when you open a Codespace from Copilot Workspace, you could open that Codespace in VS Code desktop. And use that as a companion editor to the web client (since we bi-directionally sync file changes between them). But totally agreed that a more integrated VS Code experience will be compelling!

Re: GitHub Copilot Workspace: Technical Preview

#215
post #209

I'm not sure why they insist on code spaces instead of running this inside vs code? Setups/working looks pretty similar to aider [1] that I've been using and liking, Aider is smaller steps than plandex, but plandex went into some kind of loops a couple of times so I stoped using it for now. [1] https://github.com/paul-gauthier/aider

> plandex went into some kind of loops a couple of times so I stoped using it for now.

Hey, Plandex creator here. I just pushed a release today that includes fixes for exactly this kind of problem - https://github.com/plandex-ai/plandex/releases/tag/cli%2Fv0.... -- Plandex now has a much better 'working memory' that helps it not to go into loops, repeat steps it's already done, or give up too early.

I'd love to hear whether it's working better for you now.

Re: GitHub Copilot Workspace: Technical Preview

#216
post #49

Student here: I legitimately cannot understand how senior developers can dismiss these LLM tools when they've gone from barely stringing together a TODO app to structuring and executing large-scale changes in entire repositories in 3 years. I'm not a singulatarian, but this seems like a brutal S-curve we're heading into. I also have a hard time believing that there is enough software need to make such an extreme prod…

For adding and refactoring it can be a great tool. For greenfield development, it's more tricky - yesterday I sat down and started writing something new, with no context to give Copilot. Mid sourcefile, I paused to think about what I wanted to write - it spit out three dozen lines of code that I then had to evaluate for correctness and just ended up throwing away. I could have probably helped the process by writing d…

> Totally sold on LLM written unit tests though, they are a drag to write and I do save time not writing them by hand.

This is where I've landed, but I'm also skeptical of totally relying on them for this.

In my personal experience, it's worked out, but I can also see this resulting in tests that look correct but aren't, especially when the tests require problem domain knowledge.

Bad tests could introduce bugs and waste time in a roundabout way that's similar to just using LLMs for the code itself.

Re: GitHub Copilot Workspace: Technical Preview

#217

Student here: I legitimately cannot understand how senior developers can dismiss these LLM tools when they've gone from barely stringing together a TODO app to structuring and executing large-scale changes in entire repositories in 3 years. I'm not a singulatarian, but this seems like a brutal S-curve we're heading into. I also have a hard time believing that there is enough software need to make such an extreme prod…

After programming for 35 years since I was 12 and learning everything from the transistor level up through highly abstracted functional programming, I'm a total doomer. I put the odds of programming being solved by AI by 2030 at > 50%, and by 2040 at > 95%. It's over.

Programming (automating labor) is the hardest job there is IMHO, kinda by definition. Just like AGI is the last problem is computer science. You noticed the 3 year pace of exponential growth, and now that will compound, so we'll see exponential-exponential growth. AIs will soon be designing their own hardware and playgrounds to evolve themselves perhaps 1 million times faster than organic evolution. Lots has been written about this by Ray Kurzweil and others.

The problem with this is that humans can't adapt that fast. We have thought leaders and billionaires in total detail of the situation. Basically that late stage capitalism becomes inevitable once the pace of innovation creates a barrier to entry that humans can't compete with. The endgame will be one trillionaire or AI owning the world, with all of humanity forced to perform meaningless work, because the entity in charge will lack all accountability. We're already seeing that now with FAANG corporations that are effectively metastasized AIs using humans as robots. They've already taken over most governments through regulatory capture.

My personal experience in this was that I performed a lifetime of hard work over about a 25 year period, participating in multiple agencies and startups, but never getting a win. So I've spent my life living in poverty. It doesn't matter how much I know or how much experience I have when my mind has done maybe 200 years of problem solving at a 10x accelerated rate working in tech - see the 40 years of work in 4 years quote by Paul Graham. I'm burned out basically at a level of no return now. I'm not sure that I will be able to adapt to delegating my labor to younger workers like yourself and AI without compromising my integrity by basing my survival on the continued exploitation of others.

I'd highly recommend to any young people reading this to NOT drink the kool-aid. Nobody knows what's going to happen, and if they say they do then they are lying. Including me. Think of tech as one of the tools in your arsenal that you can use to survive the coming tech dystopia. Only work with and for people that you can see being someday. Don't lose your years like I did, building out someone else's dream. Because the odds of failure which were once 90% in the first year are perhaps 99% today. That's why nobody successful pursues meaningful work now. The successful people prostitute themselves as influencers.

I'm still hopeful that we can all survive this by coming together and organizing. Loosely that will look like capturing the means of production in a distributed way at the local level in ways that can't be taken by concentrated wealth. Not socialism or communism, but a post-scarcity distribution network where automation provides most necessities for free. So permaculture, renewable energy, basically solarpunk. I think of this as a resource economy that self-evidently provides more than an endlessly devaluing and inflating money supply.

But hey, what do I know. I'm the case story of what not to do. You can use my story to hopefully avoid my fate. Good luck! <3

Re: GitHub Copilot Workspace: Technical Preview

#218

While I've not used this product, I've created somewhat similar setup using open source LLMs that runs locally. After having used it for about three months, I can say that debugging LLM prompts was far more annoying than debugging code. Ultimately, I ended up abandoning my setup and going in favor of writing code the good old fashioned way. YMMV

That is my struggle as well. I need to keep pointing out issues of the llm output, until after multiple iterations it may reach the correct answer. At that point I don't feel I gained anything productivity wise.

Maybe the whole point of coding with llms in 2024 is for us to train their models.

Re: GitHub Copilot Workspace: Technical Preview

#219

Earlier quoted context omitted.

People also forgets that coding is formal logic that describe algorithms to computer which is just a machine. And because it’s formal, it’s rigid and not prone to manipulation. Instead of using LLMs you’d better off studying a book and add some snippets to your editor. What I like about Laravel is their extensive use of generators. They know that part of the code will be boilerplate. The nice thing about Common Lisp…

You start by talking about apples and finish talking about cars.

Could you explain what you mean by that idiom?

Re: GitHub Copilot Workspace: Technical Preview

#220

While I've not used this product, I've created somewhat similar setup using open source LLMs that runs locally. After having used it for about three months, I can say that debugging LLM prompts was far more annoying than debugging code. Ultimately, I ended up abandoning my setup and going in favor of writing code the good old fashioned way. YMMV

I had ChatGPT output an algorithm implementation in Go (Shamir Secret Sharing) that I didn't want to figure out. It kinda worked, but everytime I pointed out a problem with the code it seemed more bugs were added (and I ended up hating the "Good catch!" text responses...) Eventually, figuring out why it didn't work made me have to read the algorithm spec and basically write the code from scratch, throwing away all of…

> Shamir Secret Sharing

> ChatGPT

please don't roll your own crypto, and PLEASE don't roll your own crypto from a LLM. They're useful for other kinds of programs, but crypto libraries need to be to spec, and heavily used and reviewed to not be actively harmful. Not sure ChatGPT can write constant time code :)

Post reply on HN