I build a lot of projects. Full stacks, dashboards, demos, WebGPU stuff, AWS deployments, Docker setups, GitHub Actions pipelines, authentication flows, routing, UI components, all of it. On paper it looks like I am some senior engineer cranking out production apps. I am not. What I am is someone who learned how to use AI extremely well, who understands enough about web development to steer a project, and who has built so many things that the repetition turned into a weird practical skillset. This is how I actually build things end to end with my current knowledge. No hype. No fake humility. Just what really happens.
Where My Knowledge Actually Sits
I have a B.S. in Web Development from Full Sail University. That program moves fast, one class a month and then it is gone. We switched topics constantly and you do not really get the luxury of living inside one subject long enough for everything to sink in.
What I got from school was basic HTML, CSS, and JavaScript, some React, some Python and SQL, some UX and layout fundamentals, some cloud concepts, some testing ideas. Enough to not be lost, but not enough to feel like a classic engineer.
On the flip side, things I do not have include any real data structures background, no algorithms training, no serious math foundation, no whiteboard experience, and I absolutely cannot sit down and write a full solution from a blank file with no references.
What I can do is read JavaScript, React, HTML, CSS, and Python code and understand what it is doing, follow how a full stack app behaves once it exists, describe exactly what I want in plain language, steer AI toward what I am actually trying to build, debug broken systems until they behave, and deploy almost anything if you give me time, logs, and a terminal.
My AWS internship helped a lot because it made me comfortable with AWS consoles, the CLI, EC2, S3, RDS, IAM basics, CloudWatch dashboards and alarms, and runbooks and troubleshooting workflows. It did not turn me into a principal cloud engineer, but AWS stopped feeling like some sacred scary thing and turned into a normal toolbox. That is my actual starting point. Everything else comes from building and breaking things in public.
How I Start Projects (Even When I Don’t Know Enough)
Most real engineers can open an empty folder, run npm init, and start coding from their head. I cannot. So I start in a different way.
I describe the project like I am talking to a friend. I do not open with architecture or design patterns. I open with vibes and behavior.
My first messages to AI look like:
“I want a full stack app where users can sign up, log in, and post stuff to a feed,”
“I want a clean WebGPU page that renders a triangle and maybe a cube I can flip between,”
“I want a simple Node backend that handles authentication and a React front end that consumes it,”
“I want a static portfolio with a blog and project cards that link to my real work.”
I never start with words like microservices or hexagonal architecture. I talk like a normal person and AI fills in the technical details. I correct it if it goes too wild. The point is that I anchor the idea in behavior, not implementation.
After the idea is clear, I let AI propose the first structure. I ask things like “show me the folder structure you would use for this,” or “where would you put pages, components, API routes, and config,” or “which files should I create first.” AI gives me a tree. Sometimes it's bloated and sometimes it’s too minimal. I tweak it until it feels like something I can actually navigate. I am not optimizing for textbook best practices. I am optimizing for “will my brain understand this when I come back in three days.”
Then I ask for the first file instead of the whole app. I never say “write the full app.” I say things like “give me the entry file and a single route that returns hello world,” or “give me a React page that renders a placeholder layout,” or “give me the WebGPU init function that just clears the screen to a color.”
Then I paste it in, install dependencies, and try to run it. It almost never works the first time. That is fine. I send AI the error and we start the real work.
From there I let the project teach me what it needs next. If I need authentication, I ask for that. If I need a Dockerfile, I ask for that. If I need a GitHub Actions workflow, I ask for that. If the layout is ugly, I fix it. I do not sit down and architect everything up front. I build until there is friction and then I deal with the friction. The system slowly reveals its shape over time. I do not architect from theory. I architect from pain and repetition.
Where AI Helps and Where It Breaks Everything
AI is basically my pair programmer, except it has no idea where any of the files really live and it lies sometimes.
It is good at generating boilerplate quickly, filling in syntax I cannot remember, wiring up simple React components, writing repetitive CRUD routes, creating example tests once I describe what needs to be tested, translating my plain language idea into a first-pass implementation, and even giving me rough AWS diagrams or CloudFormation ideas based on a description.
But it is terrible at remembering my exact file paths, sticking to one pattern instead of switching styles mid project, generating security-safe code unless I constantly force it to, not hallucinating older versions of APIs or tools, randomly inventing config options that do not exist, messing with service workers and caches without warning, and it absolutely cannot handle WebGPU unless I spoon-feed it context from my own files.
My workflow always ends up looking like this:
I ask for a piece of code, AI gives me version one, I run it, something breaks, I paste the error back, AI adjusts, I run it again, something else breaks or behaves weird, and this repeats until it finally works.
People on social media love to claim “AI is doing everything,” but that completely ignores the part where I am the one deciding when the answer is nonsense, gluing all the pieces together, tracking the overall shape, dealing with the real world behavior, and connecting project to deploy instead of just code to code. AI is the engine. I am the driver and the mechanic.
What I Bring That AI Cannot
There is a lot AI cannot see and cannot touch, and that is where I come in.
My biggest strength is that I understand the system once it exists. I can read through a codebase, trace a request from entry to response, follow state through the frontend, understand what the API is doing, understand where the data goes, and make sense of how the folders and files map to the mental model of the app.
I debug in the real environment, which AI cannot do. I open DevTools, inspect the network tab, check request and response bodies, read console logs, tail logs in Docker, look at GitHub Actions logs and artifacts, curl endpoints and diff them against local, inspect service workers, clear caches, and poke at CDN behavior. AI only sees what I paste in. I see absolutely everything.
I also make the real decisions. AI does not know that I am deploying to GitHub Pages or that I want a static export instead of server rendering or that I want to keep the stack simple instead of over engineered. I know what I am aiming for. That means I choose when to flatten the file structure, when to split a file, when something needs Docker, when to keep state management simple, when to use Next.js versus plain React, and what makes the project maintainable for me. AI outputs code, but I define the boundaries and the shape.
And when it comes time to actually ship a project, AI is nowhere near helpful. AI cannot log into AWS. AI cannot configure IAM. AI cannot fix DNS. AI cannot deal with real SSL errors. I am the one setting environment variables, mapping domains, fixing path issues in static exports, clearing stale caches and stuck service workers, and rerunning builds. Deployment is not “hit the AI button.” Deployment is me in a terminal, a dashboard, and a browser making everything behave.
What the AWS Internship Changed For Me
The AWS internship changed a lot for me because it showed me that I can survive in real technical environments.
I got two certifications, AWS Solutions Architect Associate and AWS AI Practitioner, during a 12-week internship window, both passed by week 7 without AI. It was real studying and real labs.
That gave me comfort navigating AWS consoles and docs, understanding alarms, runbooks, and escalation paths, and familiarity with EC2, S3, RDS, IAM, and CloudWatch in actual workflows. I got a sense of what “normal” looks like when systems are healthy and how big companies design reference architectures.
When you mix that with my AI-heavy building style, you get a weird combination where AI writes a lot of code, my AWS background keeps me from being scared of the infrastructure, and my debugging brain glues it all together. I am not walking around acting like a principal architect, but I am also not lost when someone says “we need to deploy this to AWS.”
The Real Cycle Behind Every Project I Build
If you zoom out and look at every project I do, the pattern is simple even if it is messy.
I describe what I want in plain language, AI gives me a structure and some starter files, I wire it up and try to run it, it fails, I debug with AI and my own eyes, it eventually works locally, I set up a build and deploy target, the deploy fails in some new way, I debug that using logs and DevTools and trial and error, it finally works in production, I polish the UI and text so it looks intentional, I document it enough that people can understand what it does, and then I move on to the next idea.
There is no magic. Just a lot of cycles.
I Don’t Start With Structure — I Grow Into It
I do not start with structure the way traditional engineers do. I grow into it. I start with how the product should feel and a couple behaviors I care about, and then I let the system evolve until the structure becomes obvious.
The project keeps telling me when a page is doing too much, when logic is duplicated, when a folder is chaotic, or when a route belongs somewhere else.
Structure is not planned up front. It emerges from friction. Pain is the signal.
If something is hard to find, I move it.
If something breaks too often, I isolate it.
If something is confusing to name, I rethink what it actually is.
It is slower and messier than perfect architecture, but it fits how my brain works.
Debugging Is the Education
Debugging is not a side effect for me. It is the education.
I do not learn by memorizing theory. I learn because something breaks. A runtime error, a layout issue, a failed deploy, a permissions problem, a cache bug, undefined data, missing files, broken WebGPU behavior — these are what force me to form real understanding.
When something is broken, suddenly I have an actual question to chase.
Why is this undefined here but not there?
Why is this page loading old assets?
Why does this route work locally but 404 in production?
Why does this WebGPU demo run on Chrome but not Safari?
Chasing these questions is what makes knowledge stick.
How My Background Shapes This Whole Approach
My background as a medic in the 82nd Airborne plays into this too.
In that world you rarely get perfect information. You get symptoms, pressure, and a small window to act. You stabilize, triage, move, reassess, and repeat.
Web projects obviously are not life or death, but the mindset carries over. I do not freeze because I don’t know everything. I move based on what I can see: logs, browser errors, CLI output, network behavior, AWS console states, and feedback from the environment.
AI works extremely well in this loop because it gives me something to react to fast. I take that and push the system forward.
What This All Adds Up To
All of this, when you strip away the noise, adds up to real skills.
I have practical literacy in modern web stacks.
I can read and understand code I did not write.
I know how to steer AI toward working systems instead of random snippets.
I have real debugging experience from real deployments.
I have enough AWS experience to not drown in cloud workflows.
I am comfortable with containers, pipelines, and static hosting.
And I have shipped a lot of projects that prove I am not just talking.
Things I do not have include low-level systems programming knowledge, advanced algorithms, leetcode skills, or the ability to write everything from scratch without leaning on tools.
What I do have is the ability to build real working systems — systems people can click on, systems that deploy cleanly, systems that are understandable, systems that
behave.
If a company wants deep algorithmic knowledge, hardcore math, systems programming, or whiteboard-from-scratch engineering, that is not me.
But if a company wants someone who can work inside an existing stack, understand the codebase, use AI as a multiplier, ship features end to end with support, debug weird real world behavior, and actually deploy things users can touch, that is where I fit.
Final Thoughts
AI is how I write a lot of my code. Debugging is how I learn. My AWS internship and my degree gave me enough of a foundation to not drown. My projects are where everything actually came together.
I am not a textbook software engineer. I am a practical builder who uses AI heavily, learns through friction, and ships things anyway.
You do not need perfect background or deep theory to build real systems. You need a problem, a tool, a feedback loop, and enough stubbornness to keep going until the thing in your head exists in the browser.
That is how I work right now. Honestly.
Top comments (0)