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.