The actual problem is that no-one had considered that this (desync between front and backend) COULD happen. Once it was realized that it was possible (and worth testing) the bug was practically solved already.
Such is true for many bugs. Even if you have unit tests, they only test on things you've thought of. It's usually the stuff you haven't thought of that gets you.
No reason not to unit test of course, but don't get a false sense of complacency or assume testing is easy either. That's why it's great to do things very carefully (and probably not with AI Agents).
While that may be true, you can be confident that it works in a way you personally understand. Because you understood it in the past.
Also, if you finish your work on a module with care - you return to a module you can trust with clear boundraries and known flaws. This is not true of AI output.
I'm skeptical of this. I have yet to build a codebase using AI that I wasn't able to subsequently understand after taking the time to do so, esp. when aided by AI that will tirelessly answer my questions. I mean, LLMs don't always code the exact way I do, but it's not writing totally alien code that's incomprehensible to the human mind here.
I use Claude Code, primarily writing web applications and JavaScript. I'll have it use various frameworks. It's built apps for me using React, Ember, Astro, etc. I don't restrict myself to frameworks I'm particularly familiar with, since it's easy for the AI to teach me the basics whenever I would like to dig in.
As for specific practices, these are my main ones:
- I have a gotchas-log.md file that acts as a log of gotchas likely to trip up future runs. I have the AI write to this occasionally when things go haywire in the same way multiple times. And I have it read it as part of its iterative reviews, described below.
- I have a good-code-guidelines.md file where I write my preferences for code. I have the AI read this as part of iterative reviews, described below.
- I have a plan-and-execute.md file that prompts the LLM to make a plan, and then to review and iterate on that plan repeatedly (while reading gotchas-log.md and
good-code-guidelines.md) until its reviews stop finding issues. I tag this file to implement almost every non-trivial change.
- I have other various helper prompts. For example, I can simply tag @make-a-git-commit.md and it tells the LLM to make a commit and write the message the way I like it. I have @simplify.md, which I can tag to have the LLM explain whatever it just did to me using simple language that makes it easier for me to understand, and using concentric circles of explanation that go from broad to specific so I'll repeatedly encounter important topics; this makes it much more bearable for me to read its responses.
- Occasionally, whenever a particular system of my codebase starts to get hairy, I spawn a Claude Code session to read through and trace all the relevant code paths, then write a short guide to that system in a markdown file that lives in the codebase. IT's useful for me to read and also useful to tag for future prompts to get the LLM up to speed quickly. Only challenge here is that these guides go stale and require updating, so it's important to prompt the AI to write them at the appropriate level (not to specific) that prevents them from being overly brittle and getting out of date with every little change. They're mostly high-level guides.
No. You can absolutely build things with AI small or large and understand it. If you don’t understand it. Then you’re not caring about the output to begin with and not guiding it to build the solution you want.
The word "understand" seems to mean something different to you.
If I understand something, I could write it in assembly if I wanted to. It might take a long time, but I know every level of the stack under my code down to bare metal.
Maybe an AI level of "understand" i.e the same understanding a Senior has of a Junior's code based on daily check-ins is enough for 95% of "boring" programming. But for some tasks you need to either fully understand the code or just tolerate bugs.
At the level of complexity I work at, it's (often) faster to just code it myself than to expect AI to converge on a result I like and then hand check it.
> At the level of complexity I work at, it's (often) faster to just code it myself than to expect AI to converge on a result I like and then hand check it.
Would love an example because no one has ever been able to give a coding example that AI isn’t helpful for. I had one person on linked in try claim their undocumented audio hardware won’t work with ai but when we got ai to probe it and build docs it ended up solving a bunch of complex bugs they couldn’t fix.
Impressive, also horrifying. I love what I do and if AI can do it better than that sucks.
Anyway the use case for me is to realize a new visual style through graphics programming. It's a lot less measurable for an interative AI agent than "Meet this hardware specification from a device with a discoverable API"
I have no doubt AI could create a LOT of variations on "a new visual style" but it's less controllable than just doing it yourself.
Btw, did you "understand" the sound driver after the AI coded it? Could you modify it without further help?
Right now, at least, I haven't found an AI capable of replacing a software engineer. Ive seen AI that can easily replace basic programmers, however.
I also think AI can replace non-coding artitects, and probably most middle management type jobs (my company has 6 levels of management between the CEO and "individual contributors" in my area (8 counting inclusivity)).
That's a lot of management levels, and every level has to be paid more than the level they manage as a fraud disincentive. So that's a lot of money...
Can you explain the fraud disincentive bit? I feel like there's something obvious I'm missing, but why would a manager earning less than their reports make fraud more likely?
Look, goals can differ. If you don't need to understand and predict every part of the code the AI is generating and you just need it to meet a "sketch" of what you want - by all means use AI. I do use AI in that situation for related or unimportant code.
But if you need full understanding, in my experience the only way to get that is to program it yourself. Unless what the AI is generating is so trivial you already understand it and it's grunt work, you will learn the detail by doing it yourself. Controlling the approach here is important.
However often the best way to handle grunt work is to write better abstractions, something AI sucks at.
It's the programming equivalent of many PG essays. https://www.paulgraham.com/useful.html for instance. There was one on how PG refined their thoughts via writing. It's in there somewhere.
As someone who spends way too much time searching for the best abstractions, absolutely this is still true.
I often have a long back and forth with codex to explore the problem space and settle on the best abstractions. Occasionally it will make a suggestion that helps me, but for the most part it's reviewing while I'm in the driver's seat.
Contrast this to simply giving it a function name and a vague description of what the function will do. I'll generally accept its output with a few refinements.
But for larger project structure and metaphors, it falls flat, and often lands on a solution that's going to be a maintenance nightmare or result in endless repetition across not-quite-the-same cases. I've never seen it happen upon an appropriate abstraction that can cleanly cut through the nonsense.
Random reply: 20 days ago you asked for my ChatGPT custom instructions to be more skeptical. It is :
Use an encouraging tone. Adopt a skeptical, questioning approach. Call me on things which don't seem right. List possible assumptions I'm making if any.
You know how to add logic on the outside of a function, by putting that function into a larger one and calling the function in the middle.
However, how do you inject logic INTO the middle of a function?
Say you have a function which can iterate over any list and given a condition do a filter. How do you inject the condition logic into that filter function?
In the C days you would use a function pointer for this. C++ introduced templating so you could do this regardless of type. Lambdas make the whole process more ergonomic, it's just declaring a one-shot function in place with some convenient syntax.
There is a strategy called alpha beta pruning meaning you can discard a lot of move options quickly based on the results of similar branches. That and caching similar board states means 20x options does not mean 20x CPU time.
Perhaps not in a 100% world, though I'll give you the point that they are useful now.
In a 100% renewable world we would not be extracting or refining oil. Natural gas (used by these turbines) is a byproduct of oil drilling. Were we not burning the oil, the natural gas might be too expensive alone.
Also, in a 100% renewable world we would (by definition) have enough generation all the time - (covered by batteries and good baseload sources) that turbine power was no longer required to cover peak loads.
It's not clear (yet) what a 100% clean energy powered world would use to cover the last couple of percent of demand when loads peak and/or variable generation troughs for extended periods.
It'll be some combination of demand management (which isn't nearly as horrifying as people make it out to be), pumped hydro, long-duration batteries like iron-air, but also possibly burning hydrogen or hydrogen-derived synthetic fuels (produced by electrolysis when hydrogen is abundant) and/or biofuels in turbines.
Somebody calculated that a home in UK needs 1 Megawatt-Hour battery to backup solar energy during the winter. I suspect in 10 years that may cost below 25K, a small fraction of the property cost.
But is it really 1 MWh of _electricity_, or could you replace a good chunk of that with a huge tank of boiling water? In the winter, about half of my electricity consumption goes to my heat pump, to produce 45-50C water for heating and tap water. But if we could increase the reservoir temperature to 95C (or even go superheated to 160C at 6 bar), then it could supply the 45-50C flow temperature much longer without needing to recharge.
That's probably assuming a solar system sized to cover typical summer energy usage. You can simply over-provision solar until you have wasted capacity in summer and little to no storage requirement in winter. Then it's just a tradeoff between battery and solar costs to find the best price point.
Also this calculation probably assumes no baseload power imported from the grid, where means such as wind and tidal power work year-round and help offset the need for batteries.
That is right (if rather exaggerated, and I will note that it was you who originally picked the figure of two percent), and in practice, we accept a certain risk that we will not always have all the capacity we want, even though (or because) we cannot precisely predict how big or often these events will be. There is no particular reason to think this specific case is any different.
Why can't we predict how big or how often those events would be? We have clear understandings of the distribution of probabilities for all kinds of weather scenarios - see for example 1-50/100/1000 year flood/droughts.
I'm not saying we cannot do it, just that we cannot always get it right, and there is plenty of empirical evidence for that.
The second point is that the distribution has a long tail, especially when we consider the possibility of multiple independent incidents overlapping in time, to the point where it becomes infeasible to suppose that we could be prepared to continue operating as if nothing had happened in all conceivable scenarios, regardless of how accurately we could predict their likelihood.
I do not understand your argument We also cannot get right predicting the failures of fossil fuel generation. Sometimes multiple plants have outages that coincide and we have blackouts. Shit happens, and will continue to happen. Meanwhile we can make statistically rational plans.
We have coal fired plants in Australia with <90% uptime (often unscheduled), but somehow they're considered baseload rather than intermittent.
And I cannot figure out why you are saying this, as nothing I have said previously either contradicts what you say here, or is contradicted by it. If you could say what you think I am saying in my posts in this thread, we can sort it out.
EDIT: I see the problem starts with the first sentence of your first post here: “Why can't we predict how big or how often those events would be?” - which is completely beside the point in my response to rgmerk, who wrote “It's not clear (yet) what a 100% clean energy powered world would use to cover the last couple of percent of demand when loads peak and/or variable generation troughs for extended periods.” My response to this and the follow-up is this: a) if we are talking about two percent, we can overbuild the renewable capacity, and b) if we are considering all eventualities, there inevitably comes a point where we say that we are not going to prepare for uninterrupted service in this event.
No you didn't; you pointed out why it is not, in itself, a significant issue in the first place (which rgmerk tacitly seems to recognize in his first response, through pivoting away from the 2% claim.) My position on this has been that if the issue really is over ~2%, there is a simple solution.
I'll state it plainly: to get to the same level of reliability as the existing grid with just wind, solar, and batteries requires unacceptable amounts of overprovisioning of these at high latitude (or unacceptably high transmission cost).
Fortunately, use of different long duration storage (not batteries) can solve the problem more economically.
"Creative" re/misinterpretation is becoming quite a thing here - what I actually did was agree that rgmerk had a more defensible position after he pivoted away from his original ~2% claim to a more reasonable one.
I'll state it plainly: rgmerk's subsequent pivot in his stated claims does not retroactively make my response to his original claim wrong! (Not even if the subsequent claim more accurately reflects what he really meant to say.) I am having trouble figuring out why anyone would think otherwise.
We can and do, and there are detailed plans based on those weather scenarios (eg for the Australian east coast grid; there is AEMO’s Integrated System Plan).
Things in the US are a bit more of a mixed bag, for better or worse, but there have been studies done that suggest that you can get very high renewables levels cost effectively, but not to 100% without new technology (eg “clean firm” power like geothermal, new nuclear being something other than a clusterfumble, long-term storage like iron-air batteries, etc etc etc).
The best technologies there are (IMO) e-fuels and extremely low capex thermal.
There are interesting engineering problems for sources that are intended to operate very infrequently and at very low capacity factor, as might be needed for covering Dunkleflauten. E-fuels burned with liquid oxygen (and water to reduce temperature) in rocket-like combustors might be better than conventional gas turbines for that.
It's mostly something I thought about myself. The prompting idea was how to massively reduce the capex of a turbine system, even if that increases the marginal cost per kWh when the system is in use, and also the observation of th incredibly high power density of rockets (they're the highest power density heat engines humanity makes). So, get rid of the compressor stage of the turbine, be open cycle so there's no need to condense steam back to water, and operate at higher pressure (at least an order of magnitude higher than combustion turbines) so the entire thing can be smaller.
You'd have to pay for storage of water and LOX (and making the LOX) so this wouldn't make sense to prolonged usage. On the plus side, using pure LOX means no NOx formation, so you also lose the catalytic NOx destruction system a stationary gas turbine would need to treat its exhaust.
I vaguely recall some people in Germany were looking at something like this but I don't remember any details.
The problem is the last two percent isn't evenly distributed in time, but rather occurs rarely, but in large chunks. On average it's 2%, but not at each point in time.
Also, if solar ends up much cheaper than wind there's going to be need for seasonal energy storage, which could be considerably more than 2% at high latitude. Batteries are unsuitable for this.
Particularly with the development of fracking, natural gas production is no longer a just a byproduct of oil production, and can be (and is) pursued independently. Nevertheless, I agree that we developing renewables should be our priority.
They are a bridge between those with money and those with skill. Plus they can aggregate information and act as a repository of knowledge and decision maker for their teams.
These are valuable skills, though perhaps nowhere near as valuable as they end up being in a free market.
The free market is an analyzable simplification of the real market, however I think the assumptions hold in this case.
If a CEO delivers a certain advantage (a profit multiplier) it's rational that a bidding war will ensue for that CEO until they are paid the entire apparent advantage of their pretense for the company. A similar effect happens for salespeople.
The key difference between free and real markets in this case is information and distortions of lobbying. That plus legal restrictions on the company. The CEO is incentivized to find ways around these issues to maximize their own pay.
Such is true for many bugs. Even if you have unit tests, they only test on things you've thought of. It's usually the stuff you haven't thought of that gets you.
No reason not to unit test of course, but don't get a false sense of complacency or assume testing is easy either. That's why it's great to do things very carefully (and probably not with AI Agents).