At $LARGE_ENTERPRISE_COMPANY, I've found that if you have:

1) A designer that uses Figma correctly (using well defined components / design systems) 2) A front-end framework as close to HTML / CSS as possible for the visuals (I have success with Web Components / Lit) with Figma MCP

The front-end is usually one-shot using frontier models. However in my experience, designers are all over the place with using Figma correctly.

Both NEM 2.0 and 3.0 have serious issues, but for different reasons. NEM 2.0 was basically a early adopter's rich person's subsidy that heavily distorted the market, and NEM 3.0 does not have nearly enough subsidies to justify the cost unless you pay cash up front for a large system. (For the record, I am on NEM 3.0 and got such a system).

At the end of the day, the best case scenario is large scale renewable / battery storage to bring costs down as much as possible, and for those of us who want battery backup / solar can choose to invest in it, but it shouldn't be "the" solution.

i thought the new NEM screws the homeowner because the city sells electricity at market price and buys electricity back strictly at the worst possible price, even if you're producing at peak demand.

I don’t disagree that the expectations are higher, but token output hardly correlates to code output worthy of merging.

It doesn’t necessarily mean shipping faster either. Speeding up code production doesn’t mean it speeds up qa, compliance, and the litany of other things. Everyone seems to forget Amdahl’s law.

Code quality matters to engineers. Find a senior manager who cares. Or worse, find a customer who cares.

While they obviously want a high quality product, no outages, a responsive system etc, I don’t think they necessarily understand why you need to avoid creating god-objects, need to reason about abstractions, etc.

Code quality also exists on different axes. I've seen the case where code quality was poor in some aspects, e.g., tons of technical debt, coupling making it difficult to make changes, but overall product quality was very high. It had to be: it was a medical device.

Most environments only care about the output. In the case I'm thinking of, Software made it perfectly clear to Management, most of whom were former engineers, that the product desperately needed redesign in some ways. But as long as the cost of that redesign exceeded the cost to get the next version out, it could be postponed. This went on for years.

Code quality directly correlates to everything you describe.

Yea, but I’m not sure customers or mgmt get that

As code quality goes down, so does productivity, as it becomes more difficult to add new features and there are more bugs introduced.

Nobody cares until the code gets so twisted in knots that bugs and security issues predominate.

Exactly. As long as poor code quality doesn't make a difference in the actual usage of the product, no-one but the engineers will care.

On a task by task basis the code Claude generates is pretty good these days. The biggest issue I see is that it wants to rearchitect the code constantly and I have no faith in my tests anymore because Claude will just "fix" them

I think some tests should be considered to be part of the specification rather than the product.

Thats why they said they optimize for effective output at the cost of higher token use. They didn’t say they are intending to have high token use, instead thet implied its a second order effect of seeking more effective output.

They don't care about quality as long as it works enough. It's a clown show all the way through.

As one that does, it’s a difficult discussion to have with the executives. My peers look like their teams are producing more than my teams are and any argument along the lines of “but their code sucks” isn’t going to hold water. The executives care but until there’s actual impact or poor quality, it won’t matter, and it’s a lagging metric. Many still don’t care about technical debt and that’s been well understood in industry for a while.

It’ll take production incidents, impacted customers, and brand damage to make the executives start to prioritize quality over quantity again.

Ironically Trump may end up being the most pro green energy president at the end of all of this.

Yeah, funny, all the people that turned away from EVs because the subsidies were going away suddenly realize that EVs and renewables are a much more resilient combo than being reliant on fossil fuels and their refining network.

Pro golf green.

I'm currently in repos where the context window required is so large that the output is almost always "wrong" for the problem at hand. Quite a few people at my company burn through tokens this way, and it certainly isn't providing value to the company.

As always, improving accessibility for humans makes automation more effective. If the humans need to remember a PhD's worth of source code/documentation to contribute effectively, your codebase stinks.

People at my company have started writing docs specifically for claude. They're quite useful for me too, but kinda disappointing they never wrote these docs for their colleagues.

As someone who has written many docs, it's because 99% won't read it (rightfully so if it's verbose). You can turn that doc into a skill in a repo and Claude will read it everytime it's needed.

I agree, in the general context of how I code.

The LLM hype train has me reflecting on what a spoiled existence working in a ‘proper’ language provides though…

React devs, JS devs, front-end devs working on large sites and frameworks might be triggering tens of files to be brought into context. What an OCaml dev can bring in through a 5 line union type can look very different in less token-efficient and terse languages.

I disagree. The amount of slop I need to code review has only increased, and the quality of the models doesn’t seem to be helping.

It still takes a good engineer to filter out what is slop and what isn’t. Ultimately that human problem will still require somebody to say no.

Is anyone really reviewing code anymore though? It sounds like you are, but where I work its pretty much just scan the PR as a symbolic gesture and then hit approve. There's too much to review, to frequently.

I'm in a large enterprise context--you have to use human reviewers if you don't want to end up like Github's status page. So much context exists outside of the code that the bots are either not provided or are far too large of contexts for current windows.

A lot of people thought the same thing with everything going from analog -> digital. Or heck, even learning an instrument when MIDI was first introduced.

Even before generative AI, there is a long-going debate in audio circles around simulated guitar amplifiers. The truth is, the simulations of them have gotten so insanely good that now one could simply purchase an all-in-one pedalboard and have basically all of guitar history at your toes.

My rule-of-thumb is this: "does this tool I'm using in particular take away from the authenticity of my performance or songwriting?" Example: I am very keen on performing vocals and guitar at the same time, and I don't have an expensive studio setup, and my office has background noise. I use these tools, and yes even some open source AI ones, 1) remove background noise of the individual tracks and 2) do a final master against a recording I want to target (using something like Matchering or similar [0]). It still sounds like me, my voice isn't perfect, my beat isn't consistent, but it sounds like I rented some studio space. So for me it was a cost-saving measure.

[0] https://github.com/sergree/matchering

>> one could simply purchase an all-in-one pedalboard and have basically all of guitar history at your toes

And this is actually a problem. Great art usually comes from constraints, real or artificial. These things are a lot of fun to tinker with (a really fun hobby) but one amp, one guitar, and a small number of effects pedals will probably lead to you actually make more and better stuff.

I have an all-in-one amp / pedalboard and it's just more practical, even though all I do is just pick an amp, plug in my guitar and play. They take up less space and cost less money in the long run if you actually do want to use many pedals.

I get what you're saying but in general this specific case I think the all-in-ones win for most people.

engineering learning from a senior sde maybe 5 years ago - set your constraints with purpose, and apply them without breaking your system.

just because you have infinite effects doesn't mean you have to use them all. yypu can set whatever constraints you want

This was definitely true for me, which is why I write everything acoustically and ensure the song is "good" before going in my later age. If I want a specific effect, I then google what pedals were used in a particular song or artist, then I try to recreate the chain, and then tinker with that on top.

Ultimately I spent so much of my time worrying about "what crazy expensive equipment should I buy" when I was younger and more into this stuff, and I should have simply just played my shitty instruments and recorded on my shitty equipment. That's on me, but I also find it empowering as an artist that I can clean up my recording in the way that replaces my need for expensive equipment while maintaining (in my humble opinion) a sense of authenticity of my performance. I agree there may be too many knobs, but finding the knobs that I want has never been easier and I would rather live in the now than in the past.

> A lot of people thought the same thing with everything going from analog -> digital.

A lot of people were right. Music gear lead heavily back into analog after the initial analog to digital transition. I started out using computers exclusively. When I purchased my first analog synth, I couldn't believe how much better it sounded than my VST's. It's hard to quantify exactly why, but my ears lit up the second I started using it.

In terms of amp modeling software, some of it is indeed very impressive. But, tends to fall apart when you need to tweak parameters. I assume this has to do with the capture process. But, if you are happy to use stock patches, it's basically an amp replacement.

Not to be "that guy that just says to use LLMs", but writing out how you want these things to work on your computer to something like Claude, or heck even Google AI mode without logging in with an account, allows you to describe your ideal "home server as a docker-compose.yml file" and for me it did a damn fine job doing it. I had done this all with a previous server manually, and with a new server I simply had provided that I was a Fedora Linux box, with these hard drives, with these containers, and these are the locations of the files, etc. It worked the first try.

This wasn't something that I didn't want to learn myself, but I have so little time with children and gardening on top of my super busy work at this point that I didn't have time to simply google everything. I did know enough about it beforehand to provide a general idea of what I want, so YMMV.

This is how I use my Canon t3i. Once in awhile everything will align perfectly, require very little editing and I feel a huge sense of accomplishment.

With practice and patience, the aligning perfectly will come into your control :) Just get out there and shoot more!

I'm at a large enterprise outfit, and "shoving things in your face" has been a problem with large software suites for a long time, long before the AI craze. I keep telling my skip level leadership that we need more User-Experience "mob goons" that have authority across product domains to (metaphorically) beat the living daylight out of bad "PM-brained" ideas.