ublo
bogdan's (micro)blog

bogdan » the AI-assisted finish line

12:50 am on Feb 20, 2026 | read the article | tags: buggy

i like building things.

that’s probably why i ended up in software development. there is something addictive in watching an idea go from a vague shape in your head to something you can click, run, deploy. something other people can use. something that scales beyond you.

i also like building physical objects. robots. embedded toys. but software has immediacy. you push a commit and the thing exists. you deploy and suddenly a thousand people touch what was, yesterday, just a thought.

in the last years, moving into machine learning operations amplified that feeling. end-to-end systems. messy data. pipelines. monitoring. feedback loops. systems that need to be thought through from user interaction to infrastructure and back. the problems became more interesting. the connections more diverse. the architecture more consequential.

and then ai tools entered the room.

for a long time, i was skeptical. i organized workshops warning about over-reliance. i repeated the usual mantra: tools are immature. you’ll lose your engineering instincts. we’re not there yet. two years later, i changed my mind. not because the tools magically became perfect. they didn’t. they improved, yes. but the real shift was in how i use them.

my two goals are simple:

• always learn
• build something useful

for a long time, learning dominated. i loved solving complex problems, reading papers, experimenting with architectures. but once the core challenge was solved, i would lose interest. polishing. finishing. documentation. usability. those felt… secondary. i would build something “good enough for me” and jump to the next idea.

friends were right. i wasn’t good at finishing.

ai changed that. it didn’t remove the complexity. it removed the friction between “interesting” and “done.” it gave me a way to move ideas closer to the finish line without sacrificing control or curiosity.

this is the flow that works for me.

step 1: start with the story

i begin with the usage flow. i write it as a story. who is the user? what do they click? what do they see? what frustrates them? what delights them?

then i move to architecture. components. communication. languages. libraries. third-party services. constraints. trade-offs.

when i feel i’ve exhausted my own ideas, i paste everything into ChatGPT and ask a simple question:

what do you think of my idea?

sometimes i add a role:

you’re a principal engineer at Meta or Google. you have to pitch this for funding. what would you change? be thorough. avoid positivity bias.

this conversation can last days. i let ideas sit. i argue. i refine. i adjust. the goal is not validation. it’s pressure testing.

step 2: distill into artifacts

once we converge, i ask the same conversation to generate three files:

• README.md: what this project is and why it exists
• TODO.md: a detailed mvp plan
• PREAMBLE.md: raw idea, user flow, glossary

these files become the contract between me and the machine. they encode intent. they anchor context. they define language. this is where control starts to crystallize.

step 3: small, controlled execution

i initialize an empty repository and move to implementation.

i use GitHub Copilot in agent mode with Claude Sonnet. not the biggest model. not the most expensive one.

why?

because constraints force clarity. large models drift. they summarize. they hallucinate structure when context windows overflow. they make a mess if you ask for too much at once.

so i ask for phase 0. just the structure. folder layout. initial configs. i review every change. every command. i interrupt. i correct. i add guidelines.

i learn. this is important. i don’t want a black box generating a finished cathedral. i want scaffolding that i understand and shape.

step 4: iterate, don’t delegate

each phase is a new session.

help me implement phase X from TODO.md. ask if anything is unclear.

this sentence is critical.

it keeps the implementation aligned with intent. it forces clarification instead of assumption. it keeps me in the loop.

i also learned something practical: avoid summarizing context. once the model starts compressing its own reasoning, quality drops. so i keep tasks small. coherent. atomic. each within its own session.

iteration beats ambition.

step 5: automated code review cycles

after a few phases, i open a new session with a more powerful model.

review the entire codebase. write issues in CODE_REVIEW.md. do not fix anything.

i insist on not fixing. analysis and execution should be separated. once the review is written, i switch back to a smaller model and address 3-5 issues at a time. new session for each batch.

usually i do 2-3 full review cycles. then i return to the original review session and say: i addressed the items. review again.

keeping review context stable produces surprisingly coherent feedback. bigger context windows help here. not for writing code. for holding the mental map.

step 6: manual realignment

after the automated cycles, i step in. i read the code. i check for drift between the original idea and what actually exists. i write a REALIGNMENT.md with my observations. architectural inconsistencies. naming confusion. misplaced abstractions. subtle deviations from the user story.

then i ask a powerful model to:

• read REALIGNMENT.md
• read the code
• ask me clarifying questions

we discuss.

only after that do i ask it to update TODO.md with a realignment plan. this becomes the new base. the new iteration cycle. if the discussion gets heated, i switch back to ChatGPT for research, broader context, alternative patterns.

learning doesn’t stop.

control, not surrender

many people fear that using ai tools erodes engineering skill. for me, the opposite happened.

this flow forces me to:

• articulate ideas clearly
• reason about architecture before touching code
• separate analysis from implementation
• review systematically
• think in phases
• measure drift

it’s not autopilot. it’s structured acceleration.

i don’t lose control over what is produced. i gain leverage over the boring parts while keeping the intellectual ownership.

and maybe the most important thing: i finish.

projects that would have stalled at 60% now reach usable state. not perfect. not over-engineered. but usable. deployable. testable.

that shift alone changed my relationship with building.

towards paradise

i used to chase complexity. now i chase completion.

not because it’s easy. but because it organizes and measures my energies better than any half-finished prototype ever did.

ai didn’t replace engineering. it amplified intentional engineering.

and for someone who loves building end-to-end systems, who wants to learn while shipping, who wants both curiosity and utility, this feels close to paradise.