[{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/categories/article/","section":"categories","summary":"","title":"article","type":"categories"},{"content":"author profiles used by this site.\n","date":"26 April 2026","externalUrl":null,"permalink":"/authors/","section":"authors","summary":"author profiles used by this site.\n","title":"authors","type":"authors"},{"content":"i use categories as a lightweight navigation layer across related posts.\n","date":"26 April 2026","externalUrl":null,"permalink":"/categories/","section":"categories","summary":"i use categories as a lightweight navigation layer across related posts.\n","title":"categories","type":"categories"},{"content":"this series is where i publish the looser essays that do not fit a strict tutorial format.\n","date":"26 April 2026","externalUrl":null,"permalink":"/series/commentary/","section":"series","summary":"this series is where i publish the looser essays that do not fit a strict tutorial format.\n","title":"commentary","type":"series"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/commentary/","section":"tags","summary":"","title":"Commentary","type":"tags"},{"content":"strategies for protecting your attention, dealing with cognitive load, avoiding context switching, and doing deep work in a noisy environment\n","date":"26 April 2026","externalUrl":null,"permalink":"/tags/focus/","section":"tags","summary":"strategies for protecting your attention, dealing with cognitive load, avoiding context switching, and doing deep work in a noisy environment\n","title":"focus","type":"tags"},{"content":" thesis # my opinion on using wifi on a plane has shifted. i do not think it is the right default for everyone in every situation, but when i am traveling alone, especially for work, i have started to treat a connected cabin as a feature. it takes hours that used to feel like pure waiting, time i was just trying to burn through, and turns them into a stretch where i can work with a surprisingly solid level of focus and relatively few distractions.\ncontext # a few weeks ago i wrote about how torn i still was on this topic in plane wifi: when the cabin forced disconnect. that piece was an honest inventory of the tradeoffs. this one is an update from the other side of the choice, after i have spent more flights actually buying the pass and sitting down to work instead of debating it.\nargument # when i am alone and the trip is for my job, the row stops feeling like a cage and starts feeling like a quiet room with bad legroom. i already have headphones in, so the cabin noise is under control. notifications are fewer than at my desk, nobody is making noise by my office door, and the margin of \u0026ldquo;things i could be doing instead\u0026rdquo; feels narrower. it is not peace and it is not deep rest, but it is a usable kind of concentration.\ni am now using that block to write, to debug, to plan, and to close loops i would otherwise push to after i land. i go in knowing i will get a meaningful amount done, and that expectation makes the clock feel less stuck. the time still passes at the same speed, but it passes with output attached, and that changes how it feels in my body.\ni also have a concrete proof point that this mode is not just talk. i completely stood up my personal website while airborne, end to end, in one of those sessions. right now i am on a plane again, getting ahead for an in-person meeting so i can walk in prepared instead of scrambling on the jet bridge.\ntension or counterpoint # i am not arguing that every person should pay for wifi on every flight. shared trips, family logistics, the middle seat, motion sickness, or the simple need to be offline are all good reasons to skip it. economy is still a bad default office for anyone who needs space or quiet that the cabin cannot give. my point is narrower. for me, in the situations where it fits, the cost of the pass is cheaper than the opportunity cost of treating the whole flight as lost time.\nclosing # i will probably still sometimes want the cabin to be an excuse to be unreachable. when i do, i can leave the wifi off. when i do not, i am glad the option exists, and i am using it on purpose.\nfurther reading # in-flight connectivity, background on how internet reaches aircraft related on this site # plane wifi: when the cabin forced disconnect commentary series ","date":"26 April 2026","externalUrl":null,"permalink":"/posts/20260426-on-the-plane-again/","section":"posts","summary":"in-flight wifi is not for every traveler or every trip, but when i fly solo for work it turns dead time into a calm, contained place to think, build, and prepare. i am getting real work done up here, including this site and prep for meetings on the ground.","title":"on the plane, again","type":"posts"},{"content":"i am a senior data engineer who translates complex business problems into reliable, production-ready data solutions. this site is where i share the philliant lessons i have learned.\n","date":"26 April 2026","externalUrl":null,"permalink":"/authors/philip_mathew_hern/","section":"authors","summary":"i am a senior data engineer who translates complex business problems into reliable, production-ready data solutions. this site is where i share the philliant lessons i have learned.\n","title":"philip mathew hern","type":"authors"},{"content":" helping you shine philliantly this homepage is a profile-first entry point with recent posts underneath\n","date":"26 April 2026","externalUrl":null,"permalink":"/","section":"philliant","summary":" helping you shine philliantly this homepage is a profile-first entry point with recent posts underneath\n","title":"philliant","type":"page"},{"content":"long-form writing on projects, systems, and lessons learned\n","date":"26 April 2026","externalUrl":null,"permalink":"/posts/","section":"posts","summary":"long-form writing on projects, systems, and lessons learned\n","title":"posts","type":"posts"},{"content":"series pages are where i turn scattered posts into collections of guided learning paths.\neach series has a clear focus and a practical orientation so you can move through the material in a useful order. instead of searching by date alone, you can follow a topic from fundamentals through deeper implementation and reflection.\n","date":"26 April 2026","externalUrl":null,"permalink":"/series/","section":"series","summary":"series pages are where i turn scattered posts into collections of guided learning paths.\neach series has a clear focus and a practical orientation so you can move through the material in a useful order. instead of searching by date alone, you can follow a topic from fundamentals through deeper implementation and reflection.\n","title":"series","type":"series"},{"content":"explore the topics and themes i write about. most of my writing focuses on ai, workflows, and tools that help us do better work with less friction\n","date":"26 April 2026","externalUrl":null,"permalink":"/tags/","section":"tags","summary":"explore the topics and themes i write about. most of my writing focuses on ai, workflows, and tools that help us do better work with less friction\n","title":"tags","type":"tags"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/travel/","section":"tags","summary":"","title":"Travel","type":"tags"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/wifi/","section":"tags","summary":"","title":"Wifi","type":"tags"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/work/","section":"tags","summary":"","title":"Work","type":"tags"},{"content":"","date":"24 April 2026","externalUrl":null,"permalink":"/tags/decision-making/","section":"tags","summary":"","title":"Decision-Making","type":"tags"},{"content":"","date":"24 April 2026","externalUrl":null,"permalink":"/tags/growth/","section":"tags","summary":"","title":"Growth","type":"tags"},{"content":" thesis # learning basic logic is one of the most useful, durable skills i can recommend to anyone, regardless of profession. the english-language version of if/then/else is a thinking tool that works everywhere, never expires, and quietly compounds into better decisions over a lifetime.\ncontext # most people associate logic with code, math, or a philosophy classroom. that framing is too narrow. logic is just structured cause-and-effect thinking, and the simplest version of it sounds exactly like english:\nif this, then that, else that other thing\nonce you can hold that pattern in your head on purpose, it changes how you plan, diagnose, design, and interpret almost everything in front of you. you do not need a programming language to use it. you just need to be willing to slow down for a beat and think in branches instead of straight lines.\na few familiar gates # here a few small pictures to demonstrate simple examples of logic gates that you already use in daily life. this just illustrates it so you can literally follow along with the logic gates as each situation progresses.\nand both must be true for the outcome to be true or at least one true is enough not you follow the opposite branch of the test the flow is the same kind of small chart you would sketch on a napkin.\nflowchart TB subgraph g_and [and, both need to be true] direction LR w[good weather?] --\u003e and1{and} f[afternoon free?] --\u003e and1 and1 --\u003e|yes| hike[go hiking] and1 --\u003e|no| home[stay in] end subgraph g_or [or, at least one is enough] direction LR car[friend can drive?] --\u003e or1{or} bus[transit is running?] --\u003e or1 or1 --\u003e|yes| go[you can get there] or1 --\u003e|no| stuck[you are stuck] end subgraph g_not [not, the opposite branch of the test] direction LR pow[power on?] --\u003e|no| br[check the breaker] pow --\u003e|yes| next1[next check in the chain] end none of that requires a keyboard. it is the same branch habit as the if/then/else line in the last section, just drawn with a few boxes.\nargument # logic is a thinking tool, not a coding tool # the if/then/else pattern is older than any programming language. when i write a small script, i am formalizing the same branching i already do when i pick what to wear, route around traffic, or decide how to respond when something at work breaks. the keyboard is incidental, the structure is the point.\nthis kind of structured thinking is what moves me from \u0026ldquo;i feel stuck\u0026rdquo; to \u0026ldquo;what is the next decision, and what are the branches under it\u0026rdquo;. that small shift, from a vague feeling to a concrete branch point, is where most of the leverage comes from.\nwhere it pays off in normal life # once you start noticing branches, you see them everywhere. planning a day with kids becomes a small logic tree. if the weather holds, we hike. if it does not, we move to the indoor option. if both fail, we cancel and reschedule. naming the branches up front means the day does not collapse when conditions change.\ntroubleshooting has the same shape. when something is not working, i walk a tree out loud. if the appliance has power, then check the next link. if not, then check the breaker. each step rules out a branch and shrinks the search space.\ndesigning a process at work has the same bones. i list the conditions first, then the path each one takes. naming the branches early makes the design easier to explain and easier to fix later.\nunderstanding behavior is harder, but the structure still helps. people are not perfectly logical, but their patterns often are. if my kid is tired, then certain tantrums become more likely. if a colleague is overloaded, then certain reactions track. recognizing the antecedent makes the response less personal and easier to handle.\nreverse engineering is the same thing run backward. when i look at a result and want to understand how it got there, i walk the logic in reverse. if this output exists, then these inputs and conditions must have been true. if not, then the model i had in my head is wrong, and that gap is useful information on its own.\nthe tool never goes out of style # frameworks change. tools change. programming languages come and go. if/then/else does not. it is a structure of thought, not a piece of technology, which is why it keeps working in domains it was never designed for. cooking, parenting, negotiations, medical decision trees, customer support scripts, and legal arguments all lean on the same scaffolding.\ni find real comfort in skills that age well. so much of what i learn in tech has a short half-life now. logic does not. once i have it, i have it for good.\napplying it broadly is what makes it powerful # a tool that works in one place is useful. a tool that works everywhere is leverage. logic works everywhere because every domain has cause and effect, conditions, and outcomes. that generality is the multiplier, and it is the same kind of cross-domain value i wrote about with adaptability. the principle stays steady while the surface details swap.\nlearn it as early as you can # the earlier this gets internalized, the more downstream decisions inherit it. a kid who can think in branches asks better questions, accepts fewer \u0026ldquo;because i said so\u0026rdquo; answers, and gradually builds a habit of checking conditions before reacting. that habit then runs in the background for the rest of their life.\ni think about this with my own kids, and i think about it for myself. every year i wait to make decisions more deliberately is a year of slightly noisier decisions stacked behind me.\nthe butterfly effect of better decisions # small improvements in single decisions do not look like much in isolation. two paths that differ by one degree at the start can end up far apart over a long enough timeline. better daily decisions, even by a thin margin, compound the same way a little becomes a lot does for habits. the quality of the inputs, repeated across years, becomes the quality of the life.\nlogic is one of the cheapest ways i know to nudge that compounding in a good direction.\ntension or counterpoint # logic on its own is not the whole answer. real situations carry emotion, ambiguity, missing information, and people who do not behave according to clean rules. if i treat every interaction like a flowchart, i lose intuition, empathy, and the ability to sit with uncertainty.\nthe skill is to use logic as scaffolding, not as a replacement for judgment. i map the branches i can see, then i listen for the part that the branches do not capture. both layers matter, and the logical part actually helps the intuitive part by giving it a clean place to stand.\nclosing # this is one of the cheapest, most durable investments anyone can make. learn the english-language form of if/then/else. practice naming the conditions and the branches in your own life. apply it to planning, troubleshooting, designing, and understanding the people around you.\nlearn it once and you keep it forever. apply it everywhere and it compounds. not many skills pay back like that.\nfurther reading # propositional logic decision tree critical thinking related on this site # adaptability little by little, a little becomes a lot comfortable being uncomfortable commentary series ","date":"24 April 2026","externalUrl":null,"permalink":"/posts/20260424-logic/","section":"posts","summary":"logic is not just for code. learning to think in if/then/else terms helps with planning, troubleshooting, designing, and understanding people and systems. once you learn it, you keep it forever, and the compounding effect of better decisions over time is hard to overstate.","title":"logic","type":"posts"},{"content":"","date":"24 April 2026","externalUrl":null,"permalink":"/tags/logic/","section":"tags","summary":"","title":"Logic","type":"tags"},{"content":"","date":"24 April 2026","externalUrl":null,"permalink":"/tags/problem-solving/","section":"tags","summary":"","title":"Problem-Solving","type":"tags"},{"content":"reflections on how we think, including mental models, decision-making frameworks, and the balance between human reasoning and automated logic\n","date":"24 April 2026","externalUrl":null,"permalink":"/tags/thinking/","section":"tags","summary":"reflections on how we think, including mental models, decision-making frameworks, and the balance between human reasoning and automated logic\n","title":"thinking","type":"tags"},{"content":" thesis # this is a small checkpoint post. the heavy lift is not finished, but i am out of the weeds for now, and that is worth naming out loud.\ncontext # the same work i was carrying in stick with it kept growing in weight and surface area. for a while it felt like one endless tangle. i stayed with it anyway, and eventually i approached it the way i should have from the start, as smaller chunks that stack into the much larger change. each piece still had to be real, but the sequencing and scope finally matched how my head and the system can tolerate change.\nargument # getting to a stable point did not erase the backlog. i still have more testing to run, more simulations to exercise, and real user acceptance testing ahead. the difference is that the foundation is no longer thrashing. errors and surprises have a place to land without undoing everything at once.\nthat stability is what gave me room to breathe. i can take a short break on purpose, look at the whole arc with a little distance, and come back to the tuning work with less panic and more optimism. the remaining work is still serious, but it is the kind of serious that fits a calendar instead of the kind that owns every waking hour.\ntension or counterpoint # a stable checkpoint is not the same as done. if i confuse relief for completion, i will skip validation i still need. the discipline now is to rest without pretending the job is closed.\nclosing # so i am back at it in a different posture, not firefighting the whole shape at once, but finishing the test matrix, listening to users, and dialing things in with a clearer mind. sticking with it got me here. the next stretch is about proving it in the world, calmly.\nfurther reading # chunking (psychology), on breaking information and work into manageable units related on this site # stick with it little by little, a little becomes a lot commentary series ","date":"22 April 2026","externalUrl":null,"permalink":"/posts/20260422-back-at-it/","section":"posts","summary":"i am finally out of the weeds on a recent heavy lift. i stuck with it the way i wrote about in stick with it, then moved the way i should have from the start, in smaller pieces that add up to the larger change. there is still testing and user acceptance ahead, but a stable baseline gives me room to step back, reset, and continue with a clearer head.","title":"back at it","type":"posts"},{"content":"","date":"22 April 2026","externalUrl":null,"permalink":"/tags/change/","section":"tags","summary":"","title":"Change","type":"tags"},{"content":"","date":"22 April 2026","externalUrl":null,"permalink":"/tags/persistence/","section":"tags","summary":"","title":"Persistence","type":"tags"},{"content":"","date":"22 April 2026","externalUrl":null,"permalink":"/tags/stress/","section":"tags","summary":"","title":"Stress","type":"tags"},{"content":"","date":"22 April 2026","externalUrl":null,"permalink":"/tags/testing/","section":"tags","summary":"","title":"Testing","type":"tags"},{"content":"explorations of how we work, covering systems, processes, and the practical habits required to maintain high throughput without burning out\n","date":"22 April 2026","externalUrl":null,"permalink":"/tags/workflow/","section":"tags","summary":"explorations of how we work, covering systems, processes, and the practical habits required to maintain high throughput without burning out\n","title":"workflow","type":"tags"},{"content":"","date":"16 April 2026","externalUrl":null,"permalink":"/tags/consistency/","section":"tags","summary":"","title":"Consistency","type":"tags"},{"content":"","date":"16 April 2026","externalUrl":null,"permalink":"/tags/self-talk/","section":"tags","summary":"","title":"Self-Talk","type":"tags"},{"content":" thesis # this one is for me as much as anyone reading. the single most important thing i can do on a long, hard project is keep showing up for it. motivation rises and falls, energy comes in waves, and neither of those things matter as much as continuity. if i stay with the work long enough, the payoff arrives, even when progress is invisible for stretches in the middle.\ncontext # i am in the middle of a very heavy lift right now. it started as a change i thought i would finish quickly, and it has turned into something much bigger. the effort, concentration, and validation required are more than i am used to, and the timeline has stretched well past what a typical change would take. the stress is real. i feel it in how i think about the project before bed and how quickly i reach for my laptop in the morning.\ni am still in it, though, because the value at the end is worth the cost. when this lands, i will have more stable and explainable historical data, which means my ongoing workload of troubleshooting data validity questions drops. less firefighting later is worth more pressure now, and that tradeoff is the only reason i would keep going through a change this heavy.\nargument # continuity beats intensity # motivation is a wave, not a rope. it pulls me forward for a while, then it lets go, then it comes back later with a different shape. if i tie my progress to the wave, i stop whenever the wave stops. if i tie my progress to the habit of showing up, the wave cannot take the project down with it. that is the same pattern i wrote about in little by little, a little becomes a lot, just applied to a single long problem instead of a daily practice.\nisolate your changes, even in your own playground # the hardest lesson from this round is about isolation. i have been testing work in an environment i consider my playground, and for a long time that has been fine. this time, my changes broke downstream consumers, and the pressure immediately escalated because other people were suddenly blocked. the takeaway is simple. if my changes can reach downstream consumers, i need to separate my testing from a shared test environment, regardless of how freely i am used to moving in that space. a playground still has neighbors.\ndo not try to lift several objects at once # i also tried to move multiple pieces of the system at the same time. i thought bundling them would be faster. what actually happened is that each piece depended on the others in a way that made every single one harder to validate, and the total stress grew faster than the total work. smaller, sequential chunks would have finished sooner and felt calmer. one object at a time, even if it feels slower on paper, is almost always faster in practice.\nbetter preparation shrinks the stress # the last lesson is about preparation. i went in expecting a small change and i prepared like it was a small change. when the scope grew, my preparation did not grow with it, and that mismatch is where the break points appeared. better preparation up front, regardless of how small i thought the task was, would have reduced both the stress and the number of places things could go wrong. the cost of preparing for a bigger job than you need is tiny. the cost of not preparing for the job you actually have is not.\ntension or counterpoint # persistence is not the same as refusing to reassess. sticking with every hard thing forever is just sunk cost fallacy wearing a motivational t-shirt. the honest check i keep running is whether the value at the end is still real and still mine. if the answer is yes, i keep going. if the answer turns into no, i stop, and that is not quitting, that is discernment.\nthere is also a stress cost to \u0026ldquo;push through\u0026rdquo; language. if the pressure is spilling into health, relationships, or judgment, that is a signal to change the pace, not a signal to try harder. pushing through is a tool, not a strategy, and it only works when i also rest and isolate the work properly. that is part of why i think it helps to get comfortable being uncomfortable without confusing discomfort for permission to keep grinding.\nclosing # so this is my note to myself. keep going. the work is real, the value is real, and the lessons i am collecting on the way are already paying off for the next change. next time i will isolate my testing better, break the work into one object at a time, and prepare like the task is bigger than i think it is, because it almost always is.\nand if the wave of motivation dips again tomorrow, that is fine. waves dip. what matters is that i still show up, finish one more piece, and trust that continuity is the actual engine. stick with it.\nfurther reading # grit (personality trait), angela duckworth on long-term persistence sunk cost fallacy, useful balance for deciding when to keep going versus when to stop related on this site # little by little, a little becomes a lot comfortable being uncomfortable adaptability commentary series ","date":"16 April 2026","externalUrl":null,"permalink":"/posts/20260416-stick-with-it/","section":"posts","summary":"i am in the middle of a heavy lift that has grown bigger than i thought, and i want to remind myself that continuity over time is what produces long-term results. motivation comes in waves, but sticking with the problem is how the value actually shows up.","title":"stick with it","type":"posts"},{"content":"","date":"10 April 2026","externalUrl":null,"permalink":"/tags/comfort-zone/","section":"tags","summary":"","title":"Comfort-Zone","type":"tags"},{"content":" thesis # i want to normalize a simple idea that still feels hard in practice. getting outside of your comfort zone is not a side quest. it is the main mechanism by which you stretch, learn, and see the world with more room in it for other people. yes, it is uncomfortable, and that is exactly the point.\ncontext # most of us are trained to seek stability. stability is not bad, but it is also not where the adaptation happens. when everything feels familiar, your brain is mostly rehearsing what it already knows. the moment you step into something new, the cost shows up immediately as awkwardness, uncertainty, or fear of looking foolish. that friction is not a sign you chose wrong. it is often a sign you chose honestly.\nargument # change is disruptive by definition. if it did not interrupt your default patterns, it would not be change. i think we should embrace that disruption more often, because it is where new experiences actually enter your life. without that interruption, you mostly get repetition with better packaging.\nthe growth part is not theoretical. discomfort is where skills get pressure-tested. you learn not only how to do things, but how not to do things, which is just as valuable and often faster feedback. mistakes in public or under stress are expensive emotionally, but they are also unusually clear. they show you boundaries, preferences, and limits in a way that a comfortable afternoon rarely will.\nmore experiences also broaden your worldview in a practical sense. when you have seen more contexts, constraints, and ways people solve problems, it becomes harder to treat your own habits as universal law. that widening tends to produce more tolerant and compassionate attitudes, not because tolerance is a slogan, but because you have more firsthand evidence that reasonable people can live and work in very different, equally valid ways.\nso my encouragement is simple. expose yourself to new experiences on purpose. seek situations where the pressure is on you to perform, because that is where you rise to the occasion and discover how capable you can be. it is also where you might discover that this is not your thing, and you should move on. either outcome is a win, because both give you self-insight you cannot fake. you learn what energizes you, what drains you, and what you are willing to practice until it gets easier.\nthis connects to how i think about adaptability in general. comfort is a resting state. adaptation requires movement.\ntension or counterpoint # there is a real downside to glorifying discomfort without boundaries. not every challenge is worth the cost, and not every \u0026ldquo;growth opportunity\u0026rdquo; is ethical or safe. pushing yourself is different from letting yourself be pushed past your values or health. the goal is not suffering for its own sake. the goal is chosen stretch, with recovery and discernment built in.\nclosing # i am not asking for constant chaos. i am asking for a bias toward the new when you can afford it, and toward the high-stakes try when you are ready. the uncomfortable path is where you find out who you are when the easy defaults are not available, and that knowledge is about as practical as it gets.\nfurther reading # comfort zone (psychology of performance and anxiety) related on this site # adaptability little by little, a little becomes a lot commentary series ","date":"10 April 2026","externalUrl":null,"permalink":"/posts/20260410-comfortable-being-uncomfortable/","section":"posts","summary":"growth rarely happens where you already feel at ease. change is disruptive by design, and the uncomfortable stretch is where new skills, boundaries, and compassion tend to show up.","title":"comfortable being uncomfortable","type":"posts"},{"content":"","date":"10 April 2026","externalUrl":null,"permalink":"/tags/learning/","section":"tags","summary":"","title":"Learning","type":"tags"},{"content":"","date":"10 April 2026","externalUrl":null,"permalink":"/tags/self-awareness/","section":"tags","summary":"","title":"Self-Awareness","type":"tags"},{"content":"","date":"8 April 2026","externalUrl":null,"permalink":"/tags/data-engineering/","section":"tags","summary":"","title":"Data-Engineering","type":"tags"},{"content":"this series is my working notebook for dbt architecture and transformation workflows.\ni care less about one-off clever models and more about systems that are easy to understand, easy to test, and easy to change six months later. when i publish here, i focus on practical design decisions and why they hold up under change.\nif there is a dbt topic you want prioritized, treat this as an open request queue and tell me what is most useful to publish next.\n","date":"8 April 2026","externalUrl":null,"permalink":"/series/dbt/","section":"series","summary":"this series is my working notebook for dbt architecture and transformation workflows.\ni care less about one-off clever models and more about systems that are easy to understand, easy to test, and easy to change six months later. when i publish here, i focus on practical design decisions and why they hold up under change.\n","title":"dbt","type":"series"},{"content":"","date":"8 April 2026","externalUrl":null,"permalink":"/tags/dbt/","section":"tags","summary":"","title":"Dbt","type":"tags"},{"content":" quick answer # dbt snapshots provide a native way to track slowly changing dimensions over time. by migrating from custom merge statements to native dbt snapshots, you can simplify your codebase, rely on built-in history tracking, and ensure your downstream models always have access to point-in-time records.\nwho this is for # audience: data engineers and analytics engineers using dbt prerequisites: basic knowledge of dbt models, sql, and data warehousing concepts when to use this guide: when you need to track historical changes to mutable source records and want to move away from manual merge logic why this matters # tracking historical changes is a common requirement in data warehousing. building custom merge logic to handle inserts, updates, and history tracking is error-prone and difficult to maintain. dbt snapshots handle the heavy lifting of history tracking out of the box. this ensures you do not lose historical context when source systems overwrite data.\nmoving from merge to snapshot # recently, i migrated several historical tables from a custom merge strategy to native dbt snapshots. the previous approach relied on complex merge statements that manually checked for changes and inserted or updated rows to maintain history. this was difficult to read and even harder to debug.\nby adopting native dbt snapshots, the logic became declarative. instead of writing the exact update and insert commands, i only needed to define the source query and configure how dbt should detect changes. the downstream consumer views then filter the snapshot output to return the current row or a point-in-time record.\nthe core shift in thinking # when using snapshots, your snapshot definition should remain source-representative. do not apply business date-window filtering in the snapshot definition itself. instead, capture the raw history and apply your logic for which rows to return in downstream consumer views.\nfor example, to get the current row in a downstream model, you filter using the sentinel value:\nselect * from {{ ref(\u0026#39;my_snapshot_st\u0026#39;) }} where dbt_valid_to = \u0026#39;9999-12-31 23:59:59\u0026#39; to get a freeze record for a specific point in time, you derive a freeze timestamp and filter:\nselect * from {{ ref(\u0026#39;my_snapshot_st\u0026#39;) }} where dbt_valid_from \u0026lt;= freeze_ts and dbt_valid_to \u0026gt; freeze_ts basic example # here is a basic example of a dbt snapshot using the check strategy. this snapshot tracks changes to a practice affiliation table.\n{% snapshot practice_affiliation_st %} {{ config( target_schema = \u0026#39;snapshots\u0026#39;, strategy = \u0026#39;check\u0026#39;, unique_key = [\u0026#39;fmno\u0026#39;, \u0026#39;cycle\u0026#39;, \u0026#39;committee\u0026#39;, \u0026#39;hierarchy\u0026#39;], check_cols = \u0026#39;all\u0026#39;, hard_deletes = \u0026#39;invalidate\u0026#39;, dbt_valid_to_current = \u0026#34;to_timestamp_ntz(\u0026#39;9999-12-31 23:59:59\u0026#39;)\u0026#34; ) }} select fmno, cycle, committee, practice_name, type, hierarchy from {{ ref(\u0026#39;source_practice_affiliation_v\u0026#39;) }} {% endsnapshot %} configuration options # dbt snapshots offer several configuration options that control how changes are detected and recorded. you can read more about these in the official dbt snapshot documentation.\nhere are the key options and what they control:\ntarget_schema: the schema where the snapshot table will be built strategy: determines how dbt detects changes, with the two main options being timestamp and check unique_key: the primary key of the record, which can be a single column or a list of columns for a composite key check_cols: used with the check strategy to specify which columns to monitor for changes, accepting a list of column names or the word all updated_at: used with the timestamp strategy to specify the column that indicates when the source row was last modified hard_deletes: controls how dbt handles rows that disappear from the source, such as setting it to invalidate to close the current row when a key is no longer present dbt_valid_to_current: overrides the default null value for current records, allowing you to set a far-future date to make downstream filtering easier timestamp vs check strategy # the choice between timestamp and check strategies is critical.\nuse the timestamp strategy when your source has a reliable updated column that changes whenever the row changes. dbt compares the source timestamp to the snapshot timestamp to decide if a new version is needed.\nuse the check strategy when you do not have a reliable updated timestamp, or when you want to detect any change in a specific set of columns. dbt compares the actual values of the check columns between the source and the current snapshot row. if any checked column differs, dbt closes the current row and inserts a new version.\nin my recent work, i found that the check strategy with all columns checked and a composite unique key was the most robust approach for sources where the updated timestamp was synthetic or not authoritative.\ngotchas and lessons learned # migrating to snapshots surfaced a few important lessons:\nupstream scope gating: if your upstream source query includes filters that remove keys, and you have hard deletes configured to invalidate, dbt will intentionally close the current rows for those missing keys composite keys: dbt fully supports composite unique keys, and passing a list of columns ensures that dbt tracks history at the correct grain duplicate source rows: snapshots expect the source data to be unique at the unique key grain, so if your source contains duplicate keys, the snapshot will fail or bloat defensive deduplication: in some cases, i had to add a defensive qualify row number guard in the snapshot definition to collapse known duplicate-key source rows before dbt processed them sentinel values: using a sentinel value for current rows instead of null makes downstream queries much cleaner, allowing you to use an equals operator instead of checking for nulls deployment and automation # snapshots are not updated automatically when you run your standard dbt build commands. they require a dedicated command: dbt snapshot.\nif you do not automate this, your history tracking will be manual and prone to gaps. to ensure continuous history capture, you must schedule the snapshot command to run on a regular cadence.\nin a production environment, this usually means setting up a continuous integration workflow or an orchestrator task. for example, you can use automated workflows to run snapshot tags on daily, hourly, or monthly schedules.\na typical automated workflow might look like this:\na scheduled trigger fires the workflow the workflow checks out the repository and sets up the dbt environment the workflow executes the snapshot command for specific tags dbt connects to the warehouse, compares the source data to the existing snapshot tables, and applies any necessary inserts or updates by decoupling the snapshot schedule from your standard model runs, you can capture history at the exact frequency your business logic requires.\nreferences # dbt snapshots documentation dbt snapshot configurations related reading # dbt models ","date":"8 April 2026","externalUrl":null,"permalink":"/posts/20260408-dbt-snapshots/","section":"posts","summary":"a guide on using dbt snapshots to track slowly changing dimensions, including lessons learned from migrating away from custom merge strategies.","title":"dbt snapshots: moving from merges to native history","type":"posts"},{"content":"","date":"8 April 2026","externalUrl":null,"permalink":"/tags/snapshots/","section":"tags","summary":"","title":"Snapshots","type":"tags"},{"content":"","date":"8 April 2026","externalUrl":null,"permalink":"/tags/snowflake/","section":"tags","summary":"","title":"Snowflake","type":"tags"},{"content":"","date":"6 April 2026","externalUrl":null,"permalink":"/tags/habits/","section":"tags","summary":"","title":"Habits","type":"tags"},{"content":" thesis # the importance of just trying to do a little each day cannot be overstated. we often overestimate what we can accomplish in a single afternoon, but we vastly underestimate what we can build over a year of sustained effort. incremental changes add up, and what seems like a drop in the bucket today becomes a reservoir over time.\ncontext # whether it is work, fitness, or building new routines, habit forming often feels like it takes forever to take hold. we live in a world that expects immediate results, and we naturally get frustrated when the scale does not move or the project does not finish overnight. when that initial burst of motivation inevitably fades, the reality of the daily grind sets in, and that is exactly when most people decide to walk away.\nargument # this process is a little easier when you understand you are working toward continuity and not perfection. it is not about executing flawlessly every single day, nor is it about never taking a break. it is about showing up and putting in the reps, even when the effort feels small or uninspired. missing one day is just a bump in the road, as long as you do not let it become two days in a row.\ni am starting to see the rewards of that mindset now. little by little, my experience has added up into a foundation i can actually rely on. little by little, i have started sharing via my website, turning scattered thoughts into a structured body of work. little by little, i am starting to have a greater reach and help more people, simply because i chose to publish something small rather than waiting for the perfect masterpiece.\ntension or counterpoint # the hardest part is trusting the process when the visible progress is zero. it is incredibly easy to quit when you do not see the immediate payoff of your daily effort. it feels like you are just watering dirt for weeks on end. but the compounding effect of showing up is real, even if it remains completely invisible in the short term.\nclosing # so right in theme, i will keep this short and keep focusing on the small, daily inputs rather than the distant outputs. the goal is simply to keep the chain going, trusting that a little becomes a lot when you give it enough time.\nfurther reading # atomic habits (james clear) tiny habits (bj fogg) small wins (karl weick, organizational change) related on this site # sharing is caring how i automated dev.to and linkedin publishing so visibility stops depending on memory adaptability ","date":"6 April 2026","externalUrl":null,"permalink":"/posts/20260406-little-by-little-a-little-becomes-a-lot/","section":"posts","summary":"habit forming seems like it takes forever to take hold, but it is easier when you understand you are working toward continuity and not perfection. little by little, experience adds up.","title":"little by little, a little becomes a lot","type":"posts"},{"content":"","date":"5 April 2026","externalUrl":null,"permalink":"/tags/automation/","section":"tags","summary":"","title":"Automation","type":"tags"},{"content":"","date":"5 April 2026","externalUrl":null,"permalink":"/tags/devto/","section":"tags","summary":"","title":"Devto","type":"tags"},{"content":"after i started writing more consistently, it became obvious that writing is only half the work; distribution is the other half. i wanted a system where i can publish from one canonical source and let automation push the same story to dev.to and linkedin.\nquick answer # i set up two publish automations that watch my post changes and sync them to dev.to and linkedin. the first publish creates the post on each platform, and later edits update the same external post instead of creating duplicates. this gives me consistent visibility without adding manual publishing steps after every article.\nwho this is for # people who publish technical writing and keep forgetting cross-posting creators who want one canonical source plus repeatable distribution builders who care about discoverability as much as writing quality why this matters # if distribution is manual, it eventually slips. then strong posts sit unread because i forgot to copy, paste, format, and re-share them across platforms. automation solves that by making visibility part of the same delivery path as the content itself.\nthis is the same pattern i described in a practical ai workflow: jira, github, and mcp, define one clear source of truth, then automate the handoff steps so i can spend more time on thinking and less time on clerical work.\nstep-by-step # 1) define the starting point # i chose my site post as the only canonical source. every external platform receives content from that source, not from separate drafts. this keeps language, links, and updates aligned over time.\n2) apply the change # i added automation for both targets:\ntrigger on post updates and support manual runs when i want a full backfill create posts when no external mapping exists update existing external posts when a mapping already exists keep a small state map so each canonical url stays attached to one external post id the practical result is that i can keep writing in one place and trust the sync layer to handle distribution. this complements the writing habits from my cursor setup, where reusable workflows remove repeated manual work.\n3) validate the result # i test in three passes:\ndry run to confirm detection and decisions without publishing publish-all run to verify initial backfill behavior normal change-trigger run to verify incremental updates on later edits when all three pass, i know the pipeline is reliable enough for daily use.\nfaq # what was the biggest setup mistake? # token and redirect mismatches during oauth were the main failure point at first. once i aligned scopes, callback values, and secret placement, the automation became stable.\nshould i keep manual publishing as a fallback? # yes, especially while you are in early setup. after the workflow proves stable, manual publishing becomes a recovery path instead of a default habit.\nreferences # dev.to api docs linkedin developer platform github actions documentation related reading # a practical ai workflow: jira, github, and mcp my cursor setup starter templates for ai rules, skills, and commands ","date":"5 April 2026","externalUrl":null,"permalink":"/posts/20260405-automated-devto-linkedin-visibility/","section":"posts","summary":"i now write once in my site workflow and let automation handle distribution to dev.to and linkedin, so each post reaches people consistently without manual copy and paste.","title":"how i automated dev.to and linkedin publishing so visibility stops depending on memory","type":"posts"},{"content":"","date":"5 April 2026","externalUrl":null,"permalink":"/tags/linkedin/","section":"tags","summary":"","title":"Linkedin","type":"tags"},{"content":"","date":"5 April 2026","externalUrl":null,"permalink":"/tags/publishing/","section":"tags","summary":"","title":"Publishing","type":"tags"},{"content":"","date":"5 April 2026","externalUrl":null,"permalink":"/tags/visibility/","section":"tags","summary":"","title":"Visibility","type":"tags"},{"content":"this series is where i document how i use ai as a real work system, not as a novelty tool.\ni write these posts to make decision quality visible: when ai is helping, when it is creating hidden cost, and which workflow choices keep outcomes stable over time. the goal is to make ai usage more deliberate, measurable, and easier to hand off across sessions.\nyou will see both operational playbooks and reflective pieces here. i care about execution speed, but i care just as much about clarity, cognitive load, and long-term maintainability.\n","date":"2 April 2026","externalUrl":null,"permalink":"/series/ai/","section":"series","summary":"this series is where i document how i use ai as a real work system, not as a novelty tool.\ni write these posts to make decision quality visible: when ai is helping, when it is creating hidden cost, and which workflow choices keep outcomes stable over time. the goal is to make ai usage more deliberate, measurable, and easier to hand off across sessions.\n","title":"ai","type":"series"},{"content":"thoughts on artificial intelligence, large language models, and the evolving relationship between human judgment and machine execution\n","date":"2 April 2026","externalUrl":null,"permalink":"/tags/ai/","section":"tags","summary":"thoughts on artificial intelligence, large language models, and the evolving relationship between human judgment and machine execution\n","title":"ai","type":"tags"},{"content":"this series is my living documentation for using cursor as a daily driver.\ni built it because most setup guides stop at installation, while the real leverage comes from repeatable systems: workspace boundaries, reusable rules and skills, model-routing habits, and tight review loops. those are the parts that decide whether ai-assisted editing is useful.\n","date":"2 April 2026","externalUrl":null,"permalink":"/series/cursor/","section":"series","summary":"this series is my living documentation for using cursor as a daily driver.\ni built it because most setup guides stop at installation, while the real leverage comes from repeatable systems: workspace boundaries, reusable rules and skills, model-routing habits, and tight review loops. those are the parts that decide whether ai-assisted editing is useful.\n","title":"cursor","type":"series"},{"content":"everything related to the cursor ai code editor, including my personal setup, recommended settings, and how to get the most leverage out of its agentic features\n","date":"2 April 2026","externalUrl":null,"permalink":"/tags/cursor/","section":"tags","summary":"everything related to the cursor ai code editor, including my personal setup, recommended settings, and how to get the most leverage out of its agentic features\n","title":"cursor","type":"tags"},{"content":"","date":"2 April 2026","externalUrl":null,"permalink":"/tags/future/","section":"tags","summary":"","title":"Future","type":"tags"},{"content":" quick answer # writing dbt tests and documentation is often the most neglected part of data engineering. i use cursor and custom ai agents to automate this process by reading my sql models, inferring the business logic, and generating the corresponding yaml files. this ensures high-quality data pipelines without the manual overhead.\nwho this is for # audience: data engineers, analytics engineers, and developers using dbt prerequisites: basic knowledge of dbt, sql, and cursor when to use this guide: when you want to scale your data engineering practices and reduce the time spent on writing boilerplate yaml why this matters # documentation and testing are critical for data trust, but they are tedious to write manually. when these steps are skipped, data quality suffers and debugging becomes a nightmare. by automating this with ai, you get the benefits of rigorous testing and clear documentation while freeing up your time for higher-value architectural work.\nstep-by-step # 1) define the starting point # most data engineers start with a raw sql model and a blank slate for their schema.yml file. the traditional approach requires manually typing out every column name, description, and test. this is prone to human error and inconsistency, plus almost always falls out of sync with current models with the first change.\n2) apply the change # i use cursor to bridge this gap. by creating specific ai rules and skills, i can highlight a dbt model and ask the agent to generate the documentation. the agent reads the sql, understands the joins and transformations, and produces a complete yaml file with standard tests like not_null and unique. it can even infer complex relationships and suggest custom tests based on the data domain.\n3) validate the result # once the ai generates the yaml, i review it for accuracy. i then run dbt test and dbt docs generate to ensure everything compiles correctly. the ai rarely makes syntax errors, so the validation step is mostly about confirming the business logic aligns with the documentation.\nfaq # what is the most important caveat? # you must still review the generated output. ai is excellent at scaffolding and inferring patterns, but it does not possess the full business context that you do.\nwhat should i do first? # start by creating a simple cursor skill that defines your team\u0026rsquo;s standards for dbt documentation. feed it a few examples of your best schema.yml files so it learns your preferred style.\nreferences # dbt documentation related reading # my cursor setup ","date":"2 April 2026","externalUrl":null,"permalink":"/posts/20260402-how-i-use-cursor-and-ai-agents-to-write-dbt-tests-and-documentation/","section":"posts","summary":"writing dbt tests and documentation is often the most neglected part of data engineering. i will show you how i use cursor and ai agents to automate this process, ensuring high-quality data pipelines without the manual overhead.","title":"how i use cursor and ai agents to write dbt tests and documentation","type":"posts"},{"content":" quick answer # the future of data engineering workflows with ai is about moving from manual coding to intelligent orchestration. ai agents will handle boilerplate code, pipeline generation, and data quality checks, allowing data engineers to focus on architecture, governance, and business value.\nwho this is for # audience: data engineers, analytics engineers, data architects, and technical leaders. prerequisites: an understanding of modern data stack concepts and basic ai principles. when to use this guide: when planning your data strategy and evaluating how to integrate ai into your engineering practices. why this matters # the volume and complexity of data are growing faster than engineering teams can scale. relying solely on manual workflows leads to bottlenecks, technical debt, and delayed insights. embracing ai is not just about efficiency, it is a strategic imperative to remain competitive.\nstep-by-step # 1) define the starting point # traditionally, data engineering has been a highly manual discipline. engineers spend countless hours writing sql, configuring orchestrators like airflow, and debugging failed pipelines. this approach is brittle and scales poorly as the organization grows.\n2) apply the change # the integration of ai changes this paradigm. large language models can now generate complex sql queries, translate between dialects, and even suggest optimal data models based on source schemas. ai agents can monitor pipeline health, automatically retry transient failures, and alert engineers only when human intervention is necessary. this shift transforms the engineer from a coder into a system architect.\n3) validate the result # the impact of this transformation is measurable. development cycles shorten, data quality improves through automated testing, and the overall reliability of the platform increases. engineers spend less time firefighting and more time building scalable, resilient architectures that drive business decisions.\nfaq # what is the most important caveat? # ai is a tool, not a replacement for fundamental engineering principles. you still need a strong understanding of data modeling, governance, and security to build a robust platform.\nwhat should i do first? # start by identifying the most repetitive tasks in your workflow, such as writing documentation or basic transformations. experiment with ai tools to automate these specific areas before attempting to overhaul your entire architecture.\nreferences # the modern data stack related reading # from prototype to production ai ","date":"2 April 2026","externalUrl":null,"permalink":"/posts/20260402-the-future-of-data-engineering-workflows-with-ai/","section":"posts","summary":"data engineering is evolving rapidly with the integration of artificial intelligence. i will explore how ai agents, large language models, and automated workflows are transforming the way we build, maintain, and scale data platforms.","title":"the future of data engineering workflows with ai","type":"posts"},{"content":"","date":"2 April 2026","externalUrl":null,"permalink":"/tags/early-adoption/","section":"tags","summary":"","title":"Early-Adoption","type":"tags"},{"content":"","date":"2 April 2026","externalUrl":null,"permalink":"/tags/leadership/","section":"tags","summary":"","title":"Leadership","type":"tags"},{"content":"","date":"2 April 2026","externalUrl":null,"permalink":"/tags/mentorship/","section":"tags","summary":"","title":"Mentorship","type":"tags"},{"content":" the value of early adoption # i have always found a unique kind of energy in being an early adopter. when a new tool emerges, especially something as transformative as cursor and artificial intelligence, diving in headfirst is not just about personal efficiency. it is about understanding the landscape before the map is fully drawn. by spending the hours required to become a high-level user, i build a deep familiarity with the edges of what the technology can do.\nthis mastery translates directly into value for my colleagues. when you understand the high-level nuance of a complex tool, you naturally become the point person for your team. people have onboarding questions, they hit roadblocks, and they need someone who has already navigated those early frustrations. being that resource is incredibly rewarding. it shifts my role from an individual contributor to a multiplier, helping the entire team elevate their workflow and avoid the pitfalls i have already solved.\nthe responsibility to share # this dynamic reminds me of a principle i have heard often over the years regarding the importance of using your voice and your platform to share. this is exactly why i started this website. i wanted a dedicated space to share my voice, my knowledge, my opinions, my experience, and the solutions i have discovered along the way.\nwhen you hold onto knowledge, its impact is limited to your own output. when you share it, the impact scales infinitely. writing about these tools, documenting my workflows, and answering the nuanced questions my colleagues ask are all extensions of the same core belief. knowledge is meant to be distributed.\nstepping into mentorship # i have reached a point of mastery and experience where the natural next step for me is to mentor others and deliberately increase my visibility and presence. it is no longer enough to simply be good at what i do behind the scenes. the real work now is in lifting others up.\nin fact, i am starting to feel the weight of this realization. it feels almost selfish not to share what i have learned. when you spend years honing a craft or mastering a paradigm-shifting tool like ai-assisted development, you accumulate a wealth of invisible context. keeping that context locked away serves no one. stepping into a mentorship role, both directly with my colleagues and publicly through this platform, is how i honor the effort it took to gain that experience in the first place.\nlooking forward # my goal is to continue exploring the bleeding edge of these tools, but with a renewed focus on how i can translate those discoveries into accessible guidance for others. whether it is through answering a quick onboarding question about cursor, writing a detailed guide on this site, or simply being a sounding board for a colleague, the objective remains the same. i want to use my experience to make the path easier for those who follow.\nfurther reading # cursor documentation related on this site # post title ","date":"2 April 2026","externalUrl":null,"permalink":"/posts/20260402-sharing-is-caring/","section":"posts","summary":"mastering emerging tools like cursor and ai is only the first step. true value comes from becoming a point person for your team, sharing your voice, and mentoring others through the nuances of adoption.","title":"sharing is caring","type":"posts"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/art/","section":"tags","summary":"","title":"Art","type":"tags"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/authorship/","section":"tags","summary":"","title":"Authorship","type":"tags"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/code/","section":"tags","summary":"","title":"Code","type":"tags"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/creativity/","section":"tags","summary":"","title":"Creativity","type":"tags"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/music/","section":"tags","summary":"","title":"Music","type":"tags"},{"content":" thesis # i keep pondering lately, what are we actually defending when we say \u0026ldquo;ai art is not real art\u0026rdquo;?\ni do not have a final position yet. i am writing this to think in public, not to close the debate.\ncontext # while driving on a family vacation, i asked my wife to fulfill her duty as the passenger and dj some motown bangers. she searched on spotify and found something that seemed to fit the bill. most of the songs were recognizable, memories from my childhood, riding in the backseat listening to my parents\u0026rsquo; favorites. however, the first song on the playlist was by an artist called the 19s soulers, which was an artist i did not recognize. this was a user created playlist so not everything might fit perfectly into the motown mold i was asking for, and that was ok. the song started and it was SOOO good. TOO good. i had my suspicions, but the music caught me so hard that i completely forgot. i asked my boys in the back seat to look up the artist and they did not even search and just responded \u0026ldquo;AI DAD - IT IS AI\u0026rdquo;. i felt so many conflicting emotions, including one of pride that my boys could tell the difference and they have some defense against being fooled.\nthe conversation around ai-generated images and music feels hotter every week, especially when a new ai music act gets attention or a contract. the reaction is often immediate and predictable outrage, fear, dismissal, and arguments about stolen style.\nat the same time, many of us use ai to help write code, review pull requests, or shape architecture notes without the same emotional response. that contrast is interesting to me.\nif i call code a craft, and sometimes an art form, then why does ai help feel acceptable there for so many people, but unacceptable when the ai helps write song lyrics? and if code can be expressive, why is the outrage concentrated in painting, illustration, and music.\nmy code has my fingerprints all over it, just as much as this website and the way i speak and write. it defintely qualifies as expressive. i make stylistic, logic, function, etc. choices that suit my style. how is this different from writing a book? but if you asked which one is acceptable to use ai and which one is not, i could guess your answer 99% of the time.\nargument # i see a few possible reasons, and none of them feel complete on their own:\nvisual art and music are tied to identity in a very direct way audiences often connect to the \u0026ldquo;maker story\u0026rdquo;, not only the artifact creative labor markets in those fields already felt fragile before ai software teams have normalized tool-assisted output for decades code is often judged by function first, while art is judged by intention and feeling still, even with those differences, i cannot shake the inconsistency.\nwhen i use ai in code, i still feel like the author because i set constraints, reject bad output, and own the result. i do not think that is very different from guiding a visual generator, editing outputs, and curating a final piece. maybe the difference is only social permission, not creative mechanics.\nthis question also links to my concern about ownership in the danger of trusting the ai agent, where speed is useful but responsibility still has to stay human.\ntension or counterpoint # there is also a strong counterpoint i take seriously: in code, wrong answers fail in visible ways. tests fail, services break, users complain, and teams can trace accountability. in art, value is less binary, and that makes authorship feel more central and more vulnerable.\nanother counterpoint is economic, not philosophical. people may not be reacting to \u0026ldquo;is this art\u0026rdquo; at all. they may be reacting to \u0026ldquo;will this replace my livelihood\u0026rdquo;.\nboth of those points feel real to me.\nand i think the later point is one worth exploring because the wide-spread availability of ai has \u0026ldquo;democratized\u0026rdquo; creativity, technical endeavors, etc. for people who might have great ideas, but not the musical or technical skill to carry out the plan. well, now they do. and that instant competition that was not present before can certainly feel intimidating and encroaching.\ni am currently mostly pro-ai, but with caution. we should have caution regarding how the models are being trained (and on what data) and regulated. we should exercise caution surrounding who is doing the regulating, as well. ai is a powerful assistant, and as we all know from spiderman, with great power comes great responsibility.\nclosing # i am left with questions, not conclusions.\nmaybe we value human touch most where we believe the human story is the product. maybe we accept ai more where we believe the product is utility. maybe those boundaries are changing and we are all reacting in real time.\nfor now, i am trying to keep the question open\u0026hellip;..when ai is part of the process, what still makes something mine, yours, or ours?\nfurther reading # copyright and artificial intelligence, u.s. copyright office generative art computer music related on this site # from prototype to production: my early adopter view of ai the danger of trusting the ai agent commentary series ","date":"30 March 2026","externalUrl":null,"permalink":"/posts/20260330-what-is-art/","section":"posts","summary":"i do not have a clean answer. i am trying to understand why ai-assisted code can feel normal while ai-assisted painting or music can trigger backlash, and what that says about authorship, labor, and value.","title":"what is art?","type":"posts"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/analytics-engineering/","section":"tags","summary":"","title":"Analytics-Engineering","type":"tags"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/data-quality/","section":"tags","summary":"","title":"Data-Quality","type":"tags"},{"content":"we all know testing is valuable, but almost all dbt projects still underinvest in it. i am guilty of this, shipping the model, promising i will add tests later, then moving on to the next urgent request.\nthat pattern feels fast in the moment, but it is expensive over time. dbt tests are one of the easiest ways to protect trust in your data, and the setup cost is usually smaller than people expect.\nquick answer # dbt tests are assertions about your data that run inside your transformation workflow. they verify assumptions like uniqueness, non-null keys, valid categorical values, and referential integrity. when a test fails, dbt surfaces the exact failing records so you can debug quickly. if you are new to the feature, start with the official dbt data tests documentation and add a few high-signal tests to your most consumed models first.\nwho this is for # analytics engineers who already build dbt models but still rely on manual spot checks data teams that have recurring data quality incidents in dashboards or reports anyone who wants a practical starting point instead of a perfect testing framework why this matters # the cost of bad data is usually delayed, not immediate. a broken metric can sit in production for days before someone notices, and by then that number has already been used in a deck, decision, or leadership update.\nthe frustrating part is that most of these issues are predictable. duplicate primary keys, null foreign keys, unexpected status values, and invalid date ranges are all common failures. dbt tests can catch these early, near the model that introduced the issue.\ni also think testing helps teams move faster, not slower. when tests are in place, i can refactor a model with more confidence because i have a safety net. without tests, every change feels risky and review cycles become slower because everyone is relying on intuition.\nstep-by-step # 1) define the starting point # pick one model that is heavily consumed, for example an order fact table or a customer dimension. identify three assumptions that must always be true:\nthe model key is unique important keys are never null status fields only contain known values then encode those assumptions directly in your yml.\n2) apply the change # start with generic tests in your schema file.\nversion: 2 models: - name: fct_orders columns: - name: order_id tests: - not_null - unique - name: customer_id tests: - not_null - relationships: to: ref(\u0026#39;dim_customers\u0026#39;) field: customer_id - name: order_status tests: - accepted_values: values: [\u0026#34;placed\u0026#34;, \u0026#34;shipped\u0026#34;, \u0026#34;cancelled\u0026#34;, \u0026#34;returned\u0026#34;] this single block gives you strong baseline coverage:\nnot_null protects required fields unique protects grain relationships protects joins and referential integrity accepted_values protects enum-like business states next, add one singular test for a business rule that generic tests cannot express cleanly.\n-- tests/orders_non_negative_amount.sql SELECT order_id, order_amount FROM {{ ref(\u0026#39;fct_orders\u0026#39;) }} WHERE order_amount \u0026lt; 0 this test fails only when the query returns rows. singular tests are ideal for custom rules like range checks, cross-column logic, and impossible combinations.\n3) validate the result # run tests in a tight loop while you are developing:\ndbt test --select fct_orders for a broader gate in CI or before merging, run:\ndbt build --select fct_orders+ dbt build runs models and tests together, which is useful when you want to validate both transformation logic and data quality in one pass. the + after the model name tells dbt to also run any downstream models according to the dag to make sure dependencies also pass.\na practical prioritization rule # when time is limited, i prioritize tests in this order:\nkey integrity on high-consumption models (unique plus not_null) foreign key integrity (relationships) on joins that power dashboards controlled fields (accepted_values) where business logic depends on a finite set of values one custom singular test for the highest-risk metric or business rule this sequence catches a large share of real incidents with minimal setup.\nfaq # what should i test first in a mature project with little coverage? # start where breakage is most expensive, not where modeling is most elegant. choose one or two heavily consumed models and add key integrity plus relationships first. then add one singular test for the business rule that has caused the most historical pain.\ndo dbt tests slow down delivery? # they add some upfront work, but they usually reduce cycle time later. test failures are cheaper during development than after release, and tests make refactors safer because you can verify assumptions continuously instead of rediscovering issues in production.\nreferences # dbt docs, data tests dbt docs, test properties dbt docs, writing custom generic data tests related reading # dbt docs dbt series ","date":"30 March 2026","externalUrl":null,"permalink":"/posts/20260330-dbt-tests/","section":"posts","summary":"dbt tests are one of the highest-leverage habits in analytics engineering, but they are often underfunded in real projects. this post explains how i use generic and singular tests, what to prioritize first, and a few practical examples you can copy today.","title":"dbt tests","type":"posts"},{"content":"most data engineers i know will spend hours getting a model right, then skip the one step that makes it discoverable to everyone else. dbt docs are that step, and they are worth the effort.\nquick answer # dbt docs is a built-in feature that generates a browsable website from your dbt project. it pulls descriptions from your yml files, renders a searchable model catalog, and draws a lineage graph showing how every model connects. running dbt docs generate followed by dbt docs serve gives you a local site instantly. the real payoff is that teammates who never open your sql files can still understand what each model does, what columns it exposes, and where the data comes from. this is especially useful to downstream consumers of your objects because they can see the exact format of the object, including column names and data types, etc.\nwho this is for # data engineers who use dbt but skip writing descriptions analysts, product managers, or business users who need to understand available data without reading sql team leads looking for a low-effort way to make data structures discoverable why this matters # when you build a dbt project, the models represent real business concepts. customers, products, sales, inventory, whatever the domain is. the people who consume those models in dashboards or reports often have no involvement in building them and no reason to read raw sql.\nwithout documentation, those consumers rely on tribal knowledge, slack messages, and guesswork. that does not scale. dbt docs solve this by turning the metadata you already maintain (yml files, project config, source definitions) into a navigable reference that anyone on the team can use. the effort to write a good description is small, and the compound value to the rest of the organization grows with every model you add.\ni think of it like this: if i write a model and do not document it, the only person who truly understands it is me, and even that fades after a few months. if i write a two-sentence description and add column-level context, that knowledge lives in the project permanently and serves everyone who touches the data.\nwhat dbt docs generates # when you run dbt docs generate, dbt produces two main artifacts in your target/ directory:\nmanifest.json contains the full project graph, including every model, source, seed, snapshot, and macro, along with their descriptions, tags, and configuration catalog.json contains the schema-level metadata pulled from your warehouse, including column names, data types, and row counts together with a bundled index.html, these files power a static site that you can open locally with dbt docs serve or host anywhere that serves static files.\nthe site includes # a searchable list of every model and data source in your project model-level and column-level descriptions pulled from your yml files the full sql compiled for each model (in each environment) a lineage graph (dag - directed acyclic graph) that shows upstream sources, intermediate models, and downstream consumers for any selected node the lineage graph is especially useful when someone asks \u0026ldquo;where does this column come from\u0026rdquo; or \u0026ldquo;what breaks if i change this source table\u0026rdquo;. instead of tracing through sql files manually, the graph answers it visually.\nhow to document your models # dbt reads documentation from yml files that live alongside your models. you are probably already using these for configuration and source definitions, so adding descriptions is a natural extension.\nmodel and column descriptions in yml # the most common approach is adding description fields directly in your yml files. here is what that looks like for a view in an information delivery layer:\nversion: 2 models: - name: ORDER_SUMMARY_V description: \u0026gt; aggregated view of customer orders with totals and status breakdowns, consumed by the reporting dashboard and the customer details page in the application. columns: - name: CUSTOMER_ID description: \u0026#34;unique identifier for the customer\u0026#34; - name: TOTAL_ORDERS description: \u0026#34;count of all orders placed by this customer\u0026#34; - name: TOTAL_SPEND description: \u0026#34;sum of order amounts across all completed orders\u0026#34; - name: LAST_ORDER_DATE description: \u0026#34;most recent order date for this customer\u0026#34; every model and every column can have a description. the more specific you are, the more useful the generated docs become. \u0026ldquo;id\u0026rdquo; as a column description does not help anyone. \u0026ldquo;unique identifier for the customer, sourced from the application database\u0026rdquo; does.\nsource descriptions # sources benefit from the same treatment. when your project ingests raw data from an external system, describing those sources in your shared sources file makes the lineage graph meaningful from the very first node:\nversion: 2 sources: - name: RAW_ORDERS description: \u0026#34;raw order data ingested from the transactional database via kafka\u0026#34; database: ANALYTICS_DEV_DB schema: RAW_DATA tables: - name: ORDERS description: \u0026#34;one row per order, includes order status and timestamps\u0026#34; - name: ORDER_ITEMS description: \u0026#34;line items for each order, one row per product per order\u0026#34; doc blocks for longer descriptions # when a model needs more than a sentence or two of context, dbt supports doc blocks. these are markdown files (.md) that live in your project and can be referenced from yml descriptions:\n{% docs order_summary_description %} this view surfaces the aggregated order history for each customer. it joins the hub, satellite, and link tables from the refined data layer to produce a single wide row per customer. **grain:** one row per customer. **consumers:** reporting dashboard, customer details api endpoint. {% enddocs %} then in your yml:\nmodels: - name: ORDER_SUMMARY_V description: \u0026#39;{{ doc(\u0026#34;order_summary_description\u0026#34;) }}\u0026#39; doc blocks are useful when the context is long enough that embedding it inline in yaml becomes awkward. they also let you reuse the same description across multiple references if needed.\na few useful options in dbt docs # persist_docs # by default, dbt docs only live in the generated static site. if you want the descriptions to also appear in your warehouse catalog (so someone querying snowflake information_schema can see them), you can enable persist_docs:\nmodels: my_data_product: +persist_docs: relation: true columns: true with this enabled, dbt run pushes your yml descriptions into the COMMENT property on the table or view and on each column in the warehouse. this is valuable because it means the documentation is available even outside the dbt docs site, directly in the database catalog that tools like snowflake and bi platforms already read.\nthe lineage graph # the generated site includes an interactive dag that visualizes every model, source, and their connections. you can click on any node to see its upstream dependencies and downstream consumers. this is one of the most powerful features in dbt docs because it makes the data flow tangible for people who do not read sql (or maybe they just do not have access to your workspace, but still have a need to understand it).\nwhen you have a project with dozens or hundreds of models organized into layers (raw, refined, business, information delivery), the lineage graph shows how a raw source table flows through transformations into the final views that analysts query. it replaces the need for manually maintained architecture diagrams that go stale the moment someone adds a new model.\nexposures # exposures let you document where your dbt models are consumed outside of dbt. dashboards, applications, api endpoints, anything downstream. defining them makes the lineage graph extend beyond the dbt project boundary:\nexposures: - name: customer_dashboard type: dashboard description: \u0026#34;executive dashboard showing customer order trends and retention\u0026#34; depends_on: - ref(\u0026#39;ORDER_SUMMARY_V\u0026#39;) - ref(\u0026#39;CUSTOMER_RETENTION_V\u0026#39;) owner: name: analytics team email: analytics@example.com exposures show up in the lineage graph as leaf nodes, making it clear which models are actively consumed and by what. this is helpful when you are deciding whether it is safe to refactor or deprecate a model.\nhosting dbt docs on github pages # running dbt docs serve is great for local browsing, but the real value comes from hosting the site where the whole team can access it without installing dbt or cloning the repo. github pages is a straightforward, free option for this.\nhow it works # after dbt docs generate runs, the target/ directory contains everything needed to serve the site: index.html, manifest.json, and catalog.json. you copy those files to a branch or directory that github pages serves, and the docs are live.\na basic github actions workflow # here is a minimal workflow that generates the docs on every push to main and deploys them to github pages:\nname: deploy dbt docs on: push: branches: [main] permissions: contents: read pages: write id-token: write jobs: deploy: runs-on: ubuntu-latest environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} steps: - uses: actions/checkout@v4 - name: set up python uses: actions/setup-python@v5 with: python-version: \u0026#34;3.11\u0026#34; - name: install dbt run: pip install dbt-snowflake - name: generate docs run: dbt docs generate --profiles-dir . working-directory: my_dbt_project env: DBT_SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }} DBT_SNOWFLAKE_USER: ${{ secrets.SNOWFLAKE_USER }} DBT_SNOWFLAKE_PASSWORD: ${{ secrets.SNOWFLAKE_PASSWORD }} - name: prepare pages artifact run: | mkdir -p pages cp my_dbt_project/target/index.html pages/ cp my_dbt_project/target/manifest.json pages/ cp my_dbt_project/target/catalog.json pages/ - name: upload pages artifact uses: actions/upload-pages-artifact@v3 with: path: pages - name: deploy to github pages id: deployment uses: actions/deploy-pages@v4 once this runs, your dbt docs are available at https://\u0026lt;org\u0026gt;.github.io/\u0026lt;repo\u0026gt;/ and automatically update every time someone merges to main. no one needs to install anything or run any commands to browse the documentation.\nkeep the credentials out of the repo # the workflow above uses github secrets for warehouse credentials. never commit profiles with real credentials. use environment variables or a ci-specific profiles.yml that references secrets, and make sure your .gitignore excludes any local profiles that contain actual passwords or tokens.\nfaq # do i need to write descriptions for every column? # you do not need to, but the columns that matter most to consumers deserve it. at minimum, describe the primary key, any business key, and any column whose meaning is not obvious from the name alone. over time, filling in the rest pays off as the team grows.\ncan i generate docs without connecting to the warehouse? # dbt docs generate pulls catalog metadata from the warehouse, so it does need a connection. however, if you already have a catalog.json from a previous run, you can serve the site locally with just those files.\nhow is this different from a wiki or confluence page? # dbt docs stay in sync with your code automatically. a wiki page about your data model goes stale the moment someone adds a column or renames a table. dbt docs regenerate from the source of truth (your yml files and your warehouse) every time you run the command, so the documentation and the code never drift apart.\nreferences # dbt docs overview (dbt documentation) dbt docs generate command persist_docs config exposures (dbt documentation) github pages documentation related reading # dbt series what is sql, and why it still works the difference between snowflake and the \u0026ldquo;other\u0026rdquo; databases ","date":"30 March 2026","externalUrl":null,"permalink":"/posts/20260330-dbt-docs/","section":"posts","summary":"dbt docs are one of the most overlooked features in a dbt project, but they are one of the most valuable for teammates who consume data without building it. i walk through how they work, what options matter, and how to host them for free on github pages.","title":"dbt docs","type":"posts"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/documentation/","section":"tags","summary":"","title":"Documentation","type":"tags"},{"content":"","date":"30 March 2026","externalUrl":null,"permalink":"/tags/github-pages/","section":"tags","summary":"","title":"Github-Pages","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/databases/","section":"tags","summary":"","title":"Databases","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/history/","section":"tags","summary":"","title":"History","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/querying/","section":"tags","summary":"","title":"Querying","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/relational-databases/","section":"tags","summary":"","title":"Relational-Databases","type":"tags"},{"content":"this series is where i write about sql as a working craft: clear queries, reliable debugging, and practical performance habits.\nif a specific sql pain point keeps repeating in your work, send it to me and i will use it to shape upcoming entries in this series.\n","date":"28 March 2026","externalUrl":null,"permalink":"/series/sql/","section":"series","summary":"this series is where i write about sql as a working craft: clear queries, reliable debugging, and practical performance habits.\nif a specific sql pain point keeps repeating in your work, send it to me and i will use it to shape upcoming entries in this series.\n","title":"sql","type":"series"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/sql/","section":"tags","summary":"","title":"Sql","type":"tags"},{"content":"i wanted this to be an entry point for the sql series, a clear \u0026ldquo;what is sql\u0026rdquo; reference you can scan quickly and return to later. even with constant technology shifts, relational databases and sql still anchor a huge part of modern software and analytics.\nquick answer # sql is the language most relational databases use to define, read, update, and manage data. it is declarative, which means i describe the result i want and the database engine decides how to execute it efficiently. this model has held up for decades because sql is expressive, portable, and understandable. vendor dialects differ, but the core grammar is still recognizable almost everywhere.\nwho this is for # people new to data and databases who want a quick introduction developers who use databases daily but never got the historical context analysts and engineers deciding when sql is the right tool what sql is # at its core, sql works on tables made of rows and columns. tables are connected by keys, and queries combine or reshape those tables to answer questions.\nsql usually appears in four practical categories:\nquerying data with select, where, join, group by modifying data with insert, update, delete defining structures with create table, alter table, create view controlling access and safety with grant, revoke the most important mindset shift is this: sql is set-based and declarative, not loop-first and imperative.\na short history of sql # sql has been around for more than 50 years, and that long runway is one reason it feels \u0026ldquo;locked in\u0026rdquo; as a standard.\n1970: edgar f. codd publishes the relational model at ibm mid 1970s: ibm researchers develop sequel, which later becomes sql 1979: oracle ships one of the first commercial sql database implementations 1986: ansi publishes the first sql standard (i personally ONLY write ansi standard for maximum portability) 1990s to 2000s: major vendors expand features and performance, while the core language stays recognizable today: sql powers operational databases, analytics warehouses, bi tools, and transformation frameworks why sql is important # sql is still important for practical reasons, not nostalgia.\nit is a common language shared by developers, analysts, and data engineers it is standard enough that skills transfer across many systems it lets database engines optimize queries with indexes and planners it models relationships clearly through keys and joins it supports transactional consistency for critical business data for me, one of the biggest advantages is ease of learning. for common querying and reporting tasks, sql usually has a lower starting barrier than learning a full general-purpose programming language like python.\nwhen and where to use sql # sql fits especially well in these environments:\napplication databases like postgresql, mysql, and sql server for transactional systems analytics platforms like snowflake, where large-scale reporting and transformation matter most, i cover that context more in the difference between snowflake and the \u0026ldquo;other\u0026rdquo; databases data transformation workflows where repeatable models and tests are required reporting and business intelligence when teams need consistent, auditable metrics sql is usually not the best first tool for heavy imperative algorithms, event orchestration, or specialized graph traversal.\nif you want a practical comparison between snowflake and operational database systems, i break that down in the difference between snowflake and the \u0026ldquo;other\u0026rdquo; databases.\nkey features worth knowing early # joins to combine related entities through keys aggregations (sum, count, avg) to move from row-level detail to summaries window functions for ranking, running totals, and partitioned calculations transactions for safe multi-step writes (begin, commit, rollback) constraints (primary keys, foreign keys, uniqueness) to enforce data quality views and ctes to make complex logic readable and reusable a few simple examples # filter rows # SELECT order_id, order_date, total_amount FROM orders WHERE order_date \u0026gt;= DATE \u0026#39;2026-01-01\u0026#39;; join related data # SELECT c.customer_name, o.order_id, o.total_amount FROM orders o JOIN customers c ON c.customer_id = o.customer_id; aggregate to a useful metric # SELECT customer_id, SUM(total_amount) AS total_spend FROM orders GROUP BY customer_id ORDER BY total_spend DESC; use a transaction for safe updates # BEGIN; UPDATE accounts SET balance = balance - 100 WHERE account_id = 1; UPDATE accounts SET balance = balance + 100 WHERE account_id = 2; COMMIT; faq # is sql the same thing as a database? # no. sql is a language, and a database engine is the system that executes it. two engines can both support sql while differing in extensions, performance behavior, and tooling.\nwhat is the fastest way to get good at sql? # i suggest learning in this order: filtering, joins, aggregation, then window functions. if you can always explain the grain of one row in your result, your queries become much easier to trust.\nwhen should i think twice about using sql? # if your core problem is orchestration, low-latency event handling, or algorithm-heavy logic, sql alone is usually not enough. in those cases, use sql for data access and pair it with application or workflow code.\nreferences # sql (wikipedia) sequel (programming language) iso/iec 9075 (sql standard) history of sql standards (wikipedia) related reading # sql series the difference between snowflake and the \u0026ldquo;other\u0026rdquo; databases left join an effective satellite without duplicating rows (use a cte) ","date":"28 March 2026","externalUrl":null,"permalink":"/posts/20260328-what-is-sql-and-why-it-still-works/","section":"posts","summary":"i break down sql in plain language: what it is, how it evolved over five decades, which problems it solves best, and the core features that keep it relevant","title":"what is sql, and why it still works","type":"posts"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/dynamodb/","section":"tags","summary":"","title":"Dynamodb","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/rds/","section":"tags","summary":"","title":"Rds","type":"tags"},{"content":"this series is where i document practical snowflake decisions that affect speed, cost, and reliability in day-to-day data work.\nhere, i consider the operating model: how to design warehouse layers, tune workloads, and keep teams moving without burning credits.\nif you are actively scaling snowflake right now, tell me your highest-friction topic and i will prioritize that write-up.\n","date":"28 March 2026","externalUrl":null,"permalink":"/series/snowflake/","section":"series","summary":"this series is where i document practical snowflake decisions that affect speed, cost, and reliability in day-to-day data work.\nhere, i consider the operating model: how to design warehouse layers, tune workloads, and keep teams moving without burning credits.\n","title":"snowflake","type":"series"},{"content":"when you first step into data engineering, the sheer number of database options can be overwhelming. i spend a lot of my time working in snowflake, but it is definitely not the only tool in the shed.\nto build a solid data platform, you have to understand where your data comes from and how different systems handle it. i want to break down how snowflake compares to two other popular systems you will encounter often: relational engines such as amazon rds and nosql patterns such as amazon dynamodb.\nthis is a basic guide written from a data engineer\u0026rsquo;s perspective. i will point out the similarities, the differences, and when you should use each one.\nthe contenders # before we compare them, let us define what we are looking at:\nsnowflake: a cloud-native data warehouse built for analytics (olap - online analytical processing). storage and compute are separate, so you pay for each part independently amazon rds: a managed relational database service that runs engines like postgresql, mysql, sql server, and oracle. it is built for transactional app workloads (oltp - online transactional processing) amazon dynamodb: a fully managed nosql key-value and document store built for very low-latency lookups at high scale similarities and differences # at a high level, snowflake and rds both use sql, which makes them feel familiar. dynamodb is api-first for key-value access. it also offers partiql support, but it does not behave like a relational sql engine with joins and broad ad hoc querying.\nthe biggest architectural difference is how they handle storage and compute.\nfeature snowflake amazon RDS amazon dynamodb primary use case analytics and reporting (olap) application backends (oltp) high-scale key-value applications query language sql (warehouse dialect) sql (engine-specific) api-first (partiql support) architecture storage and compute decoupled storage and compute coupled distributed key-value store data structure tables and semi-structured data relational tables key-value and document items indexes micro-partition pruning metadata user-managed indexes partition and sort keys snowflake does not require traditional user-managed indexes for most workloads. it uses micro-partitions and pruning metadata. in rds, you usually create and manage indexes manually to keep queries fast. dynamodb pushes you to define access patterns up front using partition and sort keys.\nscalability: small, big, and the limits # scalability means something completely different depending on which database you are talking about.\nsnowflake # snowflake scales compute and storage independently. storage is backed by cloud object storage, so it is effectively unbounded for most teams. you can store petabytes of data without thinking about disks.\ncompute is handled by virtual warehouses, which come in t-shirt sizes from x-small to 6x-large. if a query is too slow, you can use a larger warehouse. if you have too many concurrent users, you can add clusters.\nsmall: gigabytes of data running on an x-small warehouse big: petabytes of data running on a 4x-large warehouse limits: practically none for storage; compute is limited only by your budget amazon RDS # rds usually scales write capacity vertically by moving to a larger instance class. depending on engine and change type, this can trigger a restart or failover window. you can also scale read traffic horizontally with read replicas.\nsmall: a few gigabytes on a t3.micro instance big: several terabytes on a massive m6g.16xlarge instance limits: many engines cap around 64 terabytes per instance (roughly 64 tib), and you still hit single-instance ceilings on cpu, memory, and concurrent connections amazon dynamodb # dynamodb scales horizontally and automatically. it partitions your data across many servers behind the scenes.\nsmall: a few megabytes with single-digit read/write capacity units big: hundreds of terabytes handling millions of requests per second limits: very high scale for key-value access, but full-table scans and broad analytical queries are usually expensive and inefficient ease of learning curve and use # as a data engineer, the learning curve dictates how fast you can deliver value.\nsnowflake (easiest for analysts) # if you know sql, you can use snowflake quickly. the learning curve is low because there is very little infrastructure to manage. you do not worry about vacuuming tables, managing indexes, or tuning memory pools. you mostly load data and query it.\namazon RDS (moderate) # rds is easy to start with because postgresql and mysql are industry standards. however, the learning curve gets steep when you hit scale. you have to read query plans, manage indexes, handle connection pooling, and tune database parameters.\namazon dynamodb (steepest for modeling) # dynamodb has a notoriously steep learning curve for data modeling. because it is not a relational join engine, you usually model around known access patterns (often with single-table design). if those patterns change later, you may need redesign work and backfills.\nwhen to use each # choosing the right database is about matching the tool to the workload.\nuse snowflake when:\nyou need to analyze massive amounts of data you are building dashboards, reports, or a data warehouse you need to join data from many different sources your queries read millions of rows at a time use amazon RDS when:\nyou are building a standard web application you need strong transactional guarantees (ACID compliance) your queries typically look up or update a single row or a small batch of rows your core workload is transactional and fits a single relational instance pattern, even as it grows into multi-terabyte range use amazon dynamodb when:\nyou are building a shopping cart, session store, or gaming leaderboard you need guaranteed single-digit millisecond response times you have massive, unpredictable spikes in traffic you do not need to run complex analytical queries as a data engineer, your job is often to extract data from operational systems (like rds and dynamodb) and load it into an analytical system (like snowflake). that is what allows the business to understand what is happening.\nreferences # snowflake documentation amazon RDS documentation amazon dynamodb documentation related reading # snowflake series ","date":"28 March 2026","externalUrl":null,"permalink":"/posts/20260328-the-difference-between-snowflake-and-the-other-databases/","section":"posts","summary":"when you first step into data engineering, the sheer number of database options can be overwhelming. i break down how snowflake compares to traditional relational databases like rds and nosql options like dynamodb, focusing on when to use each and how they scale.","title":"the difference between snowflake and the \"other\" databases","type":"posts"},{"content":" thesis # i think adaptability is one of the most useful skills to develop, and its value keeps rising. ai and agents are changing workflows faster than most teams can document them. people who adjust quickly, while staying clear about outcomes, will keep moving when others stall.\ncontext # widespread ai adoption is pushing change into almost every part of work. tasks are getting split differently, handoffs are being redefined, and the idea of \u0026ldquo;the normal way\u0026rdquo; has a shorter shelf life every month.\nthis pace is not only a work story. speed and connectivity shape family logistics, routines, and attention in daily life too. the same mental flexibility that helps at work helps at home, in travel, and during any week that does not look like the one before it.\nargument # i am writing this from a very rural location, far from my normal office setup. i have no cell service except a satellite connection that can send slow texts, and the wifi is around 10 mbps down on a good day, shared across the whole family. that setup forced me to plan work in batches and communicate constraints early. it is a useful reminder that conditions change, but the work still has to get done.\nfor me, adaptability in practice looks like a few simple moves:\nshifting to an offline-first workflow when connectivity is inconsistent prioritizing high-leverage tasks before synchronous calls communicating constraints early so expectations stay realistic batching sync-heavy work into the most stable bandwidth windows choosing tools that degrade gracefully instead of failing hard this is also why i care so much about clear ownership when using ai. adaptable does not mean random. it means adjusting method while protecting intent, quality, and accountability in a rapidly changing workplace (and world). this is a theme i also touched on in the danger of trusting the ai agent.\ntension or counterpoint # there is a valid concern here: constant adaptation can turn into reactive thrashing. not every new tool deserves adoption, and not every workflow change creates real value.\nthe balance i aim for is to adapt principles faster than (or at least as fast as) tools. if i stay anchored on outcomes, quality, and ownership, i can (hopefully) swap tactics without losing direction.\nclosing # i do not see adaptability as a soft trait anymore. i see it as operational leverage. it helps me keep momentum when the environment is unstable, when tools change quickly, or when ideal conditions are not available.\ngoing forward, i expect this to matter even more. the people and teams that learn quickly, reframe constraints, and keep moving with clarity will have a durable advantage.\nfurther reading # adaptability organizational agility related on this site # the danger of trusting the ai agent commentary series ","date":"27 March 2026","externalUrl":null,"permalink":"/posts/20260327-adaptability/","section":"posts","summary":"ai and agents are accelerating how quickly work changes, and that pressure is showing up far beyond tech. i am seeing it directly while working with almost no cell signal and shared low-bandwidth internet, and it keeps reminding me that adaptability is a compounding skill.","title":"adaptability","type":"posts"},{"content":"","date":"27 March 2026","externalUrl":null,"permalink":"/tags/adaptability/","section":"tags","summary":"","title":"Adaptability","type":"tags"},{"content":"","date":"26 March 2026","externalUrl":null,"permalink":"/tags/debugging/","section":"tags","summary":"","title":"Debugging","type":"tags"},{"content":"","date":"26 March 2026","externalUrl":null,"permalink":"/tags/ownership/","section":"tags","summary":"","title":"Ownership","type":"tags"},{"content":"i love how fast ai agents can move, but i have learned that speed without ownership can become expensive very quickly. if i let an agent operate in an area i do not understand deeply, i can end up with changes i cannot explain, verify, or recover confidently.\nthis is the darker side of the acceleration story i wrote about in from prototype to production: my early adopter view of ai: ai can compress execution time, but it can also greatly expand confusion if my boundaries are weak.\nquick answer # if i trust the ai fully in a domain i do not understand, i am borrowing speed against future troubleshooting debt. the agent can still produce plausible progress, but when something breaks, i pay the bill because i do not have the mental model to debug with confidence. my rule now is simple: ai can do my work faster, but it should only do work i truly understand and could perform on my own.\nwho this is for # people using agents for coding, data, or operations tasks anyone who has watched an agent \u0026ldquo;do a lot\u0026rdquo; but struggled to explain what actually changed teams where responsibilities cross domains and ownership can get blurry why this matters # automation bias is real. when the output looks polished, it is easy to accept it before understanding it. that is manageable in low-risk tasks, but dangerous in high-impact systems where small assumptions can trigger hard-to-trace regressions.\nthe hidden cost is confidence drift. git can say everything is clean while my own understanding says something feels off. when that gap appears, stress goes up, debugging slows down, and trust in the workflow drops.\nand one other note to be fair is that in this case, i tried to use a faster, smaller agent to do work that i should have routed to a stronger, deeper thinking model. i was in a hurry and paid for it. remember the tried and true racing phrase \u0026ldquo;slow is smooth, smooth is fast\u0026rdquo;.\nthe failure mode i hit # i asked an agent to diagnose an error in an area where i did not have strong depth. during the run, it created files to handle the issue. later, it removed those same files because they were not referenced anywhere. from git\u0026rsquo;s perspective, it was a net zero diff.\nfrom my perspective, it was not zero at all. i watched a long stream of activity, expected to see resulting changes, and then found a clean tree. i spent significant time retracing the run to understand what happened, and even after reconciling local and remote state i still had low confidence that everything was truly back to a known good place.\nwhere i drew the line # the lesson for me is less \u0026ldquo;never trust ai\u0026rdquo; and more \u0026ldquo;do not outsource something you could not do yourself\u0026rdquo;. if i cannot explain the system, i should not delegate high-autonomy changes in that system to an agent.\nthat lane discipline applies to people too. if work sits in another colleague\u0026rsquo;s domain, i should route it to them, even if they use an agent themselves. the difference is not whether ai is involved. the difference is whether the person driving understands the domain deeply enough to verify and own the result.\nthe lane check i use now # before i hand work to an agent, i run five checks:\ndo i understand the domain well enough to review every change with confidence if the agent makes a wrong assumption, can i detect it quickly do i have explicit stop conditions and verification steps will i review the actual diff and command output, not just the narrative in chat if this crosses domain ownership, have i handed it to the right colleague if i answer \u0026ldquo;no\u0026rdquo; to any of these, i narrow the scope or route the task to someone else.\nfaq # does this mean ai should only do trivial work? # no. ai can do serious work, but the owner still needs to understand the system and sign off on the result. complexity is fine, unowned complexity is the problem.\nwhat do you do when git says clean but confidence is low? # i treat that as a process warning. i retrace the execution log, compare expected outcomes against actual artifacts, and document what happened before continuing. if i still cannot explain it clearly, i escalate to the domain owner instead of pushing forward on uncertainty.\nreferences # automation bias out-of-the-loop performance problem related reading # from prototype to production: my early adopter view of ai a practical ai workflow: jira, github, and mcp ai br-ai-n fr-ai ai series ","date":"26 March 2026","externalUrl":null,"permalink":"/posts/20260326-the-danger-of-trusting-the-ai-agent/","section":"posts","summary":"i share a real failure mode where an ai agent created and then deleted files while debugging, leaving a clean git tree but low confidence. the lesson for me is simple: ai should accelerate the work i own and understand, while domain-specific decisions stay with the people accountable for that domain.","title":"the danger of trusting the ai agent","type":"posts"},{"content":"","date":"26 March 2026","externalUrl":null,"permalink":"/tags/trust/","section":"tags","summary":"","title":"Trust","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/attention/","section":"tags","summary":"","title":"Attention","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/disconnect/","section":"tags","summary":"","title":"Disconnect","type":"tags"},{"content":" thesis # for a long time, a commercial flight was one of the few places where the world could not reach you unless you paid for a seatback phone nobody used. you were offline by default, not by discipline. now many cabins offer wifi strong enough to treat the plane like a slow office in the sky. that is a small technical change and a large cultural one, because it turns disconnection from a fact into a choice, and sometimes into an expectation. i used to think we should protect those disconnected spaces on purpose. today i am less sure of my own opinion, and this piece is an honest inventory of why.\ncontext # the shift did not happen all at once. first it was email that barely worked, then messaging, then enough bandwidth that \u0026ldquo;i am on a plane\u0026rdquo; stopped being a credible excuse for silence in some workplaces. the option to connect is not the same as the obligation to connect, but options have a way of becoming norms. if the team assumes you can answer, the cost of opting out is social and professional, not just the price of the wifi pass.\ni notice that i feel different about this than i did five or ten years ago. i used to romanticize the cabin as a rare enforced pause, a moving room where the only honest move was a book, a nap, or staring at clouds. now i sometimes have a different perspective since my brain is already racing and the seat is uncomfortable and sleep is not going to happen.\nargument # the case for keeping flights disconnected # there is real relief in a few hours where slack cannot ping you and the news cannot refresh on reflex. the stream of messages and media is designed to feel urgent. a metal tube at thirty thousand feet used to interrupt that design for everyone equally. when you land, nothing has changed except you, and that can be restorative even when it is boring.\ni still believe that boredom and idle time are inputs to thinking, not failures of entertainment. a flight without wifi can be a long, low-stakes walk for your attention, and that has value. it is the same thread i explored in brain defrag: time away from screens (and from \u0026ldquo;one more\u0026rdquo; with ai).\nthe case for wanting the connection # if you cannot sleep on planes, hours in the air can feel like time you are borrowing from your life and not getting back. in that frame, wifi looks less like an intrusion and more like a way to reclaim the block for work, reading you actually chose, or staying in touch with people you care about. the \u0026ldquo;wasted time\u0026rdquo; feeling is personal, but it is not irrational.\ncabin class changes how physical that tradeoff is. if you are fortunate enough to sit in first or business, the tray, the elbow room, and the seat pitch can make typing tolerable for a while. in economy, the same work is often inconvenient for you and unfair to the person beside you who did not sign up to be your armrest and your privacy screen. connectivity does not create that squeeze, but it can intensify it when everyone tries to turn a narrow row into an office.\ntension or counterpoint # the strongest counterpoint to my old \u0026ldquo;protect the disconnected cabin\u0026rdquo; instinct is that disconnection was never equally available. people with caregiving responsibilities, unpredictable schedules, or thin margins already paid a tax when flights were black holes on the calendar. wifi can reduce that tax. my nostalgia for a universal offline bubble was partly a privilege story dressed up as a wellness argument.\nthe strongest counterpoint to always-on flying is that the cabin is still a shared space, and not every kind of work belongs there without cost to neighbors and to your own nervous system. the technology says you can but your body and the person in the middle seat might wish you would not.\nclosing # i do not have a tidy answer about whether i like in-flight connectivity. some trips i am grateful for it. some trips i wish the excuse to be unreachable still existed without me having to defend it. what i know is that the choice is heavier than the toggle in the portal makes it look, and i will probably keep revisiting it every time the wheels leave the ground.\nfurther reading # in-flight connectivity, overview of how internet reaches aircraft and how adoption spread airline seat, context on pitch, width, and why economy is a poor default office related on this site # commentary series brain defrag: time away from screens (and from \u0026ldquo;one more\u0026rdquo; with ai) ","date":"24 March 2026","externalUrl":null,"permalink":"/posts/20260324-wifi-on-planes/","section":"posts","summary":"i used to want to protect disconnected travel time. now i am torn between relief from the message stream and the feeling that a long flight is wasted if i cannot sleep and i am not online. cabin class changes how real that tradeoff is, and i still do not have a clean verdict.","title":"plane wifi: when the cabin forced disconnect","type":"posts"},{"content":"this series is where i break down data vault 2.0 decisions into practical implementation patterns.\nthe focus here is concrete modeling choices: what to put in hubs, links, and satellites, how to handle change, and how to keep lineage understandable as the system grows.\nif you are implementing data vault now, share the part that feels most ambiguous and i will prioritize content that answers that exact decision point.\n","date":"24 March 2026","externalUrl":null,"permalink":"/series/data-vault-2.0/","section":"series","summary":"this series is where i break down data vault 2.0 decisions into practical implementation patterns.\nthe focus here is concrete modeling choices: what to put in hubs, links, and satellites, how to handle change, and how to keep lineage understandable as the system grows.\n","title":"data vault 2.0","type":"series"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/data-vault/","section":"tags","summary":"","title":"Data-Vault","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/effective-satellite/","section":"tags","summary":"","title":"Effective-Satellite","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/grain/","section":"tags","summary":"","title":"Grain","type":"tags"},{"content":"the dreaded left join to an effective satellite\u0026hellip;..\ni wanted to write this note, if for no other reason, so the pattern is easier to find when someone searches the same problem. the situation is uncommon enough that public answers are rare, and the fix is small once you see it.\nquick answer # if you need attributes from an effective satellite for an optional relationship, do not left join the link, hub, and effective satellite as separate tables in one flat from clause next to your driving link. that shape often reintroduces ambiguity where you can match more than one effective row or change the result grain in ways that are hard to reason about. instead, build a cte (or subquery) that already resolves one current effective row per link (for example load_end_ts = '9999-12-31' or your project\u0026rsquo;s equivalent), then left join that cte to your main link on the hub or link key you already carry.\nwho this is for # anyone modeling optional links in data vault 2.0 who still needs a stable one row per fact output readers who inherited sql where optional dimensions quietly duplicate keys why this matters # grain is the contract downstream queries trust. when an optional path multiplies rows, dashboards and application reads disagree on what \u0026ldquo;one entity\u0026rdquo; means, and the bug shows up late because the sql \u0026ldquo;looks\u0026rdquo; like a normal join tree.\nstep-by-step # 1) define the starting point # you have a driving link (for example link between a case and a cycle) with inner joins to its own hub, effective satellite, and attribute satellite so the core row is current and unique. one foreign key on that link points at an optional hub (for example an optional grouping). not every driving row has that key set.\n2) apply the change # put the optional side in a cte: start from the optional link, join the effective satellite with an inner predicate that keeps only the open interval row, then attach the hub if you need the business key. in the outer query, left join the cte on the optional hub hash (or whatever stable key you store on the driving link).\n3) validate the result # count distinct keys on the driving natural or surrogate key before and after the change. the counts should match when the optional side is empty, and optional matches should add columns without adding rows.\na minimal example # this is anonymized and trimmed; names stand in for a real link, hub, and satellites. the following sql shows the shape i use.\nWITH cte_optional_scope AS ( SELECT link_scope.scope_h, hub_scope.scope_bk FROM link_scope link_scope LEFT JOIN hub_scope hub_scope ON link_scope.scope_h = hub_scope.scope_h INNER JOIN eff_sat_scope eff_sat_scope ON link_scope.l_scope_h = eff_sat_scope.l_scope_h AND eff_sat_scope.load_end_ts = \u0026#39;9999-12-31\u0026#39; ) SELECT hub_case.case_bk AS case_id, sat_case.status_code, cte_optional_scope.scope_bk AS optional_scope_id FROM link_case link_case INNER JOIN hub_case hub_case ON link_case.case_h = hub_case.case_h INNER JOIN eff_sat_case eff_sat_case ON link_case.l_case_h = eff_sat_case.l_case_h AND eff_sat_case.load_end_ts = \u0026#39;9999-12-31\u0026#39; INNER JOIN sat_case sat_case ON eff_sat_case.case_h = sat_case.case_h AND sat_case.load_end_ts = \u0026#39;9999-12-31\u0026#39; LEFT JOIN cte_optional_scope cte_optional_scope ON link_case.scope_h = cte_optional_scope.scope_h the important part is not the column list, it is the shape: the effective satellite predicate lives inside the cte, and the outer query only left joins the already-resolved optional row set.\nfaq # what is the most important caveat? # your project may use a different literal or rule for \u0026ldquo;current\u0026rdquo; effective rows. keep that predicate consistent with every other query that reads the same satellite family.\nwhat should i do first? # reproduce the duplicate key count on a small filter (one day, one tenant, one test id) before you rewrite the full model so you can prove the cte removed multiplication.\nreferences # data vault 2.0 series related reading # how i use cursor and ai agents to write dbt tests and documentation dbt tests, why they matter and where they fit in your data workflow ","date":"24 March 2026","externalUrl":null,"permalink":"/posts/20260324-left-join-effective-satellite-cte/","section":"posts","summary":"when an entity link to another hub is optional, a naive left join that pulls in an effective satellite in the same from list can explode or blur grain. i isolate the current effective row in a cte and left join that instead.","title":"left join an effective satellite without duplicating rows (use a cte)","type":"posts"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/left-join/","section":"tags","summary":"","title":"Left-Join","type":"tags"},{"content":" thesis # i am a better thinker when i am not always on. screens pull me into a steady drip of input, and ai tools make it easy to stay in a loop of \u0026ldquo;just one more task\u0026rdquo; because the next answer always feels within reach. the counterweight is deliberate time away. spending time outside, in the yard, on a run, anywhere my attention is not being fed the next pixel is not just relaxation, it is a required input to productivity. in those stretches away from the screen, my mind does something i have come to call brain defrag, where thoughts drift, connect, and settle the way old disk defragmenters used to shuffle blocks until the filesystem looked sane again. that idle-looking time is not wasted, and it is part of how i produce anything worth shipping.\ncontext # for years the default workday has been a screen with a glowing rectangle of obligations. adding ai on top did not invent overwork, but it did lower the friction. there is always another prompt, another refinement, another pass that could make the artifact slightly better. the tool is so willing that stopping feels like leaving money on the table.\ni notice the cost in my body before i notice it in my calendar. my eyes stay tired, my shoulders stay tight, and my thinking stays noisy like too many tabs open at once. when i get outside, especially for something physical, the noise changes to wind, dirt, footsteps, breathing. the channel is wider and slower. my brain quits trying to finish every sentence in real time. that is when the defrag feeling shows up.\nargument # screens train you to produce on demand # a screen rewards continuous output. replies, commits, messages, scrolling. even \u0026ldquo;rest\u0026rdquo; on a screen is usually just another feed. and the message is always the same, if you are not typing or tapping, you are falling behind.\ni do not buy that for creative or analytical work. sustained quality needs gaps where nothing is \u0026ldquo;done\u0026rdquo; yet. if every hour is a performance hour, there is no hour left for the quiet work of connecting ideas, no time for half-formed thoughts to strengthen without someone watching, no experiementing with new ideas.\nai tightens the \u0026ldquo;one more\u0026rdquo; trap # ai assistants are useful because they answer fast and never need a break. the dark side is that the session never has to end. you can always ask for one more variant, one more edge case, one more rewrite. it feels like collaboration, so stopping feels rude, like walking out on a colleague mid-sentence.\ni have to treat that as my problem to solve, not the tool\u0026rsquo;s. the ai is not going to tell me to stop. i have to close the laptop, mute everything, and accept that some problems are supposed to sit overnight, or at least until after a run.\nbrain defrag # when i am raking, planting, hauling, or simply moving under open sky, my attention is not idle. it is unscheduled. ideas that were pinned under \u0026ldquo;urgent\u0026rdquo; can float. two half-formed notions from last week can bump into each other. a worry i suppressed because i was in flow can surface long enough to be named and filed.\nthis feels like the old windows defrag visualization: scattered fragments slowly sliding into contiguous order. the cpu was not \u0026ldquo;doing nothing\u0026rdquo;, it was reorganizing so the machine could run faster afterward. i think mental work has the same requirement. you cannot compress insight into every minute of the day. some minutes have to be for rearrangement, not for output.\ni am not claiming neuroscience labels here. i am naming a felt experience that i have encountered an uncountable number of times. if i grind on a hard problem, then step away long enough that my mind changes channel, i often return with a new angle. the solution was not missing because i lacked information, it was missing because my internal index was fragmented.\nrest is not the opposite of serious work # good work is not the sum of keystrokes. it depends on being rested enough to tell a good idea from a loud one. when i am under-slept and over-screened, i can still type plenty. what i lose is taste, patience, and the ability to notice that i am solving the wrong problem.\nrecovery is not a reward for finishing the sprint. it is a required input to the next sprint. the yard and the running shoes are part of the pipeline, not a luxury bolt-on.\ntension or counterpoint # not everyone has a yard, safe streets to run, or a schedule that allows a long unplug. \u0026ldquo;go outside\u0026rdquo; can sound tone-deaf when life is caregiving, long work shifts, or a second job. regardless of how you choose to do it, what i mean is that you still need unstructured attention sometimes, even if the form is a walk around the block, a shower with no podcast, or ten minutes staring at a ceiling without a phone. the defrag metaphor is about protected mental slack, not about the specific activity or location.\nthe other honest objection is guilt. stepping away can feel like slacking when deadlines press. i feel that too. but the counterpoint is that if i never defrag, i pay in mistakes, rework, and dull ideas. the spreadsheet likes continuous output, the brain does not.\nclosing # i am not trying to romanticize dirt under my fingernails or pretend every run is transcendent. sometimes it is just exercise. but the pattern holds true often enough that i trust it. struggle, leave, let the mind wander, come back. the best ideas frequently arrive in the gap. the same can be said about music, the spaces between the notes matter just as much as the notes you play.\nthe brain defrag works often enough that i schedule for it the same way i schedule for sleep.\nfurther reading # incubation (psychology), overview of stepping away from a problem and returning with new insight attention restoration theory, research frame for how natural environments can recover directed attention related on this site # commentary series deep dive: the ai models i use practical ai workflow: jira, github, and mcp ","date":"20 March 2026","externalUrl":null,"permalink":"/posts/20260320-brain-defrag-time-away-from-screens/","section":"posts","summary":"i argue that constant production and always-on tools work against clarity. yard work, runs, and boredom give my thoughts room to float, and that is when problems unlock after long struggle.","title":"brain defrag: time away from screens (and from \"one more\" with ai)","type":"posts"},{"content":"","date":"20 March 2026","externalUrl":null,"permalink":"/tags/rest/","section":"tags","summary":"","title":"Rest","type":"tags"},{"content":"","date":"20 March 2026","externalUrl":null,"permalink":"/tags/wellbeing/","section":"tags","summary":"","title":"Wellbeing","type":"tags"},{"content":" playbooks for writing, building, and publishing this section contains operational docs for this repository: setup steps, content standards, and repeatable publishing workflows.\ntemplate mirrors (template/index.md, commentary-template/index.md) stay draft: true on purpose, match archetypes/ for scaffolding, and are not meant as public articles unless you explicitly publish them.\n","date":"20 March 2026","externalUrl":null,"permalink":"/guides/","section":"guides","summary":" playbooks for writing, building, and publishing this section contains operational docs for this repository: setup steps, content standards, and repeatable publishing workflows.\ntemplate mirrors (template/index.md, commentary-template/index.md) stay draft: true on purpose, match archetypes/ for scaffolding, and are not meant as public articles unless you explicitly publish them.\n","title":"guides","type":"guides"},{"content":"i spend most of my working day using an ai assistant in cursor. the part that is easy to skip in public write-ups are the simpler details like which model name maps to which vendor, what each one is trying to be good at, and where i should not pretend it is interchangeable with the others.\nthis post is that roster for me, written as of friday mar 20, 2026. i am not running benchmarks here. i am writing down how these models behave in my hands, with links so you can read the official specs if you want to explore further on your own. for why i treat multi-model routing as a production-era default, see from prototype to production: my early adopter view of ai.\nquick answer # six models in my rotation right now: composer 2 when i want cursor-native agentic work, gpt-5.3 codex xhigh when i need serious implementation muscle, claude 4.6 opus max when the problem is genuinely hard and i want anthropic thinking, gemini 3.1 pro when the input is big or visual, grok 4.20 when i am stuck and want a fresh perspective, and kimi k2.5 when i want strong tool use from outside the usual three vendors.\nwho this is for # anyone already using cursor (or something similar) who wants to know what models are out there engineers who do not want to watch an hour of launch videos to get a vendor map future me, six months from now, when half of these names have changed and i need to remember what i was actually using comparison table # the table is the quick reference. the sections below are where i get honest about what each model is actually like to use.\nmodel (as shown in my router) maker speciality / intended use pro / con documentation composer-2 cursor agentic coding inside cursor: edits, terminal-shaped workflows, tool use pro: built for the editor; strong on long-horizon tasks with summarization training. con: not a portable api model in my mental model; i think of it as an environment capability, not a generic llm composer 2 model page gpt-5.3-codex-xhigh openai agentic coding via the codex line; the xhigh suffix is how my router encodes a higher reasoning effort preset on top of the codex family pro: excellent when i want careful refactors and api-shaped thinking. con: slower and more expensive than \u0026ldquo;just answer fast\u0026rdquo; tiers; easy to overuse on trivia gpt-5-codex model, codex product hub claude-4.6-opus-max anthropic maximum depth sonnet-family reasoning when latency is a fair price pro: best anthropic option in my rotation for subtle bugs, spec ambiguity, and multi-file coherence. con: the cost and latency are real; i save it for work that deserves the tax claude models overview gemini-3.1-pro google flagship gemini tier for long context and strong multimodal reasoning in the gemini stack pro: great when i am dragging in screenshots, pdf-shaped context, or very wide file sets. con: vendor-specific quirks still matter; i verify critical logic instead of trusting vibe gemini models grok-4-20 xai grok 4 family reasoning with the 4.20 snapshot naming xai uses in api surfaces pro: useful second opinion when i feel anchored to one vendor\u0026rsquo;s \u0026ldquo;house style\u0026rdquo;. con: i treat cutting-edge models as higher variance until i have personal calibration data xai api introduction kimi-k2.5 moonshot ai kimi k2 line tuned for coding, math-style reasoning, and tool calling on moonshot\u0026rsquo;s platform pro: strong when i want mixture-of-experts-style efficiency stories and a different training prior than the usual us trio. con: operational details (regions, billing, rate limits) are another console to respect kimi api quickstart composer-2 (cursor) # composer 2 is cursor\u0026rsquo;s house model for agentic work such as file edits, tool calls, and terminal workflows. it does not feel like chatting with an llm. it feels like the editor itself got smarter.\ni use it when the task lives in the repo: multi-step refactors, searching across the workspace, long sessions where i do not want to re-explain context every ten minutes. i do not think of it as an api model i happen to access through cursor. it is more like a capability of the editor itself.\nthe official docs say it is tuned for tool use and long horizons. that matches what i see.\ngpt-5.3-codex-xhigh (openai) # this is my \u0026ldquo;i need the ai to really think about this\u0026rdquo; slot on the openai side. the public docs call the family gpt-5-codex; the 5.3 and xhigh parts are how my router encodes the version and reasoning effort. your account might show a different string.\ni use it when the work is code-heavy and i want the model to show its reasoning, not just spit out an answer. it shines when the change touches contracts, apis, types, migrations, or anything where a wrong assumption quietly spreads.\nthe downside is obvious: it is slower and more expensive, and it tempts me into using a sledgehammer on a thumbtack.\nclaude-4.6-opus-max (anthropic) # this is my only anthropic route right now and i save it for the hard stuff: security-sensitive code, tricky concurrency, specs that contradict themselves, and problems where i want the model to slow down and really chew on it.\nthe trade-off is cost and patience. opus is not \u0026ldquo;better\u0026rdquo; at everything. it is better at the things where i would otherwise redo the work three times trying to get it right with a faster model.\ni check anthropic\u0026rsquo;s model pages periodically because vendors bump versions quietly and my router changes behavior without telling me.\ngemini-3.1-pro (google) # gemini is where i go when the input is not just code. screenshots, long mixed documents, big file sets, and that is where the pro tier earns its keep for me.\nsame review standard applies though. if the answer involves auth, money, or data integrity, the model is writing drafts, not making decisions. i sign off. always.\ngrok-4-20 (xai) # grok is my \u0026ldquo;break the pattern\u0026rdquo; model. when i have been staring at the same bug through two other model families and getting nowhere, throwing it at a third set of priors sometimes finds the thing i missed faster than another hour of printf debugging.\ni keep my expectations honest though. this model does not compete with the above flagship models, but it sometimes i even find value in seeing what it gets wrong which prompts a better question for me to ask to one of the better models. it is kind of like using microsoft edge to download google chrome.\nkimi-k2.5 (moonshot ai) # kimi k2.5 is my pick when i want strong coding and tool calling from outside the usual us vendor trio. moonshot makes it easy to try because their endpoints are openai-compatible, so i do not have to rewire everything to test it.\ni only keep a model in rotation to make sure i do not always only use the same two or three models. otherwise it just collects dust.\nhow i actually pick (it is not scientific) # lots of files, lots of tool calls → composer 2 hard code problem, i want to see the reasoning → codex xhigh or opus max, depending on whether i want openai-flavored or anthropic-flavored thinking big context window or images involved → gemini 3.1 pro i have been going in circles for an hour → grok or kimi for a fresh set of eyes faq # do you run all six every day? # no. most days it is 90% gpt-5-codex. the full roster is there for when i need it, and over time i have built up a mental map of which model tends to do well on which kind of task.\nshould i copy this exact list? # please do not. if you are not living inside an agentic editor all day, half of this will not make sense for your workflow. honestly, one fast model and one deep model will cover most people. add a third only if you keep running into the same wall.\nreferences # cursor documentation home openai developer documentation anthropic claude documentation google ai for developers (gemini) xai developer documentation moonshot kimi api platform related reading # from prototype to production: my early adopter view of ai my cursor setup a practical ai workflow: jira, github, and mcp ai series, the rest of the arc in one place ","date":"20 March 2026","externalUrl":null,"permalink":"/posts/20260320-deep-dive-ai-models-i-use/","section":"posts","summary":"i walk through composer-2, gpt-5.3-codex-xhigh, claude 4.6 opus, gemini 3.1 pro, grok-4-20, and kimi-k2.5 with a comparison table plus longer notes on how i actually use each one.","title":"deep dive: the ai models i use","type":"posts"},{"content":"posts that treat llms as systems to understand and steer, not as magic\n","date":"20 March 2026","externalUrl":null,"permalink":"/tags/llm/","section":"tags","summary":"posts that treat llms as systems to understand and steer, not as magic\n","title":"llm","type":"tags"},{"content":"comparisons and field notes on model families, tiers, and routing choices\n","date":"20 March 2026","externalUrl":null,"permalink":"/tags/models/","section":"tags","summary":"comparisons and field notes on model families, tiers, and routing choices\n","title":"models","type":"tags"},{"content":"i spend a lot of time in cursor with an ai assistant beside me, using the workspace and mcp layout i described in my cursor setup. for a while i thought the path to better outputs was better prompts. it was not. the thing that actually moved the needle was connecting the assistant to the systems my team already uses as source of truth like jira for issue tracking and github for prs and code review.\nquick answer # i use model context protocol (mcp) servers for jira and github inside my editor. i start from templates (that i created with ai assistance), have the ai draft a proper issue from my rough notes, and then reuse that same narrative in the pull request with cross-links. the documentation sounds like overhead, but it is actually what makes later ai sessions work better, and every future model reads from the same source of truth instead of guessing.\nwho this is for # engineers already living in jira and github who are tired of copy-pasting between tabs anyone doing multi-step ai work where the second session has no idea what the first one decided teams that care about reviewable intent, not just the final diff the loop in plain terms # i set up mcp integrations so the assistant can create and update issues and pull requests without me retyping metadata.\ni describe what i want in rough bullets:\ngoals risks open questions links the ai maps that onto my issue template so the fields read like something a human reviewer would thank me for.\ni point the same assistant (or a fresh chat) at the issue as the source of truth while it implements. the issue holds scope, acceptance checks, and explicit out-of-scope notes.\nwhen the branch is ready, i have the ai open or update the pull request using a second template which will document everything including the summary, how to test, risk, and a link back to the issue.\nthe whole idea is one narrative in the places my team already looks, instead of three slightly different versions of the story scattered across slack, a comment thread, and a scratch file on my desktop.\nwhy templates matter more with ai # i know templates look bureaucratic. but a template is really just a schema. the ai fills in structured sections way more reliably than it invents structure on its own from a blank page. my templates bake in what \u0026ldquo;done\u0026rdquo; means, what reviewers should check, and where the links go.\nand another point on the schema that a template creates is that if it is used by everyone in the team, to reiterate a point from starter templates for ai rules, skills, and commands, the common, constant format makes human reading and reviewing much easier, faster, and accurate.\nwhen the ai drafts the issue first, this all leads to something i can actually read and edit in seconds, with a clear title, scoped description, and test notes, instead of staring at a blank text box trying to remember what i, or my teammates, meant.\nmcp as the glue # without live tool access, the assistant is guessing for any information that you did not explicity provide. it does not know the ticket number, the labels, or whether a pull request already exists. with mcp, it can actually look those things up, apply the template, and keep identifiers straight.\nthat sounds small, but it kills an entire category of mistakes like wrong links, stale titles, descriptions that drifted from what the code actually does. reviewers see consistent intent instead of hunting for mismatches, and the next ai session can re-fetch the real object in its current state instead of relying on whatever was in chat history.\nthe meta move: let the ai brief the next ai # here is the single habit that made the biggest difference. before i switch contexts (new chat, sub-agent, long implementation pass), i ask the current model to document everything that was done in the jira issue. i treat that block like a handoff document between shifts. then, subsequent iterations can read the issue to see what was done, were it was left, and know what it needs to do next to continue the task (because it was well-defined with done criteria at the start because of the template).\nthe ai is surprisingly good at this. it takes a messy conversation and compresses it into a clean set of instructions that the next session can pick up and run with. no rediscovering the plan, no \u0026ldquo;where was i?\u0026rdquo;.\ntrade-offs i accept # setting up mcp and templates takes real time upfront, but it pays for itself after just a few real tasks i still read every issue and pull request before it goes out. the ai writes the first draft, and i decide if it ships for a two-line fix, i skip the full ceremony. that is fine. not everything needs a process faq # does this slow you down on tiny changes? # sometimes, yes. for a trivial low-risk change i skip the heavy template. but if there is any chance someone (including future me) will need to understand what happened six months from now, i use the full loop.\nwhat if the issue and the code drift apart? # i treat that as a bug. if scope changes during implementation, i update the issue first, then the pull request. the ai can actually do that sync for me if i ask it to, for example \u0026ldquo;update the issue description to match what the code actually does now\u0026rdquo;.\nreferences # model context protocol mcp in cursor related reading # from prototype to production: my early adopter view of ai my cursor setup ","date":"19 March 2026","externalUrl":null,"permalink":"/posts/20260319-practical-ai-workflow-jira-github-mcp/","section":"posts","summary":"i connect my editor to jira and github through mcp, create well-structured issues from templates before coding, and reuse that text in pull requests so every agent in the chain has the same ground truth.","title":"a practical ai workflow: jira, github, and mcp","type":"posts"},{"content":"","date":"19 March 2026","externalUrl":null,"permalink":"/tags/github/","section":"tags","summary":"","title":"Github","type":"tags"},{"content":"","date":"19 March 2026","externalUrl":null,"permalink":"/tags/jira/","section":"tags","summary":"","title":"Jira","type":"tags"},{"content":"","date":"19 March 2026","externalUrl":null,"permalink":"/tags/mcp/","section":"tags","summary":"","title":"Mcp","type":"tags"},{"content":"","date":"18 March 2026","externalUrl":null,"permalink":"/tags/adoption/","section":"tags","summary":"","title":"Adoption","type":"tags"},{"content":"","date":"18 March 2026","externalUrl":null,"permalink":"/tags/benchmarks/","section":"tags","summary":"","title":"Benchmarks","type":"tags"},{"content":"i have been an early adopter of new technology for all of my career, and ai has been one of the fastest shifts i have seen.\nat first, ai felt \u0026ldquo;cool / neat / useful on the side\u0026rdquo;. i used it for first drafts, rough ideas, and quick experiments. and to expand \u0026ldquo;on-the-side\u0026rdquo;, it was a stand-alone tool, separate from other applications. i had to copy/paste questions and answers back and forth between the ai and my workspace.\nnow, it is different.\nai is no longer just a sidekick in my workflow. it is powerful enough to be production-usable when paired with the right guardrails, review loops, and system design. plus, these capabilities are integrated directly into all of the tools, applications, and websites i use daily.\nquick answer # ai is not a side tool anymore. the benchmarks are better, inference is cheaper, and companies are actually using it in production, not just piloting it. in my own work, i stopped treating it as one model for everything and started routing different models to different jobs. the concrete roster i use in practice is in deep dive: the ai models i use.\nwho this is for # leaders wondering whether ai is actually ready for real workloads (not just demos) engineers figuring out which model to use for what teams trying to keep quality high without the bill getting ridiculous the evidence: 1 year ago, 6 months ago, and now # if someone asked me \u0026ldquo;why do you trust it more now?\u0026rdquo;, the honest answer is that i have been using this stuff daily for a while, and the outputs are just better than they were a year ago. that is anecdotal. but the benchmarks back it up:\nwhen study stat that stood out to me ~1 year ago (2025) stanford ai index 2025 benchmark gains in one year were large: +18.8 (MMMU), +48.9 (GPQA), and +67.3 (swe-bench) percentage points ~6 months ago (sep 2025) fluid language model benchmarking (arxiv) on MMLU, they report higher validity and lower variance with 50x fewer evaluation items most recent i could find (feb 2026) prescriptive scaling reveals the evolution of language model capabilities (arxiv) analysis used 5,000 observational + 2,000 new model-performance points, and found math-reasoning frontiers are still advancing over time the part that gets me is not just that models are getting better, it is that we are also getting better at measuring whether they are actually better. both things improving at the same time is what makes me trust the trend.\nmore companies have models now # this is not just a tech story. the org charts moved too.\nthe stanford ai index 2025 economy chapter reports that:\norganizational ai use rose from 55% (2023) to 78% (2024) genai use in at least one business function rose from 33% to 71% and at the model-building layer, the same report notes that nearly 90% of notable ai models in 2024 came from industry (up from 60% in 2023). companies are not just buying models anymore, they are building them. that shift matters.\nhow models have evolved # the story is not \u0026ldquo;bigger model = better model\u0026rdquo; anymore. it got more interesting than that:\nONERULER (mar 2025) showed long-context multilingual performance can swing by up to 20% depending on instruction language, and english was only 6th of 26 languages in their setup longbench pro (jan 2026) evaluated 46 long-context models over 1,500 real long-context samples and found long-context optimization can matter more than raw parameter scaling prescriptive scaling (feb 2026) suggests some capability boundaries are stabilizing, while math reasoning keeps moving forward what i take from all of this: \u0026ldquo;what is the best model?\u0026rdquo; is the wrong question now. the right question is \u0026ldquo;best model for what?\u0026rdquo;.\nhow model usage has evolved (including slms) # the way i use models has changed as much as the models themselves.\nbefore, i used one large model for almost everything. now, i use a system:\nlarger models for hard reasoning, large requests, and high-stakes trade-offs smaller/faster models for mechanical edits or asking basic questions this helps balance cost, latency, and quality this is exactly where small language models (slms) come in, and why i think they matter more than most people give them credit for.\nthe stanford ai index 2025 highlights that inference cost for gpt-3.5-level performance dropped by over 280x between nov 2022 and oct 2024, driven partly by more efficient model options.\nand the slm research ecosystem is catching up quickly:\nslm-bench (2025) benchmarked 15 slms across 9 tasks, 23 datasets, and 11 metrics (accuracy, compute, and consumption) this 2026 slm/srlm benchmark reported a 4b model reaching 95.64% on a log-severity task with RAG, while a 0.6b model still reached 88.12% for me, the shift is going from \u0026ldquo;one model for everything\u0026rdquo; to a \u0026ldquo;roster of models to pick the right player for the job\u0026rdquo;.\nai agents are now inside nearly every tool i use # a year or two ago, \u0026ldquo;ai in my tool\u0026rdquo; meant autocomplete or a chat sidebar you forgot about after a week. that changed. in my day-to-day as a data engineer, ai now shows up in basically every tool i touch, and it actually does useful work.\nwhat that looks like in practice:\nmy code editor reads the repo, proposes multi-file edits, runs checks, and explains what it changed. it is not just finishing my sentences anymore source control and review tools help me draft pull requests, summarize diffs, and flag the risky parts before a reviewer has to ticketing and docs tools turn my rough brain dump into structured requirements and keep threads summarized so i do not have to re-read 47 messages data tools (sql editors, dbt, warehouse observability) help with query drafts, lineage questions, test ideas, and figuring out why a pipeline broke at 3am more and more of my operational workflows are bounded loops that the ai runs end-to-end while i review results the bigger picture is that tools used to wait for me to click a button. now agents work alongside me toward an outcome. this is what i call human+.\nclosing thought # i am still an early adopter. that has not changed. what changed is why i keep using it. it is not because ai is shiny or new. it is because it actually helps with real work when you set it up right.\nthe phase where i had to convince people \u0026ldquo;no really, this is useful\u0026rdquo; is mostly over. the current phase, figuring out how to engineer it into production systems that do not break, is harder, and honestly more fun.\nfaq # what is the most important takeaway from the benchmark trend? # no single benchmark number is the story. the story is that the trend points the same direction across different benchmarks and different time windows. that consistency is what makes me think this is real progress, not just one lucky test result.\nwhat is the practical operating model today? # use more than one model. hard problems and ambiguous decisions go to the big model. repetitive transforms, classification, and high-volume calls go to something faster and cheaper. add guardrails to both.\nreferences # stanford ai index 2025 prescriptive scaling reveals the evolution of language model capabilities longbench pro related reading # deep dive: the ai models i use ai br-ai-n fr-ai how to use ai to create ai rules, skills, and commands ","date":"18 March 2026","externalUrl":null,"permalink":"/posts/20260318-from-prototype-to-production-ai/","section":"posts","summary":"i have watched ai move from a prototype side assistant to an operational core system. this post shares that journey with time-stamped benchmark evidence and a practical view on where model usage is headed next.","title":"from prototype to production: my early adopter view of ai","type":"posts"},{"content":"","date":"18 March 2026","externalUrl":null,"permalink":"/tags/slm/","section":"tags","summary":"","title":"Slm","type":"tags"},{"content":"","date":"18 March 2026","externalUrl":null,"permalink":"/tags/strategy/","section":"tags","summary":"","title":"Strategy","type":"tags"},{"content":"how to build and use trigger-based shortcuts, turning repetitive actions into quick, reliable slash commands for your ai tools\n","date":"15 March 2026","externalUrl":null,"permalink":"/tags/commands/","section":"tags","summary":"how to build and use trigger-based shortcuts, turning repetitive actions into quick, reliable slash commands for your ai tools\n","title":"commands","type":"tags"},{"content":"how to write effective rules and passive guardrails for ai systems, encoding project standards so agents behave predictably\n","date":"15 March 2026","externalUrl":null,"permalink":"/tags/rules/","section":"tags","summary":"how to write effective rules and passive guardrails for ai systems, encoding project standards so agents behave predictably\n","title":"rules","type":"tags"},{"content":"how to design active, multi-step runbooks for ai execution, turning complex processes into reliable, repeatable skills\n","date":"15 March 2026","externalUrl":null,"permalink":"/tags/skills/","section":"tags","summary":"how to design active, multi-step runbooks for ai execution, turning complex processes into reliable, repeatable skills\n","title":"skills","type":"tags"},{"content":"in how to use ai to create ai rules, skills, and commands, i made the case for having ai draft any artifacts that would be primarily used by ai.\nthis post is the practical follow-up with generic templates you can copy, then adapt to your own constraints.\ni kept the examples generic on purpose so you can drop them into whatever stack you are working in.\nquick answer # tighter templates produce more consistent ai outputs. every time i add scope boundaries, ordered steps, and a clear definition of \u0026ldquo;done\u0026rdquo;, the same prompt works better across runs. the difference is not subtle.\nwho this is for # teams writing reusable ai operating instructions people seeing inconsistent results from weak prompt artifacts reviewers who want predictable outputs with clearer acceptance checks how to use this post # for each artifact type, i show:\na weak draft that usually creates inconsistent ai behavior an improved draft that adds scope, constraints, and done criteria a short explanation of why the quality improved in the second iteration template 1: rule files # weak draft (rule file) # # coding standards - follow team conventions - run checks before finishing improved draft (rule file) # --- description: \u0026#34;core implementation standards\u0026#34; alwaysApply: true --- # intent keep changes safe, scoped, and verifiable ## scope - in scope: files directly related to the requested task - out of scope: broad refactors, unrelated cleanup, dependency upgrades unless explicitly requested ## required behavior - preserve existing naming and architecture patterns - avoid modifying unrelated files - run validation checks for substantive edits - if a check fails, report the exact failure and likely cause ## output requirements - explain what changed and why - list validations executed and outcomes - call out remaining risks or assumptions what improved (rule file) # the second draft draws a line around what the ai should and should not touch, makes it run checks instead of just hoping for the best, and gives reviewers a predictable format which makes (human) scanning faster, easier, and more accurate.\ntemplate 2: skill files # weak draft (skill file) # # implement feature skill 1. read the task 2. implement the feature 3. test and finish improved draft (skill file) # # scoped feature implementation skill ## when to use - use when a feature request has clear acceptance criteria - do not use for open-ended brainstorming ## required inputs - objective - acceptance criteria - constraints (performance, security, compatibility) ## workflow 1. restate scope and assumptions 2. inspect relevant code paths 3. implement the smallest complete change 4. add or update focused tests for changed behavior 5. run validation checks 6. summarize outcomes, risks, and follow-ups ## done criteria - every acceptance criterion is mapped to an implementation result - validations pass or known failures are documented - no unrelated files are changed what improved (skill file) # the second draft tells the ai when to use this skill, what information it needs upfront, what order to work in, and how to know when it is finished. that last part, done criteria, is the one most people skip, and it is the one that matters most.\ntemplate 3: command files # weak draft (command file) # implement a feature. do the work and test it. improved draft (command file) # implement a scoped feature with verification. required inputs: - objective - scope - constraints workflow: 1. restate scope before editing 2. implement minimal complete change 3. add or update focused tests 4. run validation checks 5. return concise change summary and risks required behavior: - modify only files needed for this objective - avoid unrelated refactors unless requested - keep interfaces stable unless requirement says otherwise response format: - scope confirmation - files changed with rationale - validation results - open risks or follow-ups what improved (command file) # the vague version is basically \u0026ldquo;go do stuff\u0026rdquo;. the second version tells the ai exactly what it needs, how to work, and what shape the answer should take. it reads like a contract.\ntemplate 4: AGENTS.md # AGENTS.md is your project\u0026rsquo;s constitution. it sits at the root of your workspace and gives the ai the broad context it needs before it reads any specific rules or skills.\nweak draft (AGENTS.md) # # project info this is a react and node app. we use postgres. write clean code. improved draft (AGENTS.md) # # project context this is the `my-repo` workspace. it is a repository containing our data warehouse, backend services, and frontend ui. ## architecture - frontend: next.js (react) - backend: nestjs (node) - data: dbt on snowflake ## core principles 1. the backend is the source of truth for business logic 2. data models must mirror backend entity definitions 3. do not duplicate types across boundaries, and use the shared schema package ## available skills - use `create-dbt-model` when adding new analytics tables - use `sync-service-entity` when a backend migration affects the data warehouse what improved (AGENTS.md) # the second version gives the ai a map. instead of \u0026ldquo;write clean code\u0026rdquo; (which means nothing), it explains how the pieces of the codebase relate and tells the ai which skills to reach for when it hits common tasks. think of it as onboarding documentation, except the new hire is an llm.\nhow to test your new templates # do not just commit a new rule and hope for the best. test it (duh).\nthe happy path test: ask the ai to perform a standard task using the new skill. does it follow the steps in order? does it output the correct format? the boundary test: ask the ai to do something explicitly forbidden by the rule\u0026rsquo;s scope (e.g., \u0026ldquo;refactor the database connection while you add this button\u0026rdquo;). a good rule will cause the ai to refuse the out-of-scope work. the failure test: introduce a deliberate syntax error in a file, then ask the ai to run its validation step. does it catch the error and report it according to your failure reporting expectations? if the ai fails any of these tests, your constraints are not tight enough. go back to the template and make the boundaries more explicit.\nweak draft to improved draft checklist # when you improve any ai-facing artifact, check these six upgrades:\ndefine intent in one line define scope boundaries explicitly require ordered execution steps define done criteria standardize output format include failure reporting expectations closing note # if you only take one thing from this post, make it scope boundaries. in my experience, almost every time the ai does something weird, the root cause is not the model. it is that nobody told the model where the walls are, so it makes up its own answer because, as we have discussed before, ai ALWAYS has an answer.\nfaq # should i start with a rule, skill, or command template? # whichever one you reach for most often. for most people that is rules, because a good rule starts paying off immediately on every single run.\nhow do i know a template is ready for production use? # run it on a real task three ways:\nthe normal path something out of scope something deliberately broken if the ai handles all three the way you would want, keep it. if not, the boundaries need tightening.\nreferences # rules in cursor skills in cursor related reading # how to use ai to create ai rules, skills, and commands my cursor setup ","date":"15 March 2026","externalUrl":null,"permalink":"/posts/20260315-starter-templates-for-ai-rules-skills-and-commands/","section":"posts","summary":"this follow-up post gives practical, generic templates you can adapt for rules, skills, and commands, plus side-by-side examples that show why tighter structure improves ai execution quality.","title":"starter templates for ai rules, skills, and commands","type":"posts"},{"content":"reusable templates and starter scaffolds providing practical, copy-pasteable foundations you can adapt for your own workflows and ai instructions\n","date":"15 March 2026","externalUrl":null,"permalink":"/tags/templates/","section":"tags","summary":"reusable templates and starter scaffolds providing practical, copy-pasteable foundations you can adapt for your own workflows and ai instructions\n","title":"templates","type":"tags"},{"content":"for each rule, skill, and/or command, remember that they are mainly read by ai. thus, ai should, at least, draft the first version. then you can dial in the details from there. but this will give you a good starting point, and most notably, it will be written in the format the ai understands the best. you can just focus on making sure the content is correct. for copy-paste templates and weak versus improved examples, see starter templates for ai rules, skills, and commands.\nthat does not mean handing over ownership. i still define the goals, the boundaries, and what \u0026ldquo;good\u0026rdquo; looks like. the ai just takes that guidance and turns it into structured instructions that other ai runs can actually follow without drifting.\nquick answer # since ai is the one reading and following a rule, skill, or command, let ai write the first draft. you still own the truth, the boundaries, and what counts as \u0026ldquo;done\u0026rdquo;. but the formatting and structure? ai is better at writing for ai than you are, and that is fine.\nwho this is for # teams building reusable ai instructions for repeated workflows people who want cleaner ai execution with fewer ambiguous outputs reviewers who need predictable artifact quality and safer constraints definitions: rules vs. skills vs. commands # before you ask ai to draft anything, it helps to know which bucket it belongs in. here is how i think about the three types:\nrules (.mdc files): passive, always-on guardrails. use these for things the ai should never do, or formatting it should always use. (e.g., \u0026ldquo;always use lowercase for markdown headings\u0026rdquo;.) skills (SKILL.md files): active, multi-step runbooks. use these for complex processes that require a specific order of operations. (e.g., \u0026ldquo;how to scaffold a new dbt model and its tests\u0026rdquo;.) commands (.md files): trigger-based shortcuts. use these for quick, repetitive actions you want to fire off with a slash command. (e.g., \u0026ldquo;/review-pr\u0026rdquo; to run a specific review prompt.) the core idea # match the writer to the reader.\nif ai is the one following the instructions, ai should write the first draft. in my experience it will:\npick a format that is natural for ai to parse (.md, .mdc) draw sharper lines around what the task is and is not spell out acceptance criteria i would have left vague produce fewer \u0026ldquo;wait, what do i do next?\u0026rdquo; gaps stay more consistent when the same artifact runs multiple times (repeatable across human users) why this works in practice # the format fits the reader, ai writes instructions in a shape that other ai runs parse well, which is not surprising but it matters more than people expect iteration is faster, you can go from rough idea to usable draft in minutes instead of agonizing over wording from a blank page the scaffolding is more complete, ai is annoyingly good at remembering to include constraints, edge cases, and verification steps that i would skip reuse gets easier, once a rule or skill format works, you can stamp out the same pattern for a different task or a different repo without starting over where humans stay in charge # the human still decides:\nwhat problem we are actually solving what is in scope and what is not what \u0026ldquo;good\u0026rdquo; looks like which risks are not acceptable whether the final version ships the ai writes. i approve. this boundary is non-negotiable for me.\nstarter workflow you can use # write a short human brief: objective, scope, constraints, and examples ask ai to draft the rule/skill/command in a strict template review for accuracy, ambiguity, missing constraints, and unsafe assumptions feed corrections back and ask for a tighter second draft test it on one real task ONLY keep the artifact if the final state adds direct, consistent value BE CAREFUL to not create too many rules just for ceremony example of the human brief # this does not need to be polished. i treat it as a brain dump about what you want.\nhuman brief: \u0026ldquo;i need a skill for adding a new api endpoint. it needs to update the openapi spec first, then create the controller, then write a failing test. do not let it touch the database layer\u0026rdquo;.\nthe ai will take this messy sentence and turn it into a structured markdown file with clear trigger conditions, step-by-step instructions, and explicit out-of-scope boundaries.\nmaintenance and decay # ai instructions rot over time. as your project evolves, the rules that worked in march will start causing friction in august.\nhow to spot decay:\nthe ai starts apologizing and saying \u0026ldquo;i will follow the rule next time\u0026rdquo; (but it did not this time) you find yourself manually overriding the ai\u0026rsquo;s output on a specific task the rule references files or folders that have been renamed when this happens, do not just tweak the rule manually. feed the broken rule back to the ai, explain why it is failing, and ask it to generate an updated draft. i regularly add a note at the end of my prompts that says something like \u0026ldquo;please update any relevant documentation\u0026rdquo;.\ncommon failure mode # the biggest way this goes wrong is when ai starts making up policy instead of encoding your policy.\nhere is the thing about ai, it always has an answer. always. so if your intent is vague, the ai will not stop and ask, and it will just guess. and confident guesses that are wrong are worse than no answer at all.\nmy rule is to get the truth right first. let ai worry about the formatting second.\nnext post # here is a follow-up with concrete starter templates plus weak-draft \u0026gt; improved-draft examples:\nstarter templates for ai rules, skills, and commands faq # what should i optimize first: format or policy? # policy, every time. if the policy is vague, a beautifully formatted rule just makes the wrong behavior repeat faster and with more confidence.\nwhen should i not use this method? # when you are still figuring out what you even want. if requirements are fuzzy, start with human conversation. do not convert anything into a structured artifact until you actually know where the walls are.\nreferences # rules in cursor skills in cursor related reading # starter templates for ai rules, skills, and commands my cursor setup ","date":"14 March 2026","externalUrl":null,"permalink":"/posts/20260314-how-to-use-ai-to-create-ai-rules-skills-and-commands/","section":"posts","summary":"this kickoff post explains why ai-authored rule, skill, and command scaffolds are often clearer for ai execution, and how to keep humans in control with constraints, reviews, and acceptance checks.","title":"how to use ai to create ai rules, skills, and commands","type":"posts"},{"content":"yes, the title is a philliant joke, but the problem is real: when everything is ai-assisted, everything multiplies exponentially, so your brain starts feeling cooked.\nquick answer # when i just allow the ai to run wild, especially letting it run on an ambiguous prompt, the likelihood of brain fry increases. i get that familiar brain fog feeling from when i am overworked, under-rested, and thinking deeply without breaks. think of it like running, eventually you have to take breaks to recharge or else you risk fatiguing to the point of mistakes and failure.\nwho this is for # anyone juggling multiple ai-assisted tasks at the same time and feeling it teams where activity is high but confidence in what shipped is low builders who want to stay fast without feeling mentally cooked by noon what i mean by \u0026ldquo;brain fry\u0026rdquo; # in this post, \u0026ldquo;ai brain fry\u0026rdquo; means:\nthe burnt-out brain feeling you get from thinking too hard about too many things at once (like muscle exhaustion but for your brain) this feeling is largely driven by: too many parallel prompts without a clear decision path constant context switching across tools, tabs, and models shallow progress loops that feel busy but not meaningful low confidence in final output quality despite high activity the result is spending more energy and resources on thinking than is humanly possible because you are trying to keep up with a machine. i like to call this the john henry effect.\nsymptoms of ai brain fry # how do you know you have crossed the line from \u0026ldquo;highly productive\u0026rdquo; to \u0026ldquo;fried\u0026rdquo;? look for these symptoms:\nyou have 15 different chat threads open and cannot remember which one has the working solution you find yourself writing prompts that are just \u0026ldquo;fix it\u0026rdquo; over and over without reading the errors you forget what the original jira ticket was even asking for because you got lost in a refactoring rabbit hole (the leaky faucet effect) you feel the \u0026ldquo;brain fog\u0026rdquo; that comes with mental fatigue if you hit two or more of these, you need to step away from the keyboard.\nwhat i want to explore (and answer here) # what is the right split between human judgment and ai execution? the human owns the problem. framing, constraints, trade-offs, and final sign-off are yours. ai owns first drafts, option generation, repetitive transforms, and test scaffolding.\nmy shortcut for deciding:\nif the decision is high-impact and hard to undo, i own it\nif the task is mechanical and easy to roll back, ai performs it\nhow do i keep speed without experiencing fatigue and burn-out?\nspeed that burns you out is not speed. i use short cycles, define the outcome, run the ai, review what it produced, then pause before jumping into the next thing. the stopping conditions matter, and i decide when to stop before i start, because once i am in the flow it is way too easy to keep going. when i want that discipline backed by a single narrative in jira and github, i use the loop in a practical ai workflow: jira, github, and mcp.\nwhich workflows reduce cognitive load instead of adding hidden overhead? boring workflows. seriously. one thread per objective, one source of truth for requirements, one review checklist before merge. it sounds dull, but it kills the hidden tax of constantly reopening context and trying to remember what you were doing ten minutes ago.\nwhat team habits prevent ai-assisted chaos? shared prompt patterns, short decision logs, and agreeing on what \u0026ldquo;done\u0026rdquo; actually means. if ai creates a second coordination problem on top of the one you already had, you are doing it wrong.\nmy working thesis # brain fry is not an \u0026ldquo;ai is bad\u0026rdquo; problem. it is a \u0026ldquo;how do i work with something that never gets tired when i absolutely do?\u0026rdquo; problem.\nset your own personal boundaries with the ai. here are some things to avoid: the \u0026ldquo;just one more task\u0026rdquo; trap (i unpack that loop in brain defrag: time away from screens (and from \u0026ldquo;one more\u0026rdquo; with ai)) going down the rabbit-hole and \u0026ldquo;fixing\u0026rdquo; things that are tangent to the task, but actually out-of-scope trying to keep up with ai as it works having ai perform more work than you are able to review having ai perform work that is outside your area of expertise (i.e. you are not able to understand or verify the changes) i try my best to use the ron popeil method and set it and forget it. just let the ai run and then come back and review the results/output when it is complete.\nmaking set it and forget it work # to actually walk away, you have to write prompts that include their own verification loops.\ninstead of: \u0026ldquo;write the data model\u0026rdquo;.\nuse: \u0026ldquo;write the data model. then write the dbt tests for it. then run dbt test. if it fails, read the error and try to fix it up to 3 times. stop when it passes or after 3 attempts\u0026rdquo;.\nnow you can actually walk away. the ai has permission to struggle, retry, and stop on its own. you come back to results instead of error messages.\nfaq # how many active ai threads are too many? # i do not have a magic number. but here is my test: if i cannot explain from memory what each open thread is doing and where it left off, i have too many. time to close some and get back to one thread per objective.\nshould i slow down ai usage to reduce fatigue? # not really. slowing down the ai is not the fix. redesigning the workflow is. keep the ai running fast, but reduce how often you have to context-switch to check on it. bounded loops and batch review usually get you there.\nreferences # task switching (psychology) cognitive load related reading # brain defrag: time away from screens (and from \u0026ldquo;one more\u0026rdquo; with ai) a practical ai workflow: jira, github, and mcp how to use ai to create ai rules, skills, and commands from prototype to production: my early adopter view of ai ","date":"14 March 2026","externalUrl":null,"permalink":"/posts/20260314-ai-br-ai-n-fr-ai/","section":"posts","summary":"this post frames ai brain fry as a workflow design problem and gives a practical framework to reduce cognitive overload while keeping ai leverage high.","title":"ai br-ai-n fr-ai","type":"posts"},{"content":"below is my cursor setup as of friday mar 13, 2026, but rewritten as a tutorial you can actually use.\ni am not claiming this is the \u0026ldquo;best\u0026rdquo; setup. i am claiming this setup works for my day-to-day work, and that you can borrow the pieces that work for you.\nquick answer # three things make this setup work for me: one workspace with all my repos in it, rules and skills that tell the ai how my projects actually work, and a habit of verifying outputs before i trust them.\nwho this is for # people using cursor for technical work across multiple repositories teams that want higher ai throughput without losing review quality builders who want a practical setup they can replicate quickly why this matters # my goals for this post:\nexplain what i use, why i use it, and what each part does give you enough links and steps to replicate the setup quickly keep it opinionated (because opinions are useful), but still practical if you want references while reading:\ncursor docs home model context protocol intro what is dbt machine # first, i will admit that i am in a very good hardware situation for data + ai workflows. that helps.\nmy current machine:\ndevice: macbook pro 16\u0026quot; (m2 max, 64gb ram) os: tahoe 26.3.1 workspace layout # my setup is multi-repo on purpose. i work as part of a larger team with separated repos for data, backend, and ui. there are a few more infrastructure related repos, but for the most part, our work is in the three aforementioned repos, with my work being exclusive to the data repo. all of this combines into one web application.\nif your work spans multiple repos, put all of them in one cursor workspace (even if you do not commit in all of them). the extra context makes agent output much more useful.\nwhy:\nagents can reason across boundaries (for example, backend contract changes that impact frontend and data models) you reduce manual cross-team \u0026ldquo;did you change x?\u0026rdquo; pings indexing across repos improves semantic search quality how to set this up:\ncreate/open your primary repo in cursor add other related repos via file -\u0026gt; add folder to workspace... order the repos from top to bottom in the order of which repo you use most at the top and least at the bottom (this is because semantic search scans your workspace file tree from top to bottom, so having your most used repo at the top means the search returns results from that repo first) save the workspace file so you can reopen the exact same context each day references:\nmulti-root workspaces (vs code docs) cursor semantic + agentic search cursor settings i rely on (what each one does) # these are not exotic settings. they are just my defaults.\nstarter settings.json:\n{ \u0026#34;workbench.colorTheme\u0026#34;: \u0026#34;Cursor Dark\u0026#34;, \u0026#34;editor.fontFamily\u0026#34;: \u0026#34;JetBrains Mono, Menlo, Monaco, \u0026#39;Courier New\u0026#39;, monospace\u0026#34;, \u0026#34;editor.fontSize\u0026#34;: 14, \u0026#34;editor.fontLigatures\u0026#34;: true, \u0026#34;editor.formatOnSave\u0026#34;: true, \u0026#34;files.autoSave\u0026#34;: \u0026#34;onFocusChange\u0026#34;, \u0026#34;editor.inlineSuggest.enabled\u0026#34;: true, \u0026#34;editor.minimap.enabled\u0026#34;: false, \u0026#34;editor.rulers\u0026#34;: [100], \u0026#34;terminal.integrated.defaultProfile.osx\u0026#34;: \u0026#34;zsh\u0026#34; } what each setting does and why i keep it:\nsetting what it does why i use it workbench.colorTheme controls editor color theme i use cursor dark because contrast is good without being harsh on long sessions editor.fontFamily picks the code font stack i keep a clean mono font stack so rendering is predictable on any machine editor.fontSize controls code text size 14 is my readability/screen-density balance editor.fontLigatures enables ligatures in supported fonts helps quick symbol parsing, especially in sql and typescript editor.formatOnSave auto-formats when saving eliminates style drift and manual formatting overhead files.autoSave auto-saves files by trigger onFocusChange is safer than after-delay for active edits editor.inlineSuggest.enabled enables inline ai suggestions keeps quick local iteration fast editor.minimap.enabled shows/hides code minimap i disable it to reduce visual noise editor.rulers vertical line markers keeps me honest on line length terminal.integrated.defaultProfile.osx chooses terminal shell profile ensures my shell scripts and aliases behave as expected references:\nthemes and appearance keyboard shortcuts keybindings i use constantly # these are the shortcuts i use hundreds of times a day:\naction mac why this matters toggle ai sidepanel cmd+i or cmd+l fastest path to agent context command palette cmd+shift+p entry point for almost every cursor power feature reference:\ncursor keyboard shortcuts model selection strategy (my opinionated default) # my model strategy is simple:\nuse the biggest, baddest model i can afford for all tasks again, i recognize my privilege here that i have effectively unlimited access to all of the most powerful models your model strategy should probably be something a little more like:\nuse auto / composer for most tasks switch to a stronger model for architecture or debugging-heavy work switch to a faster/cheaper model for repetitive edits, formatting, or broad scans this keeps quality high without letting cost run wild.\nreference:\nmodels and pricing project-level ai behavior: rules, agents.md, and skills # this is the part that made the biggest difference for me. everything above is editor configuration. everything below is what turns the ai from \u0026ldquo;generic assistant\u0026rdquo; into something that actually knows your project.\nrules # rules are persistent instructions that live in your project. i use them to encode the stuff i got tired of repeating, such as team conventions, naming patterns, and \u0026ldquo;do not do this\u0026rdquo; guardrails.\nreference:\nrules example rule (.cursor/rules/project-standards.mdc):\n--- description: \u0026#34;project coding and validation standards\u0026#34; alwaysApply: true --- - keep edits scoped to the requested task - follow existing naming and folder patterns - run project validation checks for substantive changes agents.md # AGENTS.md is a markdown file at the root of your repo. i use it for plain-language context that the agent should always have, including project architecture, how repos relate, and what skills exist.\nreferences:\nrules and agents.md overview skills # skills are step-by-step runbooks for tasks you do over and over. i have one for creating a new data model that handles the sql, the docs, the tests, and the validation summary all in one pass.\nreference:\nskills example skill (.cursor/skills/release-checklist/SKILL.md):\n# release checklist 1. run lint, format, and tests 2. list any failing checks with exact remediation 3. summarize risk areas and edge cases 4. provide release notes in markdown context hygiene: ignore what should not be indexed # cursor respects .gitignore, and you can add .cursorignore for extra exclusions.\nthis matters for two reasons:\nsignal quality (so the ai is not reading garbage) safety (so it does not index your secrets, generated files, or vendor blobs) reference:\nignore files starter .cursorignore:\nnode_modules/ dist/ build/ coverage/ *.min.js .env* the art of the @ mention # even with a clean index, you do not want the ai guessing which files matter. i rely heavily on explicit @ mentions in my prompts.\n@Files to pull in specific files @Folders to give the ai a boundary to look within @Web when i need it to read a specific documentation page that is not in my workspace my rule of thumb is that if i already know where the answer lives, i point the ai directly to it. do not make the ai go on a scavenger hunt.\nwhen the ai gets stuck (troubleshooting) # no setup prevents every failure. when the ai starts hallucinating or going in circles, here is what i actually do:\nstop arguing with it. if it fails twice on the same thing, going back and forth just fills the context window with noise. i learned this the hard way start a new chat. drop the baggage. open a fresh session with only the specific files you need attached switch models. sometimes the model is just stuck in a rut. swapping to a different one breaks the pattern more often than you would expect mcp servers in my setup (what each one actually gives you) # mcp is what allows cursor agents to talk to my other tools. for how i turn jira and github into the documentation-first loop with those integrations, see a practical ai workflow: jira, github, and mcp. here are the servers i use and what they actually do for me:\nmcp server what it enables when i use it docs github repo/issue/pr context and actions code review, pr drafting, issue triage, release hygiene github mcp server atlassian jira + confluence context and updates converting specs to tickets, reading decisions, status updates atlassian rovo mcp dbt labs dbt metadata, lineage, semantic layer, dbt actions model design, lineage checks, docs generation, build/test help dbt mcp snowflake governed data access and mcp-native tools query validation, analytics checks, warehouse-backed exploration snowflake mcp figma design-system + frame context for implementation translating designs to components with less guesswork figma mcp server slack search/read/post capabilities in slack context finding decisions, summarizing threads, drafting updates slack mcp server a word on security:\nany mcp tool that can write or change things is real power, not a toy use least privilege, prefer oauth over api keys sitting in plaintext, and make sure destructive actions require you to say \u0026ldquo;yes\u0026rdquo; before they fire dbt references i actually use # if your setup includes dbt, these are the docs i recommend bookmarking:\ndbt quickstarts dbt project documentation dbt docs command reference theme choice # i prefer dark everything, so my theme in cursor is cursor dark, of course\nreferences:\ncursor themes and appearance replicate this setup in 45 minutes # if you want the practical version, do this in order:\ninstall/update cursor from cursor downloads create one workspace and add all related repos paste the starter settings.json and tweak font/theme set your core shortcuts (cmd+i, cmd+l, cmd+shift+p) add one always-on project rule for coding standards add one skill for your most repeated workflow add a .cursorignore file connect mcp servers one by one (github first is usually easiest) verify each integration with one safe test prompt document your final setup so your team can copy it verification prompts you can copy # these are good smoke tests after setup:\n\u0026ldquo;scan this workspace and summarize architecture in 10 bullets\u0026rdquo; \u0026ldquo;list project conventions i should follow before i edit code\u0026rdquo; \u0026ldquo;for this dbt project, explain lineage for model x and suggest tests\u0026rdquo; \u0026ldquo;summarize open engineering tickets related to this feature\u0026rdquo; \u0026ldquo;draft a release update message from recent merged prs\u0026rdquo; results # what this actually gives me day to day:\ni start tasks faster because the ai already knows my project i almost never retype the same instruction twice the ai can reason across repos, which catches things i would miss handoffs are cleaner and i have far fewer \u0026ldquo;oh no, i forgot about that dependency\u0026rdquo; moments closing # do not copy my setup 1:1. that is not the point.\nthe point is to try things, keep what removes friction, and ruthlessly delete what adds ceremony. the best setup is not the fanciest one. it is the one where the loop between \u0026ldquo;i want this\u0026rdquo; and \u0026ldquo;it is done and verified\u0026rdquo; stays as short as possible.\nfaq # what should i set up first if i only have 20 minutes? # one workspace with your most-used repos and your core shortcuts. then write one always-on rule so the ai knows your project constraints from the first prompt. everything else can wait.\nwhat is the most common failure mode with this setup? # context drift. if you do not tell the ai which files or folders matter, it burns tokens wandering around your codebase instead of solving the thing you actually asked about. explicit @ mentions fix this almost instantly.\nreferences # cursor docs home model context protocol intro related reading # a practical ai workflow: jira, github, and mcp how to use ai to create ai rules, skills, and commands starter templates for ai rules, skills, and commands deep dive: the ai models i use ","date":"13 March 2026","externalUrl":null,"permalink":"/posts/20260313-my-cursor-setup/","section":"posts","summary":"this is my real cursor setup as of march 13, 2026, rewritten as a practical tutorial with settings explanations, mcp server breakdowns, and a replication checklist.","title":"my cursor setup","type":"posts"},{"content":"tactics and philosophies for getting things done, with a focus on sustainable output and reducing friction rather than just doing more for the sake of it\n","date":"13 March 2026","externalUrl":null,"permalink":"/tags/productivity/","section":"tags","summary":"tactics and philosophies for getting things done, with a focus on sustainable output and reducing friction rather than just doing more for the sake of it\n","title":"productivity","type":"tags"},{"content":"notes on the craft of writing, covering everything from personal knowledge management to writing better instructions for ai agents\n","date":"13 March 2026","externalUrl":null,"permalink":"/tags/writing/","section":"tags","summary":"notes on the craft of writing, covering everything from personal knowledge management to writing better instructions for ai agents\n","title":"writing","type":"tags"},{"content":"posts that go beyond the basics, covering more nuanced or technical territory for readers who already have the fundamentals down\n","externalUrl":null,"permalink":"/tags/advanced/","section":"tags","summary":"posts that go beyond the basics, covering more nuanced or technical territory for readers who already have the fundamentals down\n","title":"advanced","type":"tags"},{"content":"this privacy policy explains how i handle data for philliant.com and the automation i use to publish my posts to social platforms, including linkedin and dev.to.\nwhat this policy covers # this policy covers:\nthis website and its published content my github-based publishing automation my linkedin publishing integration for my personal profile my dev.to publishing integration for my personal account data i access # for automation and publishing, i may access:\nlinkedin authorization data, including access token, granted scopes, and member identifier dev.to authorization data, including api key and account identifier post metadata from my site content, such as title, summary, tags, and canonical url workflow run metadata in github actions logs how i use data # i use this data only to:\npublish links and post summaries for my own content run, monitor, and troubleshoot publishing automation maintain the reliability and security of my publishing workflow where data is stored # linkedin access tokens and dev.to api keys are stored in github as encrypted repository secrets site content is stored in my github repository workflow execution details are stored in github actions logs according to github retention settings data sharing # i do not sell personal data.\ni only share required data with service providers needed to operate this workflow:\nlinkedin, for post publishing through linkedin apis dev.to, for post publishing through the dev api github, for repository hosting and github actions automation data retention and deletion # i can rotate or delete linkedin tokens or dev.to api keys at any time i can remove linkedin app access from linkedin account settings at any time i can delete published dev.to posts from my dev.to account at any time automation-related data stored in github follows repository and github retention policies your choices # you can:\navoid authorizing the app revoke app permissions at any time in linkedin settings contact # for privacy questions related to this site and automation, contact me on linkedin:\nphilip hern ","externalUrl":null,"permalink":"/privacy/","section":"philliant","summary":"this privacy policy explains how i handle data for philliant.com and the automation i use to publish my posts to social platforms, including linkedin and dev.to.\nwhat this policy covers # this policy covers:\n","title":"privacy policy","type":"page"}]