Today, the United States turns 250.
Most of the attention will be on the celebration. Mine keeps drifting to the design. The most useful way to honor a founding is not nostalgia. It is to borrow the design pattern.
I should be clear about what this is. I am not a historian or a political scientist, and this is not a political post. I am an engineer working on a specific problem: how to safely delegate real work to AI agents. The anniversary just happens to put a 250-year-old answer to a similar problem back in the news.
Read through an engineer’s eyes, the founding was a systems architecture problem. The Constitution is a governance framework for a country of non-deterministic agents: millions of humans who are unpredictable, self-interested, occasionally brilliant, and frequently wrong. The founders did not try to fix human nature. They built a structure that assumed it. Madison put the operating principle plainly in Federalist No. 51: “Ambition must be made to counteract ambition.” And a few lines later: “If men were angels, no government would be necessary.”
That may be the most relevant sentence in 18th-century political thought for the age of AI agents. Because agents are not angels either. They hallucinate. They inherit poisoned context. They produce confident nonsense. And they are moving from answering questions to taking actions: sending emails, opening pull requests, negotiating with other agents, spending money.
So the question is not: Can I trust this agent?
The better question is: Can I trust the system that governs this agent?
That is a different question. It is also the question constitutional government was built to answer.
Before the branches, the American design settles a prior question: who holds power in the first place? Not the government. The people. Every power the government has is delegated, enumerated, and revocable. That is what sovereignty means.
In your agent republic, the sovereign is you. Agents hold no native authority. Everything they can do is delegated from you, everything delegated is bounded, and everything bounded can be revoked. Agenda-setting stays with the sovereign too: agents work in response to your mandate, not their own.
Hold onto that, because every design choice below is downstream of it.
There are two obvious ways to use agents, and both fail.
The first is blind trust: ask the agent, accept the answer, let it act, hope it was right. This is how you get a model making a bad assumption, approving its own plan, and taking real-world action before anyone notices.
The second is exhaustive review: check every claim, approve every step manually. Safer, but it defeats the point. If the human must review everything, the human remains the bottleneck. The agent never becomes a delegate. It stays a typing accelerator.
The third path is constitutional:
Let agents work. Do not let one agent hold all powers.
That is the whole trick. Everything else is implementation detail.
The Constitution lists the branches in a deliberate order. Article I is the legislature. Article II is the executive. Article III is the courts. I will not pretend to know everything the framers meant by that sequence. But read as a design document, it sketches a theory of a high-trust society: law comes first, because most behavior in a functioning society is governed by rules people have already internalized, not by a judge pre-approving every act. Action comes second, with real latitude inside the law. Judgment comes last, after the fact, and its rulings feed back into the law.
Agents deserve the same order.
Legislative: write the law before any agent acts. Policies, acceptance criteria, budgets, boundaries. Versioned, testable, scoped, expiring. A prompt is advice; a policy is law. If your standards live only in a prompt, you have suggestions, not standards. The sovereign ratifies the law. Agents can help draft it, but they do not enact it.
You do not need a complete legal code on day one. The founders did not write one either. They started with a bill of rights: a short list of hard limits no future law could cross, and left the rest to be worked out. Your agent republic starts the same way. A handful of inviolable rules from the first hour: never spend money, never send anything external without a signature, never modify your own policies. Everything else starts narrow and grows. New laws get written the way they always have: when an edge case finds you.
Formation: evals are how agents grow up. Here is the piece most agent architectures skip. Think about how a human becomes trustworthy. Nobody hands a teenager the car keys after a courtroom hearing. They get years of formation: prompts revised constantly, right and wrong reinforced daily, small freedoms extended and sometimes pulled back. Evals are that process for agents. Continuous testing against the law, before consequential authority is ever granted. An agent does not earn latitude by seeming smart. It earns latitude by passing the curriculum, repeatedly, under conditions that look like the real job. Formation is what allows judgment to move to the end instead of blocking every act.
Executive: act within enumerated powers. The executive branch is the only one that mutates state, so its powers are enumerated, not general. Inside its jurisdiction, it moves fast and does not stop to ask permission. At the edges, it hits structure, not persuasion: deterministic gates that no clever argument can talk past. This is the pattern underneath the whole design: stochastic in thought, deterministic in authority. The founders could only make usurpation punishable. A gate makes it impossible. And some actions, like an irreversible wire transfer, sit outside any agent’s enumerated powers entirely and require the sovereign’s signature. That is not distrust. That is the constitution doing its job.
Judicial: review after, and let rulings compound. With law written and formation done, judgment can sit where the framers put it: at the end. Review after the fact only works if there is a record worth reviewing, so every meaningful action produces a receipt: the mandate, the policy version, the evidence, the tool calls, the outcome, the rollback path. Not the agent’s summary of the test run. The actual test output. Without receipts, after-the-fact review is theater. With them, the judicial function audits, adjudicates failures, and turns verdicts into precedent. A violation shrinks jurisdiction. A clean record expands it. Every ruling flows back into the law and the evals, so the system gets more trustworthy with use. Trust is jurisdiction: the calendar agent that safely rescheduled a hundred meetings earned autonomy for scheduling, not the right to move money.
In practice, all of this runs as one loop:
Law → Formation → Action → Receipt → Review → Amend
The sovereign holds the pen at both ends. You write the law, and you ratify the amendments. In between, agents act with real latitude, bounded by structure, accountable to review.
The doctrine is short:
Let stochastic systems advise. Let bounded systems act. Let humans amend.
The promise of agents is not that they will be perfect. They will not be. The promise is that we can build systems where trust is earned before authority is granted, and mistakes are caught, judged, and compounded into better law. That is what constitutional government tried to do for human power. It did not make people angels. It made power safer to grant.
None of it works, though, if you treat non-determinism as a defect to be engineered away. It is the feature. The reason to delegate to an agent at all is that it can produce answers you did not specify in advance. The same range of possibility that makes an agent useful is what makes it risky, and you cannot keep one while eliminating the other. The engineering problem is combining non-deterministic judgment with deterministic authority so the variance lands where you can afford it. And that requires leaders to accept something uncomfortable: some level of risk is the price of the reward. A republic that tolerates no failure gets no initiative. The founders accepted that trade for people. We will have to accept it for agents.
Two hundred fifty years is one experiment, still running, and I hold the analogy loosely. But it is also the longest-running production system we have for governing non-deterministic agents at scale, and it would be strange not to borrow from it.
As America turns 250, that may be the best idea to carry forward into the agent age:
Do not build oracle machines. Build trust machinery.
Fast where reversible. Careful where consequential. Impossible where forbidden. Audited where trusted. Human where sovereign.
]]>I’ll keep updating this as I find new ones worth keeping, or retire ones that stop being useful.
Most end up being people problems. The system does what the organization tells it to, whether anyone intended that or not.
Related: Conway’s Law
Being wrong is fine. Not understanding why is not. Before you tear something down, make sure you know why it was built in the first place.
Related: Chesterton’s Fence
Start simple, start now. A complex system that works is always built from a simple system that worked first. The bigger risk is standing still.
Related: Gall’s Law
Decide what matters. Then decide what doesn’t. Strategy isn’t something that happens to you. It’s something you choose.
The size of the team is not the measure of the impact. When the metric becomes the goal, it stops being a useful metric. This will matter even more as AI makes it possible to do more with less.
Related: Goodhart’s Law
Things will go wrong. Your composure determines the outcome. The person who stays calm in the room is usually the one who finds the way through.
Related: Murphy’s Law
Purpose before mechanics. Every feature, process, and meeting should be able to justify itself. If it can’t, remove it.
Related: YAGNI
The fastest way to a better answer is to put yours out first. Hold strong opinions loosely, and invite people to challenge them.
Related: Cunningham’s Law
Process should earn its place. Automate what you can, and regularly ask whether the rest is still necessary. If a process can’t be automated, it should at least be intentional.
Related: Scout Rule
Transparency surfaces problems faster. Share what you learn. Reduce barriers for others. Open source isn’t an identity; it’s a strategy that works.
Related: Linus’s Law
Independence over output. The best thing you can do for someone is teach them to think for themselves. Multiply yourself through others, not by creating dependencies on yourself.
Last updated: April 2026
]]>Most systems don’t fail dramatically.
They fail quietly.
They slow down. They confuse people. They produce answers no one fully trusts. Responsibility blurs. Everyone stays busy, but nothing feels solid.
AI didn’t cause this. It exposed it.
The real problem is not intelligence — it’s loss of clarity.
Consider a common example: an organization deploys an AI system to triage support tickets, loans, claims, or incidents. At first, it works. Throughput improves. Costs drop. Humans remain “in the loop.”
Months later, something feels off.
Edge cases rise. Overrides become routine. When a bad decision occurs, no one can explain why the system behaved as it did. Postmortems point everywhere — the model, the data, the policy, the workflow. Responsibility dissolves into the system itself.
Nothing is obviously broken. But no one is confident.
This is quiet failure.
The instinctive response is to add more layers: dashboards, rules, approvals, governance. Each layer promises control, but together they reduce agency. Humans supervise outcomes they no longer understand.
Now compare that to a corrected version of the same system.
The organization redraws the boundaries.
Deterministic rules are made explicit and separated from probabilistic decisions. The model is constrained to recommendation, not execution, for high-risk cases. Every automated decision produces a short, human-readable rationale and a traceable path back to inputs and policy. Overrides are logged not as exceptions, but as learning signals.
Most importantly, responsibility is made local again: specific humans own specific failure modes.
The result is not perfect accuracy. It is something better.
Humans trust the system because they can interrogate it. Failures are faster to diagnose. Improvements compound because decisions leave artifacts. The system becomes easier to operate as it grows, not harder.
Aside: Agency is not the same thing as agents.
Agents are components that act.
Agency is the ability for humans to understand, intervene, and remain accountable.
You can add agents and still lose agency. Restoring it is a design choice.
Intelligence is no longer a black box. It is a tool.
The lesson is not “use less AI.”
It is design for clarity before scale.
Instead of asking, “How do we automate this?” ask:
Clarity is not simplicity.
Clarity is knowing where complexity belongs — and where it does not.
The future will not belong to those who build the smartest systems.
It will belong to those who build systems that stay legible as they grow.
That is how you scale intelligence without losing agency.
]]>Before applying for a job, take the time to research Red Hat and its culture. Start by reading about the company’s values, mission, and products. Look for information about the work environment to see if it’s a good fit for you. Read employee reviews and feedback online to get a better understanding of what it’s like to work at Red Hat. Keep in mind that Red Hat has a strong and unique culture, so it’s important to determine if it’s a good fit for you before you apply.
Reaching out to local Red Hat employees can provide valuable advice and guidance. Attend industry events and conferences where Red Hat employees might be present, and connect with them on LinkedIn, Twitter, GitHub, or other professional networks. Ask for referrals or introductions from your existing network. The goal should absolutely not be to secure a job through these connections, but rather to build a relationship and learn more about working at Red Hat.
After your research and interactions, you’re now sure you want to join Red Hat. Let’s start with the scenario to help you navigate the next few steps: At your current company, you are in a role that allows you to get exposure to Red Hat products. You find the idea of working with these products daily compelling. You also love sharing your knowledge with people, so you think a role in Consulting will be a good fit. Not only that, but you have been in your current role for a while, so you think the role of Senior Consultant is where you would fit in. Alright, now we can dig in.
Take a look at the available jobs on Red Hat’s website and review a few of them. Make sure to find the role that best fits your background, abilities, and area of interest. Some roles may be more focused on AppDev, while others may be more focused on the platform engineering and infrastructure side of the house.
Once you have a good understanding of the type of consulting role that best fits your background, abilities, and interests, it’s time to determine which part of the organization would be the best fit for you. There are different teams within Red Hat that support different types of customers. For example, there is a team that supports public sector customers (NAPS, the North American Public Sector group) like the Department of Defense and many well-known public service providers. On the other hand, there are consultants who support commercial customers (NACOM, North America Commercial) such as healthcare providers, banks, telecommunications companies, and other well-known brands.
After identifying which part of the organization you are best suited, you can then start searching for the specific job posting that matches your skills and experience. The job postings available on Red Hat’s website usually provide a clear description of the expectations and responsibilities of each role. Make sure to read a few of these postings to get a better understanding of the types of roles available and to find one that best fits your needs.
Once you’ve found a role (or roles) you would be a good candidate for, it’s time to apply. This should go without saying, but you need to ensure that your resume and cover letter (assuming it is needed) are up-to-date and that they accurately reflect your relevant skills and experience. Tailor your cover letter to the specific role you are applying for and emphasize your passion for Red Hat’s products and culture. Highlighting your relevant experience and qualifications will increase your chances of standing out to hiring managers and getting hired.
Once you’ve updated your resume and cover letter, it’s time to apply for the job. Red Hat’s application process is straightforward and easy to navigate. You can apply for a job by clicking on the “Apply Now” button on the job posting. You will be asked to create an account and upload your resume and cover letter. You will also be asked to answer a few questions about your background and experience. Once you’ve completed the application, you will receive an email confirmation. If you are a good fit for the role, you will be contacted by a Red Hat recruiter to schedule an interview.
If you know someone at Red Hat, you can ask them to refer you for the role. This could increase your chances of getting hired. Even if it doesn’t increase your changes, it still allows the referring employee to help you with the application process, track your submission status, and to provide you with valuable feedback.
Getting hired at Red Hat requires not only a strong application but also a successful interview. It’s essential to prepare for the interview process by researching common interview questions and practicing your answers in advance. You don’t need to wear a suit and tie, but dress professionally. Red Hat is generally relaxed about clothes as it’s more important that you know your way around the technology, but it’s still important to make a good first impression. During the interview, make sure your enthusiasm for the company and interest in the role are clear. Ask thoughtful questions about the role and the company to demonstrate your interest and more importantly to get a better understanding of what it’s like to work at Red Hat. This is your chance to learn directly from the people who work there, so make the most of it.
If you are not hired right away, don’t get discouraged. Keep practicing your interview skills and networking. Stay in touch with your Red Hat contact and ask for feedback on your application. Keep working towards your goal and eventually, you will get there. In the meantime, consider taking courses or attending workshops related to Red Hat’s products and services to further your knowledge and skills. Stay up-to-date on the latest industry developments and participate in online forums or discussion groups to network with other professionals in the field. Obtain certifications and other credentials to demonstrate your expertise and increase your chances of getting hired. You should also consider volunteering for open source projects to gain valuable experience and build your resume.
Finally, it’s important to maintain genuine relationships with your Red Hat contacts. Consider connecting with them on LinkedIn or reaching out to them periodically to offer help and to check in and see if there are any new opportunities that would be a good fit for your skills and experience. By maintaining these relationships, you will not only increase your chances of being hired at Red Hat, but you will also have a strong network for when you are inevitably hired on to Red Hat.
Good luck with your job search!
]]>However, it’s important to use AI tools as a supplement to, rather than a replacement for, human expertise and judgment. While AI can be a useful tool, it’s not perfect, and it’s always a good idea to review the code that it generates to ensure that it meets the desired specifications and is of high quality.
What follows is my evaluation of the benefits and limitations of current AI tooling. I did not focus on any one single tool, but rather the genre as a whole. After exploring the landscape, we’ll wrap up with a few tips for using these tools effectively. Let’s dig in.
The Benefits of AI Tools:
The Limitations of AI Tools:
Despite these limitations, AI tools can still be a valuable addition to a software engineer’s toolkit when used effectively. And now for the tips I promised for using AI tools effectively in software development.
Tips for Using AI Tools Effectively:
By following these tips, you can maximize the value of AI tools in your workflow and avoid becoming overly reliant on them.
However, it’s always a good idea to periodically check in with yourself to ensure that you are using the tools effectively. One way to do this is to ask yourself the following “break glass” question (i.e. a question that’s available in case you don’t know what else to do): “If I had to write code manually, would I be able to do so effectively?” If the answer is “no,” it may be a sign that you are becoming overly reliant on the AI tool. In such cases, it may be a good idea to take a step back and reassess your use of the tool to ensure that it is being used effectively and in a way that complements your own skills and expertise.
Break Glass Question: “If I had to write code manually, would I be able to do so effectively?”
In some cases, you may be able to write large blocks of effective code manually without the help of an AI tool, but it might take longer because you would need to perform some research, make a number of decisions, and iterate towards a solution. In these situations, it’s important to be mindful of the scope of the AI usage and avoid biting off more than you can chew, as this can lead to the over-reliance problem mentioned earlier. To strike the right balance, consider using the AI tool to automate certain tasks or generate code for simple, routine tasks, while reserving more complex or creative tasks for yourself. This can help ensure that you are using the AI tool effectively and not asking it to do too much at once.
AI tools can be a valuable addition to a software engineer’s toolkit, providing the ability to generate code quickly and improve efficiency. But remember, it’s important to use these tools to supplement your own expertise and judgment, not to do all the work on your behalf. By understanding the benefits and limitations of AI tools, and using them effectively, you can maximize their value in your workflow.
Do you have any tips for using AI tools effectively in software development? Share your thoughts in the comments below!
]]>In addition to welcoming my third child into the world, I also had the opportunity to work on the VCS Collection System, a project that was a huge accomplishment for myself and my team. The VCS Collection System required tons of man hours to complete, but it allowed us to learn so much in such a short period of time – both about technology and about ourselves.
We spent two years building and supporting multiple systems to help customers safely return to the office at the end of the pandemic. On top of that, we open sourced the VCS Collection System in accordance with our values, making the code freely available to the public.
In a future blog post, I will go into more detail about the VCS Collection System and the challenges and triumphs we faced while working on it.
One of the highlights of the year for me actually happened relatively recently with the rise of ChatGPT, which broke the internet. Likewise, it has consumed much of my time since. It has been an exciting and challenging experience learning about this new technology, and I have enjoyed figuring out how to use it effectively in my everyday life.
Moreover, I have enjoyed finding and contributing to the LangChain community. LangChain is an open source LLM python library. I stumbled upon the project while building an application and had just overcome a technical hurdle. It was frustrating at first because I felt like it had been wasted time, but I realized that it helped me better understand the library from the start. My contributions to-date have been relatively small, but it’s been fun watching the community grow and solve problems day in and day out. I plan to continue contributing in the foreseeable future.
As I look ahead to the new year, I am excited to continue building on the progress I have made in terms of personal goals. I have been focusing on building technical depth and consistency, and I am proud of the progress I have made. In 2023, I hope to see even more progress in these areas, as well as continue building strong relationships in my open source communities.
To ring in the new year, I will be keeping things low-key with family. Thank you for reading my blog post. If you have any comments or questions, please find me on Twitter. I would love to hear from you! Here’s to a successful and fulfilling 2023!
]]>First things first, what’s your goal? Do you want to build a killer app, solve a specific problem, or just learn a new skill? Having a clear goal will help keep you motivated and focused as you work your way through the learning process.
Now, let’s talk about choosing a programming language. There are tons of options out there, but if you’re just starting out and feeling a little overwhelmed, Python is a great choice. It’s versatile, easy to use, and has a huge community of developers. Plus, it’s used in all sorts of applications, from web development to data analysis.
As you start learning, it’s helpful to find an instructor or resource that clicks with you. YouTube is a great place to find programming tutorials and courses, and there are tons of talented and experienced instructors out there who offer their knowledge for free. Look for content that’s easy to understand and fits your learning style – it’ll make the process much more efficient and enjoyable.
Okay, so you’re working through a tutorial and suddenly you hit a wall. Don’t worry, this is completely normal! When you get stuck, take a break, do some additional research, and try again. It’s important to be persistent and keep trying until you fully grasp the concept. And remember, practice makes perfect – the more you code, the better you’ll get.
As you continue learning and solving problems, you’ll start to identify areas where you have a solid understanding and others where you might need to improve. Focus on learning concepts rather than technologies – technologies come and go, but the underlying concepts stay the same.
In addition to your primary instructor or course, it’s helpful to seek out additional resources like online documentation (don’t be afraid to read the docs), forums, and online communities. These can provide additional perspectives and help you troubleshoot problems.
Collaborating with others is also a great way to learn and improve your skills. If you’re in school, consider joining a programming club or online community, or working on a project with a group of friends or classmates. If you’re not in school, Twitter, StackOverflow, and GitHub are excellent places to find experienced and helpful people.
And don’t forget to stay up to date! The field of programming is constantly evolving, with new technologies and techniques being developed all the time. Keep an eye on industry newsletters, blogs, and social media accounts to stay informed about the latest developments. You don’t need to take action on the new hotness right away, but if it comes up multiple times from a variety of resources it might be time to explore it further.
Finally, don’t be afraid to ask for help. It’s okay to not know everything, and there are tons of people out there who are willing to help you learn and grow. Reach out to your instructor, a mentor, or a community for assistance when you’re stuck.
In summary, the key to becoming a successful programmer is to have a clear goal, choose a language that fits your needs, find an instructor you enjoy learning from, be persistent in your learning and problem-solving, and don’t be afraid to ask for help. With dedication and hard work, you can achieve your programming goals and even turn it into a rewarding career. Good luck, and happy coding!
]]>Are you looking for a way to deploy your Next.JS application to multiple stages or environments, such as staging and production? In this blog post, I’ll show you how to use GitHub Pages and Actions to set up a multi-stage deployment process for your Next.JS application.
GitHub Pages is a free hosting service that allows you to publish static websites directly from a GitHub repository (provided you follow their generous terms of service). You can use GitHub Pages to host your Next.JS application in the staging environment by pushing your code changes to the main branch of a repository.
To set up GitHub Pages for the staging environment, follow these steps:
main branch.main branch of the repository. The application will be automatically deployed to the staging environment by GitHub Pages.GitHub Actions is a powerful tool that allows you to automate your workflow and build, test, and deploy your applications. You can use GitHub Actions to set up a workflow that deploys your Next.JS application to the production environment when you create a new release and tag it with the desired version number.
To set up GitHub Actions for the production environment, follow these steps:
By using GitHub Pages and Actions, you can easily set up a multi-stage deployment process for your Next.JS application. Whether you’re deploying to staging or production, these tools make it easy to automate your workflow and ensure that your application is always up-to-date.
I hope this blog post has helped you understand how to use GitHub Pages and Actions to deploy your Next.JS application to multiple stages or environments. If you have any questions or comments, feel free to reach out to me on Twitter or LinkedIn.
Repositories:
Live demo sites:
]]>Today, I wanted to share a simple yet timeless message with all of you: “Hello, world!”
You may be wondering, what does this phrase mean and why is it so important? Well, “Hello, world!” is often used as a starting point for new programmers learning a programming language. It is a simple program that outputs the message “Hello, world!” to the screen, which serves as a way to verify that the basic syntax of the programming language is correct and that the programmer’s environment is set up properly.
But beyond just being a technical exercise, “Hello, world!” is a way to connect with others and to start building a community. It’s a way of saying “I’m here, and I’m excited to share my thoughts and experiences with you.”
So with that said, I hope that this simple message can serve as a reminder to stay connected and to always keep learning and growing. Whether you’re a seasoned programmer or just starting out, there is always more to learn and discover.
Thank you for stopping by and I hope you’ll join me on this journey of self-discovery and growth.
Until next time.
]]>