HN user

mleo

353 karma
Posts1
Comments206
View on HN
Fox to buy Roku 1 month ago

Begin? I haven’t heard anything positive about Roku in 10 years or so. They had to race to the bottom to compete with Amazon and Google. And maybe they mostly survived til now, but all I hear is complaints about ads.

I can’t understand this. The first thing I do with new agent driven project is set up quality checks. Linters, test frameworks, static analysis, etc… Whatever I would expect a developer to do, I would expect an agent to do. All implementation has to go through build success and mixed agent reviews before moving on. I might not do this with initial research/throwaway prototype, but once I know what direction to go and expect code to go to production it is vital to set guard rails.

As a percentage of good to mediocre, maybe. Engineers of 40 years ago were probably better than engineers 20 years ago. Less of them and more constraints they had to deal with. Democratization of technology makes it easier for more people to use. It applies to programming as much as just using a computer.

This is my go to solution for code sync across macOS laptop, Windows VMs, and Linux VMs to build and run/debug across environments. Unless something has changed, exclusions of build artifacts was always an issue with cloud sync providers. I have been doing more cross compilation on macOS, copy and run on those other machines lately for prototypes, but for IDE based debugging it’s great to edit local or remote and get it all synced to the machine to run it in seconds.

My wife's work laptop gives this stupid warning anytime any USBC charger is plugged in, other than the Dell brick. So even a dock delivering 100w would get a complaint. The Dell brick offers non-standard charging at 140w, which can't get replaced by standards compliant, smaller chargers.

Claude can do mermaid diagrams and I started with those, but I have been asking it to generate draw.io diagrams as of late. I haven't actually tried the AI integration recommendations for draw.io, yet. I will have to pull the skill and references to see if it makes the process faster.

My M4 MacBook Pro for work just came a few weeks ago with 128 GB of RAM. Some simple voice customization started using 90GB. The unified memory value is there.

Same way you would in a terminal.

You can provide the agent details to use either through skills or commands that provide reference and context to use. The agent can load when needed.

Having cli tool access provides me option to run the tools when I want to look at or do something as well.

I somewhat disagree. Sure, if the prompt is “build fully functional application that does X from scratch”, then of course you are going to get crap end product because of what you said and didn’t say.

As a developer you would take that and break it down to a design and smaller tasks that can show incremental progress and give yourself a chance to build feature Foo, assess the situation and refactor or move forward with feature Bar.

Working with an LLM to build a full featured application is no different. You need to design the system and break down the work into smaller tasks for it to consume and build. It and you can verify the completed work and keep track of things to improve and not repeat as it moves forward with new tasks.

Keeping fully guard rails like linters, static analysis, code coverage further helps ensure what is produced is better code quality. At some point are you baby sitting the LLM so much that you could write it by hand? Maybe, but I generally think not. While I can get deeply intense and write lots of code, LLMs can still generate code and accompanying documentation, fix static analysis issues and write/run the unit tests without taking breaks or getting distracted. And for some series of tasks, it can do them in parallel in separate worktrees further reducing the aggregate time to complete.

I don’t expect a developer to build something fully without incrementally working on it with feedback, it is not much different with an LLM to get meaningful results.

Breaking down requirements, functionality and changes into smaller chunks is going to give you better results with most of the tools. If it can complete smaller tasks in the context window, the quality will likely hold up. My go to has been to develop task documents with multiple pieces of functionality and sub tasks. Build one piece of functionality at a time. Commit, clear context and start the next piece of functionality. If something goes off the rails, back up to the commit, fix and rebase future changes or abandon and branch.

That’s if I want quality. If I just want to prototype and don’t care, I’ll let it go. See what I like, don’t like and start over as detailed above.

There is a lot of data shuttling or shuffling in enterprise applications and if agents can write that part, so be it. I can spend more time on the harder business and technical problems that require creativity and working through the options and potential solutions. Even here, the speed to write multiple different experiments in parallel, is fantastic.

As for “it-compiles” that is nothing new. I have written code that I go back to later and wonder how it ever compiled. I have a process now of often letting the agent prototype and see if it works. Then go back and re-engineer it properly. Does doing it twice save time? Yeah, cause who’s to say my first take on the problem would have been correct and now I have something to look at and say it is definitely wrong or right when considering how to rebuild it for long term usage.

Depends on how many times the few more servers are duplicated. Getting an extra server for on-premises installed products is worse than pulling teeth. It’s not one server, it is one server times a thousand.

This has been one of my pet peeves on our projects; how simply can I build a project and run it. Ideally with just Java and git, can I download, build and run. Throw in some projects with native libraries, can I build with compiler tools installed but not building 5 other projects first with environment variables pointing to locations of code.

Agreed. There is a difference.

I used vibe coding to build a UI prototype of workflow. I used mockup images as the basis of the layout and let the agent use Redis as the persistence layer. I know it will be throw away and don't care how it is working underneath as long as it can demonstrate the flow I want.

I have also used prompt driven development to allow the agent to code something I expect to turn into a longer term product. I do more review of the code, ensure it is meeting all standards to development I would expect of myself or any other developer.

There are certainly differing degrees of the two types of development.

The CoPilot plug-in for IntelliJ is not on par with other coding agents at the moment. The usability of the plug-in and integration of ide is a bit annoying to use for any length of time.

It will likely occur, just maybe not this year or next. If we look over the last eighty years of computing, the trend has been smaller and more powerful computers. No reason to think this won’t occur with running inference on larger models.

Why wouldn’t 3rd party hardware vendors continue to work on reducing costs of running models locally? If there is a market opportunity for someone to make money, it will be filled. Just because the cloud vendors don’t develop hardware someone will. Apple has vested interest in making hardware to run better models locally, for example.