Much like our diets, the content that consumes our attention on has an effect on our health. The tools and environments we work with affect our thinking patterns, and the way we approach our solutions. Some tools, like auto-complete frameworks and generative AI, give us an instant gratification akin to a sweet treat. Let's look for some signs of an unbalanced workflow, and some exercises to protect our biome of agency and metabolization of information.

I recall a conversation with a senior developer who expressed disappointment when setting up a junior developer's machine. After a full morning of machine setup and project introduction, their first question was: "How do I install co-pilot?"

One course I designed had students build their own content-management projects over several weeks. In the planning phase, many students would present their shiny figmas, but with grey obfuscated boxes and lorem ipsum text where the dynamic content would actually go. In the worst case, the wireframe was entirely hallucinated by an image generator. As part of feedback, we sketched up some wireframes using the well-known effective strategy of pencil and paper, which brought a lot of clarity and alignment back into the planning process.

Here are some warning signs of an unbalanced workflow:

- Avoiding original text and sources in favor of summaries

- Prompting, then prompting again within a few seconds

- Excessively perusing framework options / packages / plugins

- Using predictive text to continue your chain of thought

There is a common danger here: letting the tool do the thinking for you. In my opinion, if you are relying on a hammer to tell you which nails to hit, there may be an inversion of relationship between tool and builder. Many developers live in fear of AI replacing their value. I believe that it will only if you allow it.

There is a new generation of builders who have yet to experience the luxury / pain of sitting with a frustrating bug for hours, only with the council of their trusty rubber duck. Time spent problem solving is never wasted. Building doesn't always show up with what you produce, sometimes the active process is building yourself. The value of frustration while building deserves its own piece.

I believe there will be a growing demand for teams and graduates to 'un-learn' AI dependency. If that sounds like your team, here is a exercise you can try as a team, or individually:

- Look for a simple coding challenge. "Simple" is relative, but ideally something that wouldn't take longer than half an hour using whatever tools you have at your disposal. Here are some fun challenges I've been a fan of.

- Once you have chosen your problem, try to get as far as you can with a basic text editor, paper, and/or whiteboard.

- For project leads, describe what the problem is in the form of an email. For developers, describe what your solution is in the form of a function comment.

- Write our what your solution will look like with pencil and paper, or as a whiteboard sketch. How do you convey information to your user? What are you asking them to do? How long do you estimate your solution to take?

- For application developers, see if you can wire-together components (front-end, server, database) without any libraries.

- Write an email summary of how your solution works, ideally by including some test functionality and or demonstration.

- If there is a bug, work through the bug together by documenting the expected result and the observed result.

It can be painful at first to try and build something without any external suggestions of what line to write next, organizing your strategy into broad goals, or tracing through debugging and challenging your assumptions. That's the point of the exercise! If you have a team leader observing, or as part of self-reflection, take notes of which areas you struggled with and why.

An exercise like this may be harder for some than others. While working through the Micromasters of Statistics and Data Science, nearly all of my code experiments and tests have been written in the terminal and nano, and my first instinct when building hobby projects is involves vanilla JS + PHP + MySQL without the use of frameworks. I don't do this as any kind of personal challenge or flex, but its how I'm used to working.

You may be thinking that these techniques are a waste of efforts, and that I'm being obtuse to the new era of AI-driven development. I don't have any issue with the use of AI, and I think incorporating it into the modern workday is inevitable. The exercises put us back into the driver's seat, so that we can approach our tools with a re-grounded sense of agency and intention.

Working without frameworks will make it easier to pick up on the patterns that the frameworks suggest to you. It is much easier to adopt a solution when you understand the types of problems the frameworks try to solve. When I document my work, it makes it easier to summarize my thoughts and approaches. Those skills can be applied to effective prompting as well. When I work through a situation and plan the actions I will take, it allows me to more comprehensively evaluate strategies that are placed before me.

If your team is interested a fun, empowering workshop exercise, feel free to reach out!

 Candy photo by Sebbi Strauch. Modified by Christine Bittle

This writing was last updated Oct 27, 2025. It is part of a larger series of reflections, and how they continue to shape my journey as a builder and educator. It is also an effort to bring humanity back into the online world. No AI was used in this piece.