I write code for a living, but more and more I feel like my job is designing systems. Some of those systems include code I type. Some include services, models and tools that I orchestrate. The biggest shift is mental: stop thinking in files and start thinking in flows, boundaries, feedback and failure. If you have solid fundamentals, this moment can multiply your impact. If you treat every new tool like magic, it will waste your time and your client’s money.
Why systems thinking
Systems thinking is a habit. Map the parts, name the goal, set constraints, add feedback, and decide who owns what. It sounds obvious until you are in a rush. When I slow down and sketch the system, my work gets simpler and safer. It also makes new tech easier to evaluate. If a model or agent does not have a clear job, an input contract, and a way to check its output, it does not belong in the system.
I start with a few questions: what outcome am I building for, what are the inputs and outputs, where does the data come from, what can go wrong, and how will I know quickly when it does. Writing those answers first saves me pain later.
The multiplier
Good developers already break problems down, choose boring solutions, and automate the repeatable parts. New tools raise the ceiling when used with that mindset. A strong developer with a reliable assistant becomes a force. You can spin up drafts, scaffolds, tests and documents in minutes, then spend your energy on the last mile where judgment matters. You can search a large codebase faster, try three designs and compare trade offs, or turn a messy spec into clear steps.
That is the multiplier. Not pressing a button and hoping. It is using speed to explore the space, then applying taste and discipline to pick the right path.
Using the tools well
Here is how I try to do it in practice:
- Start with the system sketch. Draw the boxes and arrows. Decide where a model fits and where it does not.
- Write the definition of done. Make it a checklist tied to user outcomes, not tool features.
- Keep inputs clean. Structure prompts and data like an API. Version them. Review them.
- Add feedback. Log inputs and outputs. Sample and review them. Measure quality, cost and latency.
- Fail safe, not loud. Prefer defaults that keep users safe when any part misbehaves.
- Keep a human in the loop where harm is likely. Approval steps are part of the system.
- Prefer small loops. Ship a thin slice, evaluate it, then widen the scope.
Avoid a few traps: do not rebuild your stack because a demo looked shiny, do not hand core business logic to a tool you cannot verify, do not ignore cost curves, and do not pretend non‑determinism does not exist.
The tools are powerful, but the edges are rough. Evaluation is still young. Standards are still emerging. Teams are figuring out ownership between product, engineering and data. That is good news if you have patience.
When I add a model or agent to a project, I use a simple playbook: map the work, pick one low‑risk task with a clear success metric, define inputs and outputs like an interface with examples, build a small evaluator, add basic observability for cost, time and quality, ship to a small audience with a manual override, then review logs and decide to keep, iterate or remove.
This is not flashy, but it works. The model is a component in a system you understand, not a black box that “just does stuff”.
People and stack choices
Once you think in systems, hype loses its pull. A simple server rendered app with a queue and a cache is often the right base. If I need content editing and speed, I might choose WordPress or a static site generator. If I need heavy data or strict rules, I might choose Rails, Laravel or Django. Then I add the smallest set of model powered pieces that move the needle. The goal is a whole system that is clear, not a bag of cool parts.
The system includes the team and the client. That means habits like clear writing, honest estimates, and pushback when a path feels wrong. It means documentation that explains how to operate the thing, not just how to build it. It means a plan for handover so the next person is not trapped.
We are early, but not too early. The people who treat this wave like a system design problem will learn faster than the people who chase demos. If you have built reliable software with boring tools, you already have the right muscles. Add a few new ones: evaluation, data care, prompt design as interface design, and a bias toward safe defaults.
The future of programming is systems thinking. Code still matters. Taste still matters. What changes is where you spend your time. Less on typing, more on shaping flows, contracts and feedback. If you do that well, the new tools become a multiplier on top of skills you already have. And if you keep your values fixed on honesty and usefulness, you will build things you are proud to sign.