mleo

San Antonio is in the middle of the state with 360 degrees of growth and relatively flat. California’s land growth has half of that with hills and mountains near the desirable areas.

Apple has the mlx framework. Most/all major software for running models locally support it. Apple also has RDMA for interconnecting multiple machines across Thunderbolt connections.

There are such a wide variety of fireworks available now there is probably less need for those specifically. The show I was at still had enough loud booms to set off dozens of cars' alarms repeatedly during the twenty minutes.

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.

If I don’t know what I don’t know, how am I going to build something any better than a coding agent? An approach on a couple of projects has been to prototype with the agent, learn, write a design and then start over. I then know the areas to look into more detail.

I use the cursor cli, not the IDE. Why? Someone else is paying for it.

And 32-bit to 64-bit.

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.

I am not sure how, but at one point even private browser mode would still have me logged in to Entra ID. Couldn’t log out of main browser and same session would follow me to private.

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.

It is 15mph at this school with kids present. So percentage wise kind of high, but in absolute terms not much.

Just completed my first, small go program. It is just a cli tool to use with code quality tool for coding agent skill. The toolchain built into go left a good first impression. Recursion and refinement of guard rails on coding agents has been high on my priorities to deliver better quality code faster.

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.

It forces you to consider when, where and why a change occurs and can help reason later about changes. Thread safety is a big plus.

Do they often publicize the threats that are predicted and handled? I can’t say for certain, but it seems like the old adage about IT.

Already exists in some parts of southern california as toll lanes for single drivers.

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.

It’s still early days for these agents. There isn’t any reason the agents won’t build or understand AST in the future to more quickly refactor.

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.

We had a lemon tree that did this. The irrigation line connector was probably not 100% sealed and the roots grew to it slowly broke it. It enabled the lemon tree to gets lots of water and grow. Meanwhile the trees further down the irrigation line suffered.