---

How My Journey with AI Started - GitHub Copilot GA

I got access to GitHub Copilot a bit early into its technical preview, and found it super handy. Back then I was frequently switching between Go, Python and TypeScript, and was doing a bunch of cross-platform work. So with AI, a lot of redundant work like looking up syntax, boilerplate alignment, screen definitions across platforms, and platform-specific behavior was taken care of, and I could focus on the logic and the architecture. It was a great boost to my productivity, and I felt like there was potential in it. I had learned vim macros to help me with things like schema edits, fixes and other typing-heavy dumb work where you're just copy-pasting and changing a few things, and AI was like a supercharged version of that. At some point, even the flexibility of macros starts feeling limiting, since you still have to, well, "spend hours automating a task that you only have to do a few times". With AI, I could just do it on the fly, and it would be just as simple as adding a comment above the code and asking it to do something, and it would do it in seconds (the Chat-based AI coding tools were still rough around that time; now the IDE/Editor integrations are pretty nifty, no need for clunky copy-pasting). Today that dynamic has shifted from inline comments to a chat-based interface, which feels more natural to some (more on that later), but the point is that it was a great boost to my productivity, and I felt like there was potential in it.

There wasn't a feeling of loss of control, or that I was outsourcing my thinking to a black box, because I still had to review the code and understand it, and I could easily modify it if it wasn't exactly what I wanted. It was more like having a super smart pair programmer who could help me with the boring stuff, so I could focus on the fun and creative parts of coding ("Copilot" was thus the perfect name, but Microsoft has since ruined it by using that branding for everything). The same can't be said about how "agent-driven" programming is today; the edits from comment-driven completions are more local to the current file, you still have to figure out how to wire that with the rest of your code, and that is a good thing and bad thing depending on your perspective (again, more on that later).

I saw the upsides: I went from shipping updates for my startup way quicker, and a lot of the boring parts of a task didn't bother me as much. The inertia to pick up a new ticket (I subjected myself to Jira to maintain discipline when working on my startup, despite being a solo founder, which you can read about here) was much lower, and the burnout factor after a giant feature build was much lower. I also found myself getting AI to write more test cases for my code, which got me to build a healthy habit that I guess a lot of solo founders back then didn't have, which was to prioritize testing. I mostly had tests for things that I knew were sensitive, or that I had broken in the past, but now with AI, I could come up with a test plan and just get AI to copy my style of writing test cases and replicate it for the rest. The code still felt like I wrote it, so it was something I could be confident about throughout the lifecycle of the project, and I felt like I had a good handle on it. I also found myself using AI to help me with things like writing documentation. I love documenting code, but as a one-man army, that would eat into time that could go into marketing or planning, so it was a practical trade-off and was limited to key architectural decisions and complex logic; with AI, I had time for it.

What AI did back then for me was improve my ability to get my thoughts into code faster, and spared me the pain of the boring parts. I found myself spending more time reading and understanding how to build stuff better (things that most people skip out on due to a lack of time and accumulating fatigue), and I knew it was worth investing into, since I also implement this new shiny trinket in my code without much pain. That was how I picked up Playwright and continue to swear by it to this day (which back then would've been a lot of effort to get off the ground and time that could've gone into building features).

This post-technical preview era of Copilot was so good for me, I ended up getting the annual subscription the second it went GA, and it has continued to get renewed since (maybe that'll change with the new pricing model, I'm yet to fully feel the impact of that personally since I only work on personal projects during the weekends).

Enter AI Bubble - The Hype, The Disillusionment and The Realization (Pre-2025H2)

Copilot code completion was a 10x difference for me personally; agents, not so much, and I'll explain why. The humble autocomplete got tagged with a chat window, the ability to manipulate in-place multiple files, and the ability to have greater insights from LSPs through MCPs. This, in my opinion, at least in the 6 months leading up to mid-2025, was 1 step forward and 2 steps back. The reason being that the more "agent-driven" approach to coding felt like I was outsourcing my thinking to a black box, and I had less control over the code that was being generated. It felt more like I was giving up on my creativity and problem-solving skills, and just letting the AI do all the work. Instead of being more actively involved with the code, I was in a prompt window, offering instructions like a PM (no offense to them, my current job is to cosplay as one when needed, and since AI, haven't we all? If you aren't, you should). Now I just said "add i18n to the following files", it would edit 20 files, follow some pattern that it deemed was good (model-dependent, and it did get better over time), then changing 20 files manually or asking it to not push i18n a certain way would either be manual effort or what I like to call "prompt gambling", where you hope the AI gets what you want and properly follows it. A lot of these issues came down to how new the Agentic toolsets were back then, and the models too. Context engineering, IMO, has been the biggest facelift in the past year and it shows in the quality of the outputs today. Since the AI changed files in the background, the review time went up, and most of the time you're trying to read things with more focus because you fear the mythical "AI hallucinations" that leave silent bugs in your code. If I wrote it myself, I would have skimmed comfortably (this is a mindset thing more than it is a technical thing; you determine what helps you sleep better at the end of the day. For me, it's knowing exactly what code is being changed and how, and that is something I lost with the agent-driven approach, but again, this was in the early days of it, and it has gotten better since then).

This approach, when it worked well, especially for moderately complex tasks, made you feel like you had a junior dev who was super fast and competent, but with the need for the occasional hand-holding—which is alright, I guess everyone can learn to work with a junior dev, and programmers particularly need to learn to play nice. In that way, I've seen people who embraced AI right do the following better:

• Documentation: AI needs to know what to do; centralizing it helps, so everyone started prioritizing documentation, even if most of it was also AI-generated, but hey, it's better than nothing.
• Testing: You suddenly have time, and if you're smart with your test cases, it saves you review overhead.
• Code Reviews: AI cut down the time to dig through large PRs, and if you prompt it right, it lets you focus and drill down on the things that matter.

The Hidden Overhead of Context Drift

While "prompt gambling" is annoying, there is a far more exhausting tax that nobody warns you about when shifting to an agent-driven workflow: Context Drift. When you write code linearly, your brain is in creation mode. You map out the data structures, execute the logic, and mentally track the system state. It’s demanding, but it’s cohesive.

When you delegate a massive multi-file change to an agent loop, your role abruptly shifts from creator to auditor/debugger. This psychological pivot is jarring. Suddenly, you aren't holding your own mental model in your head; you are forced to reverse-engineer the agent's mental model while simultaneously running a diff check against your project's architectural standards. Vibe-checking an AI’s code choices across 20 modified files requires an entirely different kind of hyper-focused cognitive energy. If you aren't careful, the time you "saved" writing the code is quickly cannibalized by the immense mental fatigue of trying to ensure the agent didn't quietly drop a subtle bug or invent a localized pattern that breaks consistency.

Recognizing Skill Atrophy

With how quick AI is at everything, and with models getting better each generation, for most tasks your thought process over time becomes "just throw AI at it". For simpler tasks, the error message or a relevant snippet of code is sufficient for AI to figure out what to do, no prompting (this is how I've continued to use NixOS and keep my config up-to-date, by the way). For more complex tasks, you do it the way I described above, but here's the thing: at some point, you stop flexing your proverbial "muscles". Your muscle memory with syntax will fade before you know it. I tried coding on a personal project that had a Go backend and a Next.js frontend without Copilot (just standard autocomplete), and I could feel a lag in my thoughts. It took longer for me to figure out what I was going to type out, because my brain had been wired to explain the problem in an inline comment or chat box, get some code, and hack on it. When I found myself staring at a fresh SQL transaction, it took me a bit to get going and reach my flow state.

Now here's where it gets dangerous: you now realize you're slower and are left with two choices, either find a way to regain what you've lost or double down on AI since that's going to replace you according to the billionaire in the leather jacket. I chose the former, and I'll talk about it in a bit, but for most people with jobs and revised productivity expectations once an AI tool has been provided, "trad coding" may not be an option. You simply cannot out-code something that fills out 20 files in seconds; no vim macros or actual human pair programmer can get you there for the simpler stuff that AI can do reliably without too much supervision.

Market Shifts (and a rant about hype cycles)

Everyone now wants AI agents because their perceived productivity is greater, and most engineers have become reviewers and PMs of sorts. I like the PM/BA shift; most engineers suffer from a lack of understanding of the domain/product, and the gaps between product and engineering are where most applications fail. So people having to understand the product better to prompt the AI better, just like the documentation adoption thing, is a win in my book.

There are also layoffs as a result of AI, and that sucks for the individuals. Since COVID, that has definitely become a means for public companies to boost stock prices (not necessarily cut costs). The private ones probably are the only ones, for whatever reason, either for actual cost-cutting or to get leaner (because organizational bloat is sadly very much true). The point is, AI may not actually take your job, but cause you to lose it because of how a particular AI company decides to market its latest models and fudge benchmarks to sell the next 30-60% pricier model with a 5-10% improvement in quality to you or your org. On a personal level, I hate these hype cycles. We saw it with Crypto recently, and now it's AI. Most of the AI companies are just shuffling money amongst themselves to keep their books green for a potential IPO at an overvalued 100x valuation, and the only people hurt (well, aside from the r/WallStreetBets crowd who time their trades right) are the engineers who get laid off for reasons beyond their control.

The Mentorship Gap: Guardrails for Next-Gen Engineers

This market shift raises a darker question: What happens to the engineers who didn't get to live through the pre-AI preview era? Those of us with a few years under our belts use AI to skip the boring stuff because we already know how the boring stuff works under the hood. We have the baseline mental compiler to spot a bad abstraction or a garbage SQL index instantly.

But for entry-level developers entering the industry today, AI isn't just a productivity booster—it's an intellectual bypass. When junior engineers use agents to skip the foundational struggle of debugging, reading stack traces, and wrestling with syntax, they miss out on building their core engineering intuition. If the team environment rewards pure velocity over deep comprehension, we end up creating a dangerous gap where junior devs become heavily dependent on an external cloud model just to write basic logic. As senior engineers, we have to establish strict team guardrails. We need to measure junior developer growth not by how many tickets their agent completed, but by their ability to explain the underlying system topology without a chat prompt open.

Another factor that irks me is the blatant abuse of copyrights, with companies going as far as to torrent copyrighted material to train their models, and then DMCA'ing the YouTube channel of 10-year-olds who wanted Linkin Park playing on their game edits. There is definitely some kind of profit-sharing or royalties arrangement that these companies need to arrive at with creators of the work they plagiarize (AI learning isn't the same as a human learning). If the companies love subscriptions so much, they should start paying royalties to the creators of the work they use to train their models, and if they don't, then they should be held accountable for it. The fact that they can get away with it is a testament to how much power these companies have, and how little power individual creators have. It's a sad state of affairs, and I hope that changes in the future.

A byproduct of AI is "slop". I personally don't write blogs often because I feel like the slop blogs with keyword soups are going to outrank my content and drown out my niche blogs from potential audiences. Creativity became a commodity; everyone can generate AI art or literature, and people have abused it to make bank, with AI Spotify artists stealing revenue from actual artists, and AI-generated content flooding the internet. It has become a real sad situation for anyone who wanted to make a living off their craft. The value of your art is dictated by the market, and with AI being something that corporations control while dictating your commission fee, then as long as they keep the market flooded with AI-generated content, the value of your art is going to be very low, and you have no control over it. Movie dialogue and lyrics of music sound so "engineered" today; there are definitely people cutting corners with AI (maybe due to how predatory the industry already was with time/$ trade-offs), but it has become a real problem. Not really sure how that changes.

Also, I guess we will never have cheap consumer-grade hardware thanks to AI hogging all the resources, and the fact that the companies building these models are also the ones building the hardware to run them. They have no incentive to make it affordable for the average consumer because they can just sell you a subscription to their cloud service to run the models on, which is a win for them, but a loss for us. The fact that they can get away with it is a testament to how much power these companies have, and how little power individual consumers have. I'm looking forward to seeing homebrew solutions come up (they won't match, but they're worth exploring).

My Current Perspective and Habits with AI

Like I've said earlier, I'm happy that engineers are adopting better practices like documentation, testing, and code reviews as a result of AI, and stack switches for people feel less daunting. Learning a new language or framework with AI is a lot easier (AI can solve all your npm errors; also, stop using npm). If you can build self-discipline around it, it can be a great tool to have in your arsenal, but I also think it's important to recognize the potential downsides and pitfalls of relying too heavily on AI, and to develop habits that allow you to use it sustainably and effectively.

How I use AI for work and personal projects

At work I have a Copilot license, so most of my focus is on using the right model for the right job. Big ADRs go through Claude Opus for planning and proposals, and then are broken down into smaller tasks by complexity and ordered by priority and business value. Depending on the kind of task, I have my Agent.md updated and the model selected with the right expectations on what needs to be done, how, and how it is to be validated. For everything the AI does, I have it generate an artifact that I can review—whether it's a PR, a design doc, a test plan, or a piece of code, I review it and make sure it meets the requirements and standards before merging or deploying it. For personal projects, I use AI more for brainstorming and prototyping, and less for actual implementation; I want to keep my skills sharp and not become too reliant on AI for the fun parts of coding. So I usually have a smaller model like Haiku 4.5 or GPT-4o for most codemods, and I can rely on slightly larger models for planning (planning is less token-intensive than implementation, so you can get away with a large model for planning and a smaller one for implementation, which is more cost-effective).

If I were to break down my workflow at work, it would be:

• Source stories and requirements (from PMs, BAs, customers, etc.), run them through a model that is native to the source (Rovo on Jira, Office Copilot on Word/Excel), export them to a markdown file, and push it to my repo under the docs/planning directory.
• Review generated markdown and add additional context manually with Copilot Code Generation active (it has repo context, so its inline suggestions are handy for fleshing out the details and filling in the blanks, but I still have to do the thinking and structuring, so I stay in touch with the requirements and have a rough idea of how the solution is going to look like).
• Get a planner model involved (Claude Opus) to help me break down the tasks, and get a rough estimate of the complexity and priority. I also have it generate a test plan for the ADR, which I can review and modify as needed.
• Manually review the plan, make changes with Copilot Code Generation active, and then create the necessary stories in Jira, and link them to the original markdown file for traceability.
• Depending on what's going, I also get Lucid's AI involved to help me with diagrams and flowcharts for the ADR, which I can then export to the docs/planning directory for future reference. These are usually fed by either mermaid or ASCII diagrams that I generate in the first phase within my markdown artifacts.
• For implementation, I use a mid-sized model like Sonnet and switch to Opus depending on task complexity (someone needs to come up with a harness where I can tag tasks by model and an agent loop executes it as such—now that's how you lose even more agency).
• Pay close attention to the reasoning text generated by the AI as it goes about executing your tasks. This is where you can catch any potential issues or misunderstandings early on, and correct them before they become bigger problems down the line. Luckily, most tools let you cut-in and steer the conversation in the right direction, so you can maintain a good level of control over the output. This also saves you time when reviewing the outputs since you followed the AI as it was generating the code; you have a good idea of what to expect and where to look for potential issues, rather than being surprised by a large PR that you have to read through carefully to understand what it does.
• Once the code is generated, I review it, run tests, and make sure it meets the requirements and standards before merging or deploying it.
• Export a summary of the work done, the reasoning behind it, and any potential follow-ups or improvements that can be made in the future, and share it with the team for visibility and knowledge sharing. I like to include this in a PR summary or a follow-up comment in the original markdown file; this way it stays connected to the original requirements and can be easily referenced in the future.

My Tooling Specs: Inside the Agent.md Framework

To prevent the agent from running completely off the rails and racking up massive token costs, I enforce an explicit system contract in every workspace via an Agent.md file located at the repository root. Most modern developer tools respect this file as instructions for the agent loop. It functions as a set of rules that forces the AI to check its ego before altering the codebase.

Here is the general layout of the framework I use:

# Agent Workflow Contract

## Role & Context
You are an expert developer with deep context over this specific repository architecture. Your target language runtime is [Go/TypeScript/Nix] and you must respect local design choices.

## Execution Rules
1. Plan First: Before modifying ANY file, write out your intended plan of action in a concise summary. Wait for user confirmation if the change touches more than 2 files.
2. State Assumptions: Explicitly list your assumptions about existing database schemas or helper utilities before writing logic.
3. Reasoning Trace: Maintain an explicit, readable chain-of-thought during agent execution loop steps.

## Quality Standards
- No placeholder comments (e.g., "TODO: implement later"). Write the actual implementation.
- Every functional change requires a corresponding update or new addition to the test suites.
- Do not add external third-party dependencies unless explicitly requested.

By constraining the model to this structure, I effectively eliminate "blind merges." The AI is forced to expose its logic before it writes a line of code, saving me hours of audit overhead.

Also, something I've loved doing with AI is handing it CVEs from tools like Snyk (they let you export the CVE related context (what, where and why) into something like a CSV, that is perfect for AI to consume) and just letting it generate the necessary code changes to fix them. This is a great way to keep your dependencies up-to-date and secure without having to spend a lot of time researching the fixes yourself, and it also helps you learn about the vulnerabilities and how to fix them, which is a nice bonus. If your code is well covered with tests, you can be more confident about the fixes that AI generates, since you can quickly run the tests to validate that the fix works and doesn't break anything else. In this scenario, I genuinely think AI makes you a more competent engineer, because you are forced to adopt best practices, otherwise managing AI outputs effectively becomes a chore and you could very well be shipping AI slop.

Please, please come up with an AI charter of sorts for your team, so that everyone is on the same page with how AI-work is to be used, validated, and reviewed. You can be disciplined about it, but if your coworkers fall into negative habits, it'll soon affect your work and your sanity, so it's better to set some ground rules and expectations early on, and have a shared understanding of how to use AI effectively and sustainably.

Also I'd like to emphasize the point that 100% code-coverage isn't a silver bullet, tests are limited at the end of the day by your understanding of the product and the edge cases you've encountered, so you have to be mindful about what you're testing and how you're testing it. You can have 100% code coverage and still ship a broken product if your tests don't cover the right scenarios, so it's important to have a good understanding of the product and the edge cases that are likely to occur in production. This is where AI can help you, but it can't replace your understanding of the product and the edge cases that are likely to occur in production. So chasing 100% code coverage with AI may be easier, but it's not going to give you what you're looking for, your expectations with AI have to be realistic and grounded, it is a force multiplier in the right hand (nullifier in the wrong set of hands), but you can't put in 0 and expect to get 100 out of it, and you've to check if the "100" is actually spelled out right, given AI, it could've very well been a "001" (good thing modern day AI isn't this bad, or is it?).

AI is not a substitute for your own understanding of the codebase, and you should always review the code that it generates, and make sure that it meets your standards and expectations. You should also be mindful of the token costs associated with using AI, and make sure that you are using it effectively and efficiently. Just because it works today on the simpler stuff, doesn't mean it will work tomorrow on the more complex stuff, and you should always be prepared to fall back to your own understanding of the codebase and your own problem-solving skills when needed. I've often seen engineers gain a false sense of security or competency with AI, it's a new kind of impostor syndrome I guess, you feel like you are growing, but you then realize that you are just getting better at prompting, and not actually improving your own skills, which can be a dangerous trap to fall into. It's important to strike a balance between using AI as a tool to enhance your productivity and creativity, and maintaining your own skills and understanding of the codebase.

An unlimited token budget is only good until the prices start skyrocketing (already happening, insert frog in a boiling pot), so be mindful about the models you use, the configurations (thinking level, context size), learn how to prompt effectively, learn when sessions need to be reset, when you need to move into a new session, and when the context of the sessions is worth compacting and proceeding.

For personal projects, my workflow is a bit more relaxed:

• I usually have my ideas in the notes app on iOS or Obsidian, both of which export to markdown. I quickly review and clean them up with Copilot and then put them in the docs/planning directory. Diagrams are usually Mermaid or ASCII depending on what I need (mermaid is nice but rendering it in the terminal is a pain, so I usually use ASCII for that as a NeoVim user).
• Update the Agent.md with the right model and expectations, and then let the AI generate a plan for me. I review it and modify it as needed, but I don't create stories in Jira or anything, I just keep track of it in the markdown file. The tasks being native to a repo are useful for AI, and I can skip the token costs of some fancy MCP to supply my stories from Jira to the AI.
• Haiku and Sonnet for most implementations, and I hand-code the fun parts with a mix of autocomplete and just doing it myself. This helps me also enjoy the process, because the joy of programming is in the problem-solving and the creativity, and if I let AI do all the work, I might as well just go watch a movie or something, which is not what I want to do with my free time.
• Finally, I have AI generate logs for what it's done and I add my notes on what's next.

Both workflows are similar, and yet the budget differences between a corporate license and a personal one make you more mindful with AI. IMO, if you use smaller models, you will have more agency in the process since you will have to be more involved (again, this may not be for you in light of your productivity expectations and the nature of your work), but it also helps you stay in touch with the code and not lose your skills. It also helps you avoid the "prompt gambling" thing where you hope the AI gets it right, because with a smaller model, you have to be more specific and involved in the process, which can lead to better outcomes and a more sustainable use of AI. Larger models cover a lot more ground with their changes due to their better understanding of context and better reasoning capabilities, but they can also lead to more "slop" if not used carefully, so it's a trade-off that you have to manage based on your needs and preferences. This also means after each iteration, you have that much more code to review, so you have to be mindful about that as well. There's a good argument to be had about how modular your codebase should be so that you can batch your AI changes in a way that is more manageable and reviewable, but that's a topic for another day.

Some Personal Anecdotes

Over time, I can think of a couple of instances where AI truly felt like a superpower and wowed me, so I wanted to share those here to illustrate the potential of AI when used effectively and sustainably:

• This whole blog (the site, not the content you're reading) and my portfolio website were rebuilt with the help of Sonnet and Haiku 4.5. I provided samples of how I wanted the TUI design to look like by copy-pasting the ASCII elements and letting the AI come up with React components for them (there's nothing I hate more than writing CSS, and Tailwind doesn't get me that much more excited about it despite being much more palatable). I just hacked on the logic and the styling to get it to where I wanted. It was a great way to get a project off the ground quickly, and I learned a lot in the process. I also had fun with it, which is what matters at the end of the day. It took me about 2 days and ~30 premium requests on my Copilot subscription (before this credit-based monstrosity took over).
• My dotfiles were handwritten, but with all the on-the-fly edits over time, they got super dirty and inflexible. I don't like spending too much time fixing my config and just want to get work done, which was why I chose NixOS over Arch (you can read more about my setup and approach with new tooling here). So I had AI help me clean up my nix files better and come up with a common pattern for adding new packages that worked across macOS and Linux, along with custom dev shells, and I've since turned that into a lighter flavor that I use for work as well. Since I update my system infrequently now, there's a good amount of broken packages, and agents resolve the issues easily (just make sure you prohibit them from making any changes outside of the config files, since you don't want them to mess with your system without you knowing).
• I also had AI figure out a way to generate tex files based on the JSON used by React components to show the contents of my portfolio, so that a LaTeX resume could be generated in one go. This was a super cool project that got me well acquainted with how LaTeX as a whole works, and not having to fight PDF-generation code was a bonus.

I'm currently building a bunch of long-abandoned personal projects with AI while enjoying the process. It isn't as quick as it is at work, but I'm doing justice to the hobby part of it, and I'm learning a lot in the process. I also have a couple of ideas for new projects that I want to explore, and I'm excited to see where they go. AI definitely has that potential; all you need is the discipline to use it effectively and sustainably, and the curiosity to explore new ideas and learn new things. That balance is tough, and it can keep shifting as you get occupied with work and life, but if you can maintain that balance, you'll be able to get the most out of AI without losing your skills or your creativity.

On that note, I want to end this blog here with a quote from Tony Stark in Spider-Man: Homecoming, "If you're nothing without the suit, then you shouldn't have it." If you don't think you could do the tasks AI is doing for you without it, then you shouldn't be using it, because it'll only build a false sense of competency. The engineers who will survive the AI bubble are the ones who know what they're doing, and the ones who can actually understand and fix AI slop later when vibe-coded apps crash our economy and "trad coders" become the new COBOL devs with 401Ks for annual salaries instead of pensions. The future is bright, and I hope you enjoy the ride as much as I do, and that you can find a way to use AI effectively and sustainably in your work and life.

Also, with how pricing is going and the whole "x model banned outside the US" thing, AI access may not be as ubiquitous in the near term as it is today, so you may have to invest in your personal skills before the rug gets pulled out from under you. Local models are great, but the hardware requirements for SOTA-class models are beyond what any of us have access to, unless you were mining Bitcoin in 2024 and have a warehouse full of GPUs. So it's better to be prepared and not rely too heavily on AI for your work, because you never know when it might become unavailable or unaffordable. I don't want to be too pessimistic or optimistic—neither is good—but investing in your skills and maintaining a good understanding of the fundamentals of programming and software development is always a good idea, because those skills will always be in demand regardless of how AI evolves, and they'll also help you use AI more effectively and sustainably when you do have access to it.

Here are my key takeaways from my journey with AI and the habits I've developed to use it sustainably and effectively:

• Use the right model for the right job, and be mindful of the token costs.
• Adopt clean coding practices like documentation, testing, and code reviews to manage AI outputs effectively.
• Work on your language and expression. You need to be able to explain your problems and requirements clearly to the AI so that it can generate the right code for you, and that also means you need to have a good understanding of the problem domain and the product you're building, because that will help you communicate better with the AI and get better results. Invest in prompt engineering.
• Keep your foundational skills sharp, keep learning, be well acquainted with everything you work on today, and own what you ship.
• Set up a learning plan for yourself to explore new ideas and technologies, and use AI as a tool to help you learn and grow, not as a crutch to do all the work for you.

An exercise I'd recommend as a parting lesson: Write code without AI every once in a while, just for fun, to keep your skills sharp and to enjoy the process of coding without any distractions or dependencies. Go home today (unless you're home right now) and disable your AI tools and try to build something small. It can be anything: a simple script, a small web app, a game, whatever you like. Just try to do it without AI and see how it feels. You might be surprised by how much you enjoy it and how much you learn from it. Just use docs and Stack Overflow like we used to, and see how it feels to be back in the good old days of programming. It can be a nice trip down memory lane, and it can also help you appreciate the tools you have today even more, and it can also help you find a good balance between using AI and doing things yourself, which is what this whole blog is about.