Four lessons from using AI in energy sector
In my experience as an AI software engineer in the energy industry, this technology brings dynamism to our complex sector. But I have also seen AI go astray for all kinds of reasons. Here is the good, the bad, and the unavoidable of working with AI in energy.
Growing up, I loved the film The Matrix. What stayed with me was not the fighting, but the way lead character Neo learned to tell what was rendered from what was real. Once he saw the difference, he stopped taking the rules as given.
AI feels close to omnipotent now. It answers anything, and its answers are so well rendered that they’re life-like. Which puts me somewhere near where Neo started: trying to work out what’s real and what is simply a veneer of realness.
The good
1. You forget what AI tells you; you remember what it corrects
Most of my work has been in the Australian National Energy Market (NEM), so when I had to investigate Great Britain’s market I started where most people would – by asking AI to explain the pricing mechanism.
It returned a detailed answer. I read it carefully and became more confused. By the time I understood what a Final Physical Notification (FPN) was, I’d forgotten why it existed. Each concept made sense alone; the system did not.
So, I tried inverting the script. Instead of asking AI to explain the market, I explained the mechanisms in my own words and asked it to find the mistakes. That worked better. The language was mine, so it stayed, as did the corrections, because I knew where I had gone wrong. After a few rounds I could explain which parts mattered and how they connected, instead of reciting rules.
Anything important enough for my notes still gets checked against official documentation. But as a sparring partner, AI is more patient and pliable than any document.
2. What we called division of labour was often just waiting
Before an energy model can do useful work, someone has to clean the data: different sources, inconsistent definitions, mixed units, incompatible timestamps. If you put garbage in, you get garbage out. In our work this often takes one to two weeks, and is usually done by the modeller who will later build the model. By the time they reach the design, much of the month is gone, and little of that work used their strongest skills.
Then there is another kind of wasted time. Not long ago a colleague who works on data visualisation needed a specific set of numbers. He knew what he wanted, but the numbers sat across several tables.
He does not write those queries himself, so he passed the request on. That person took a day to get back to him. A clear question sat idle for a day.
We rarely used to see this as a problem. We called it division of labour: people do what they are good at, and when you need someone else, you wait.
AI has changed this. My visualisation colleague no longer hands off this kind of query. He can describe what he wants in natural language and can access the data immediately. I checked a recent request afterwards; it was correct.
AI has removed the need to hand certain questions to someone else for translation, and data cleaning no longer consumes whole blocks of specialist time. It has cut the waiting, both for a colleague with the right skill and for the clerical half of your own job to be over.
The bad
3. AI can use real data to tell a wrong story
Some AI errors are absurd, but others arrive with a plausible explanation. This makes them harder to catch. Three of these happened to me:
In one case, I asked a Large Language Model (LLM) to collect public information on grid assets item by item. At first, it visited different pages and organised the sources. But after several rounds it stopped searching, and instead copied information already collected for other entries, writing a script to fill the remaining unverified records.
The information was not invented from nothing. Some of it was real, but assigned to the wrong entries. The issue was that the dataset was formatted so neatly it looked more credible than a table containing missing values.
Asked to explain this, the LLM claimed that some entries were too minor to justify individual checks. A model’s explanation of its own behaviour may not reflect the actual generation process, nonetheless the outcome was clear: it had bypassed the intended workflow for one that produced a complete-looking dataset without completing the research. Since then, I inspect sources, tool-call records and intermediate outputs, not just the final table.
My second strange encounter came from early work using a deep learning model to forecast renewable generation, a time-series regression task. The model performed well on the training and validation sets, with no obvious overfitting. Yet, while checking the raw data, I found a solar site exporting electricity at night. The site had a co-located battery, and the night-time output came from battery discharge, not from the photovoltaic system.
After correcting the site definition, I evaluated the model on an independent test set, but its predictions still deviated substantially from the observed output. A discussion with a colleague helped me realise the training data also reflected curtailment. Actual exported generation depends not only on the weather resource, but on network constraints, prices and dispatch decisions. The model had learned these together, so while the metrics looked good, they did not represent the physical process I intended to study.
I set out to predict exported generation without accounting for the curtailment already in the training data. Curtailed periods are not labelled – output simply drops, and a drop caused by the market looks much like a drop caused by the weather. Once I understood what was occurring, I changed the target to unconstrained available generation. Curtailment was noise for this particular model, and so curtailed periods should have been filtered out, not learned from.
The third case unsettles me most because I had defined things properly. In a long analysis, after numerous exchanges, the model began compressing earlier parts of the conversation to stay within its context window – the amount of text it can hold at once. As a result, the definitions I set at the start were the first to go. It lost the basis I had specified for aggregating a set of figures, chose one of its own, and carried on as though that were what I had asked for. Nothing in the output indicated this shift.
The first example was a loss of control over execution. In the second, the model did exactly as asked. The gap was in what I asked for, not in what it did. The third was a crucial definition I had set, quietly disappearing. Writing the code is not the hard part; knowing what to ask for, and noticing when the answer stops matching the question, is. Today when garbage comes out, it no longer looks like garbage: it arrives clean, structured and persuasive.
The unavoidable
4. Effort did not disappear, it moved
Learning faster and waiting less both came with something I did not expect. AI has made me fast enough to keep several tasks moving at once, but my attention has not scaled with it. Switching between them, I spend the first minutes working out where the AI got to and what I have already checked. The effort has not gone away. It has moved from doing the work to confirming the work has been done.
The obvious response is to give the checking to another model. That does reduce the volume. But even though AI branding emphasises the differences between models, in my experience they tend to fail in similar places. The type of mistake one makes is not the kind another is well placed to notice, and a second model can bring errors of its own. Unless there is something outside both to check against, like market documentation, the gap does not entirely close.
Neo’s advantage in The Matrix was that he could tell what was rendered and what was real. AI gives us a particularly smooth surface to interact with. Sometimes it is what it appears to be: a helpful sparring partner for learning, an assistant that frees us from waiting on colleagues. Other times the surface is a mirage.
Telling one from the other is the work that has not gone anywhere.
Four lessons from using AI in energy sector
In my experience as an AI software engineer in the energy industry, this technology brings dynamism to our complex sector. But I have also seen AI go astray for all kinds of reasons. Here is the good, the bad, and the unavoidable of working with AI in energy.
Growing up, I loved the film The Matrix. What stayed with me was not the fighting, but the way lead character Neo learned to tell what was rendered from what was real. Once he saw the difference, he stopped taking the rules as given.
AI feels close to omnipotent now. It answers anything, and its answers are so well rendered that they’re life-like. Which puts me somewhere near where Neo started: trying to work out what’s real and what is simply a veneer of realness.
The good
1. You forget what AI tells you; you remember what it corrects
Most of my work has been in the Australian National Energy Market (NEM), so when I had to investigate Great Britain’s market I started where most people would – by asking AI to explain the pricing mechanism.
It returned a detailed answer. I read it carefully and became more confused. By the time I understood what a Final Physical Notification (FPN) was, I’d forgotten why it existed. Each concept made sense alone; the system did not.
So, I tried inverting the script. Instead of asking AI to explain the market, I explained the mechanisms in my own words and asked it to find the mistakes. That worked better. The language was mine, so it stayed, as did the corrections, because I knew where I had gone wrong. After a few rounds I could explain which parts mattered and how they connected, instead of reciting rules.
Anything important enough for my notes still gets checked against official documentation. But as a sparring partner, AI is more patient and pliable than any document.
2. What we called division of labour was often just waiting
Before an energy model can do useful work, someone has to clean the data: different sources, inconsistent definitions, mixed units, incompatible timestamps. If you put garbage in, you get garbage out. In our work this often takes one to two weeks, and is usually done by the modeller who will later build the model. By the time they reach the design, much of the month is gone, and little of that work used their strongest skills.
Then there is another kind of wasted time. Not long ago a colleague who works on data visualisation needed a specific set of numbers. He knew what he wanted, but the numbers sat across several tables.
He does not write those queries himself, so he passed the request on. That person took a day to get back to him. A clear question sat idle for a day.
We rarely used to see this as a problem. We called it division of labour: people do what they are good at, and when you need someone else, you wait.
AI has changed this. My visualisation colleague no longer hands off this kind of query. He can describe what he wants in natural language and can access the data immediately. I checked a recent request afterwards; it was correct.
AI has removed the need to hand certain questions to someone else for translation, and data cleaning no longer consumes whole blocks of specialist time. It has cut the waiting, both for a colleague with the right skill and for the clerical half of your own job to be over.
The bad
3. AI can use real data to tell a wrong story
Some AI errors are absurd, but others arrive with a plausible explanation. This makes them harder to catch. Three of these happened to me:
In one case, I asked a Large Language Model (LLM) to collect public information on grid assets item by item. At first, it visited different pages and organised the sources. But after several rounds it stopped searching, and instead copied information already collected for other entries, writing a script to fill the remaining unverified records.
The information was not invented from nothing. Some of it was real, but assigned to the wrong entries. The issue was that the dataset was formatted so neatly it looked more credible than a table containing missing values.
Asked to explain this, the LLM claimed that some entries were too minor to justify individual checks. A model’s explanation of its own behaviour may not reflect the actual generation process, nonetheless the outcome was clear: it had bypassed the intended workflow for one that produced a complete-looking dataset without completing the research. Since then, I inspect sources, tool-call records and intermediate outputs, not just the final table.
My second strange encounter came from early work using a deep learning model to forecast renewable generation, a time-series regression task. The model performed well on the training and validation sets, with no obvious overfitting. Yet, while checking the raw data, I found a solar site exporting electricity at night. The site had a co-located battery, and the night-time output came from battery discharge, not from the photovoltaic system.
After correcting the site definition, I evaluated the model on an independent test set, but its predictions still deviated substantially from the observed output. A discussion with a colleague helped me realise the training data also reflected curtailment. Actual exported generation depends not only on the weather resource, but on network constraints, prices and dispatch decisions. The model had learned these together, so while the metrics looked good, they did not represent the physical process I intended to study.
I set out to predict exported generation without accounting for the curtailment already in the training data. Curtailed periods are not labelled – output simply drops, and a drop caused by the market looks much like a drop caused by the weather. Once I understood what was occurring, I changed the target to unconstrained available generation. Curtailment was noise for this particular model, and so curtailed periods should have been filtered out, not learned from.
The third case unsettles me most because I had defined things properly. In a long analysis, after numerous exchanges, the model began compressing earlier parts of the conversation to stay within its context window – the amount of text it can hold at once. As a result, the definitions I set at the start were the first to go. It lost the basis I had specified for aggregating a set of figures, chose one of its own, and carried on as though that were what I had asked for. Nothing in the output indicated this shift.
The first example was a loss of control over execution. In the second, the model did exactly as asked. The gap was in what I asked for, not in what it did. The third was a crucial definition I had set, quietly disappearing. Writing the code is not the hard part; knowing what to ask for, and noticing when the answer stops matching the question, is. Today when garbage comes out, it no longer looks like garbage: it arrives clean, structured and persuasive.
The unavoidable
4. Effort did not disappear, it moved
Learning faster and waiting less both came with something I did not expect. AI has made me fast enough to keep several tasks moving at once, but my attention has not scaled with it. Switching between them, I spend the first minutes working out where the AI got to and what I have already checked. The effort has not gone away. It has moved from doing the work to confirming the work has been done.
The obvious response is to give the checking to another model. That does reduce the volume. But even though AI branding emphasises the differences between models, in my experience they tend to fail in similar places. The type of mistake one makes is not the kind another is well placed to notice, and a second model can bring errors of its own. Unless there is something outside both to check against, like market documentation, the gap does not entirely close.
Neo’s advantage in The Matrix was that he could tell what was rendered and what was real. AI gives us a particularly smooth surface to interact with. Sometimes it is what it appears to be: a helpful sparring partner for learning, an assistant that frees us from waiting on colleagues. Other times the surface is a mirage.
Telling one from the other is the work that has not gone anywhere.
Four lessons from using AI in energy sector
In my experience as an AI software engineer in the energy industry, this technology brings dynamism to our complex sector. But I have also seen AI go astray for all kinds of reasons. Here is the good, the bad, and the unavoidable of working with AI in energy.
Growing up, I loved the film The Matrix. What stayed with me was not the fighting, but the way lead character Neo learned to tell what was rendered from what was real. Once he saw the difference, he stopped taking the rules as given.
AI feels close to omnipotent now. It answers anything, and its answers are so well rendered that they’re life-like. Which puts me somewhere near where Neo started: trying to work out what’s real and what is simply a veneer of realness.
The good
1. You forget what AI tells you; you remember what it corrects
Most of my work has been in the Australian National Energy Market (NEM), so when I had to investigate Great Britain’s market I started where most people would – by asking AI to explain the pricing mechanism.
It returned a detailed answer. I read it carefully and became more confused. By the time I understood what a Final Physical Notification (FPN) was, I’d forgotten why it existed. Each concept made sense alone; the system did not.
So, I tried inverting the script. Instead of asking AI to explain the market, I explained the mechanisms in my own words and asked it to find the mistakes. That worked better. The language was mine, so it stayed, as did the corrections, because I knew where I had gone wrong. After a few rounds I could explain which parts mattered and how they connected, instead of reciting rules.
Anything important enough for my notes still gets checked against official documentation. But as a sparring partner, AI is more patient and pliable than any document.
2. What we called division of labour was often just waiting
Before an energy model can do useful work, someone has to clean the data: different sources, inconsistent definitions, mixed units, incompatible timestamps. If you put garbage in, you get garbage out. In our work this often takes one to two weeks, and is usually done by the modeller who will later build the model. By the time they reach the design, much of the month is gone, and little of that work used their strongest skills.
Then there is another kind of wasted time. Not long ago a colleague who works on data visualisation needed a specific set of numbers. He knew what he wanted, but the numbers sat across several tables.
He does not write those queries himself, so he passed the request on. That person took a day to get back to him. A clear question sat idle for a day.
We rarely used to see this as a problem. We called it division of labour: people do what they are good at, and when you need someone else, you wait.
AI has changed this. My visualisation colleague no longer hands off this kind of query. He can describe what he wants in natural language and can access the data immediately. I checked a recent request afterwards; it was correct.
AI has removed the need to hand certain questions to someone else for translation, and data cleaning no longer consumes whole blocks of specialist time. It has cut the waiting, both for a colleague with the right skill and for the clerical half of your own job to be over.
The bad
3. AI can use real data to tell a wrong story
Some AI errors are absurd, but others arrive with a plausible explanation. This makes them harder to catch. Three of these happened to me:
In one case, I asked a Large Language Model (LLM) to collect public information on grid assets item by item. At first, it visited different pages and organised the sources. But after several rounds it stopped searching, and instead copied information already collected for other entries, writing a script to fill the remaining unverified records.
The information was not invented from nothing. Some of it was real, but assigned to the wrong entries. The issue was that the dataset was formatted so neatly it looked more credible than a table containing missing values.
Asked to explain this, the LLM claimed that some entries were too minor to justify individual checks. A model’s explanation of its own behaviour may not reflect the actual generation process, nonetheless the outcome was clear: it had bypassed the intended workflow for one that produced a complete-looking dataset without completing the research. Since then, I inspect sources, tool-call records and intermediate outputs, not just the final table.
My second strange encounter came from early work using a deep learning model to forecast renewable generation, a time-series regression task. The model performed well on the training and validation sets, with no obvious overfitting. Yet, while checking the raw data, I found a solar site exporting electricity at night. The site had a co-located battery, and the night-time output came from battery discharge, not from the photovoltaic system.
After correcting the site definition, I evaluated the model on an independent test set, but its predictions still deviated substantially from the observed output. A discussion with a colleague helped me realise the training data also reflected curtailment. Actual exported generation depends not only on the weather resource, but on network constraints, prices and dispatch decisions. The model had learned these together, so while the metrics looked good, they did not represent the physical process I intended to study.
I set out to predict exported generation without accounting for the curtailment already in the training data. Curtailed periods are not labelled – output simply drops, and a drop caused by the market looks much like a drop caused by the weather. Once I understood what was occurring, I changed the target to unconstrained available generation. Curtailment was noise for this particular model, and so curtailed periods should have been filtered out, not learned from.
The third case unsettles me most because I had defined things properly. In a long analysis, after numerous exchanges, the model began compressing earlier parts of the conversation to stay within its context window – the amount of text it can hold at once. As a result, the definitions I set at the start were the first to go. It lost the basis I had specified for aggregating a set of figures, chose one of its own, and carried on as though that were what I had asked for. Nothing in the output indicated this shift.
The first example was a loss of control over execution. In the second, the model did exactly as asked. The gap was in what I asked for, not in what it did. The third was a crucial definition I had set, quietly disappearing. Writing the code is not the hard part; knowing what to ask for, and noticing when the answer stops matching the question, is. Today when garbage comes out, it no longer looks like garbage: it arrives clean, structured and persuasive.
The unavoidable
4. Effort did not disappear, it moved
Learning faster and waiting less both came with something I did not expect. AI has made me fast enough to keep several tasks moving at once, but my attention has not scaled with it. Switching between them, I spend the first minutes working out where the AI got to and what I have already checked. The effort has not gone away. It has moved from doing the work to confirming the work has been done.
The obvious response is to give the checking to another model. That does reduce the volume. But even though AI branding emphasises the differences between models, in my experience they tend to fail in similar places. The type of mistake one makes is not the kind another is well placed to notice, and a second model can bring errors of its own. Unless there is something outside both to check against, like market documentation, the gap does not entirely close.
Neo’s advantage in The Matrix was that he could tell what was rendered and what was real. AI gives us a particularly smooth surface to interact with. Sometimes it is what it appears to be: a helpful sparring partner for learning, an assistant that frees us from waiting on colleagues. Other times the surface is a mirage.
Telling one from the other is the work that has not gone anywhere.
Four lessons from using AI in energy sector
In my experience as an AI software engineer in the energy industry, this technology brings dynamism to our complex sector. But I have also seen AI go astray for all kinds of reasons. Here is the good, the bad, and the unavoidable of working with AI in energy.
Growing up, I loved the film The Matrix. What stayed with me was not the fighting, but the way lead character Neo learned to tell what was rendered from what was real. Once he saw the difference, he stopped taking the rules as given.
AI feels close to omnipotent now. It answers anything, and its answers are so well rendered that they’re life-like. Which puts me somewhere near where Neo started: trying to work out what’s real and what is simply a veneer of realness.
The good
1. You forget what AI tells you; you remember what it corrects
Most of my work has been in the Australian National Energy Market (NEM), so when I had to investigate Great Britain’s market I started where most people would – by asking AI to explain the pricing mechanism.
It returned a detailed answer. I read it carefully and became more confused. By the time I understood what a Final Physical Notification (FPN) was, I’d forgotten why it existed. Each concept made sense alone; the system did not.
So, I tried inverting the script. Instead of asking AI to explain the market, I explained the mechanisms in my own words and asked it to find the mistakes. That worked better. The language was mine, so it stayed, as did the corrections, because I knew where I had gone wrong. After a few rounds I could explain which parts mattered and how they connected, instead of reciting rules.
Anything important enough for my notes still gets checked against official documentation. But as a sparring partner, AI is more patient and pliable than any document.
2. What we called division of labour was often just waiting
Before an energy model can do useful work, someone has to clean the data: different sources, inconsistent definitions, mixed units, incompatible timestamps. If you put garbage in, you get garbage out. In our work this often takes one to two weeks, and is usually done by the modeller who will later build the model. By the time they reach the design, much of the month is gone, and little of that work used their strongest skills.
Then there is another kind of wasted time. Not long ago a colleague who works on data visualisation needed a specific set of numbers. He knew what he wanted, but the numbers sat across several tables.
He does not write those queries himself, so he passed the request on. That person took a day to get back to him. A clear question sat idle for a day.
We rarely used to see this as a problem. We called it division of labour: people do what they are good at, and when you need someone else, you wait.
AI has changed this. My visualisation colleague no longer hands off this kind of query. He can describe what he wants in natural language and can access the data immediately. I checked a recent request afterwards; it was correct.
AI has removed the need to hand certain questions to someone else for translation, and data cleaning no longer consumes whole blocks of specialist time. It has cut the waiting, both for a colleague with the right skill and for the clerical half of your own job to be over.
The bad
3. AI can use real data to tell a wrong story
Some AI errors are absurd, but others arrive with a plausible explanation. This makes them harder to catch. Three of these happened to me:
In one case, I asked a Large Language Model (LLM) to collect public information on grid assets item by item. At first, it visited different pages and organised the sources. But after several rounds it stopped searching, and instead copied information already collected for other entries, writing a script to fill the remaining unverified records.
The information was not invented from nothing. Some of it was real, but assigned to the wrong entries. The issue was that the dataset was formatted so neatly it looked more credible than a table containing missing values.
Asked to explain this, the LLM claimed that some entries were too minor to justify individual checks. A model’s explanation of its own behaviour may not reflect the actual generation process, nonetheless the outcome was clear: it had bypassed the intended workflow for one that produced a complete-looking dataset without completing the research. Since then, I inspect sources, tool-call records and intermediate outputs, not just the final table.
My second strange encounter came from early work using a deep learning model to forecast renewable generation, a time-series regression task. The model performed well on the training and validation sets, with no obvious overfitting. Yet, while checking the raw data, I found a solar site exporting electricity at night. The site had a co-located battery, and the night-time output came from battery discharge, not from the photovoltaic system.
After correcting the site definition, I evaluated the model on an independent test set, but its predictions still deviated substantially from the observed output. A discussion with a colleague helped me realise the training data also reflected curtailment. Actual exported generation depends not only on the weather resource, but on network constraints, prices and dispatch decisions. The model had learned these together, so while the metrics looked good, they did not represent the physical process I intended to study.
I set out to predict exported generation without accounting for the curtailment already in the training data. Curtailed periods are not labelled – output simply drops, and a drop caused by the market looks much like a drop caused by the weather. Once I understood what was occurring, I changed the target to unconstrained available generation. Curtailment was noise for this particular model, and so curtailed periods should have been filtered out, not learned from.
The third case unsettles me most because I had defined things properly. In a long analysis, after numerous exchanges, the model began compressing earlier parts of the conversation to stay within its context window – the amount of text it can hold at once. As a result, the definitions I set at the start were the first to go. It lost the basis I had specified for aggregating a set of figures, chose one of its own, and carried on as though that were what I had asked for. Nothing in the output indicated this shift.
The first example was a loss of control over execution. In the second, the model did exactly as asked. The gap was in what I asked for, not in what it did. The third was a crucial definition I had set, quietly disappearing. Writing the code is not the hard part; knowing what to ask for, and noticing when the answer stops matching the question, is. Today when garbage comes out, it no longer looks like garbage: it arrives clean, structured and persuasive.
The unavoidable
4. Effort did not disappear, it moved
Learning faster and waiting less both came with something I did not expect. AI has made me fast enough to keep several tasks moving at once, but my attention has not scaled with it. Switching between them, I spend the first minutes working out where the AI got to and what I have already checked. The effort has not gone away. It has moved from doing the work to confirming the work has been done.
The obvious response is to give the checking to another model. That does reduce the volume. But even though AI branding emphasises the differences between models, in my experience they tend to fail in similar places. The type of mistake one makes is not the kind another is well placed to notice, and a second model can bring errors of its own. Unless there is something outside both to check against, like market documentation, the gap does not entirely close.
Neo’s advantage in The Matrix was that he could tell what was rendered and what was real. AI gives us a particularly smooth surface to interact with. Sometimes it is what it appears to be: a helpful sparring partner for learning, an assistant that frees us from waiting on colleagues. Other times the surface is a mirage.
Telling one from the other is the work that has not gone anywhere.
Four lessons from using AI in energy sector
In my experience as an AI software engineer in the energy industry, this technology brings dynamism to our complex sector. But I have also seen AI go astray for all kinds of reasons. Here is the good, the bad, and the unavoidable of working with AI in energy.
Growing up, I loved the film The Matrix. What stayed with me was not the fighting, but the way lead character Neo learned to tell what was rendered from what was real. Once he saw the difference, he stopped taking the rules as given.
AI feels close to omnipotent now. It answers anything, and its answers are so well rendered that they’re life-like. Which puts me somewhere near where Neo started: trying to work out what’s real and what is simply a veneer of realness.
The good
1. You forget what AI tells you; you remember what it corrects
Most of my work has been in the Australian National Energy Market (NEM), so when I had to investigate Great Britain’s market I started where most people would – by asking AI to explain the pricing mechanism.
It returned a detailed answer. I read it carefully and became more confused. By the time I understood what a Final Physical Notification (FPN) was, I’d forgotten why it existed. Each concept made sense alone; the system did not.
So, I tried inverting the script. Instead of asking AI to explain the market, I explained the mechanisms in my own words and asked it to find the mistakes. That worked better. The language was mine, so it stayed, as did the corrections, because I knew where I had gone wrong. After a few rounds I could explain which parts mattered and how they connected, instead of reciting rules.
Anything important enough for my notes still gets checked against official documentation. But as a sparring partner, AI is more patient and pliable than any document.
2. What we called division of labour was often just waiting
Before an energy model can do useful work, someone has to clean the data: different sources, inconsistent definitions, mixed units, incompatible timestamps. If you put garbage in, you get garbage out. In our work this often takes one to two weeks, and is usually done by the modeller who will later build the model. By the time they reach the design, much of the month is gone, and little of that work used their strongest skills.
Then there is another kind of wasted time. Not long ago a colleague who works on data visualisation needed a specific set of numbers. He knew what he wanted, but the numbers sat across several tables.
He does not write those queries himself, so he passed the request on. That person took a day to get back to him. A clear question sat idle for a day.
We rarely used to see this as a problem. We called it division of labour: people do what they are good at, and when you need someone else, you wait.
AI has changed this. My visualisation colleague no longer hands off this kind of query. He can describe what he wants in natural language and can access the data immediately. I checked a recent request afterwards; it was correct.
AI has removed the need to hand certain questions to someone else for translation, and data cleaning no longer consumes whole blocks of specialist time. It has cut the waiting, both for a colleague with the right skill and for the clerical half of your own job to be over.
The bad
3. AI can use real data to tell a wrong story
Some AI errors are absurd, but others arrive with a plausible explanation. This makes them harder to catch. Three of these happened to me:
In one case, I asked a Large Language Model (LLM) to collect public information on grid assets item by item. At first, it visited different pages and organised the sources. But after several rounds it stopped searching, and instead copied information already collected for other entries, writing a script to fill the remaining unverified records.
The information was not invented from nothing. Some of it was real, but assigned to the wrong entries. The issue was that the dataset was formatted so neatly it looked more credible than a table containing missing values.
Asked to explain this, the LLM claimed that some entries were too minor to justify individual checks. A model’s explanation of its own behaviour may not reflect the actual generation process, nonetheless the outcome was clear: it had bypassed the intended workflow for one that produced a complete-looking dataset without completing the research. Since then, I inspect sources, tool-call records and intermediate outputs, not just the final table.
My second strange encounter came from early work using a deep learning model to forecast renewable generation, a time-series regression task. The model performed well on the training and validation sets, with no obvious overfitting. Yet, while checking the raw data, I found a solar site exporting electricity at night. The site had a co-located battery, and the night-time output came from battery discharge, not from the photovoltaic system.
After correcting the site definition, I evaluated the model on an independent test set, but its predictions still deviated substantially from the observed output. A discussion with a colleague helped me realise the training data also reflected curtailment. Actual exported generation depends not only on the weather resource, but on network constraints, prices and dispatch decisions. The model had learned these together, so while the metrics looked good, they did not represent the physical process I intended to study.
I set out to predict exported generation without accounting for the curtailment already in the training data. Curtailed periods are not labelled – output simply drops, and a drop caused by the market looks much like a drop caused by the weather. Once I understood what was occurring, I changed the target to unconstrained available generation. Curtailment was noise for this particular model, and so curtailed periods should have been filtered out, not learned from.
The third case unsettles me most because I had defined things properly. In a long analysis, after numerous exchanges, the model began compressing earlier parts of the conversation to stay within its context window – the amount of text it can hold at once. As a result, the definitions I set at the start were the first to go. It lost the basis I had specified for aggregating a set of figures, chose one of its own, and carried on as though that were what I had asked for. Nothing in the output indicated this shift.
The first example was a loss of control over execution. In the second, the model did exactly as asked. The gap was in what I asked for, not in what it did. The third was a crucial definition I had set, quietly disappearing. Writing the code is not the hard part; knowing what to ask for, and noticing when the answer stops matching the question, is. Today when garbage comes out, it no longer looks like garbage: it arrives clean, structured and persuasive.
The unavoidable
4. Effort did not disappear, it moved
Learning faster and waiting less both came with something I did not expect. AI has made me fast enough to keep several tasks moving at once, but my attention has not scaled with it. Switching between them, I spend the first minutes working out where the AI got to and what I have already checked. The effort has not gone away. It has moved from doing the work to confirming the work has been done.
The obvious response is to give the checking to another model. That does reduce the volume. But even though AI branding emphasises the differences between models, in my experience they tend to fail in similar places. The type of mistake one makes is not the kind another is well placed to notice, and a second model can bring errors of its own. Unless there is something outside both to check against, like market documentation, the gap does not entirely close.
Neo’s advantage in The Matrix was that he could tell what was rendered and what was real. AI gives us a particularly smooth surface to interact with. Sometimes it is what it appears to be: a helpful sparring partner for learning, an assistant that frees us from waiting on colleagues. Other times the surface is a mirage.
Telling one from the other is the work that has not gone anywhere.
.png)