My Job Is To Ask Is This True?
January 24, 2026
The more time I spend as an engineer, the more I realize that the fundamental purpose of my job is to interrogate whether an assumption is true. Sure, sometimes I am asked to create code that nudges the software in a direction that will align it with the current business goals, and much of that work also involves determining whether the assumptions made along the way are correct.
When the job is not about determining whether the present assumptions are true, it means that I must instead determine whether present desires conform with accepted truisms of the past. Instead of asking if something is true, it becomes a matter of asking if something will be true when we pull on a given thread.
Every process involved in the management of software is some variation of this. When preparing a release, we might want to know what the last good deployed version is to roll back quickly if there is an issue. Communicating what the last known good version is should be simple; check the pipelines to see which version made it all the way to production.
That can be reliable and is usually correct, but does the deploy system have a means of getting something to production outside the pipeline? If so, the best course of action is to get as close to the metal where code is deployed and check the version that is running, then communicate that in the rollback plan. Once that is done, you immediately have the task of ensuring you still have the means to deploy the last known good version. It's verification all the way down..
All of these things eventually become second nature to a seasoned employee because they have done the hard work of validation many times before and possess the Fingerspitzengefühl to execute these backup plans without needing to rummage around the innards of a run book. Some environments may have more advanced processes than what is described here, but there is definitely an engineer somewhere in that process who knows how to get the truth. Or in the case of the mass layoffs that we have seen in the tech industry, this person existed within the company at some point.
Is being a ruthless paranoid about where one gets their deployment information from necessary? 9.9 times out of 10, it is probably sufficient to check readout of your pipeline; however, being paged when you're out of office for that .1 percent of time weighs heavy on the soul.
What about configuring your ./well-known files for integrating new interactions into your Android and iOS applications? Can you update those files without impacting production? Are you sure? Do you want to be wrong? What is the process for modifying these files in your top-level production domains versus development & testing subdomains? Does that exist, or do you have to go spelunking? One thing is certain: if the documentation doesn't already exist, it is unlikely that an LLM can traverse the corporate networks and social structures to get you the truth. Nor do they know who and how to get the permissions from so you eventually can update them. Even if you can get permissions to update the files, do those permissions grant you the ability to modify how domains route traffic to staging versus production versions of the files? If they don't, you're back to traversing the labyrinth. The writing and management of software is a constant process of communication and navigating complex social networks. Coming up with an accurate, reproducible answer is your job as the engineer, and being wrong threatens the fundamental technical goals and, usually, the bottom line.
What about developers whose work is closer to simply implementing feature work and bug fixes? Surely, that might be a good use case. Let's assume your team does not believe in solving every problem in-house and prefers to import packages for certain solved problems, like a parsing library. Does that library you pulled in handle your needs out of the box? It looks like it parses information the exact way you need it to, but what about the edge cases? It is here you would read the docs and scan the code to see if anything is called out. You might even set up tests for your use cases before importing the library. At this stage you are verifying whether the parser conforms to all the assumptions. Here you might be tempted to throw an LLM at the code generation, but you are still responsible for the truth and now instead of doing the (widely considered) fun part of being a software engineer (writing code) your main task is now the (widely considered) laborious part of being a software engineer (reviewing code).
Writing software for solo projects differs slightly. I might need to spend some time challenging assumptions before I get to writing code but through being responsible for implementation and knowing the desired outcomes I have a pretty innate understanding if a behavior is or is not going to be true. I might think of an edge case as I continue development or it may surface through testing. Writing for yourself does not mean that you stop asking if things are true but it does mean that by virtue of having the desires, ideas, knowledge, and skills siloed within your brain it means that you get to interrogate the veracity of the more difficult problems sooner. Doing your job as an engineer within an organization means that at every step you should be validating truthfulness because communication is messy and often other people with different assumptions or motivations tread the path before you.
Introducing a non-deterministic bot into your workflow means that you sacrifice the siloed skill, knowledge, ideas, and desire in order to get faster outputs. This work flow ends up looking eerily similar to working a day job. You do not get to skip a bunch of verification steps. Instead, you replace emails with a chat interface where you ask a text generator follow-up questions and issue corrections. By pursuing this methodology, you have given up the benefits of a siloed work environment and decided to pay for the privilege of roleplaying what it's like to be a software engineer in a corporate work environment. You can, of course, skip some of these steps for 'speed,' but the probabilistic nature of the tool means you never know if you are merely borrowing against your future time.
Sure, sometimes the bot may highlight an element you were unaware of or direct you to the perfect library or do any number of the things that look like what you get when working collaboratively with other people. The only difference is that if I am work shopping which library we will use to support us in implementing a feature, I can ask my coworker to go validate that it actually handles x,y, and z as well as whether it complies with our license policy. We might even say, put the results into a spike where one of the artifacts is the reference implementation for the team.
I can ask a chatbot these questions, and it might give me the right answers, but if it is wrong and I ship it, I cannot tell my manager that "the bot said it was correct" because my job is to evaluate whether something is true, and it turns out my coworker has the same obligation. I might need to glance over my colleagues work for my own understanding, but because I have great coworkers, I don't have to be on edge that they are getting something subtly wrong on every task. LLMs are not great coworkers; outright or subtle wrongness is baked into how they work.
Which brings me to the real meat of this. If my job is to determine whether assumptions are true or that a process will produce consistent results each and every time. Why would I introduce a system into my workflow that increases the frequency where I need to determine the truth? If I work to the same standards when I am alone that I do when I am at work, I have no doubt that removing the benefits of being siloed would slow me down. If suddenly I and every other coworker and add a slot machine bot that might be accurate to our work, that will increase how much verification we need to do. Not only through the issues introduced by the bot but also because that goodwill and trust we formerly had for one another has been kicked in a chest out the window in service of a hype cycle.
I can see how getting a system to transform text into something that looks like the right format might be useful, but I'm not sure that it is better than a template. The tedious part of reports, Jira tickets, etc., is the boilerplate. The part that most people are paid for is the stuff that gets wedged in between the boilerplate, the actual communicative intent. Robust templating and scripting would get most people 80 percent of the way and save them time. That final 20 percent is what they are paid for. Using their brains and relationships to produce a written artifact that will inform the reader. Adding bots to this process increases the workload for everyone but the writer. If the writer cares about their job and double-checks everything anyway, it increases their workload too.
I do my fair share of soft and administrative engineering tasks, but assume that it's code that we are after. Writing code isn't the hard part. In fact, it is often a meditative respite after I have fully understood the problem and chased down the impacts of going in a given direction. The process of implementing the code myself grants me that Fingerspitzengefühl for when issues might arise. If I allow a bot to just have at it, when there is a bug, I will need to perform the much harder task of reading foreign code, and because none of my coworkers wrote it, I cannot ask them about it or for additional details. I could ask the bot that wrote it, but I am presumably in the middle of incident response and would prefer not to burn cycles interlocuting with something that fundamentally doesn't understand anything.
When your job is to determine if something is true, adding a random dice roller of subtle wrongness to the process might give you job security, but only if you want your job to become an accountability sink and nothing else. If you wish to be a skilled, knowledgeable worker whose word and efforts are trusted by your peers and managers, adding a large language model between you and your outputs will make that goal more difficult to grasp.